All posts by Bozho

Земетресението в Лисабон, Великден и коронавирусът

Post Syndicated from Bozho original https://blog.bozho.net/blog/3532

През 1755 г. Лисабон е ударен от много силно земетресение – 8.5-9 по скалата на Рихтер.

Земетресението е на 1-ви ноември, денят на вси светии, поради което много хора са в църквите и палят свещи. Свещи се палят и по домовете, за празника.

Заради свещите, градът пламва и ако нещо е останало здраво от силното земетресение, то изгаря.

Хората излизат от църквите и къщите и се струпват на открито пространство в града. За съжаление, епицентърът е в Атлантическия океан и скоро градът е залят от цунами.

Иронията е, че на религиозния празник всичко е опустошено, а кварталът с „червените фенери“ има най-малко щети (просто е на хълм с по-здрави скали).

Земетресението, случило се точно на релгиозния празник, дава тласък на т.нар. теодицея – философското търсене на причините защо Бог позволява да се случват лоши неща (или защо ги предизвиква). Защо въпреки, че жителите на Лисабон са почели светиите, точно на този ден е дошло Божието наказание.

Това дълго въведение е във връзка с предстоящия Великден и рискът от струпване на хора в църквите в ситуация на епидедмия.

Жителите на Лисабон не са знаели, че ги очаква земетресение. Но ние знаем, че струпването на хора носи висок риск от разпространение на вируса.

И всички вярващи, които смятат, че вярата им е достатъчна, за да не се заразят – теодицеята е израз на това, че колкото и да вярваме, лоши неща се случват. Можем да търсим философско обяснение за това, но на първо място трябва да вземем всички земни мерки, които можем, за да ограничим щетите – за себе си и за близките ни.

Целуването на икони и струпването в църквите е опасно. А както и земетресението в Лисабон, заразата няма да ни се размине, само защото сме силно вярващи.

Ще ни подслушва ли МВР през трафичните данни?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3521

Със Закона за извънредното положение депутатите дадоха право на МВР да получава трафични данни без предварителен съдебен контрол за лица, които са нарушили принудителна карантина, наложена от Министъра на здравеопазването, във връзка с вируса. Това предизвика доста реакции и свръхреакции и предупреждения, че с тези правомощия ще започне едно „безконтролно подслушване“. Ще опитам да направя няколко кратки уточнения и след това да опитам да обясня защо въпреки, че злоупотреби са много малко вероятни, текстът в закона е лош.

Не, МВР няма да ни подслушва. В трафичните данни не влизат данни за самите разговори и съобщения, така че това е технически невъзможно. Влизат метаданни – с кого сме говорили, кога, колко дълго, както и към кои клетки сме били вързани, т.е. приблизително какво ни е било местоположението. Ако трябва да сме прецизни, последното не са трафични данни, а данни за местоположение, но и те влизат в обхвата на Закона за електронните съобщения (ЗЕС):

1. проследяване и идентифициране на източника на връзката;
2. идентифициране на направлението на връзката;
3. идентифициране на датата, часа и продължителността на връзката;
4. идентифициране на типа на връзката;
5. идентифициране на крайното електронно съобщително устройство на потребителя или на това, което се представя за негово крайно устройство;
6. установяване на идентификатор на ползваните клетки.

Конкретната мярка, обаче, се отнася само до точка 6 – използваните клетки. Т.е. само проследяване на придвижване.

Не, МВР няма да го прави безконтролно – мярката е предвидена само за случаите, в които е нарушена принудителна карантина. Законът не дава право да се искат данни в други случаи. Това е на теория, на практика ще видим след малко. И не, мярката не е противоконституционна (поне на пръв поглед от човек без опит в тълкуване на конституционни норми), защото в извънредно положение някои конституционни гаранции, вкл. това на неприкосновеност на комуникацията и за защита от следене, отпадат.

Мярката важи само до изтичане на извънредното положение. Но депутатите са искали точно този параграф да важи и по-дълго (до отпадане на нуждата от принудителна карантина). Може би от техническо недоглеждане, а може би нарочно, мярката е по чл. 61 изобщо, т.е. мярката ще остане в сила заради други болести, при които може да се налага карантина. Така че на практика мярката не е временна.

Аз лично смятам, че целта на измененията е приемлива – имаме вече случаи на лица, които са избягали и които са били заразени и това не е окей. Утре ще се качат в автобуса и ще заразят всички.

Смятам обаче, че текстовете не са добри (да не каже мърляви) и създават рискове за злоупотреби. В по-широк контекст, Законът за електронните съобщения има дефицити, които трябва да бъдат поправени не само за рамките на извънредното положение, а по принцип. Никога нещата не са чернобели – никой няма да въведе „безконтролно подслушване“, но това не значи, че определени политически фактори не искат да имат вратичка за набавяне на информация за свои опоненти. И затова задачата по формулиране на тези текстове е трудна.

Дотук добре. Следя измененията (и опитите за такива) в Закона за електронните съобщения отдавна и при тях винаги има конфликт между желанието на органите на реда по-свободно да придобиват информация и желанието на гражданите това да не се случва. Оперативно работещите по престъпления полицаи реално имат нужда от такива данни, за да си свършат работата. Но рядко вземат предвид рисковете, които нормативната уредба създава.

Законът има дълга история, която включва и една отменена европейска директива, но най-важното и интересно – решение на Конституционния съд, което отменя предишни текстове, които въвеждат събирането и достъпа до трафични (и свързани с тях) данни. Решението си струва да се прочете в цялост, защото до голяма степен аргументите важат и за действащите текстове на закона. Цитирам един от най-важните абзаци:

Въведеният с оспорените разпоредби на ЗЕС режим на запазване на данните от телекомуникационния трафик страда от редица други несъвършенства и пороци, които също се оказват несъвместими с конституционната граница на допустимата намеса в сферата на основните права. За да бъде оправдана, нейната материалноправна и процесуалноправна уредба трябва да съдържа ясни, точни и недвусмислени основания и процедури, които да осигуряват достатъчно сериозни и надеждни гаранции, че достъпът на съответните национални органи до запазените данни ще бъде използван само за целите на предотвратяването и разкриването на тежки престъпления и ще обслужва единствено наказателните производства, водени за такива престъпления. Казано с други думи, правната уредба трябва да създава и гарантира сигурност у гражданите, че са изключени всякакви злоупотреби с техните данни както от страна на държавните органи, на които е осигурен достъп до тях, така от търговските дружества (предприятията), предоставящи съответните съобщителни мрежи и услуги, които всъщност ги съхраняват.

И нещо, което на няколко пъти съм предлагал:

На следващо място е необходимо да се констатира, че изобщо липсва уредена със закона правна възможност, а оттам и основания и процедура засегнатите от мерките лица, чиито данни са били предоставени на съответните държавни органи, но не са послужили за образуване на наказателно производство или образуваното е било прекратено, да бъдат уведомени за това кога и на какво основание са били обект на тяхното приложение, както и за какво са били използвани.

От моят гледна точка, и в пълно съгласие с мнението на Конституционния съд, както в действащите текстове, така и в новоприетите, имат два дефицита:

  • Законови гаранции за спазването на процеса – в момента пише, че се води регистър на исканията за трафични данни. В зависимост от това за коя институция става дума, той може да е на тетрадки пръснати из страната (а достъп имат не само МВР – и ДАНС, и прокуратура, и др. Уточнявам, че конкретно за карантината достъп има само МВР, а в другите случаи). Липсва и делегация към наредба, с която да се установи реда за водене на документацията. В т. 2.2 от този доклад (от 2015 г) виждаме, че почти всичко се води „на хартиен носител“ (което значи „тетрадка“). Проследимостта на процеса е много важна и възможността някой да забърше лист от тетрадката или да мине с коректор или изобщо да не впише нещо съществува. Да, в МВР конкретно със заповед на министъра е уреден по-адекватен ред, но това не следва по никакъв начин от закона и както се е появило, може утре да отпадне.
  • Липса на ред за уведомяване – в случаите, когато използваните данни не са довели до повдигнато обвинение, човек не разбира изобщо, че са искали данни за него. А особено в случай на карантина, това е важна защитна мярка. Особено ако се направи умно и може да бъде направена проверка и в мобилния оператор (който също трябва да съхранява някаква документация по въпроса).

„Ама какво толкова може да стане, нали имат процедури“. Да, никой няма да тръгне да ви гледа кога сте ходили на магазина и кога сте говорили с майка си по телефона. Едва ли ще има и мащабни злоупотреби. Само че когато липсват и нормативни, а и технически гаранции, остава да разчитаме на едни вътрешни процеси и на хората, които ги изпълняват. И си представете как утре един министър на вътрешните работи или пък главен прокурор решава, че някой много го дразни и иска да намери нещо, за което да го „хване“ (буквално и преносно). Може или да промени заповедта, която установява сегашния режим, или просто да нареди устно на някого да поиска данни без да ги вписва никъде. Или да впише грешно основание. И да го замаже в тетрадката, за да е нечетливо. И след това няма проверка на документи назад във времето. Или точно за проверката на тези документи някой е пратен в командировка. И други хипотези, звучащи малко вероятни, но възможни.

Онзи ден четох пример за прането пари – в САЩ банките трябва да изпращат до държавата доклад за съмнителни транзакции. И банките са дефинирали такъв вътрешен процес, но служители, участващи в прането на пари, подготвят документите, вкарват копието за банката в архива, а копито за държавата – в коша.

Процесите се изпълняват от хора, а хората имат началници, страхове, слабости. В ситуация на млада демокрация, след тоталитарен режим, без изградени традиции, изкушенията за злоупотреби с най-разнообразни цели, в т.ч. политически, не са малки. Помним делото „Червей“ само от преди няколко години. И ще е грешно да се доверим сляпо на вътрешни процеси в МВР, прокуратурата и службите, които дори не са скрепени с нормативни текстове. Особено когато част от тези институции напоследък демонстрират непризнаване на принципите на правото.

Последният щрих на законодателната немарливост е че новите текстове са сложени в члена, който се отнася за тежките престъпления. Нарушаването на карантината не е тежко престъпление (макар че за малко да го превърнат в такова с увеличаване на наказанията в Наказателния кодекс). Да, режимът на достъп без предварителен съдебен контрол е по този член. Но е въпрос на добра законодателна техника да не смесваш тежки престъпления с нарушаване на карантина, дори режимът да е същият – по-добре би било да има нов член, който препраща към режима по съществуващия.

В заключение – целите на мярката са разбираеми и приемливи. В краткия период е малко вероятно (но не изключено) някой да злоупотреби. За щастие прокуратурата няма достъп до тази процедура, а само МВР. Но дефицитите на самия закон допускат злоупотреби и всяко разширяване на правомощията автоматично страда от тези дефицити. Извънредното законодателство не е нещо, което трябва просто да мине, защото е извънредно – трябва да бъде прецизно. Настоящият състав на Народното събрание за съжаление няма това разбиране на кохерентност на правната рамка и поради това предизвиква скандали. Скандали, които се увеличават допълнително заради липсата на доверие в институциите.

Automating the Change of WordPress Permalinks

Post Syndicated from Bozho original https://techblog.bozho.net/automating-the-change-of-wordpress-permalinks/

WordPress is powering 35% of website. And while it may not be seen as very complex or interesting, it is one of the most prevalent technologies of our time. And many developers, even if they are not working with PHP, have to support some WordPress installation (e.g. a blog like this one). And unfortunately, there are still basic things that you can’t easily do. Plugins do help, but they don’t always have the proper functionality.

Today I had to change permalinks on a website. From https://example.com/post-name to https://example.com/blog/post-name. And WordPress allows that, except there’s a problem – when you change it, the old links stop working (404). Not only that ruins your SEO, any previous share of your post will not work. I’ve pointed that out a long time ago when Spring broke their documentation links. Bottomline: you don’t want that to happen.

Instead, you want to do 301 redirect (and not 302, which appears to also break your SEO). But all tutorials that are easily found online assume you can manually configure redirection through some plugin. But if you have 100-200 posts, that’s a lot of tedious work. There are plugins that allegedly monitor your posts for changes and create the redirects automatically. That may work if you manually edit a post, but it didn’t work for me when changing the permalink format settings.

So how to do it in an automated way and without disrupting your website? You’d need a little bit more than a plugin – namely SQL and Regex. Here are the steps:

  1. Install and activate the Redirection plugin
  2. Open your blog’s hosting admin page and navigate to the PhpMyAdmin to browse your MySQL database. That’s the typical setup. If you are using another database admin tool, you’ll know what to do
  3. Run a query to fetch the post name of all published posts: SELECT post_name FROM `wpgk_posts` where post_type = "post" and post_status = "publish" LIMIT 200 (if you have more than 200 posts, increase the limit; if you don’t put a limit, PhpMyAdmin puts a default one)
  4. Expand the retrieved text (with the big T), select all records with the checkbox below and click “Copy to keyboard”
  5. Paste in Notepad++ (or any regex-supporting text editor, or if you are running Linux, just create a file and then you’ll be able to do regex replaces wit sed)
  6. Replace all tabs that you may have copied (\t)
  7. Then replace (.+) with /$1/,/blog/$1/ (if you are redirecting /postname to /blog/postname, otherwise you have to write the appropriate regex)
  8. Change the permalink format settings
  9. Import the resulting CSV file in the Redirection plugin. It interprets it as: source,target. That way you have redirected all your existing posts to their new permalink (the redirects are created in the chosen group). Note the trailing slash. Just in case, you may repeat the same operation to produce another CSV without the trailing slashes, but the canonical WordPress URL is with the trailing slash.

It feels a bit awkward that such an obvious things that probably happens often would need such a non-trivial set of steps to do automatically. But software, no matter how user-friendly and “no code”, will require knowledge of basic things like SQL and Regex. And maybe that’s good.

The post Automating the Change of WordPress Permalinks appeared first on Bozho's tech blog.

10 дигитални мерки във връзка с коронавируса

Post Syndicated from Bozho original https://blog.bozho.net/blog/3512

Поради извънредното положение във връзка с вируса COVID-19 има много мерки, които могат и трябва да бъдат взети. Те са комплексни – здравни, информационни, нормативни, организационни, технически. Надали има човек, който може да даде с увереност пълен списък от мерки, които трябва или не трябва да се вземат. Информацията и ситуацията се променя често, Световната здравна организация публикува общи препоръки.

Аз нямам претенции да разбирам от епидемиология, затова няма да обяснявам за изправяне на криви, да строя математически модели на заразата. Не съм и икономист, че да изчислявам ефекта върху икономиката на една или друга мярка. Но все пак има област, в която мога да дам препоръки – дигиталната. Тъй като приоритетът на извънредното положение е социално дистанциране, т.е. да се минимизират контактите между хората, информационните технологии предоставят такава възможност, ако бъдат използвани правилно от публичните институции.

Затова предлагам 9 мерки, които институциите могат да предприемат, за да намалят напрежението, за да не спира животът и да не бъдат излагани хора на излишен риск. Повечето мерки не изискват нормативни изменения, а само ясни правила и организация в публичния сектор.

1. Единна информационна точка с въпроси и отговори. В момента МЗ и МВР публикуват информация на сайтовете си, но тя е или „ето ви една колекция от заповеди, четете“ или откъслечна и трудно проследима във времето. Националният щаб няма сайт. Нужно е да има единна информационна точка, към която всички сайтове на институции, включително на Министерския съвет, да водят. На нея да има актуална информация, както и лесна за ориентиране секция с въпроси и отговори. На едно място, а не препращаща към сайтове на Външно, на МЗ и т.н. Въпроси като „трябва ли да си затворя търговския обект“ (с възможност за избор на типа дейност и динамичен отговор), какво да правя ако се прибирам от чужбина, къде да отида ако имам симптоми, какви са симптомите на вируса, как да използвам електронни услуги и т.н. Може и е редно да бъде добавен и брояч за наличните и използваните тестове за вируса, тъй като това е основен инструмент за контролиране на епидемията. В момента са направени прекалено малко тестове и реално нямаме добра картина върху разпространението.ю

2. Задължително използване на електронно връчване от всички администрации, без нужда от квалифициран електронен подпис – Държавна агенция „Електронно управление“ поддържа система за електронно връчване, през която може по сигурен начин да се обменят документи между гражданите и бизнеса от една страна и администрацията от друга. Той в момента е достъпен само с Квалифициран електронен подпис (за щастие доставчиците на облачни подписи ги пуснаха безплатно за периода на извънредното положение), но трябва и ПИК на НАП да бъде интегриран там спешно. При връчването не трябва да се изисква подпис на самите документи, тъй като те са подадени през система след успешна идентификация (в духа на чл. 22, ал. 5 от Закона за електронното управление).

3. Въвеждане на електронна рецепта. В момента ходенето на лекар е непрепоръчително и затруднено, но хората не спират да боледуват от други неща, само защото има вирус. Аптеките пък не могат да продават лекарства без рецепта (а ако го правят – ги затварят). Този параграф 22 може да бъде решен с някаква форма на електронна рецепта. На пръв поглед изглежда, че задача, която не е решена десетилетия, не може да се реши за 10 дни. Но една базова система, в която лекарите влизат с предварително раздадени данни за достъп и описват какво изписват, като го свързват с ЕГН-то на пациента. След това в аптеката (с използване на предварително получени данни за достъп) проверяват, през компютър или смартфон, ЕГН-то на клиента и ако има издадена рецепта, му дават лекарствата. Разбира се, това са чувствителни данни и защитата на информацията и проследимостта на това кой какво е проверявал трябва да е на ниво. ЕГН-то не трябва да се съхранява в явен вид, а в криптографски трансформиран, за да се избегне риска от изтичане на данни. Една такава проста система може да бъде разработена бързо с директно възлагане.

4. Регламентирането и прилагането на телемедицината е от ключово значение. За да изпише рецепта, лекарят все пак трябва да се запознае със симптомите. Много лекари го правят вече по телефона или чрез чат приложение, но е редно това да бъде регламентирано ясно, в т.ч. каналите и типовете информация, която се предава.

5. Регистър на бизнесите, засегнати от вируса – Министерски съвет предложи да плаща заплатите на служителите, които биха били съкратени заради извънредното положение. За да може държавата да провежда политика по обезщетяване, трябва да знае кой да обезщети. Бизнесите трябва да могат да се вписват в регистър, посочвайки колко и кои служители подлежат на обезщетяване от държавата. В противен случай процесът ще бъде хаотично размятане на документи, а много хора може и да не разберат и да останат без полагащите им се обезщетения.

6. Служебно събиране на информация за административни услуги – подаването на заявление за услга през системата за електронно връчване е само един от компонентите на отдалеченото обслужване. Всяка институция трябва да спазва изискванията на Закона за електронното управление и служебно да събира необходимата ѝ информация. Това е технически възможно с внедряване на Системата за служебен достъп до удостоверения в RegiX. В кризисна ситуация дежурното оправдание „ама моите правила и подзаконова нормативна уредба не позволяват“ могат спокойно да отпаднат.

7. Осигуряване на сигурна среда за отдалечена работа на администрацията. При работа с вътрешни системи е важно те да не бъдат отворени за външния свят, съответно на служителите трябва да бъде осигурена VPN връзка. В противен случай кибератаките няма да закъснеят. Липсата на VPN връзка може да е оправдание служители да не бъдат пускани за отдалечена работа. Поради това такава трябва да бъде изградена спешно.

8. Заседания на колективни органи трябва да могат да бъдат провеждани чрез технически средства (видеоконференции) – както публични такива, така и управителни съвети на дружества и неправителствени организации. Вземането на решения може да бъде удостоверявано от председателстващия заседанието на колективния орган. За това е необходима нормативна промяна.

9. Инициатива за насърчаване и популяризиране на услуги в помощ на населението – много доброволци създават услуги в помощ на населението при вируса – напр. за свързване на хора, имащи нужда от нещо, с такива, които могат да го предоставят. Трябва тези инициативи, често придружени със софтуерни приложения, да бъдат разглеждани от съответен държавен орган и бъдат популяризирани.

10. Дистанционно обучение – тази мярка би била доста по-високо в списъка, но тя вече е въведена. Все пак има доста оперативни и процедурни проблеми, които трябва да бъдат оправяни в бърз порядък. Част от тях са свързани с мащабируемостта на платформите, част – с липсата на ясни правила как да се използват платформите, без това да доведе до хаос.

Има много предложения за мерки и ограничен ресурс, с който те да бъдат изпълнявани. Тук именно е трудната задача по координиране и приоритизиране, за която трябва управленски капацитет. Повечето от предложенията по-горе изискват фокусирани, но минимални усилия и според мен са изпълними и ще помогнат за подобряване на ситуацията.

An AWS Elasticsearch Post-Mortem

Post Syndicated from Bozho original https://techblog.bozho.net/aws-elasticsearch-post-mortem/

So it happened that we had a production issue on the SaaS version of LogSentinel – our Elasticsearch stopped indexing new data. There was no data loss, as elasticsearch is just a secondary storage, but it caused some issues for our customers (they could not see the real-time data on their dashboards). Below is a post-mortem analysis – what happened, why it happened, how we handled it and how we can prevent it.

Let me start with a background of how the system operates – we accept audit trail entries (logs) through a RESTful API (or syslog), and push them to a Kafka topic. Then the Kafka topic is consumed to store the data in the primary storage (Cassandra) and index it for better visualization and analysis in Elasticsearch. The managed AWS Elasticsearch service was chosen because it saves you all the overhead of cluster management, and as a startup we want to minimize our infrastructure management efforts. That’s a blessing and a curse, as we’ll see below.

We have alerting enabled on many elements, including the Elasticsearch storage space and the number of application errors in the log files. This allows us to respond quickly to issues. So the “high number of application errors” alarm triggered. Indexing was blocked due to FORBIDDEN/8/index write. We have a system call that enables it, so I tried to run it, but after less than a minute it was blocked again. This meant that our Kafka consumers failed to process the messages, which is fine, as we have a sufficient message retention period in Kafka, so no data can be lost.

I investigated the possible reasons for such a block. And there are two, according to Amazon – increased JVM memory pressure and low disk space. I checked the metrics and everything looked okay – JVM memory pressure was barely reaching 70% (and 75% is the threshold), and there was more than 200GiB free storage. There was only one WARN in the elasticsearch application logs (it was “node failure”, but after that there were no issues reported)

There was another strange aspect of the issue – there were twice as many nodes as configured. This usually happens during upgrades, as AWS is using blue/green deployment for Elasticsearch, but we haven’t done any upgrade recently. These additional nodes usually go away after a short period of time (after the redeployment/upgrade is ready), but they wouldn’t go away in this case.

Being unable to SSH into the actual machine, being unable to unblock the indexing through Elasticsearch means, and being unable to shut down or restart the nodes, I raised a ticket with support. And after a few ours and a few exchanged messages, the problem was clear and resolved.

The main reason for the issue is 2-fold. First, we had a configuration that didn’t reflect the cluster status – we had assumed a bit more nodes and our shared and replica configuration meant we have unassigned replicas (more on shards and replicas here and here). The best practice is to have nodes > number of replicas, so that each node gets one replica (plus the main shard). Having unassigned shard replicas is not bad per se, and there are legitimate cases for it. Our can probably be seen as misconfiguration, but not one with immediate negative effects. We chose those settings in part because it’s not possible to change some settings in AWS after a cluster is created. And opening and closing indexes is not supported.

The second issue is AWS Elasticsearch logic for calculating free storage in their circuit breaker that blocks indexing. So even though there were 200+ GiB free space on each of the existing nodes, AWS Elasticsearch thought we were out of space and blocked indexing. There was no way for us to see that, as we only see the available storage, not what AWS thinks is available. So, the calculation gets the total number of shards+replicas and multiplies it by the per-shard storage. Which means unassigned replicas that do not take actual space are calculated as if they take up space. That logic is counterintuitive (if not plain wrong), and there is hardly a way to predict it.

This logic appears to be triggered when blue/green deployment occurs – so in normal operation the actual remaining storage space is checked, but during upgrades, the shard-based check is triggered. That has blocked the entire cluster. But what triggered the blue/green deployment process?

We occasionally need access to Kibana, and because of our strict security rules it is not accessible to anyone by default. So we temporarily change the access policy to allow access from our office IP(s). This change is not expected to trigger a new deployment, and has never lead to that. AWS documentation, however, states:

In most cases, the following operations do not cause blue/green deployments: Changing access policy, Changing the automated snapshot hour, If your domain has dedicated master nodes, changing data instance count.
There are some exceptions. For example, if you haven’t reconfigured your domain since the launch of three Availability Zone support, Amazon ES might perform a one-time blue/green deployment to redistribute your dedicated master nodes across Availability Zones.

There are other exceptions, apparently, and one of them happened to us. That lead to the blue/green deployment, which in turn, because of our flawed configuration, triggered the index block based on the odd logic to assume unassigned replicas as taking up storage space.

How we fixed it – we recreated the index with fewer replicas and started a reindex (it takes data from the primary source and indexes it in batches). That reduced the size taken and AWS manually intervened to “unstuck” the blue/green deployment. Once the problem was known, the fix was easy (and we have to recreate the index anyway due to other index configuration changes). It’s appropriate to (once again) say how good AWS support is, in both fixing the issue and communicating it.

As I said in the beginning, this did not mean there’s data loss because we have Kafka keep the messages for a sufficient amount of time. However, once the index was writable, we expected the consumer to continue from the last successful message – we have specifically written transactional behaviour that committed the offsets only after successful storing in the primary storage and successful indexing. Unfortunately, the kafka client we are using had auto-commit turned on that we have overlooked. So the consumer has skipped past the failed messages. They are still in Kafka and we are processing them with a separate tool, but that showed us that our assumption was wrong and the fact that the code calls “commit” doesn’t actually mean something.

So, the morals of the story:

  • Monitor everything. Bad things happen, it’s good to learn about them quickly.
  • Check your production configuration and make sure it’s adequate to the current needs. Be it replicas, JVM sizes, disk space, number of retries, auto-scaling rules, etc.
  • Be careful with managed cloud services. They save a lot of effort but also take control away from you. And they may have issues for which your only choice is contacting support.
  • If providing managed services, make sure you show enough information about potential edge cases. An error console, an activity console, or something, that would allow the customer to know what is happening.
  • Validate your assumptions about default settings of your libraries. (Ideally, libraries should warn you if you are doing something not expected in the current state of configuration)
  • Make sure your application is fault-tolerant, i.e. that failure in one component doesn’t stop the world and doesn’t lead to data loss.

To sum it up, a rare event unexpectedly triggered a blue/green deployment, where a combination of flawed configuration and flawed free space calculation resulted in an unwritable cluster. Fortunately, no data is lost and at least I learned something.

The post An AWS Elasticsearch Post-Mortem appeared first on Bozho's tech blog.

Ролята на бащата през първата година

Post Syndicated from Bozho original https://blog.bozho.net/blog/3486

В началото на месеца Оги стана на една годинка. След година бащинство ми се иска в една малко по-лична публикация да споделя размисли за ролята на бащата в целия процес.

Първата година е „код червено“ – всичко се променя много бързо, сблъсквате се с неща, които за първи път виждате, и за които няма „верен отговор“. Предвид статистиката, че най-много разводи стават през първата година след раждането, периодът поставя под особено напрежение отношенията на родителите.

Приоритетната задача, разбира се, е малкото човече да расте здраво, наспано, нахранено и жизнерадостно. Но това е функция на много неща, в т.ч. информираността, дисциплината и организираността на родителите, но най-вече на тяхната психическа възможност да напредват с „мисията“ бебе.

А колкото и да помага бащата, психическата тежест диспропорционално пада върху майката – тя е тази, която стои по цял ден вкъщи с едно много сладко, но изискващо и не особено разнообразно същество. Без хора, които да ѝ помагат, с които да споделя ежедневието. Сама през голямата част от деня. И тя е тази, чийто живот е най-преобърнат.

Има африканска поговорка, че има нужда от цяло село, за да се отгледа дете. И тя е важала до голяма степен и за нашия континент до неотдавна. Децата са гледани от роднини, съседи, техните деца и внуци. И това е позволявало както много по-лесно предаване на знанията, така и доста по-малко стрес за майката.

В цивилизования свят, обаче, майката и бебето са между четири стени, извън които има предимно непознати, които най-много да се усмихнат на бебето на улицата (но и това е рядко). А тези, от които могат да черпят практични знания и за гледането на бебето, и за психическото си здраве – техните родители – почти нищо не помнят (а дори и да помнят, са препоръки, които междувременно са се променили – напр. дали да се дава вода на бебетата). Организираното излизане с приятелки, дори в рамките на същия квартал, е сложно – синхронизирането на съня на бебетата, особено като са по-малки, е доста трудно.

Говорейки за съня – липсата му утежнява ситуацията допълнително. Дори когато сумарно имаш определено количество сън, ако той е накъсан, качеството му е по-ниско и съответно се чувстваш като парцал. А това е ежедневие за много родители.

Бащата трябва да може да прави всичко, което може майката и е добре да го прави във всеки момент, в който е на разположение (защото през останалото време го прави тя). Невинаги това ще е възможно (напр. след шестия месец приспиването става сложно до невъзможно), но родителите трябва да са оперативно взаимозаменяеми – това спестява доста проблеми.

Бащата не е герой. И трябва да е наясно с това. Сменянето на памперс е лесно. Спането на дивана не е толкова лошо. От пускането на прахосмукачка не падат ръце. Извеждането на разходка е дори приятно. Написването на текст като този също не е геройство. А когато влизам с количката в тясна тоалетна, „не ти е лесно“ е позитивен коментар от придържащия вратата мъж, но изпуска цялата картинка – вкарването на количка в тоалетна не е трудната част. Може да попаднете и на статии, които обясняват, че след раждането майката все пак е „длъжна“ да прави неща за бащата. Това са опасни глупости, които могат да изострят и без това нелекия период (не, няма нужда жената да бъде „лирическият герой“ на Кобилкина).

И със сигурност не си и помисляйте да се скатавате. Изморени сте след работа? Жена ви е по-изморена. Не сте си доспали? Тя не е спала нормално от месеци. Някой ви е изнервил в офиса? Поне е имало с кого да се „напсувате“, тя и това няма.

Така че ролята на бащата, поне през първата година, според мен е да минимизира негативния ефект от съвременния начин на живот върху майката. Не само битово, но и емоционално. Чрез помощ, старание, разбиране, немрънкане, говорене, излизане, правене на неща заедно. Няма да се получава перфектно. Ако сте несръчни и разсеяни, колкото мен, ще е много далеч от перфектно. Вероятно ще е недостатъчно. Ще има криви моменти. Но от моята гледна точка това е правилният подход. Това означава и от възможно най-рано бащата да бъде равноправен родител, а не „детегледачка“.

А в по-общ план трябва да помислим как да решим дългосрочно тези проблеми. Явно е, че не можем да гледаме бебетата на улицата, заедно със съседите. Бабите и дядовците ни са работещи хора и не могат да помагат през цялото време. А оставянето на тримесечно бебе на бавачка с адаптирано мляко (както се случва в САЩ, например, поради липса на регламентирано майчинство), не мисля, че е най-доброто за бебето. Нямам конкретни предложения, но това майките да не бъдат гледани като „истерични бг-мами“, а да се чувстват добре трябва да е приоритет не само на бащите, а на цялото общество. По очевидни причини.

Квалифициран електронен подпис на юридическо лице не съществува

Post Syndicated from Bozho original https://blog.bozho.net/blog/3494

Юридическите лица у нас (или по-точно законните им представители) си имат квалифицирани електронни подписи, с които ползват електронни услуги от държавата (и по-рядко – подписват договори, макар че това би било чудесно). Само че такова нещо като квалифициран електронен подпис на юридическо лице няма в правната рамка на електронните подписи. Да цитирам Регламент (ЕС) 910/2014, който урежда материята:

14) „удостоверение за електронен подпис“ означава електронен атестат, който свързва данните за валидиране на електронен подпис с физическо лице и потвърждава най-малко името или псевдонима на това лице

Та, електронните подписи на юридически лица доставчиците ги водят делегирани електронни подписи (или нещо подобно), за да бъдат все пак коректни спрямо законодателството. Но какво всъщност правят – вписват ЕИК (и името) на фирмата в удостоверението за квалифициран електронен подпис. Толкова. Това, обаче е голям проблем. И голяма глупост. Тя е глупост както на администрацията, която изисква ЕИК в удостоверението за електронен подпис, така и на доставчиците, че го издават. Нека да обясня защо.

Вписването на ЕИК в КЕП (наложило се съкращение, значещо „квалифициран електронен подпис“, но реално визиращо удостоверението за квалифициран електронен подпис или по терминологията на eIDAS – квалифицираното удостоверение за електронен подпис) означава едно нещо – този човек, който е приносител на удостоверението, има представителна власт по отношение на дружеството, вписвано в удостоверението. Тази представителна власт (дали в качеството му на управител или упълномощено от управител лице) се проверява в момента на издаването на удостоверението за електронен подпис и се вписва там. Оттам нататък администрациите, предоставящи електронни услуги (напр. НАП), разчитат на вписаното ЕИК в удостоверението. Проблемът идва, когато управител бъде сменен или пълномощно бъде оттеглено преди изтичане на срока на КЕП-а (който може да се издава за три години).

В този момент човек без представителна власт продължава да може да представлява дружеството пред администрацията (а и някои банки) и това ще бъде прието, защото удостоверението е валидно. Какви щети могат да бъдат нанесени така – не съм навлизал в такива хипотези, но най-малкото може да бъде причинено неудобство на новия управител.

А не трябва ли, при смяна на управителя, съдружниците да уведомят всички доставчици на електронни подписи за промяната, за да могат те да прекратят действието на удостоверението? По принцип може, само че надали много хора ще се сетят. Освен това, при единния цифров пазар, това значи уведомяване не само на няколко български доставчици, а на всички доставчици в ЕС. Защото управителят може през това време да си е извадил КЕП в Белгия (ако е успял да убеди белгийския доставчик да впише допълнително поле за ЕИК, така че да работи с е-услугите). Така че трябва да се уведомят всички доставчици в ЕС. Поне ги има на списък от европейската комисия, но задачата става безумна.

Друг вариант би бил доставчиците на електронни подписи да получават всеки ден от търговския регистър променените обстоятелства и ако са издали удостоверение на някой, който вече не е управител (т.е. не са налице обстоятелствата, на база на които е издадено удостоверението), да го прекратят автоматично. Това е възможно, но безмислено, тъй като доставчикът е грешното място да се случва това.

Правилният подход е да няма ЕИК в удостоверението, да няма изобщо различна услуга за юридически лица. С моя личен КЕП трябва да мога да се идентифицирам и заявявам услуги на всички дружества, които представлявам (въпросът дали КЕП трябва да може да се ползва за идентификация е отделен, разгледал съм го тук). В момента на идентификация, без значение дали с КЕП или с друго средство, доставчикът на услугата трябва в реално време да проверява в Търговския регистър или регистъра Булстат дали представлявам съответното дружество. В повечето случаи отговорът се получава еднозначно и нещата могат да продължат автоматизирано. В редки случаи на по-сложна представителна власт (напр. само заедно за определени неща), тъй като Търговският регистър не поддържа номенклатури за такъв тип представителство, се налага ръчна проверка от страна на предоставящия услугата, но това са много малка част от случаите. Когато става въпрос пък за упълномощени лица, автоматичната проверка трябва да работи в за съжаление все още несъществуващия регистър на овластяванията по Закона за електронната идентификация.

Вместо това доставчиците на услуги или изобщо не признават личния КЕП като вариант да се идентифицираш и заявиш услуга като представител на юридическо лице, или изискват да отидеш на място (НАП, вас гледам), за да потвърдиш с декларация, че ти наистина си управител на това дружество (да, НАП искат да се подпишеш, че данните от Търговския регистър са верни, не си го измислям. Сигнализирах на Агенция по вписванията, но мисля, че нищо не направиха по въпроса, даже не ми отговориха). И в крайна сметка администрацията разчита на доставчиците на електронни подписи да са направили необходимите проверки, а не на актуалните данни в Търговския регистър, които са единствените, на които може да се има доверие в реално време. А първичните администратори на данни имат задължение да предоставят данни за представителна власт в реално време (чл. 24б от Закона за електронното управление). И Агенция по вписванията дори го спазва отчасти.

Не знам кой и защо е измислил и приел този начин на работа и дали просто не е е наложил като много по-прост, защото е по-лесно да прочетеш едно поле от удостоверение за електронен подпис, отколкото да правиш връзка с Търговския регистър. Но това е неправилно, незаконно (чл. 27 от ЗЕУ) и създава излишни рискове.

Но както често се случва и тук практиката се разминава от нормативната уредба и от правилния подход. И почти никой не може да каже на администрациите да сменят тази своя практика. Защото те винаги така са го правили. Доставчиците на електронни подписи пък изобщо не се оплакват, че могат да продават на тройна цена същата услуга (с усложнението да направят проверка в Търговския регистър при издаване). И така всичко си тече. Не че това е фатален проблем, но е един от многото проблеми, едно от многото малки неща, които са не баш както трябва. И като се съберат всички тези малки неща, се оказва, че имаме нездрави основи, на които трудно можем да построим смислено електронно управление.

Running a Safe Database Cluster in AWS With Auto-Scaling Groups

Post Syndicated from Bozho original https://techblog.bozho.net/running-a-safe-database-cluster-in-aws-with-auto-scaling-groups/

When you have to run a scalable application on AWS, your database must also be scalable. It’s easier to scale the stateless application layer, where each node is mostly disposable – even if a node in a 3-node cluster fails, you can just fire up another one and nobody notices.

The database layer is stateful and therefore there’s a risk to lose data. Having just a single node is not an option, as a node can always go down and that would mean downtime. So you need multiple nodes in a cluster to make sure your application is highly available and fault tolerant (I won’t go into the differences in terminology).

What database am I talking about? It doesn’t matter. It can be a SQL or a NoSQL database – each has some form of clustering available. Whether it’s active-active or active-passive.

Now, for AWS in particular, you can choose RDS (or another managed option), which will handle it for you. But if there’s no managed option (e.g. Cassandra) or you don’t feel the managed option is giving you enough control, or is more expensive, or the version you require is not available, you have to manage the database layer yourself. I won’t go into the details of how to configure the database-specific clustering – you should check the documentation of the particular database for that. I’ll try to give some tips how to safely run your infrastructure that supports the database cluster.

And here come auto-scaling groups. They allow you have have a group of identical nodes (based on a launch configuration) and the ASG makes sure you always have at least X healthy nodes by starting new nodes if existing ones fail( they can automatically kill unhealthy nodes (that is, nodes that do not respond to automated healthchecks)).

That’s awesome for application nodes, but it can be an issue with database nodes. You don’t necessarily want your database node killed if it gets unresponsive for a while. That’s why below I’ve compiled a list of tips to avoid pitfalls. Unfortunately, many of them are not available through CloudFormation, so you have to do them manually. And document them so that you don’t forget in case you need to recreate the stack:

  • Set the minimum number of nodes to 1. It protects from accidentally setting the “Desired” count to 0 as part of experimenting with other, unrelated ASGs
  • Make sure you have enabled termination protection for each instance as well as scale-in termination protection per ASG.
  • In the ASG settings there’s “Suspended Processes”. Make sure you suspend “Terminate” and “ReplaceUnhealthy”.
  • Make sure that in your LaunchConfiguration the EBS volume is not deleted in case of termination. Why do you need that, given that you have disabled all termination options? Well, termination can occasionally happen due to issues with the underlying host, or a node may be scheduled for decommission
  • If at some point you need to restore from an EBS volume, 1. let the ASG spawn a new node 2. temporarily add “Launch” to the suspended actions 3. Detach the root volume of the node 4. attach the old EBS volume to /dev/xvda 5. start the node.
  • Setup a lifecycle policy (through CloudFormation or manually) to do a backup on the database EBS volumes. Make sure you set the proper tags to the volumes (and this can only be done manually)
  • Make sure the ASG can spawn instances in multiple availability zones (in case one goes down)

If you follow that, your auto-scaling groups will not behave exactly as auto-scaling groups. You can still configure automatically increasing the number of nodes in case of increased load, but the rest of the features are rarely a good idea for database layers – you’d prefer to resolve your database issues on existing machines, even if stopped temporarily, rather than just spawn new ones.

But you should embrace failure. Even with all termination protections, you have to assume everything may fail and die and you should have a clear path to restoring your nodes.

The post Running a Safe Database Cluster in AWS With Auto-Scaling Groups appeared first on Bozho's tech blog.

Where Is This Coming From?

Post Syndicated from Bozho original https://techblog.bozho.net/where-is-this-coming-from/

In enterprise software the top one question you have to answer as a developer almost every day is “Where is this coming from?”. When trying to fix bugs, when developing new features, when refactoring. You have to be able to trace the code flow and to figure out where a certain value is coming from.

And the bigger the codebase is, the more complicated it is to figure out where something (some value or combination of values) is coming from. In theory it’s either from the user interface or from the database, but we all know it’s always more complicated. I learned that very early in my career when I had to navigate a huge telecom codebase in order to implement features and fix bugs that were in total a few dozens line of code.

Answering the question means navigating the code easily, debugging and tracing changes to the values passed around. And while that seems obvious, it isn’t so obvious in the grand scheme of things.

Frameworks, architectures, languages, coding styles and IDEs that obscure the answer to the question “where is this coming from?” make things much worse – for the individual developer and for the project in general. Let me give a few examples.

Scala, for which I have mixed feelings, gives you a lot of cool features. And some awful ones, like implicits. An implicit is something like a global variable, except there are nested implicit scopes. When you need some of those global variables, so just add the “implicit” keyword and you get the value from the inner-most scope available that matches the type of the parameter you want to set. And in larger projects it’s not trivial to chase where has that implicit value been set. It can take hours of debugging to figure out why something has a particular value, only to figure out some unrelated part of the code has touched the relevant implicits. That makes it really hard to trace where stuff is coming from and therefore is bad for enterprise codebases, at least for me.

Another Scala feature is partially applied functions. You have a function foo(a, b, c) (that’s not the correct syntax, of course). You have one parameter known at some point, and the other two parameters known at a later point. So you can call the function partially and pass the resulting partially applied function to the next function, and so on until you have the other arguments available. So you can do bar(foo(a)) which means that in bar(..) you can call foo(b, c). Of course, at that point, answering the question “where did the value of a come from” is harder to answer. The feature is really cool if used properly (I’ve used it, and was proud about it), but it should be limited to smaller parts of the codebase. If you start tossing partially applied functions all over the place, it becomes a mess. And unfortunately, I’ve seen that as well.

Enough about Scala, the microservices architecture (which I also have mixed feeling about) also complicates the ability of a developer to trace what’s happening. If for a given request you invoke 3-4 external systems, which both return data and manipulate data, it becomes much harder to debug your application. Instead of putting a breakpoint or doing a call hierarchy, you have to track the parameters of each interaction with each microservice. It’s news to nobody that microservices are harder to debug but I just wanted to put that in the context of answering the “where is this coming from” question.

Dynamic typing is another example. I’ve included that as part of my arguments why I prefer static typing. Java IDEs have “Call hierarchy”. Which is the single most useful IDE functionality for large enterprise software (for me even more important than the refactoring functionality). You really can trace every bit of possible code flow, not only in your codebase, but also in your dependencies, which often hide the important details (chances are, you’ll be putting breakpoints and inspecting 3rd party code rather often). Dynamic typing doesn’t give you the ability to do that properly. doSomething called on an unknown-at-compile-time type can be any method with that name. And tracing where stuff is coming from becomes much harder.

Code generation is something that I’ve always avoided. It takes input from text files (in whatever language they are) and generates code, turning the question “where is this coming from” to “why has this been generated that way”.

Message queues and async programming in general – message passing obscures the source and destination of a given piece of data; a message queue adds complexity to the communication between modules. With microservices you at least have API calls, with queues, you have multiple abstractions between the sender and recipient (exchanges, topics, queues). And that’s a general drawback of asynchrounous programming – that there’s something in between the program flow that does “async magic” and spits something on the other end – but is it transformed, is it delayed, is it lost and retried, is it still waiting?

By all these examples I’m not saying you should not use message queues, code generation, dynamic languages, microservices or Scala (though for some I’d really advice against). All of these things have their strengths, and they have been chosen exactly for those strengths. A message queue was probably chosen because you want to really decouple producer and consumer. Scala was chosen for its expressiveness. Microservices were chosen because a monolith had become really hard to manage with multiple teams and multiple languages.

But we should try to minimize the “damage” of not being able to easily trace the program flow and not being able to quickly answer “where is this coming from”. Impose a “no-implicits” rule on your scala code base. Use code-generation for simpler components (e.g. DTOs for protobuf). Use message queues with predictable message/queue/topic/exchange names and some slightly verbose debug logging. Make sure your microservices have corresponding SDKs with consistent naming and that they can be run locally without additional effort to ease debugging.

It is expected that the bigger and more complex a project is, the harder it will be to trace where stuff is going. But do try to make it as easy as possible, even if it costs a little extra effort in the design and coding phase. You’ll be designing and writing that feature for a week. And you (and others) will be supporting and expanding it for the next 10 years.

The post Where Is This Coming From? appeared first on Bozho's tech blog.

One-Month of Microsoft DKIM Failure and Thoughts on Technical Excellence

Post Syndicated from Bozho original https://techblog.bozho.net/one-month-of-microsoft-dkim-failure-and-thoughts-on-technical-excellence/

Last month I published an article about getting email settings right. I had recently configured DKIM on our company domain and was happy to share the experience. However, the next day I started receiving error DMARC reports saying that our Office365-backed emails are failing DKIM which can mean they are going in spam.

That was quite surprising as I have followed every step in the Microsoft guide. Let me first share a bit about that as well, as it will contribute to my final point.

In order to enable DKIM, on a normal email provider, you just have to get the DKIM selector value from some settings screen and copy them in your DNS admin dashboard (in a new ._domainkey. record). Microsoft, instead, make you do the following:

  • Connect to Exchange Powershell
  • Oh, you have 2FA enabled? Sorry, that doesn’t work – follow this tutorial instead
  • Oh, that fails when downloading their custom application? An obscure stackoverflow answer tells you that you should not download it with Firefox or Chrome – it fails to run then. You should download it with Internet Explorer (or Edge) and then it works. Just Microsoft.
  • Now that you are connected, follow the DKIM guide
  • In addition to powershell, you should also go in the Exchange admin in your Office365 admin, and enable DKIM

Yes, you can imagine you can waste some time here. But it finally works, and you set the CNAME records and assume that what they wrote – namely, that the TXT records to which the CNAME records point, are generated on Microsoft’s end (for onmicrosoft.com), and so anyone trying to validate a signature will pick the right public key from there and everything will be perfect. Well, no. Here’s an excerpt from a test mail I sent to my Gmail in December:

DKIM: ‘FAIL’ with domain logsentinel.com
ARC-Authentication-Results: i=2; mx.google.com;
dkim=temperror (no key for signature) [email protected] header.s=selector1

I immediately reported the issue in a way that I think is quite clear, although succint:

Hello, I configured DKIM following your tutorial (https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email), however the TXT records at your end that are supposed to be generated are not generated – so me setting a CNAME records points to a missing TXT record. I tried disabling and reenabling, and rotating the keys, but the TXT record is still missing, which means my emails get in spam folders, because the DMARC policy epxects a DKIM record. Can you please fix that and create the required TXT records?

What followed was 35 days of long phone calls and repetitive emails with me trying to explain what the issue is and Microsoft support not getting it. As a sidenote, Office365 support center doesn’t support tickets with so much communication – it doesn’t have pagination so I can’t see the original note online (only in my inbox).

On the 5th minute of my first-of-several 20 minute calls my wife, who was around, already knew exactly what the issue is (she’s quite technical, yes), but somehow Microsoft support didn’t get it. We went through multiple requests for me providing DMARC reports (and just the gmail report wasn’t enough, it had to be from 2 others as well), screenshots of my DNS administration screen, screenshots to prove the record is missing (but mxtoolbox is some third party tool they can’t trust), even me sharing my computer for a remote desktop session (no way, company policy doesn’t allow random semi-competent people to touch my machine). I ended up providing an nslookup (a Microsoft tool) screenshot, to show that the record is missing.

In the meantime I tried key rotation again form the exchange admin UI. That got stuck for a week, so I raised a separate ticket. While we were communication on that ticket as well, rotation finished, but the keys didn’t change. What changed was (that I later figured) the active selector. We’ll get to that later.

After the initial few days I executed Get-DkimSigningConfig | fl to get the DKIM record values and just created TXT records with them (instead of CNAME), so that our mails don’t get in spam. Of course, having DKIM fail doesn’t automatically mean you’ll get in spam, even though our DMARC policy says so, but it’s a risk one shouldn’t take. With the TXT records set everything was working okay, so I didn’t have an urgent problem anymore. That allowed me to continue slowly trying to resolve the issue with Microsoft support, for another month.

Two weeks ago they acknowledged something is missing on their end. Miracle! So the last few days of the horror were about me having to set the CNAME records back (and get rid of my TXT records) so that they can fix the missing records on their end. I know, that sounds ridiculous – you don’t need a CNAME to point to your TXT in order to get that TXT to appear, but who knows what obscure and shitty programs and procedures they have, so I complied. What followed was a request for more screenshots and more DKIM reports.

No. You have nslookup. No screenshot of mine is better than aн nslookup. The TTL for my entries is 300s, so there should be no issue with caching (and screenshots won’t help with that either).

Then finally, after having spoken to or emailed probably 5-6 different people, there was an email that made sense:

Good Afternoon,

As per the public documentation you followed (https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email) it is mentioned to have TXT records created in Microsoft DNS server for both Selector CNAME Records. we agree with that.

Our product engineer team has confirmed that there is a design level change was rolled out and it is still not published in public documentation. To be precise, we don’t require TXT record for both CNAME Records published. The TXT record will be published only for the Active Selector.

LastChecked 2020-01-01 07:40:58Z
KeyCreationTime 2019-12-28 18:37:38Z
RotateOnDate 2020-01-01 18:37:38Z
SelectorBeforeRotateOnDate selector1
SelectorAfterRotateOnDate selector2

Above info confirms that the active selector is “Selector2” and we have the TXT record published. So we don’t have to wait for the TXT record for Selector1 in our scenario.

Also we require the Selector1 CNAME record in your DNS, whenever next rotate happen. Microsoft will publish the other TXT record. This shouldn’t affect your environment at any chance.

Alright. So, when I triggered key rotation, I fixed the results of the original bug that lead to no records present. The rotation made the active selector “selector2” and generated its TXT record. Selector1 is currently missing, but it’s inactive, so that is not an issue. What “active selector” means is an interesting question. It’s nowhere in the documentation, but there’s this article from 2016 that sheds some light. Microsoft has to swap the selectors on each rotation. According to the article rotation happens every week, but that’s no longer the case – since my manual rotation there hasn’t been any automatic one.

So to summarize – there was an initial bug that happened who knows why, then my stuck-for-a-week manually triggered rotation fixed it, but because they haven’t documented the actual process, there was no way for me to know that the missing TXT record is fine and will (hopefully) be generated on the next rotation (which is my current pending question for them – when will that happen so that I check if it worked).

To highlight the issues here. First, a bug. Second, missing/outdated documentation. Third, incompetent (though friendly) support. Fourth, a convoluted procedure to activate a basic feature. And that’s for not getting emails in spam in an email product.

I can expand those issues to any Microsoft cloud offering. We’ve been doing some testing on Azure and it’s a mess. At first an account didn’t even work. No reason, just fails. I had to use another account. The UI is buggy. Provisioning resources takes ages with no estimate. Documentation is far from perfect. Tools are meh.

And yet, Microsoft is growing its cloud business. Allegedly, they are the top cloud provider in the world. they aren’t, obviously, but through bundling Office365 and Azure in the same reporting, they appear bigger than AWS. Azure is most likely smaller than AWS. But still, Satya Nadella has brought Microsoft to market success again. Because technical excellence doesn’t matter in enterprise sales. You have your sales reps, nice conferences, probably some kickbacks, (alleged) easy integration with legacy Windows stuff that matters for most enterprise customers. And for the decision maker that chooses Microsoft over Amazon or Google the argument of occasional bugs, poor documentation or bad support is irrelevant.

But it is relevant for the end results. For the engineers and the products they build. Unfortunately, tech companies have prioritized alleged business value over technical excellence so much that they can no longer deliver the business value. If the outgoing email of an entire organization goes in spam because Microsoft has a bug in Office365 DKIM, where’s the business value of having a managed email provider? If the people-hours saved form going from on-prem to Azure are wasted because of poor technology, where’s the business value? Probably decision makers don’t factor that in, but they should.

I feel technical excellence has been in decline even in big tech companies, let alone smaller ones. And while that has lead to projects gone out of budged, poor quality and poor security, the fact that the systems aren’t that critical has made it possible for the tech sector to get away with that. And even grow.

But let me tell you of big player in a different industry that stopped caring about technical excellence. Boeing. This article tells the story of shifting Boeing from an engineering organization to one that cuts on quality expenses and outsources core capabilities. That lead to the death of people. Their plane crashed because of that shift in priorities. That lead to a steep decline in sales, and a moderate decline in stock and a bailout.

If you de-prioritize technical excellence, and you are in a critical sector, you lose. If you are an IT vendor, you can get away with it, for a while. Maybe forever? I hope not, otherwise everything in tech will be broken for a long time. And digital transformation will be a painful process around bugs and poor tools.

The post One-Month of Microsoft DKIM Failure and Thoughts on Technical Excellence appeared first on Bozho's tech blog.

Няма WiFi – да решим въпроса политически!

Post Syndicated from Bozho original https://blog.bozho.net/blog/3488

В парламента спира WiFi-ът. Депутатите свикват извънредно заседание, на което да се съгласят, че проблем има. Опозицията обяснява, че по тяхно време WiFi винаги е имало. Управляващите се оправдават, че има кофти рутери, купени с обществена поръчка от опозицията, когато е била на власт, и това в основата на проблема. Все пак депутатите приемат, че WiFi няма и това трябва да се реши.

Председателят на комисията по транспорт, информационни технологии и съобщения свиква работна група – участват заинтересовани депутати, експерти от академичната общност и от ИТ сектора. В рамките на месец работната група се събира три пъти, но дискусията рядко е по същество. Минава се през изграждането на мрежата на държавната администрация НАМДА и кой какво е направил за нейното функциониране, през милионите дадени за инфраструктура, през това как са идвали наскоро гости от САЩ и Израел и какво са казали за WiFi-а в хотелите си.

Накрая работната група стига до заключение, че трябва да има устойчивост в комуникационната инфраструктура и това е национален приоритет. В доклад от една страница (защото по-дълъг би отнел година работа на работната група), се препоръчва приемане на законодателство по въпроса и създаване на държавен орган, който да е натоварен с политиката по изграждане и поддържане на комуникационна инфраструктура.

„Група народни представители“ дават доклада на адвокатска кантора, където няколко стажанти за месец написват законопроект. Депутатите го внасят (както си е – без пълен член и с редица правни неточности). Официално е Закон за комуникационната инфраструктура, но всички го наричат Закон за WiFi-a.

Но WiFi все още няма.

Дебатът на първо четене не е по същество. Говори се за важността на компютрите. За това как не може в 21-ви век една институция да няма WiFi. Един по-технически запознат депутат взема думата и споменава, че е хубаво като тръгне WiFi-ът, да се ползва WPA3, защото WPA2 е несигурен, но бързо бива скастрен от председателя с фразата „не технологизирайте дебата!!“

Между първо и второ четене фирмите, изграждащи мрежи, вкарват свои поправки през депутати, за да могат да продадат старото си оборудване, религиозни организации вкарват текст за освещаване на рутерите, а Менда Стоянова вкарва с преходни и заключителни разпоредби изменения на държавното устройство в Конституцията.

Шест месеца след спирането на WiFi-а законът е приет. Ще се създаде Държавна агенция за електронна и безжична администрация (защото никой не е обърнал внимание какво съкращение се получава), към нея ще има Съвет по комуникационна инфраструктура. Свикана е работна група към Министерски съвет са изготвяне на устройствен правилник и друга – за изработване на наредба към закона. Наредбата включва стандарти като IEEE 802.11, но няколко специалисти по ЗОП настояват да се запише „или еквивалентен“, за да нямало наказателна процедура от Европейската комисия за фаворизиране на един стандарт.

След година и половина агенцията е създадена, но два месеца по-късно все още WiFi няма. Депутатите от опозицията отправят питане до ресорния вицепремиер, а той от трибуната отговаря, че това управление е свършило изключително много за наличието на WiFi, а това, че в момента в сградата няма е неприятно обстоятелство, но важното е, че е отчетен сериозен напредък, покрити са редица индикатори – за наличие на нормативна уредба, за транспониране на европейски норми, за стратегическа рамка, и всеки момент ще стигнат до индивидуални проблеми, които институциите или гражданите може да имат въпреки бляскавия успех на политиките по комуникационната инфраструктура.

На втората година от спирането, в парламента постъпва на работа младши системен администратор (разбира се, племенник на заместник-министър) и рестартира рутера. WiFi-ът тръгва. Управляващите отчитат успеха, по националните медии се изреждат говорители (предимно бивши ченгета), които да величаят колко напредничаво е управлението. „Ето, даже вече мога да отварям сайтове на телефона си“ показва в ефир един депутат.

Междувременно Илон Мъск каца на Марс.

One-Time Passwords Do Not Provide Non-Repudiation

Post Syndicated from Bozho original https://techblog.bozho.net/one-time-passwords-do-not-provide-non-repudiation/

The title is obvious and it could’ve been a tweet rather than a blogpost. But let me expand.

OTP, or one-time password, used to be mainstream with online banking. You get a dedicated device that generates a 6-digit code which you enter into your online banking in order to login or confirm a transaction. The device (token) is airgapped (with no internet connection), and has a preinstalled secret key that cannot be leaked. This key is symmetric and is used to (depending on the algorithm used) encrypt the current time, strip most of the ciphertext and turn the rest into 6 digits. The server owns the same secret key, does the same operation and compares the resulting 6 digits with the ones provided. If you want a more precise description of (T)OTP – check wikipedia.

Non-repudiation is a property of, in this case, a cryptographic scheme, that means the author of a message cannot deny the authorship. In the banking scenario, this means you cannot dispute that it was indeed you who entered those 6 digits (because, allegedly, only you possess the secret key because only you possess the token).

Hardware tokens are going out of fashion and are being replaced by mobile apps that are much easier to use and still represent a hardware device. There is one major difference, though – the phone is connected to the internet, which introduces additional security risks. But if we try to ignore them, then it’s fine to have the secret key on a smartphone, especially if it supports secure per-app storage, not accessible by 3rd party apps, or even hardware security module with encryption support, which the latest ones do.

Software “tokens” (mobile apps) often rely on OTPs as well, even though they don’t display the code to the user. This makes little sense, as OTPs are short precisely because people need to enter them. If you send an OTP via a RESTful API, why not just send the whole ciphertext? Or better – do a digital signature on a server-provided challenge.

But that’s not the biggest problem with OTPs. They don’t give the bank (or whoever decides to use them as a means to confirm transactions) non-repudiation. Because OTPs rely on a shared secret. This means the bank, and any (curious) admin knows the shared secret. Especially if the shared secret is dynamically generated based on some transaction-related data, as I’ve seen in some cases. A bank data breach or a malicious insider can easily generate the same 6 digits as you, with your secure token (dedicated hardware or mobile).

Of course, there are exceptions. Apparently there’s ITU-T X.1156 – a non-repudiation framework for OTPs. It involves trusted 3rd parties, though, which is unlikely a bank scenario. There are also HSMs (server-side hardware security modules) that can store secret keys without any option to leak them to the outside world that support TOTP natively. So the device generates the next 6 digits. Someone with access to the HSM can still generate such a sequence, but hopefully audit trail would indicate that this happened, and it is far less of an issue than just a database breach. Obviously (or, hopefully?) secrets are not stored in plaintext even outside of HSMs, but chances are they are wrapped with a master key in an HSM. Which means that someone can bulk-decrypt them and leak them.

And this “can” is very important. No matter how unlikely it is, due to internal security policies and whatnot, there is no cryptographic non-repudation for OTPs. A customer can easily deny entering the code to confirm a transaction. Whether this will hold in court is a complicated legal issue, where the processes in the bank can be audited to see if a breach is possible, whether any of the admins has a motive to abuse their privilege and so on, whether there’s logs of the user activities that can be linked to their device based on network logs from internet carriers, and so on. So you can achieve some limited level of non-repudiation through proper procedures. But it is not much different than authorizing the transaction with your password (at least it is not a shared secret, hopefully).

But why bother with all of that if you have a mobile app with internet connection? You can just create a digital signature on a unique per-transaction challenge and you get proper non-repudiation. The phone can generate a private key on enrollment and send its public key to the server, which can later be used to verify the signature. You don’t have the bandwidth limitation of the human brain that lead to the requirement of 6 digits, so the signature length can be arbitrarily long (even GPRS can handle digital signatures).

Using the right tool for the job doesn’t have just technical implications, it also has legal and business implications. If you can achieve non-repudiation with standard public-key cryptography, if your customers have phones with secure hardware modules and you are doing online mobile-app-based authentication and authorization anyway, just drop the OTP.
.

The post One-Time Passwords Do Not Provide Non-Repudiation appeared first on Bozho's tech blog.

Спам от името на държавни институции?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3473

Миналата седмица от името на МВР беше изпратен спам. МВР не е хакнато, но в интернет всеки може да се представи за всеки и да изпрати вирус или линк, в който да си въведете паролата или номера на кредитната карта.

Изпращането на спам/фишинг от името на някоя държавна институция е хитра стретегия – изпращат ти фиш, данъчно задължение, призовка, болничен лист, документи за обществена поръчка и дори, защо не, съобщение от министър-председателя. Ако домейнът на изпращача наистина е съответстващия на институцията (mvr.bg, nap.bg, government.bg, parliament.bg), е по-вероятно повече хора „да се вържат“.

Какво могат да направят институциите, обаче? На пръв поглед – нищо. Всеки може да прати имейл от фалшив адрес и да се представи за институция. Само че институциите всъщност има какво да направят – поне за да не могат злонамерените изпращачи да злоупотребяват с домейна им и така да дават допълнителна достоверност на своя имейл. Има няколко настройки (DNS записи), които всеки притежател на домейн може и трябва да направи, за да гарантира, че никой няма да може да изпраща имейли от негово име. Или по-скоро – ако изпраща, системите за електронна поща ще ги класифицират автоматично като спам.

Техническите детайли съм описал тук, но с две думи, собственикът на домейна посочва от кои IP адреси е позволено да се изпращат мейли от името на неговия домейн, както и публичния ключ, с който да се валидира електронния подпис върху имейлите (да, мейлите автоматично се подписват електронно от системата за електронна поща, макар че това не е познатия ни квалифициран електронен подпис). И не на последно място – посочва какво да прави получателят на писма от неговия домейн, ако някоя от предходните проверки се провали – дали да го праща в „спам“ или не. Това са т.нар. SPF, DKIM и DMARC DNS записи.

Реших да проверя колко от институциите са направили тези настройки. И за съжеление, резултатът не е твърде добър. В таблицата по-долу съм показал 39 институции и дали те имат или нямат съответния DNS запис. На места има въпросителни – по принцип DKIM може да се провери само ако си получил имейл от съответния домейн, защото DNS записът включва селектор, който може да е произволен. Направил съм проверката с най-често срещаните селектори (default, selector, dkim, selector1) и съм допълнил информацията с ръчна проверка в собствената ми поща с мейли от съответните институции. Ако не мога да определя дали има или няма DKIM, съм сложил въпросителна. На места има „не“ по презумпция – ако нямаш нито един от другите два записа, едва ли ще имаш DKIM. Със звездичка в колоната DMARC са отбелязани институциите, които имат DMARC политика, но тя инструктира получателя да не прави нищо специално, ако проверките се провалят (вместо да го инструктира да сложи писмото в спам). С болд са „шампионите“ – тези, които са си настроили нещата както трябва.

ИнституциядомейнSPFDMARCDKIM
Агенция по вписваниятаregistryagency.bgДаДаНе
Агенция Митнициcustoms.bgДаДа*Да
АГККcadastre.bgДаДаДа
ВССjustice.bgДаДаДа
ГРАОgrao.bgДаДа?
ДАЕУe-gov.bgДаНеНе
ДАНСdans.bgДаДа*?
ДАТОdato.bgНеНеНе
МВнРmfa.bgДаНеНе
МВРmvr.bgДаНеНе
Министерство на енергетикатаme.government.bgДаДа*Да
Министерство на здравеопазваентоmh.government.bgДаНеНе
Министерство на икономикатаmi.government.bgДаДа*Да
Министерски съветgovernment.bgДаНеНе
Министерство на спортаmpes.government.bgНеНеНе
Министерство на културатаmc.government.bgНеНеНе
Министерство на отбранатаmod.bgДаДа*?
МОНmon.bgДаНеНе
МОСВmoew.government.bgДаНеНе
Министерство на правосъдиетоjustice.government.bgДаНеНе
МРРБmrrb.bgДаНеНе
Министерство на туризмаtourism.government.bgДаНеНе
МТИТСmtitc.government.bgДаДа*Не
МТСПmlsp.government.bgДаНеНе
МФminfin.bgДаДаДа
НАПnap.bgДаНеНе
НАПnra.bgДаДа*Не
НЗОКnhif.bgНеНеНе
Народно събраниеparliament.bgНеНеНе
Президентpresident.bgДаДа*Да
Община Бургасburgas.bgДаНеДа
Община Варнаvarna.bgНеНеНе
Община Пловдивplovdiv.bgДаНеНе
Столична общинаsofia.bgДаНеНе
Търговски регистърbrra.bgНеНеНе
КЗЛДcpdp.bgДаДаДа
КЗКcpc.bgНеНеНе
КФНfsc.bgДаДа*?
КРСcrc.bgНеНеНе
CERTgovcert.bgНеНеНе

Това ли е най-важната мярка за киберсигурност? Не – в киберсигурността (и киберустойчивостта) няма най-важна мярка. Всичко е серия от мерки, които покриват серия от рискове и уязвимости. Има много какво да се желае от киберсигурността в публичния сектор. Базовите настройки са едно добро начало – както за изпращане на имейли, така и за криптирането им. Но продължаваме да нямаме системно усилие за адекватна киберсигурност, което да дава резултат. Има закон, наредба, съвет, вицепремиер. Но явно няма сисадмин, който да настрои едни записи. И няма политика, насочена към това, да има такъв сисадмин навсякъде.

Solving Problems Properly Is Often Not Viable

Post Syndicated from Bozho original https://techblog.bozho.net/solving-problems-properly-is-often-not-viable/

How many times you, as a software expert, saw some software or process and thought “damn, this can be done so much better”. Yes, a lot. But why, since large organizations spend a lot of money on IT? Is it because software is too complex, is it because of organizational issues, is it legacy software, or just the way things are?

And if what we see is so bad, isn’t common market sense saying that surely these companies will be disrupted and made obsolete by a new and better competitor? I won’t give a definitive answer why software is bad (I have already blamed developers, though I admit, developers are only a part of the problem). But I’ll try to reason about what it’s not getting replaced under market forces.

Peter Thiel in his book “From Zero to One” says that a a new product has to be at least 10 times better in order to be disruptive. Everything below that is just gradual improvement over the status quo. Google was 10 times better than AltaVista, Lycos and Yahoo as a way to find information on the web. Skype was 10 times better than whatever was out there before that. But most of the things that we see as broken don’t get fixed because there’s no 10x improvement that would kill them. Let’s take a loot at a few examples.

Banking. Banking is horrible. Online banking UX is usually on par with a legacy ERP, bank transfers rely on a patchwork of national specifics and ages old international standards like SWIFT. I can’t really think of anyone who really likes their online banking. Mobile banking is even worse, as, of course, it’s tedious to copy-paste IBANs on a phone. Banks are, in many cases, still running COBOL on mainframes, and it’s really hard and expensive to get something changed or fixed. Why they are still around? Because the experience of the online banking is of marginal importance to the bank’s bottom line.

Yes, Revolut and TransferWise are cool tech billion-dollar-valuation startups that are “disrupting” banking. But not really. They are just fancier banks. Yes, finally you can do something on your mobile and you can be onboarded without going to a physical office and support is better and the UI is sleek, and the UX make sense. Do banks care? Not much. Because these startups are just small banks that are currently losing money in order to get to more people and make them spend small amounts online. Nothing of that is a 10x improvement in the value provided. It surely is much better technically, but once you have to transfer money elsewhere, you hit SWIFT or ideally SEPA. Once you want to pay in store, you hit Visa or MasterCard. Nothing of the legacy infrastructure is replaced, we just have better UX for, in many cases, sending money to those legacy banks.

Digital Identity. Anything online where it’s important to know who’s on the other end, requires digital identity. And yet we are nowhere near solving that problem. There are country-specific solutions where governments and/or consortia of banks issue some form of digital identity which others can trust. But it’s fragmented, with varying levels of security and integration isn’t necessarily easy. At the same time we have KYC companies that basically let you scan your customers passport or ID, optionally does a liveness detection (automated or manual) video conference and then check the person against databases of terrorists or sanctioned individuals. So for each service you have to do that again, slightly differently, and if something changes (e.g. an address or name change), there’s not really much you can do.

Ideally, digital identity is federated, using a common standard and easy to integrate, so that enrollment in sensitive online services that require some knowledge about a customer, is straightforward. The identification process gives just as much information as you need. Identity can be managed by multiple entities, government or private, that can vouch that an individual is indeed who they claim to be. The way you identify, with the current technology setting, would be with a key, securely stored in a mobile phone secure storage, using WebAuthn, SAML. There should be a way to re-issue they key in case a phone is lost, and then we’ll have an awesome, reusable digital identity to solve all online authentication and enrollment woes.

Alas, we are nowhere near that. Because what we currently have is working. It’s working terribly, expensively and with a lot of hacks and patches, and most importantly – users have to enrollment for every service separately, but from the point of view of each individual company, it’s easier to just get some service for passport verification and then issue username and password, with optional 2FA, and you are done. The system I described above is not 10 times better than the status quo. A blockchain-based self-sovereign identity, by the way, is also not 10 times better. And it has usability issues that even make it inferior to the status quo.

Privacy. Literally every day there’s a huge data breach or a huge privacy issue (mostly with Facebook). Facebook has been giving our data to 3rd parties, because why not. Companies are collecting whatever they can get ahold of, without much care of protecting it. Sensitive personal data is still stored unencrypted, unpseudonymized, in SQL databases with barely tracked admin access; applications still export bulks of sensitive data to excel sheets sent over email or published to public S3 buckets. Passwords are still stored in plaintext or unsalted, data is communicated over unencrypted connections.

We know how to fix all that; there are many best practices to address all of that. How many companies encrypt data at rest, which is the simplest and most obvious thing to do? How many encrypt data with separate keys to protect bulk exports? How many use pseudonymization when doing exports? Knowledge and best practices are out there but our software is still built as a CRUD application over a SQL datastore and the most important task is to get it done quickly, so let’s not bother with privacy protections.

And, from a business point of view, rightly so, unfortunately. Check the share price of a few recently breached companies. It drops for a few days and then bounces back up. And at the same time no privacy-preserving technology is 10 times better than what we have today, no company will be 10 times better if it protects personal data. So why bother?

Security. In the long run cybersecurity is very important. In the short term, it isn’t. Nothing bad will happen. The other day I inspected the 2FA application of a bank. It’s full of mistakes and yet, through multiple hoops and security-through-obscurity, it reduces the risk of something very bad happening. And if it happens, well, insurance will cover the losses. Data breaches happen not only because we don’t care about personal data, but also because we don’t care about security. Chief infomration security officers find it hard to convince boards that their role is needed, let alone that it needs budget. Security tools are a patchwork of barely working integrations. There was recently a series of rants from one infosec professional that rightly points out that our infosec tools are bad.

Are things improving? A little bit, mostly by introducing more secure protocols. Backward compatibility slows down the improvements, of course, but we’re getting there. But is there a security “fix” that makes things 10 times better, that changes the game, that cuts costs or risk so much? Nope.

These observations go for many more areas, both horizontal and vertical – social networks (where Facebook can’t even get sharing right, let alone data protection), public sector software is mostly still in the 90s, even online payments have not moved since PayPal at the beginning of the century – we still take our credit card from our wallets and type numbers and CVC codes, with all the associated fraud.

In many cases when there’s no visible improvement for years, some proactive governmental structure like the European Commission decides to step in and write some piece of legislation that tries to fix things. For banks, for example, there’s the PSD2 (2nd payment services directive), which mandates open banking – all data about a bank account should be accessible via APIs to third parties who can manage it, display it properly, analyze it. Wonderful in theory, a mess in practice so far – APIs barely work, there’s no standardization and anyone who wants to offer a service ontop of open banking APIs is suffering at the moment. SEPA, the single euro payment area standard, was introduced by a directive as well, more than a decade ago.

Regarding digital identity, there’s the eIDAS regulation which defines how governments should offer their eID cross border, so that, in theory, anyone can use any government or otherwise issued electronic identity to identify for any service across the EU. Things are not there yet at all, and the architecture is so complicated, I don’t think it will work as intended. The fragmented eID space will remain fragmented for all practical purposes.

For privacy there’s, of course, GDPR. And while it resulted in more people trying to take care of personal data, it lead to more documents being written than lines of code changed. Same for information security – the NIS directive tried to improve the security of providers of substantial services. It’s often unclear, though, what is a substantial service to begin with. And then it’s mostly organizational measures. Countries like the UK and Germany have good guidelines and frameworks to improve security but we are yet to see the results.

Why is solving problems properly so hard? Legacy software, legacy standard and legacy thinking certainly doesn’t help. But in many of these domains, solving problems properly does not bring sufficient business value. And we are not prepared to do things properly – while the knowledge on how to do things better exists, it’s not mainstream. And it’s not mainstream, because it’s not perceived as required.

We have half-assed our technology because it kinda works sufficiently to support the bottom line and to make users happy. We have muddled through the myriad of issues with the minimum effort required. Because even the maximum effort would not have been a sufficient improvement to change the game. Even the perfect re-imagined banking, digital identity, social network would not be significantly different for the end user. Sure, a little cheaper and a little more convenient, but not groundbreaking. Not to mention hidden horizontal aspects like security and privacy.

And we will continue that way, pushed by standards and regulations when nothing else helps, to a messy gradual improvement. But it won’t be worth the investment to do things right – why would you invest millions in quality software development when it will marginally affect your business? It’s only worth to get things to barely work.

The post Solving Problems Properly Is Often Not Viable appeared first on Bozho's tech blog.

Getting Email Sending Settings Right

Post Syndicated from Bozho original https://techblog.bozho.net/getting-email-sending-settings-right/

Email. The most common means of internet communication, that has been around for ages and nobody has been able to replace it. And yet, it is so hard to get it right in terms of configuration so that messages don’t get sent in spam.

Setting up your own email server is a nightmare, of course, but even cloud email providers don’t let you skip any of the steps – you have to know them and you have to do them. And if you miss something, business will suffer, as a portion of your important emails will get in spam. The sad part is that even if you get all of them right, emails can still get in spam, but this is on the spam filters and there’s little you can do about it. (I dread the moment when an outgoing server will run the email through standard spam filters with standard sets of configurations to see if it would get flagged as spam or not)

This won’t be the first “how to configure email” overview article that mentions all the pitfalls, but most of the ones I see omit some important details. But if you’ve seen one, you are probably familiar with what has to be done – configure SPF, DKIM and DMARC. But doing that in practice is trickier, as this meme (by a friend of mine) implies:

So, you have an organization that wants to send email from its “example.com” domain. Most tutorials assume that you want to send email from one server, which is almost never the case. You need it for the corporate emails (which would in many cases be a hosted or cloud MS Exchange, or Google Suite), you need it for system emails from your applications (one or more of them), which use either another internal server or a cloud email provider, e.g. Amazon SES, you also need it for your website, which uses the hosting provider email server, and you need it for your email campaigns, e.g. via Mailchimp or Sendgrid.

All of the email providers mentioned above have some parts of the picture in their documentation but it doesn’t work in combination. As most providers wrongly assume they are the only one. Their examples assume that and their automated verifications assume that – e.g. Microsoft checks if your SPF record matches exactly what they provide, rather than checking if their servers are allowed by your more complex SPF record which includes all of the above providers.

So let’s get to the individual items you have to configure. Most of them are DNS records, which explains why a technical person in each organization has to do it manually, rather than each service pushing it there automatically after some API authentication:

  • SPF (Sender Policy Framework) – a DNS recrod that lists the permitted senders (IP addresses) and an instruction flag on what to do with those that don’t match. In the typical scenario you need to include multiple senders’ policies rather than listing IP addresses, as they can change. E.g. in order to use Office365, you have to add include:spf.protection.outlook.com. Note that this should be a TXT record, but some DNS providers support a special type of record – SPF. So some older software may expect an SPF header, which means you should support both records with identical values. The syntax is straighforward but sometimes tricky, so you can use a tool to generate and validate it.
  • DKIM (DomainKeys Identified Mail) – a DNS record that lets email senders sign their emails. The DNS record includes the public key used to verify the signature. Why is it needed if there’s SPF? Among other things (like non-repudiation), because with SPF the From header can still be spoofed. Not that DKIM always helps with that, but in combination with DMARC it does. How does DKIM work in multi-sender scenario? You have multiple DKIM selectors which means multiple TXT records. Usually every provider will recommend its own selector (e.g. selector1._domainkey.example.com). Some may insist on being default._domainkey, and if two of them insist on that, you should contact support (the message contains the selector and then verification will fail if it does not match). Email providers would prefer CNAME instead of TXT records as that allows them to rotate the keys without you having to change your DNS records.
  • DMARC (Domain-based Message Authentication, Reporting and Conformance) – this DNS record contains the policy according to which your emails should be validated – it enforces SPF and DKIM and tells the receiving side what to do if they fail. You can have one DMARC policy (again as a TXT record). The syntax is not exactly human readable, so use a tool to generate and validate it. An important aspect of DMARC is that you can receive reports in case of failures – you can specify an email where reports are sent and you can analyze them. There are services (like ReportURI) that can aggregate and analyze these reports. I prefer setting multiple report emails – one administrative and one for ReportURI.
  • PTR (pointer) – this is used for reverse DNS loopkups – it maps a domain name to an IP address (as opposed to A records which map IP adresses to domain names). Spam filters use it to check incoming email. The PTR records should be there for the servers that send the email, e.g. mail.example.com. External providers are likely to already have that record so no need to worry about it. And in many cases you won’t even be able to anyway if you don’t own/control the network.
  • Service-specific settings – you may configure your headers properly but the service sending the emails (e.g. Office365, Mailchimp) might still be missing some configuration. In some cases you have to manually confirm your headers in order to enable DKIM signing. With MS Exhange, for example, you have to execute a few PowerShell commands to generate and then confirm the DKIM records.
  • Blacklists – if you haven’t had everything setup correctly, or if one of your sending servers/services has been compromised, your domain and/or servers may be present in some blacklist. You have to check that. There are tools that aggregate blacklists and check against the, e.g. this one

After everything is done, you can run a spam test using some of the available online tools: e.g. this, this or this. And speaking of tools, MXToolbox has many useful tools to verify all aspects of email configuration.

By the way, this is not everything you can configure about your email. SMTP over TLS (SMTPS), MTA-STS, TLS RPT, DANE. I’ve omitted them because they are about encrypted communication and not about spam, but you should review them for proper email configuration.

By now (even if you already knew most of the things above) you are probably wondering “why did we get here?”. Why do we have to do so many things just to send simple email. Well, first, it’s not that simple to have a universal messaging protocol. It looks simple to use and that’s the great part of it, but it does hide some complexities. The second reason is that the SMTP protocol was not designed with security in mind. Spam and phishing were maybe not seen as such a big issue and so the protocol does not have built-in guarantees for anything. It doesn’t have encryption, authentication, non-repudiation, anything.

That’s why this set of instruments evolved over time to add these security features to email (I haven’t talked about encryption, as it’s handled differently). Why did it have to be DNS-based? It’s the most logical solution, as it guarantees the ownership of the domain, which is what matters even visually to the recipient in the end. But it makes administration more complicated, as you are limited to one-line, semicolon or space separated formats. I think it would be helpful to have a way to delegate all of that to external services, e.g. by a single authenticating DNS record which points to a URL which provide all these policies. For example an EML record to point to https://example.com/email-policies which can publish them in a prettier and more readable (e.g. JSON) format and does that in a single place rather than having to generate multiple records. Maybe that has its own cons, like having the policy server compromised.

But if anything is obvious it is that everything should be designed with security in mind. And every malicious scenario should be taken into account. Because adding security later makes things even more complicated.

The post Getting Email Sending Settings Right appeared first on Bozho's tech blog.

Има ли македонски език?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3460

Онзи ден, по повод становище на БАН, че македонски език няма, публикувах следното, което предизвика много онлайн полемика:

И на кого е нужно БАН да обяснява, че няма македонски език?

Македонски език има. Как се е появил на езиковата карта и дали не е имало политическо влияние в първоначалната книжовна норма няма значение за днешния ден, в който не просто има македонски език, ами мнозинството от българите няма да разбират повече от 60%, гледайки македонска телевизия, напр.

Езикът, това е диалект с армия. Няма ясно дефинирана разлика между език и диалект. И няма нужда да изобретяваме такава, за да смущаваме геополитическия прогрес.

Темата, обаче, е по-сложна и просто „има“ и „няма“ са не са достатъчни отговори. Затова ще опитам да обясня, особено за хората, които смятат несъществуването на македонски език за въпрос от национално значение.

Лингвистиката, като наука, която се занимава с изучаване на езика, не прави разлика между език и диалект. Няма такава. Дали едно нещо се нарича език или диалект е въпрос на други съображения. Най-значимото от които – наличието на геополитически субект, който да застане зад дадено наречие и да го нарече език.

А как така няма такава? За да има са ни нужни два компонента. Първият е отдалеченост на езиците. Има начини това да бъде изчислено с някакво приближение. Не е тривиално, но комбинация от лексикална отдалеченост (колко думи, и по-конкретно колко основни думи, напр. от списъка на Суодеш) се различават; фонологична отдалеченост – колко звуковите правила се различават; морфологична и синтактична отдалеченост – доколко, грубо казано, „граматиката“ се различава. И да кажем, че събираме единен индикатор за отдалеченост на база на претегляне на гореизброените. Идва обаче въпросът без отговор – къде слагаме границата? На отдалеченост = 1, 5, 7, 12? И защо? Македонският диалект ли е на българския, белоруският диалект ли е на украинския, австрийският и люксембургският диалекти ли са на немския, кантонският диалект ли е на китайския (путунхуа) и т.н. и т.н. И ще видим, че няма обективен критерий, по който да теглим чертата. Кантонският е толкова различен от други китайски диалекти, колкото френски от испански, например.

Именно поради тази невъзможност да бъде дефинирана разлика е прословутата фраза, че „езикът, това е диалект с армия и флот“. Или иначе казано – геополитическа конструкция. Ако Македонската държава казва, че има македонски език, значи такъв има (научих, че имали бойни кораби в Охридското езеро, така че и критерия с флота покриват).

Вече чувам блъскащите по клавиатурата пръсти на хората, които са наизвадили Гоце Делчев и Братя Миладинови, исторически извори за напъна за създаване на македонска нация и не на последно място – БАН, които все пак са професори, дето разбират от тая работа.

И искам веднага да ги успокоя – не смятам, че строителството на македонската нация е естествен процес. Или че „Антична Македония“ съществува, и че говорят езика на Александър Македонски. Дългогодишното изкривяване на историята от страна на македонските власти не е в услуга на никого, особено на самите македонци. Когато през 45-та година се кодифицира македонската книжовна норма, тя в немалка степен измислена на празно място. В следващите 70 години, обаче, така наложеният език търпи естествено (и отчасти насилствено) влияние от своите съседи, а именно – сръбския. Така той вече звучи различно и макар да няма изследване доколко е разбираем за българите, смятам, че много от думите, конструкциите и дори различните ударения ще са объркващи и дори неразбираеми за нетренираното ухо на носител на българския език.

Това желание да сложим езиците в едни кутийки и да кажем, че нещо е български и нещо не е български е следствие от опростената ни представа за езика като цяло. Езикът, това не е книжовна норма. Езикът е жив организъм, който се развива постоянно в следствие на естествени или изкуствени стимули. Езикът се развива на различни места по различен начин и затова лингвистичната карта не съвпада с държавните граници. В Крива паланка говорят едно, в Охрид друго. В Пирот говорят едно, в Нови сад – друго. Това сръбски ли е, ако, например няма всички падежи на книжовния сръбски? Отговорът – няма значение.

Лингвистиката се интересува от това какво се говори, какви са явленията в него, и как се е стигнало до тях.

И тук идва становището на Института за български език към БАН (Останалите становища имат по-малко общо с езикови аргументи, така че не ги коментирам). В становището на ИБЕ-БАН почти няма цитирана литература, липсва библиографска справка в края. Това беше първи червен флаг. Аргументацията вътре е вярна, доколкото разглежда българската диалектна карта и особеностите в нея, както и литературния български преди кодифицирането на македонския. Но по никакъв начин от това не следва, че има или няма македонски език. Именно защото това не е научен въпрос.

И това е тъжното – че становището на научна институция е с политически цели. Използването на науката с политически цели е нещо, което комунизмът е правил, включително при кодифицирането на македонския език. И вместо да се поучим от това, което не харесваме, правим същото – използваме научни институции за геополитически цели. Може би това е легитимен подход, защото „всички го правят“. Но нека не се заблуждаваме, че това е научно заключение.

И това важи и за двете страни – целият казус започна от (най-вероятна) провокация от страна на македонски научни среди, които публикуваха документ, в който повтарят до болка познати тези за „континюитета“ на македонската нация и езика като част от това. Които БАН правилно опровергава, макар че беше по-добра идея да не пада в капана.

Има ли македонски език или няма е въпрос без значение за лингвистичната наука. И тя няма отговор на него. Но спокойно – това, че има македонски език, защото македонската държава смята така, не означава, че Гоце, Даме и Яне са македонци. Не означава, че Александър Македонски е говорил славянски език. Не дава отговор има или няма македонска нация.

И призивът ми е да не се хващаме за разграничението между език и диалект като нещо толкова значимо за македонския въпрос. Не е.

A Disk-Backed ArrayList

Post Syndicated from Bozho original https://techblog.bozho.net/a-disk-backed-arraylist/

It sometimes happens that your list can become too big to fit in memory and you have to do something in order to avoid running out of memory.

The proper way to do that is streaming – instead of fitting everything in memory, you should stream data from the source and discard the entries that are already processed.

However, there are cases when code that’s outside of your control requires a List and you can’t use streaming. These cases are rather rare but in case you hit them, you have to find a workaround. One is to re-implement the code to work with streaming, but depending on the way the library is written, it may not be possible. So the other option is to use a disk-backed list – one that works as a list, but underneath stores and loads elements from disk.

Searching for existing solutions results in several 3+ years old repos like this one and this one and this one.

And then there’s MapDB, which is great and supported. It’s mostly about maps, but it does support a List as well, as shown here.

And finally, you have the option to implement something simpler yourself, in case you need just iteration and almost nothing else. I’ve done it here – DiskBackedArrayList.java. It doesn’t support many things (not all methods are overridden to throw an exception, but they should). But most importantly, it doesn’t support random adding and random getting, and also toArray(). It’s purely “fill the collection” and then “iterate the collection”. It relies on ObjectOutputStream which is not terribly efficient, but is simple to use. Note that I’ve allowed a short in-memory prependList in case small amounts of data need to be prepended to the list.

The list gets filled in memory until a specified threshold and then gets flushed to disk, clearing the memory which starts getting filled again. This too can be more efficient – with background flushing in another thread that doesn’t interfere with adding elements to the list, but optimizations complicate things and in this case the total running time was not an issue. Most importantly, the iterator() method is overridden to return a custom iterator that first streams the prepended list, then reads everything from disk and finally iterates over the latest batch which is still in memory. And finally, the clear() method should be called in the end in order to close the underlying stream. An output stream could be opened and closed on each flush, but ObjectOutputStream can’t be used in append mode due to some implementation specific about writing headers first.

So basically we hide the streaming approach underneath a List interface – it’s still streaming elements and discarding them when not needed. Ideally this should be done at the source of the data (e.g. a database, message queue, etc.) rather than using the disk as overflow space, but there are cases where using the disk is fine. This implementation is a starting point, as it’s not tested in production, but illustrates that you can adapt existing classes to use different data access patterns if needed.

The post A Disk-Backed ArrayList appeared first on Bozho's tech blog.

Защо новите трудови книжки няма да са електронни?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3458

В последните няколко месеца за втори път се появява новината за новите трудови книжки, а именно – че не просто няма да са електронни, а ще се смени дизайна им с по-грозен.

Трудовите книжки са един ужасен анахронизъм, който трябваше отдавна да е в историята, но по някаква причина не е. Министерство на труда предлага нищо да не се промени по същество и да продължаваме да мъкнем един (в някои случаи) парцал по работодатели, които с нечетим почерк, замазан от огромни печати, да пишат никому ненужна информация.

Защо са ни нужни изобщо трудови книжки? На пръв поглед не ни трябват – всеки трудов договор се регистрира в НАП, т.е. НАП има необходимата информация, а осигурителният стаж се пази в НОИ.

Само, че както винаги, „нещата са малко по-сложни“. Има разлика между осигурителен стаж и трудов стаж. Каква е разликата – може да прочетете на тази „красива“ страница на Главна инспекция по труда. Макар синдикатите да държат на тези разлики, отпадането им би улеснило много системата. Още повече че напр. управителите на фирми не трупат трудов стаж, защото не са на трудов договор, а на договор за управление и контрол, т.е. действащото положение активно наказва предприемачи, които в малките фирми много често вършат същата работа, като работниците, но се водят управители. „Клас прослужено време“ са добавка към заплатата, чието отпадане няма да навреди на никого (и не, работниците няма да вземат по-малко пари; ако тази добавка има значение, работодателите просто дават по-ниска основна заплата, за да се стигне до договорената нетна заплата.)

В трудовата книжка има и други параметри, които в момента никъде не се записват – код на професия, основание за прекратяване на правоотношение, работа на пълен или непълен работен ден и др.

Но дори политическото решение за отпадане на трудовия стаж и приравняването му към осигурителния да е прекалено трудно, проблемът има практически решения, а именно – някой да води регистър на трудовия стаж. Кандидатите са няколко – НАП, НОИ, МТСП, главна инспекция по труда, синдикатите, работодателските организации. Последните, логично, не биха искали и нямат интерес от това. Синдикатите нямат капацитет (те за какво ли имат). За НОИ и НАП това не е присъщи дейности, тъй като не се отнасят до приходи и осигуровки. МСТП и ГИТ остават като логичните администрации, които да водят такъв регистър.

Администрацията вижда воденето на електронен регистър като нещо ужасно тежко. И то в известна степен е, предвид, че все още не е дори стартирал проекта за базов регистър, който да позволи всяка администрация да създават с няколко стъпки изцяло нов регистър. Но дори МТСП/ГИТ да поръчат изграждане на регистър на трудовия стаж, някой трябва да въвежда данни в него. Най-логичното е това да са работодателите, но те може да разглеждат това задължение като допълнителна административна тежест. Тя не е такава, тъй като те така или иначе имат задължение за поддържане на трудови книжки, но от друга страна това добавя стъпка на комуникация с администрацията.

В трудовия договор на практика има цялата тази информация, а за него се изпраща уведомление до НАП. Данните, които трябва да се подават, са описани в Наредба 5 от 2002г, и включват кода на длъжността, възнаграждението, дата, срок, прекратяване.

Съвсем логично решение е просто Наредба 5 да се измени и в уведомлението за сключване на трудов договор да се добавят данните, които се вписват в трудовата книжка. НАП пък от своя страна може да има задължението просто да ги препраща към новосъздаден регистър на трудовите правоотношения („електронна трудова книжка“) в МТСП. По този начин административната тежест не се променя, а единствено се разширява обхвата на уведомлението до НАП.

В трудовата книжка трябва да се вписват и запори (вероятно има и други събития, които не са ми известни). Всички те са сравнително редки случаи и могат да се докладват директно към регистъра в МТСП, отново по електронен път или на хартия, за по-нискотехнологични работодатели.

Първоначалното въвеждане на данните от хартиените книжки пък може да е задължение на работодателя, за което да има срок от една година. При уведомление за новопостъпил работник пък работодателят може да получава отговор, че на този служител данните от трудовата книжка не са въведени и да ги въведе еднократно. Така за няколко години всичко ще е електронно.

След всички тия скучни членове, алинеи и регистри, изглежда, че по-скоро имам отговор на въпроса „как да имаме електронна трудова книжка“, а не защо нямаме.

Отговорът на въпроса в заглавието е нежелание за поемане на отговорност и липса на политическа инициатива. Някой на високо политическо ниво трябва да събере всички участници в процеса, да им предложи подобно на гореописаното решение, да го прецизира заедно с тях и да им наложи неговото изпълнение. Иначе никоя институция няма да си „навлече“ повече работа и повече отговорности.

Нов дизайн на трудовата книжка е каране по една убийствена инерция и единственият начин това да се промени е адекватност в политическото ниво. Не е късно да имаме електронни трудови книжки и да изхвърлим хартията и призовавам новия министър на труда и социалната политика да разгледа сериозно тази възможност.

Near Real-Time Indexing With ElasticSearch

Post Syndicated from Bozho original https://techblog.bozho.net/near-real-time-indexing-with-elasticsearch/

Choosing your indexing strategy is hard. The Elasticsearch documentation does have some general recommendations, and there are some tips from other companies, but it also depends on the particular usecase. In the typical scenario you have a database as the source of truth, and you have an index that makes things searchable. And you can have the following strategies:

  • Index as data comes – you insert in the database and index at the same time. It makes sense if there isn’t too much data; otherwise indexing becomes very inefficient.
  • Store in database, index with scheduled job – this is probably the most common approach and is also easy to implement. However, it can have issues if there’s a lot of data to index, as it has to be precisely fetched with (from, to) criteria from the database, and your index lags behind the actual data with the number of seconds (or minutes) between scheduled job runs
  • Push to a message queue and write an indexing consumer – you can run something like RabbitMQ and have multiple consumers that poll data and index it. This is not straightforward to implement because you have to poll multiple items in order to leverage batch indexing, and then only mark them as consumed upon successful batch execution – somewhat transactional behaviour.
  • Queue items in memory and flush them regularly – this may be good and efficient, but you may lose data if a node dies, so you have to have some sort of healthcheck based on the data in the database
  • Hybrid – do a combination of the above; for example if you need to enrich the raw data and update the index at a later stage, you can queue items in memory and then use “store in database, index with scheduled job” to update the index and fill in any missing item. Or you can index as some parts of the data come, and use another strategy for the more active types of data

We have recently decided to implement the “queue in memory” approach (in combination with another one, as we have to do some scheduled post-processing anyway). And the first attempt was to use a class provided by the Elasticsearch client – the BulkProcessor. The logic is clear – accumulate index requests in memory and flush them to Elasticsearch in batches either if a certain limit is reached, or at a fixed time interval. So at most every X seconds and at most at every Y records there will be a batch index request. That achieves near real-time indexing without putting too much stress on Elasticsearch. It also allows multiple bulk indexing requests at the same time, as per Elasticsearch recommendations.

However, we are using the REST API (via Jest) which is not supported by the BulkProcessor. We tried to plug a REST indexing logic instead of the current native one, and although it almost worked, in the process we noticed something worrying – the internalAdd method, which gets invoked every time an index request is added to the bulk, is synchronized. Which means threads will block, waiting for each other to add stuff to the bulk. This sounded suboptimal and risky for production environments, so we went for a separate implementation. It can be seen here – ESBulkProcessor.

It allows for multiple threads to flush to Elasticsearch simultaneously, but only one thread (using a lock) to consume from the queue in order to form the batches. Since this is a fast operation, it’s fine to have it serialized. And not because the concurrent queue can’t handle multiple threads reading from it – it can; but reaching the condition for forming the bulk by multiple threads at the same time will result in several small batches rather than one big one, hence the need for only one consumer at a time. This is not a huge problem so the lock can be removed. But it’s important to note it’s not blocking.

This has been in production for a while now and doesn’t seem to have any issues. I will report any changes if there are such due to increased load or edge cases.

It’s important to reiterate the issue if this is the only indexing logic – your application node may fail and you may end up with missing data in Elasticsearch. We are not in that scenario, and I’m not sure which is the best approach to remedy it – be it to do a partial reindex of recent data in case of a failed server, or a batch process the checks if there aren’t mismatches between the database and the index. Of course, we should also say that you may not always have a database – sometimes Elasticsearch is all you have for data storage, and in that case some sort of queue persistence is needed.

The ultimate goal is to have a near real-time indexing as users will expect to see their data as soon as possible, while at the same time not overwhelming the Elasticsearch cluster.

The topic of “what’s the best way to index data” is huge and I hope I’ve clarified it at least a little bit and that our contribution makes sense for other scenarios as well.

The post Near Real-Time Indexing With ElasticSearch appeared first on Bozho's tech blog.

Забраната на Airbnb – аналогови хора в дигиталния свят

Post Syndicated from Bozho original https://blog.bozho.net/blog/3449

Тези дни депутати предложиха Airbnb да бъде на практика забранен – предложението е да не могат некатегоризирани обекти по Закона за туризма да се предлагат през платформата. Ограничението не е само за Airbnb, а за Booking, Facebook и други платформи за предлагане на места за настаняваме. Надолу в текста ще ползвам Airbnb като събирателно за всички тях, поради сходния модел.

Тази забрана е още един пример как аналогови хора достигат тавана на възможностите си да възприемат дигиталния свят.

Airbnb е проблем на много места, по много различни начини. И правилното решение почти никога не е „забраняваме го“. Най-малкото защото контролът е скъп и труден до невъзможен и на моменти граничещ с умствено изоставане – задължаваш интернет доставчици да блокират Airbnb за своите клиенти? „Давам апартаменти под наем“ е новото „продавам оръжие“, явно.

Факт е, че хотелиери, собственици на къщи за гости (ама от истинските), и като цяло туристическият бранш е недоволен, че някой може да заобикаля правилата, които важат за тях. И са прави – бизнесът трябва да работи при максимално изравнени външни условия, за да има истинска конкуренция.

Само че тия правила са от преди минимум 20 години, като начин ма мислене поне. Табели, тарифи, категории – все неща, които имат за цел да гарантират удобство на клиента, но не са единствения начин за това – Airbnb дава други начини за гарантиране на това удобство.

Та, вместо да ги забраняваме, каквато е вечната рецепта тук (както стана и с Uber), имам две конкретни предложения, които са със същата философия като предложенията ми за Uber тогава

  • интегриране на Airbnb със системите на НАП за автоматично изпращане на данни за получените плащания. Така данъци няма да могат да се укриват. Естония направи така с Uber – „върза“ ги с API на данъчните.
  • олекотяване на режимите за хотелите, къщите за гости и другите места за настаняване. Всичко да може да става онлайн, за да може усилието да си регистрираш апартамента в Airbnb да е съизмеримо с това да си го регистрираш в Министерство на туризма. А ако сме особено амбициозни, Министерство на туризма да даде API (програмен интерфейс), през който Airbnb автоматично да регистрира обявените места за настаняване, с някакви смятани за важни параметри – тоалетни/бани, квадратура, асансьор, пушене, които така или иначе са важните неща за клиента, а не че нещо е 3 или 4 звезди. Ако МТ пусне такъв интерфейс, ще видим, че за няколко месеца и хотелиерските софтуери ще започнат да го ползват и да обявяват местата си там

Напомням, че в Закона за електеронното управление и подзаконовата нормативна уредба вкарахме изискване всички системи да предоставят всичките си функционалности през програмен интерфейс. Именно за да позволим такива интеграции. За Airbnb това ще е една седмица работа, а те така или иначе са си организирали кода да позволява национални специфики. Само че важността на програмните интерфейси (APIs) за електронното управление остава недоразбрана.

Хората ползват Airbnb не защото искат да бягат от правилата, а защото правилата са неадекватни и начинът на комуникация с институциите е неудобен и тромав. Публикуването на обява в Airbnb е не толкова просто, но удобно и предсказуемо занимание. Ако отворим сайта на Министерство на туризма, виждаме това. Списък с новини в CMS-а на сайта, като всяка препраща към страница със стена от текст и няколко формуляра в doc или pdf, които да разпечатаме и занесем в общината и/или министерството. Еми, не, мерси.

(Знам, че преди време Ангелкова обяви, че всички електронни услуги са достъпни и с eID от един частен доставчик, но за 10 минути търсене не ги открих. Знаейки за една малко известна система – портала за е-форми, все пак ги намерих, но и там са под формата попълване на PDF и изпращането му по електронен път – все пак е нещо, но много далеч от потребителското изживяване на Airbnb)/

Дигиталната трансформация понякога изисква малко мисъл и малко усилия, но аналоговите човечета предпочитат просто да сложат хикса и да кажат „интернет – лош; хора в интернет – лоши“.