All posts by Bozho

Developers Are Obsessed With Their Text Editors

Post Syndicated from Bozho original https://techblog.bozho.net/developers-are-obsessed-with-their-text-editors/

Developers are constantly discussing and even fighting about text editors and IDEs. Which one is better, why is it better, what’s the philosophy behind one or the other, which one makes you more productive, which one has better themes, which one is more customizable.

I myself have fallen victim to this trend, with several articles about why Emacs is not a good idea for Java, why I still use Eclipse (though I’d still prefer some IDEA features), and what’s the difference between an editor and an IDE (for those who’d complain about the imprecise title of this post).

Are text editors and IDEs important? Sure, they are one of our main tools that we use everyday and therefore it should be very, very good (more metaphors about violin players and tennis players, please). But most text editors and IDEs are good. They evolve, they copy each other, they attract their audiences. They are also good in different ways, but most of the top ones achieve their goal (otherwise they wouldn’t be so popular). Sure, someone prefers a certain feature to be implemented in a certain way, or demands having another feature (e.g. I demand having call hierarchies on all constructors and IDEA doesn’t give me that, duh…) But those things are rarely significant in the grand scheme of things.

The comparable insignificance comes from the structure of our work, or why we are being now often called “software engineers” – it’s not about typing speed, or the perfectly optimized tool for creating code. Our time is dedicated to thinking, designing, reading, naming things. And the quality of our code writing/editing/debugging tool is not on the top of the list of things that drive productivity and quality.

We should absolutely master our tools, though. Creating software requires much more than editing text. Refactoring, advanced search, advanced code navigation, debugging, hot-swap/hot-deploy/reload-on-save, version control integration – all of these things are important for doing our job better.

My point is that text editors or IDEs occupy too much of developers’ time and mind, with too little benefit. Next time you think it’s a good idea to argue about which editor/IDE a colleague SHOULD be using, think twice. It’s not a good investment of your time and energy. And next time you consider standardizing on an editor/IDE for the whole team, don’t. Leave people with their preference, it doesn’t affect team consistency.

The post Developers Are Obsessed With Their Text Editors appeared first on Bozho's tech blog.

List of Open Source Security Tools

Post Syndicated from Bozho original https://techblog.bozho.net/list-of-open-source-security-tools/

As a founder of a security company, I’m constantly looking for open source tools to either incorporate in our offering, or get inspiration from, or provide integration with. And there are dozens of great open source security tools, so I decided to publish a list of them. This plethora of options is one of the reasons that security is so hard – they are many different ways to achieve something and it almost always involves headaches with configuring and connecting various “point solutions” (as marketers call them). So here’s the list in on apparent order (note that I’ve listed only defensive tools, offensive ones like metasploit, nmap, wireshark, etc. probably deserve a separate post):

Security monitoring, intrusion detection/prevention

  • Suricata – intrusion detection system
  • Snort – intrusion detection system
  • Zeek – network security monitoring
  • OSSEC – host-based intrusion detection system
  • Wazuh – a more active fork of OSSEC
  • Velociraptor – endpoint visibility and response
  • OSSIM – open source SIEM, at the core of AlienVault
  • SecurityOnion – security monitoring and log management
  • Elastic SIEM – SIEM functionality by Elasticsearch
  • Mozdef – SIEM-like layer ontop of
    Elasticsearch
  • Sagan – log analytics and correlation
  • Apache Metron – (retired) network security monitoring, evolved from Cisco OpenSOC
  • Arkime – packet capture and search tool (formerly Moloch)
  • PRADAS – real-time asset detection
  • BloodHound – ActiveDirectory relationship detection

Threat intelligence

  • MISP – threat intelligence platform
  • SpiderFoot – threat intelligence aggregation
  • OpenCTI – threat intelligence platform
  • OpenDXL – open source tools for security intelligence sharing

Incident response

Vulnerability assessment

  • OpenVAS – very popular vulnerability assessment
  • ZAProxy – web vulnerability scanner by OWASP
  • WebScarab – (obsolete) web vulnerability scanner by OWASP
  • w3af – web vulnerability scanner
  • Loki – IoC scanner
  • CVE Search – set of tools for search in CVE data

Firewall

  • pfsense – the most popular open source firewall
  • OPNSense – hardenedBSD-based firewall
  • Smoothwall – linux-based Firewall

Antivirus / endpoint protection

Email security

I’m sure there are more (and I’d be happy to add them, e.g. this list suggested in reddit, or others in the reddit thread). Assessing each individual tool, its ease of use, its compliance aspects and the combination between multiple tools is a hard task (here’s a SANS paper on “stitching” multiple tools together). And making sense of the whole landscape (as I’ve tried previously) hints about the complexity of a security professional’s job.

The post List of Open Source Security Tools appeared first on Bozho's tech blog.

Кратък наръчник на законодателя

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

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

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

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

  • Не трябва да се въвеждат изисквания за удостоверения – законите създават права и задължения. Когато в закон пише „заявителят представя удостоверение за Х“, то задължението за това е негово. Администрацията може да приложи Закона за електронното управление и вместо да го иска от гражданина, да го събере служебно и да му го представи за потвърждение, но това е заобиколен начин да се изпълни законовото изискване, и поради това не много го правят – а всеки закон се явява специален спрямо Закона за електронното управление и администрацията казва „ами то може в ЗЕУ да пише, че трябва да съберем служебно, ама в НАШИЯ закон пише вие да го представите“. Затова удостоверяването на обстоятелства трябва да е задължение на администрацията, напр. „органът по чл. ХХ установява наличието на следните обстоятелства“. Това оставя възможност все пак за изискване на удостоверение в подзаконовата нормативна уредба, ако такова не може да бъде събрано служебно или авотматизирано, но задължението да разбере дали заявителят отговаря на всички условия е на администрацията
  • Без декларации за служебно проверими обстоятелства – като алтернатива на удостоверенията се използват декларациите – заявителят декларира, че нещо е така, както пише в закона, но ако то се окаже иначе, той носи отговорност за деклариране на неистина (по чл. 313 от Наказателния кодекс). Има немалко дела за това – част от тях се разминават с административна санкция (НК позволява това), но това не значи, че е приятно. Другият минус на тези декларации е, че правят заявяването на услугите по-сложно – освен заявление трябва да се попълват по няколко декларации „по образец“. Нерядко законите (и съответно администрацията) ни кара да декларираме данни, с които администрацията разполага. Къде точно е границата между служебното събиране и декларирането не е очевидно, но ако нещо е толкова значимо, че да бъде законово изискване, то администрацията трябва да разполага с него в структуриран вид. Разбира се, понякога регистър липсва и декларацията е единственият начин, но това трябва да е само в преходен период – докато се появи такъв електронен регистър.
  • Минимизиране на нотариално заверените декларации – декларациите са неудобни, но когато трябва да се разходите до нотариус, това не само ни бави и струва пари, а и чупи възможността за изцяло електронно предоставяне на услугата. Защото документът, който изпращаме, трябва да е сканиран, а не в оригиналния си електронен вид. Още повече, че квалифицираният електронен подпис, поне за някои неща, може да бъде приравнен на нотариално заверен, защото доставчиците на квалифицирани удостоверителни услуги проверяват нашата самоличност като ни издават подписа, а към него съществуват технически гаранции, че не може да бъде копиран и използван от друг. Разбира се, нотариусите няма да останат без работа, но в момента законодателството изисква излишно много нотариални заверки (напр. декларацията по ЗМИП)
  • Необходимо е да се водят електронни регистри – когато се въвежда регистър със закон, той е редно да спазва изискванията на Закона за електронното управление. Макар това да звучи подразбиращо се, то не е така и е нужна изрична препратка към ЗЕУ. Всеки закон урежда реда на водене на своите регистри, но има много общи компоненти, които са съществени и няма нужда да се копират навсякъде – проследимост и история на действията, отворени данни, уникални идентификатори, отворени програмни интерфейси и т.н. Всички тези неща са описани в наредба към ЗЕУ, но рядко се изпълняват, защото липсва връзката между въведения със специален закон регистър и подзаконовата нормативна уредба на ЗЕУ. Затова за всеки нововъведен регистър е добре да има една алинея: „Регистърът по ал. х трябва да отговаря на изискванията на Закона за електронното управление“
  • Задължителна електронна комуникация за големите компании – когато кръгът регулирани от даден закон лица включва големи компании (напр. банки, застрахователи, телекоми), то задълженията за докладване могат и трябва да бъдат само по електронен път. Примерът отново е Законът за мерките срещу изпирането на пари, където има предвидена опция за електронно докладване за съмнителни транзакции от банките към ДАНС, но това не е задължително и съответно тази система не работи ефективно. Банките изпращат писма на хартия, които не е ясно доколко се обработват (имаше такъв казус покрай изтеглена голяма сума от обвиняем). Можем да презюмираме, че компании над определен размер са длъжни да имат адекватен ИТ капацитет.
  • Без несвързани изменения с „преходни и заключителни разпоредби“ – един закон може да изменя други закони, когато има логическа връзка между тях – напр. ако изменяш Закона за търговския регистър и регистъра на юридическите лица с нестопанска цел, ако някой друг закон споменава ЗТРРЮЛНЦ, той може да трябва да бъде изменен. Но нерядко депутатите използват този инструмент да правят абсолютно несвързани промени, защото нещо им е хрумнало (или защото трябва да прокарат нещо по-тихичко). Има си процедура за това – нов законопроект. Ако парламентът работи ефективно, може да гледа малки законопроекти отделно.
  • Без значителни промени между първо и второ четене – между двете четения депутатите могат да правят предложения за промени в даден законопроект. Това е съвсем естествено, тъй като на първо четене се приема законопроектът „по принцип“, а детайлите му се разглеждат на второ четене. Но съществува практиката след като е приет законопроект по принцип, в него да се направят толкова значителни промени, че принципното съгласие по него вече да не е налице. Напр. с редакция между първо и второ четене не върви да се променят данъчни ставки. Ако някой иска да внася някаква значителна промяна, да се е сетил навреме, когато се вкарват за разглеждане група законопроекти по един закон. Ако му е толкова важно, през председателския съвет да помоли да се изчака малко, докато са му готови измененията. Така е доста по-чисто и честно спрямо избирателите, а и спрямо изискванията за оценка на въздействието.

Списъкът не е изчерпателен и не искам да звучи „наставнически“ (въпреки, че имам някакъв законодателен опит, не се имам за гуру). Но това са неща, които народните представители е добре да имат предвид – като предлагат текстове и като гласуват текстове. По-доброто законодателство зависи от всеки един депутат.

Материалът Кратък наръчник на законодателя е публикуван за пръв път на БЛОГодаря.

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

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

Държавна агенция „Електронно управление“ публикува обобщена версия на доклада за съответствие на машините за гласуване.

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

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

  • Предоставени са три машини. Това е малко, като не става ясно от кои партиди на доставка са били, т.е. дали от всяка доставка има поне по една машина.
  • В доклада пише, че „За цялостното произвеждане на изборен процес чрез ТУМГ се използват допълнителни инструменти създаването на Image и инсталирането на операционната система и приложния софтуер.“ – т.е. за всеки избор има отделен image на операционната система плюс приложния софтуер. Според мен е по-добре да има един image на операционната система, а изборите да се конфигурират на приложно ниво. Иначе стои възможността изискванията към операционната система, които според доклада са спазени, да не бъдат спазени при друг image
  • Пише също така, че „Операционната система, инсталирана в основната памет на ТУМГ, има вградена функция, която при всяко зареждане, изчислява контролна сума (”хеш”). Този „хеш“ се визуализира на екрана със системна информация и се отпечатва върху служебните разписки. Чрез проверка за съвпадение с предварително изчисления „хеш“ на компонентите подготвени за инсталиране в ТУМГ се удостоверява и може да се гарантира автентичността на инсталирания в основната памет на ТУМГ базов и потребителски софтуер;“ – това е много важно. Всички застъпници и наблюдатели трябва да поискат от секционните избирателни комисии тази разписка и да яснимат, за да се установи дали всички машини имат идентичен хеш (както се очаква в рамките на един избор). Друг коментар тук е, че не трябва да се разчита на вградената функционалност за изчисляване на хеша, защото тя може да бъде подменена и да визуализира не реалния, а избран хеш. Т.е. трябва при предварителен и последващ одит да се използва външен механизъм за това (поне върху артефактите на приложния софтуер)
  • Докладът казва и следното: „Промените в „образа“ (дизайна)на бюлетината се реализират чрез промени в изходния код на приложението. При произвеждане на нови избори, в които се налага промяна в „образа“ на бюлетината, е необходимо препрограмиране, компилиране и нова инсталация на приложния софтуер в ТУМГ“ – това е много странно решение. Дизайн трябва да може да се реализира чрез шаблони, които да се настройват, вместо да се компилира наново цялото приложение за гласуване. Компилирането наново означава, че освен дизайна, някой може да промени и функционалност по отчитането.
  • Данните и номенклатурите за съответния избор се зареждат чрез USB флаш памет на всяка машина. Прозрачността на този процес не е описана в изборния кодекс, а би следвало съдържанието на тази флаш памет да бъде гарантирано (подписано), и публикувано предварително.
  • Докладът отбелязва, че „При невъзможност имената на партиите и кандидатите, да бъдат визуализирани на един екран, бюлетината се извежда на няколко последователни екрана и преминаването към всеки от тях се извършва с бутони;“ – това е потенциален проблем за партии с по-задни номера. „Моята партия я няма тука“ е нещо, което хора могат да си кажат, докато опитват да гласуват. Не казвам, че е лесно да се направи интерфейсът така, че хем да е идентичен с хартиената бюлетина, хем да не крие част от партиите/коалициите, и този проблем е отчасти заложен от самия Изборен кодекс, но трябва да се отбележи.
  • Протоколът се записва на файл на флашката и се подписва електронно. Докладът, обаче, не казва с какъв частен ключ се случва това и как се управлява той, съответно къде се съхраняват публичните ключове. Дали има един ключ за всички машини или се генерира отделен ключ за всяка? Използват ли се смарткартите на СИК-овете или се съхранява отделно, и ако да – това място защитено ли е от изтичане (съответно от възможността някой да вземе ключа и да подпише нов, фалшифициран протокол). В техническата спецификация се говори за генериране на ключове, но от доклада не става ясно как машините поддържат описания там процес.
  • Техническата спецификация изисква покритие с автоматизирани тестове на поне 70%. Това не е установено от доклада, макар че изглежда, че достъп до изходния код е бил предоставен
  • В доклада много бегло се споменава как е протекъл анализа на изходния код, както и откриването на уязвимости – не се посочва дали са сравнявани наличните компоненти с бази данни от уязвимости (NVD/CVE). Не изглежда да е прилаган статичен анализ на кода за откриване на уязвимости (SAST)
  • Установена е липса на ПИН пликове – това не е драматично и не е част от машините, но изпълнителят трябва да го предостави в изборния ден. Наблюдателите и застъпниците е добре да следят дали такива пликове са налични.
  • Следният сценарий не е изпълнен: „Тестване на модула за валидация и обобщаване на контролни записки, както и проверка на съдържанието на ЗТУ и основната памет на дефектирала машина –чрез устройството за четена на 2D бар кода“, защото от ЦИК не са предоставили необходими документи. Това е притеснително, защото проверката на съдържанието е важно за интегритета на машинния протокол
  • В техническата спецификация има изискване системната информация да бъде електронно подписана. От докладът не става ясно дали това е така.
  • „Всеки запис е в отделен файл, със случайно генерирано име, а всички файлове имат една и съща дата и час.“ – имената вероятно зависят от текущото време, което се използва за генератора на случайни числа (съответно имена). Не изглежда да е направен анализ дали може от имената да се извлече поредността. Това е сложна задача и може би не попада в обхвата на такъв доклад, но в дългосрочен план тази функционалност трябва да се прегледа.
  • Споменава се, че дисковите дялове са криптирани, но не се казва с какъв ключ и дали е full disk encryption, както пише в техническата спецификация. Може би в протоколите има повече детайли.

Със сигурност е редно да бъдат публикувани детайлните протоколи. Редно и поне след изборите да бъде даден достъп на външни експерти да разгледат машините. Редно е ЦИК да предостави достъп до данните от флашките, както и наблюдателите и застъпници да снимат разписките със служебна информация.

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

Материалът Коментари по доклада за съответствие на машините за гласуване е публикуван за пръв път на БЛОГодаря.

За трите папки – съдебна реформа, изборна реформа, модернизация

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

В петък в Панорама Христо Иванов показа три папки, пълни със законопроекти. В едната – за съдебна реформа (вкл. изменение на конституцията), реформа на регулаторите и лустрация. Във втората – за промени в изборните правила, за да не гледаме пак този хаос, който се развива в момента. И третата – за модернизация и електронно управление.

Демократична България ще внесе тези законопроекти на първия ден на следващото народно събрание. Без забавяне, без „да видим“, без „експертите трябва да кажат“. Експертите вече са казали – експертите са в листите и са подготвили тези законопроекти.

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

Предлагаме изменения, с които:

  • администрацията да няма повече оправдания, че „нашият закон е специален и не можем да предоставим услугата по електронен път или да съберем удостоверението по служебен път“ (това, за което бях писал преди време – отпадането на удостоверенията)
  • да електронизираме на практика всички регистри чрез централизирана система за управление на регистри, така че създаването на нов електронен регистър да отнема часове, а не години, и да има възможност за интеграции, отворени данни, проследимост. (миграцията на исторически данни ще последва това). Тази стъпка също е ключова за отпадане на удостоверенията и административната тежест.
  • гражданите да могат да заявяват услуги не само с квалифициран електронен подпис. Тази опция вече съществува частично (въведена на база на мое предложение преди 5 години), но трябва да бъде пояснена и разширена.
  • да уредим отношенията на държавата със системния интегратор, а не както сега „всеки възлага всичко на Информационно обслужване без обществена поръчка“. Това включва каталог на услугите, пълна прозрачност на възлаганията, отчетност, и премахване на (де факто) законово гарантирания монопол.
  • да премахнем някои дребни на пръв поглед проблеми и анахронизми, като синия талон (към шофьорската книжка), като хартиената трудова книжка, като нуждата от изрично заявяване на EORI номер за освобождаване на дребни пратки от извън ЕС, като защитата на данните, събирани от камерите на АПИ, и др.

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

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

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

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

Пътят ще е дълъг, но започва на 4-ти април. С номер 11.

Материалът За трите папки – съдебна реформа, изборна реформа, модернизация е публикуван за пръв път на БЛОГодаря.

Избирателния права и гражданска регистрация

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

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

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

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

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

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

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

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

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

Разбира се, това минава през вкарване на адекватни хора в парламента. На 4-ти април с #11.

Материалът Избирателния права и гражданска регистрация е публикуван за пръв път на БЛОГодаря.

Always Name Your Thread Pools

Post Syndicated from Bozho original https://techblog.bozho.net/always-name-your-thread-pools/

Our software tends to use a lot of thread pools – mostly through java.util.concurrent.ExecutorService implementations (Created via Executors.new.... We create these for various async use-cases, and they can be seen all over the place. All of these executors have a thread factory. It’s hidden in the default factory method, but you can supply a thread factory. If not supplied, a default thread factory is used whenever a thread is needed.

When using spring, those can be created using <task:executor />. In that case, each executor service’s thread factory is provided by spring and it uses the name of the executor bean (specified with id="executorName"). But for those not created by spring, a default name is used which isn’t helpful and doesn’t let you differentiate threads by name.

And you need to differentiate threads by name – in case of performance issues you have various options to investigate: thread dumps and using the top command. In both cases it’s useful to know what function does a thread service, as the stacktrace in the dump might not always be revealing.

And my favorite tool for quick investigation is top. More precisely, top -H -p <pid>. This shows the usual top table, but the -H flag means that threads for the chosen process should be printed. You basically get the most CPU-heavy and currently active threads, by name. In those cases it’s extremely useful to have custom names.

But how do you set a name? By specifying a named thread factory when creating each executor. Here’s a stackoverflow answer with multiple ways to achieve thread naming.

The method that I’m using is based on the 2nd answer:

public class AsyncUtils {
    public static ThreadFactory createNamedThreadFactory(String name) {
        return new ThreadFactoryBuilder().setNameFormat(name + "-%d").build();
    }
}

Centrally managing all executors through spring might be a better idea, but not everyone is using spring and sometimes an executor is needed for a small piece of functionality that could even go outside spring beans. So it’s a good idea to have that method up your sleeve.

The post Always Name Your Thread Pools appeared first on Bozho's tech blog.

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

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

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

Не е тайна, че съм част от Да, България от самото начало – от инициативния комитет и учредяването на партията, до ден днешен. До момента, обаче, не съм бил кандидат – нито на парламентарните избори 2017г, нито на европейските, нито на местните. Заради бизнес, семейство, предпазливост. На тези парламентарни избори, обаче, не мога да си позволя да стоя отстрани. И не че през цялото това време не съм помагал експертно и комуникационно, но сега е различно.

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

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

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

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

На осмо място съм в листата на Демократична България в 23-ти МИР (София). Предвид, че това място по подразбиране не е избираемо, може отстрани да изглежда, че съм „използван“ или че съм „пълнеж“. Не се чувствам така и влизането в тази листа на това място е мое, осъзнато решение. Да, при настоящите социологически данни не изглежда, че Демократична България ще събере достатъчно гласове, за да вкара 8 души от този район.

Но с участието си в листата искам да дам ясен сигнал, че парламентарната група ще може да разчита на мен и че електронното управление ще ѝ бъде приоритет. Затова са листите – те не са просто хората, които ще влязат, а и хората, които публично са се ангажирали с дадена политика. Пред мен в листата от Да, България са Антоанета Цонева и Надежда Йорданова – именно хората, с които в последните четири години съм работил по всеки законопроект и всяка позиция на тема е-управление. Така че нямам съмнение, че те ще са проводници на тези политики, с пълната ми подкрепа.

Програмата на Демократична България за Електронно управление и модернизация на администрацията вече е публикувана. Участвал съм активно в нейното писане, смятам я за реалистична, а много от нещата могат да бъдат придвижени напред както в управление, така и в опозиция.

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

Искам да благодаря предварително на всички за подкрепата и доверието, за търпението и разбирането. Знаете, че чрез мен ще имате де факто човек в парламента. Но по-важното – че давате гласа си за листа, чрез която България да стане по-добро място. Чрез силен политически натиск за съдебна реформа и модернизация ще можем да реализираме потенциала си като държава. Избрал съм да живея тук с този аргумент и именно затова толкова ми допада предизборния ни слоган – България може много повече!

Материалът Защо съм кандидат за народен представител е публикуван за пръв път на БЛОГодаря.

Connecting to Kibana Within an AWS VPC

Post Syndicated from Bozho original https://techblog.bozho.net/connecting-to-kibana-within-an-aws-vpc/

When you use the managed Elasticsearch service on AWS, you usually choose an encrypted connection (via KMS-managed keys), which means you can’t use just any tool to connect to your Elasticsearch cluster. In fact, in order to manually execute commands the easiest option is to use the built-in Kibana and its dev tools.

However, connecting to Kibana is also not trivial due to typical security precautions. Elasticsearch can be run outside or inside a VPC. If you run it outside a VPC, you have to modify its access policy to allow connections from a set of IPs (e.g. your office network).

But if you run it inside a VPC (which is recommended), you have to connect to the VPC. And you have a lot of options for that, but all of them are rather complicated and sometimes even introduce additional cost.

A much simpler approach is to connect via SSH to a machine in the VPC (typically your bastion/jump host) and use it as a SOCKS proxy for your browser. The steps are:

  1. Open an SSH tunnel. If you are using Windows, you can do it with PuTTy. On Linux, you can use ssh$ ssh -D 1337 -q -C -N [email protected]
  2. Set the SOCKS proxy in the browser. On Firefox, open Options and type “SOCKS”, you’ll have only one option (in Network options) to choose, and then set localhost, 1337 (or whatever port you’ve chosen). Here are the instruction for Chrome (or you can use a plugin)
  3. Open the Kibana URL in the browser. Note that now all your browser traffic will go through your VPC, so depending on the VPC configuration other websites might not work.

That’s it, a quick tip that might potentially save a lot of time trying to get a VPC connection to work.

The post Connecting to Kibana Within an AWS VPC appeared first on Bozho's tech blog.

Чиповете, които държавата ще слага на автомобилите, са грешно решение

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

ИААА (по-известна като ДАИ) ще слага чипове на автомобилите (по-конкретно – чипове в стикерите за технически преглед). Доста притеснителен подход с много проблеми и малко ползи.

Да започнем от чисто процедурните аспекти – на сайта на ИААА липсва информация за обществено обсъждане по въпроса. Такова има на strategy.bg, но там в мотивите изобщо не се засяга въпроса с чиповете. Това се случило миналата година, но аз не помня адекватно обсъждане по темата. Затова и чак сега разбирам за него.

Измененията в наредбата са с цел маркиране на екологичните показатели на автомобилите, което само по себе си е добре, но не бих реализирал мерките чрез задължителен RFID стикер. В наредбата се говори за „стикер“ и единствено в приложение на края на наредбата става ясно, че ще има чип. Какви са проблемите (и ще извините техническите детайли, но и те са важни)?

  • Всеки може да прочете поне част от съдържанието на чипа. UHF RFID може да бъде четен на 5-6 метра, но в зависимост от големината може да стигне и до 30, така че със сравнително проста техника всеки може да записва номера на преминаващи автомобили през определени места.
  • Избраният стандарт не е предвиден за такива цели. EPCGlobal е стандарт, с който може да се заменят баркодовете за маркиране на продукти. Той не предвижда криптиране на данните. Според наредбата някои данни в чипа ще се „кодират“, но не казват как. Кодирането е некриптографска трансформация, т.е. не е нужен ключ, за да бъде декодирана записаната информация. Дори да е използван грешния термин, наредбата не казва кой създава и пази ключовете и как. Т.е. на практика дори „кодираните“ данни са достъпни за всички, или поне за „определени хора“. Тези данни включват технически параметри, но и административни такива – регистрационен номер, дата на регистрация, и др. Включва и доста данни, потенциално полезни на автокрадци, например.
  • Четенето на регистрационни номера става с камери, които трябва да са обозначени и са видими на пътя. Четенето на RFID чип става тихомълком и без да разберете, че някой го е прочел.
  • Обикновено такива чипове могат да бъдат клонирани (стандартът определя различни възможности за защита, но наредбата не казва какъв ще бъде използван). Т.е. на черния пазар ще тръгнат фалшиви чипове.
  • Не се предвижда нищо за екраниране на чипа или за неговото повреждане. Т.е. съвсем спокойно в един момент половината чипове в стикерите могат да спрат да работят.
  • Според изпълнителния директор на агенцията (който преди това работеше в КАТ и има репутация на добър професионалист), в чипа ще има данни за собственика на автомобила, а не само технически параметри на автомобила. Това би било безкрайно притеснително, но според наредбата не е вярно. Та г-н Рановски ли бърка, медиите ли са предали грешно думите му, или ИААА планира да сложи лични данни?
  • Няма нужда от това. Информацията за екологичния клас и останалите технически параметри трябва да се намира в централизирана база данни, а не да се размотава по чипове. Органите, на които им е нужна, ще могат да си я набавят по регистрационен номер на автомобила (чрез ръчно въвеждане или чрез автоматична проверка чрез камери), като за това ще остават необходимите следи, предпазващи от злоупотреби. Ако някоя община иска да контролира допустимите автомобили в дни с повишено замърсяване, да направи това с камери, а не с четци за чипове.

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

Материалът Чиповете, които държавата ще слага на автомобилите, са грешно решение е публикуван за пръв път на БЛОГодаря.

За добрия сън (включително с бебе)

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

Преди месец Кака Сийка написа 24 съвета за добър сън. С повечето съм съгласен, но имам коментари и добавки. На първо място – сънят е много важен. Много.

Ето десетина причини, но нещата са още по-критични – хроничното недоспиване има дълготрайно негативно влияние върху мозъка. Така че прочетете тези съвети. Имам следните коментари и добавки от мен:

  • Медитацията е важна във всички нейни форми, но на мен най-полезното ми е способността да спирам да мисля. Понякога е трудно да заспиш, а мозъкът ти превърта темите от изминалия или от следващия ден. Тогава е най-важно да можеш да се „изключиш“, вместо час по късно още да не си заспал.
  • Т.нар. powernap (10-20 минутна, най-често следобедна, дрямка) е много полезен. Вместо следобедно кафе или непродуктивно дремене пред монитора, може да дремнете. На бюрото, дори (а в условия на работа от вкъщи е по-лесно). Културата на работното място е важен аспект тук, защото някъде не е допустимо да си спиш на бюрото, но всъщност дори от гледна точка на работодателя е по-добре да дремнеш 10 минути и да си свеж и продуктивен, отколкото да си полузаспал и нищо да не свършиш.
  • Не съм съгласен, че трябва да си направим перфектната спалня – перфектно тъмна, перфектно тиха. Защото така влизаме в сценария „принцесата и граховото зърно“ – всеки път, когато спим на друго място, нещо ни дразни и буди. А се случва да спим у роднини, на хотел, на почивка или в командировка. Да, стаята трябва да е тиха и затъмнена, но не ни трябва „сферичен кон във вакуум“.
  • На студено се спи по-добре. Тук има различни предпочитания, но препоръчителната температура за сън е 18.3 градуса. Това значи, че спокойно може да спите на отворен прозорец през зимата (ако около вас е сравнително тихо). Или поне да намалявате парното.
  • Когато избирате къде да живеете (под наем или в собствено жилище), съобразявайте околния шум – булеварди, нощни заведения, дори съседи. Ако нещо влияе силно негативно на съня, това сваля значително качеството на живот, без значение колко добре е ремонтиран апартаментът.
  • „Не бъдете дебел“ не е съвет, с който съм съгласен. Не че не е добре човек да е във форма, но понякога това не е избор, а понякога е следствие, а не причина за лошия сън. А сънна апнея може да има всеки (и на мен ми се случва понякога).

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

  • Сънят на бебето е пряко свързан със съня на родителите, така че усилията за по-добър сън на бебето са важни. Катя е обобщила всичко, което е прочела по темата, за да подобри съня на Оги, и оттам – нашия. Препоръчвам за четене. За начало – дълги разходки навън, дори през зимата, са полезни за съня на бебето
  • Потърсете режим, който работи за вас и не се притеснявайте той да включва сън на дивана. Оги, например, се буди всяка нощ между 1 и 3. След известно време опити да бъде приспан в леглото си, което разсънва и Катя и мен, решихме проблема – аз отивам да спя на един топматрак на дивана в хола, а тя продължава с Оги на спалнята. Така спим от година и нещата са много гладки.
  • Оставяйте си буфери – понякога бебетата будуват през нощта (на Оги му се случваше редовно). Така че в сметките „как да направя 7-8 часа сън“ ви трябва поне един час буфер.

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

Материалът За добрия сън (включително с бебе) е публикуван за пръв път на БЛОГодаря.

Elasticsearch – Scalability and Multitenancy [slides]

Post Syndicated from Bozho original https://techblog.bozho.net/elasticsearch-scalability-and-multitenancy-slides/

Last week I gave a talk in a local tech group about my experience with Elasticsearch at LogSentinel, and how we achieve multitenancy and scalability.

Obviously, the topic of scalability is huge and it can’t be fully covered in 45 minutes, but I tried presenting the main aspects from the application perspective (I entirely skipped the Ops perspective, as it was a developer audience). The list of resources at the end of the slides show some of the sources of my “research” on the topic, which I recommend going through.

Below are the slides (the talk was not in English):

I hope it’s a useful intro to the topic and the main conclusion is – it’s counterintuitive if you are used to relational databases, and some internals (shards, Lucene segments) “leak” through the abstractions to influence the application design (as per the law of leaky abstractions).

The post Elasticsearch – Scalability and Multitenancy [slides] appeared first on Bozho's tech blog.

„Тук не е информация“ като символ

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

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

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

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

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

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

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

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

Но като погледнеш какво е отчетено – обикновено изхарчени пари, закупени предмети (или лицензи) и най-много някое проведено обучение. В повечето стратегически документи в държавата (стратегии, пътни карти, екшън планове) твърде рядко има каквито и да било индикатори за успех, а когато такива има, те не са свързани с отчитане на постигнатото, а с отчитане на извършеното. Пренесохме 20 чувала! Само че реално 10 чувала са отишли и после са се върнали. Работа е свършена, резултат няма.

„Тук не е информация“ е начинът на администрацията да ни каже „ние и нашите административни ръководители сме извършили преките си нормативни изисквания дотолкова, че да не ни съдите, а политическото ни ръководство е заето с кой знае какво“.

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

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

Колкото и да не ми се иска текстът да звучи негативно, това е неизбежно. Само че има как тук да бъде информация. Да има информация. Да бъде удобно.

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

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

Материалът „Тук не е информация“ като символ е публикуван за пръв път на БЛОГодаря.

Content-Security-Policy Nonce with Spring Security

Post Syndicated from Bozho original https://techblog.bozho.net/content-security-policy-nonce-with-spring-security/

Content-Security-Policy is important for web security. Yet, it’s not mainstream yet, it’s syntax is hard, it’s rather prohibitive and tools rarely have flexible support for it.

While Spring Security does have a built-in Content Security Policy (CSP) configuration, it allows you to specify the policy a a string, not build it dynamically. And in some cases you need more than that.

In particular, CSP discourages the user of inline javascript, because it introduces vulnerabilities. If you really need it, you can use unsafe-inline but that’s a bad approach, as it negates the whole point of CSP. The alternative presented on that page is to use hash or nonce.

I’ll explain how to use nonce with spring security, if you are using .and().headers().contentSecurityPolicy(policy). The policy string is static, so you can’t generate a random nonce for each request. And having a static nonce is useless. So first, you define a CSP nonce filter:

public class CSPNonceFilter extends GenericFilterBean {
    private static final int NONCE_SIZE = 32; //recommended is at least 128 bits/16 bytes
    private static final String CSP_NONCE_ATTRIBUTE = "cspNonce";

    private SecureRandom secureRandom = new SecureRandom();

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;

        byte[] nonceArray = new byte[NONCE_SIZE];

        secureRandom.nextBytes(nonceArray);

        String nonce = Base64.getEncoder().encodeToString(nonceArray);
        request.setAttribute(CSP_NONCE_ATTRIBUTE, nonce);

        chain.doFilter(request, new CSPNonceResponseWrapper(response, nonce));
    }

    /**
     * Wrapper to fill the nonce value
     */
    public static class CSPNonceResponseWrapper extends HttpServletResponseWrapper {
        private String nonce;

        public CSPNonceResponseWrapper(HttpServletResponse response, String nonce) {
            super(response);
            this.nonce = nonce;
        }

        @Override
        public void setHeader(String name, String value) {
            if (name.equals("Content-Security-Policy") && StringUtils.isNotBlank(value)) {
                super.setHeader(name, value.replace("{nonce}", nonce));
            } else {
                super.setHeader(name, value);
            }
        }

        @Override
        public void addHeader(String name, String value) {
            if (name.equals("Content-Security-Policy") && StringUtils.isNotBlank(value)) {
                super.addHeader(name, value.replace("{nonce}", nonce));
            } else {
                super.addHeader(name, value);
            }
        }
    }
}

And then you configure it with spring security using: .addFilterBefore(new CSPNonceFilter(), HeaderWriterFilter.class).

The policy string should containt `nonce-{nonce}` which would get replaced with a random nonce on each request.

The filter is set before the HeaderWriterFilter so that it can wrap the response and intercept all calls to setting headers. Why it can’t be done by just overriding the headers after they are set by the HeaderWriterFiilter, using response.setHeader(..) – because the response is already committed and overriding does nothing.

Then in your pages where you for some reason need inline scripts, you can use:

<script nonce="{{ cspNonce }}">...</script>

(I’m using the Pebble template syntax; but you can use any template to output the request attribute “csp-nonce”)

Once again, inline javascript is rarely a good idea, but sometimes it’s necessary, at least temporarily – if you are adding a CSP to a legacy application, for example, and can’t rewrite everything).

We should have CSP everywhere, but building the policy should be aided by the frameworks we use, otherwise it’s rather tedious to write a proper policy that doesn’t break your application and is secure at the same time.

The post Content-Security-Policy Nonce with Spring Security appeared first on Bozho's tech blog.

2020: Сблъсък на дезинформацията с живота и здравето

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

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

Няма да опитвам да оборвам всички измислици относно COVID-19 ваксините – това вече са го правили много хора с по-подходяща квалификация от мен (биолози, лекари). Накратко – не, във ваксината няма чипове. Не, не се умира от нея. Не, не ни променя ДНК-то. Не, не е направено „много бързо“ (а е стъпила на години изследвания на предишната епидемия с коронавирус в Азия – SARS-CoV-1, както и на MERS в близкия изток). Не, хората, които си слагат ваксина по телевизията не си инжектират водя или глюкоза. И т.н.

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

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

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

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

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

Хората не са свикнали да отсяват такъв поток от информация и съответно той директно влияе не възприятието им за света. А кой се грижи за отсяването на информацията? Социалните мрежи. Фейсбук, Гугъл (YouTube), Туитър. Техните алгоритми промотират или ограничават разпространението на дадено съдържание – на новина, на статус, на снимка.

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

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

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

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

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

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

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

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

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

Материалът 2020: Сблъсък на дезинформацията с живота и здравето е публикуван за пръв път на БЛОГодаря.

Releasing Often Helps With Analyzing Performance Issues

Post Syndicated from Bozho original https://techblog.bozho.net/releasing-often-helps-with-analyzing-performance-issues/

Releasing often is a good thing. It’s cool, and helps us deliver new functionality quickly, but I want to share one positive side-effect – it helps with analyzing production performance issues.

We do releases every 5 to 10 days and after a recent release, the application CPU chart jumped twice (the lines are differently colored because we use blue-green deployment):

What are the typical ways to find performance issues with production loads?

  • Connect a profiler directly to production – tricky, as it requires managing network permissions and might introduce unwanted overhead
  • Run performance tests against a staging or local environment and do profiling there – good, except your performance tests might not hit exactly the functionality that causes the problem (this is what happens in our case, as it was some particular types of API calls that caused it, which weren’t present in our performance tests). Also, performance tests can be tricky
  • Do a thread dump (and heap dump) and analyze them locally – a good step, but requires some luck and a lot of experience analyzing dumps, even if equipped with the right tools
  • Check your git history / release notes for what change might have caused it – this is what helped us resolve the issue. And it was possible because there were only 10 days of commits between the releases.

We could go through all of the commits and spot potential performance issues. Most of them turned out not to be a problem, and one seemingly unproblematic pieces was discovered to be the problem after commenting it out for a brief period a deploying a quick release without it, to test the hypothesis. I’ll share a separate post about the particular issue, but we would have to waste a lot more time if that release has 3 months worth of commits rather than 10 days.

Sometimes it’s not an obvious spike in the CPU or memory, but a more gradual issue that you introduce at some point and it starts being a problem a few months later. That’s what happened a few months ago, when we noticed a stead growth in the CPU with the growth of ingested data. Logical in theory, but the CPU usage grew faster than the data ingestion rate, which isn’t good.

So we were able to answer the question “when did it start growing” in order to be able to pinpoint the release that introduced the issue. because the said release had only 5 days of commits, it was much easier to find the culprit.

All of the above techniques are useful and should be employed at the right time. But releasing often gives you a hand with analyzing where a performance issues is coming from.

The post Releasing Often Helps With Analyzing Performance Issues appeared first on Bozho's tech blog.

Да оправим наредбата за електронните рецепти

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

Министерският съвет е приел изменение на наредбата за реда за отпускане на лекарствени продукти, добавяйки текстове за електронна рецепта., която е обнародвана днес.

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

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

Ето и моите критики и предложения:

  • Наредбата казва, че „електронните предписания се издават, въвеждат, обработват и съхраняват чрез специализиран медицински и аптечен софтуер.“. Електронните рецепти трябва да се съхраняват в Националната здравна информационна система (НЗИС), а не в медицинския и аптечен софтуер. Там може да се съхраняват временно и за удобство, но централното място за съхранение трябва да бъде НЗИС. В следваща алинея наредбата урежда „висящото“ положение на прогресивно появяваща се НЗИС, което може да звучи добре, но няма как да е нормативен акт. Наредба не може да казва „като стават някакви неща, ще видим как ще ги ползвате“.
  • Наредбата казва, че „За издаването на електронно предписание лекарят или лекарят по дентална медицина се идентифицира чрез КЕП“. Ред за идентифициране с КЕП има временен по наредба към Закона за електронното управление и е редно тази наредба да препрати към нея, защото иначе „идентификация с КЕП“ не значи нищо. А е важно в този контекст как точно ще се извършва идентификацията. Правилният подход е от квалифицираният електронен подпис на лекаря да се вземе ЕГН-то, то да се провери в регистъра на лекарите (или фармацевтите, за които имат сходен ред в следващия член) (вместо, например, да се изисква вписване на служебен номер в КЕП). Също така, идентификация трябва да може да се извършва и по реда на Закона за електронната идентификация. Но при издаване, процесът на идентификация може всъщност да е излишен – предвид, че рецепта се издава чрез софтуер при лекаря (и се проверява в аптеката), лекарят вече е влязъл в системата. Наредбата не казва пред кого се идентифицират, така че стъпката може да се премахне.
  • Според наредбата „При електронното предписване на лекарствения продукт се извършва автоматична проверка в регистъра [..]“ – тук е важно да се отбележат техническите параметри на тази проверка, т.е. посоченото по-горе – че на база на ЕГН се извлича УИН. Дали регистъра на БЛС и на фармацевтите поддържат такава справка? И да не поддържат, може бързо и лесно да се добави, тъй като я има. Но по-проблемното е тази алинея е, че тя не представлява норма, а прави разказ. Нормативните актове създават права и задължения. Не може да кажеш „се прави проверка“. Казваш кой е длъжен да направи тази проверка. Освен, че е лош нормативен текст, наистина не става ясно кой е длъжен да я прави – дали доставчикът на болничен и аптечен софтуер, или, както е правилно – НЗИС, откъдето трябва да минават всички рецепти. Само че НЗИС не е лице, на което може да се вменят задължения, така че трябва ясно да се напише, че Министерството на здравеопазването прави тази проверка чрез НЗИС.
  • Подписване на рецептата с КЕП според наредбата се прави след проверка в регистрите, а е редно да е обратно – в момента на изпращане на подписаната рецепта към НЗИС, да се проверят всичките ѝ реквизити.
  • След като пациентът отиде в аптеката,“ Магистър-фармацевтът извършва действия по идентифициране на издаденото електронно предписание, при които като водещ критерий използва ЕГН на пациента.“ – това тука е доста проблемно. Според публичните изказвания от преди месец идентифицирането на рецептата трябваше да става по ЕГН и последните 4 цифри от кода на рецептата. Този текст не казва как се прави проверка, „водещ критерий“ е неясно. Може ли само по този критерий (не би трябвало)? По кои други критерии може – ЕГН+номер на лична карта, ЕГН+4 цифри от номер на рецепта? По принцип е добре да се спести разпечатване на електронни рецепти (защото това би ги обезсмислило), така че предложението, което аз бях направил пред 8 месеца беше ЕГН+номер на лична карта, или поне част от номер на личната карта. Фармацевтът може да вижда няколко активни рецепти и е добре да знае коя да изпълни. Дали това трябва да се опише в наредба е спорно, но предвиждам обърквания, поне в началото
  • „При осигурени технически и организационни условия за това от Министерството на здравеопазването и НЗОК“ – това е много неясен критерий, за да го има в нормативен акт. Редно е държавата първо създаде условията и тогава да налага срокове.
  • Липсват изисквания за сигурност и защита на данните – в какъв вид НЗИС обработва и съхранява рецептите? След колко време те се изтриват или анонимизират? Има ли проследимост кой какви справки е правил – напр. фармацевти по кои ЕГН-та са търсили и съответно има ли отпуснати след това лекарства. Кой до каква функционалност има достъп? Как е уреден достъпа до НЗИС в МЗ, включително за справочни функционалности? Комисията за защита на личните данни дала ли е становище по проекта на наредба?
  • Липсват ясни инструкции за доставчиците на болничен и аптечен софтуер – къде и какви номенклатури да ползват и имат ли гаранция, че те са актуални. Наредбата казва, че „Програмните интерфейси и номенклатурите за обмен на информация между медицинския и аптечен софтуер и НЗИС се актуализират текущо“, но това е неясно и неприемливо. Липсва препратка към чл. 14 от наредбата към Закона за електронно управление, която урежда поддържането на версии на програмните интерфейси – не трябва да може МЗ/НЗИС да смени от днес за утре един итнерфейс и всичко да се счупи.
  • Не е уреден форматът на кода на рецептата. Това е малък проблем, но обикновено се урежда с нормативния акт, който въвежда дадена система. Бих предложил да следва предписанията на чл. 4, ал. 5 от наредбата към ЗЕУ, т.е. да ползва UUID (RFC 4122), особено ако няма да се налага да се цитират 4 цифри/букви от него

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

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

Материалът Да оправим наредбата за електронните рецепти е публикуван за пръв път на БЛОГодаря.

Електронно трудово досие?

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

Пандемия. Работа от вкъщи. Обаче…

Трудовото законодателство е над тия неща и съответно работодателите и служителите трябва да си общуват на хартия за неща като болнични, отпуски, фишове и други.
Сега запознатите ще кажат „ама то от 2018г. има наредба за електронно трудово досие“. А-ха! Има, ама… все едно няма:

(4) Електронни изявления между страните по трудовото правоотношение се връчват чрез услуга за електронна препоръчана поща.

Т.е. не може ти просто да си изпратиш неща по имейла, а служителите да ги подпишат в Adobe Reader (дали с КЕП или с друг вид подпис, няма значение), и после да ги сложиш в папката в OneDrive/Google Drive на съответния служител. Не. Трябва да ползваш удостоверителна услуга по смисъла на регламента (или да си изградиш такава). И също така:

(3) Всяко действие в системата се удостоверява с квалифициран електронен времеви печат.

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

Да, някои много, много иновативни компании може и да изградят такава система (или някой да направи такава система „като услуга“), да сключат допълнителни споразумения със служителите за ползването на системата, да се закачат към някоя удостоверителна услуга за препоръчана електронна поща, и да уговорят какъв вид електронен подпис приемат.

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

Има, разбира се, компании, които предоставят услуга, която е в съответствие с наредбата: EHR.bg, timeoff, Тереза. Което е разбираемо и хубаво – когато се появи някаква свръхрегулация, се намира кой да предостави услуга, която да улесни регулираните субекти, срещу съответното заплащане. Признавам, не съм разглеждал тези софтуери/услуги в детайли и дали отговарят на всички изисквания (бих искал да видя квалифицирания печат, напр., както и реализацията на услуга за препоръчана електронна поща)

Само че как щеше да е по-добре да стане това, така че да не се въвежда допълнителна бюрокрация, нужда от допълнителен доставчик, разходи и увеличен риск заради споделянето на данни за трудовото правоотношение с трети лица, но в същото време правата на служителите да са защитени? Без да оставаме на хартия, (както с трудовата книжка)

  • Ориентиране на наредбата не към имагинерни системи за електронни трудови досиета, а към т.нар. HRM системи (Human Resource Management, системи за управление на човешки ресурси)
  • Наредбата да определи какво счита за електронен подпис, защото не само квалифицираният е такъв – „read receipt“ може да бъде електронен подпис (оставил е данни в електронен вид до изходящото писмо, което е също данни в електронен вид), може да бъде сканиран подпис, сложен в Adobe Reader, може да е дори нарисуван на екран подпис. Може да бъде вход и поставяне на инициали в документ в облачна услуга, която пази история на редакциите и удостоверява потребителя с неговите данни за достъп. Не че в момента наредбата ги изключва, но в общия случай бизнеса не влиза в тези правно-философско-технически дебри на Регламент (ЕС) 910/2014
  • Отпадане на изискването на услуга за препоръчана електронна поща. Да, трябва да се удостовери, че служителят наистина е получил документа (а работодателят не е направил това вместо него), но при трудови спорове, които биха били редки за най-тривиалните неща като отпуски и болнични, обстоятелствата мога да се установят от вещо лице – при облачни email услуги по-лесно, при локални – със съответните проверки на логове както на сървър, така и на компютъра на служителя.
  • Отпадане на изискването за квалифицирани електронни времеви печати – да, времето на настъпване на събитията е важно. При използване на облачни HR системи биха били изпълнени условията за (обикновен) времеви печат, тъй като датите в системата не могат да бъдат манипулирани от работодателя. При локално инсталирана такава би съществувал потенциален риск от манипулиране на времето на настъпване на някакво събитие, но отново – ако има копие за служителя, на негов компютър, както и свидетели, би било възможно при трудов спор да се установи истината. Хартиени документи също могат да бъдат подправени, като и в двата случая това може да бъде документно престъпление.

С други думи – относно поне най-масовите документи, като фишове за заплата, болнични и отпуски, „качени са в HR системата и са прегледани от служителя“ или „изпратени са по имейл“ или „качени са в съответната папка на служителя в Google Drive / OneDrive / на FTP-то и има логове за достъпа до тях“ трябва да е напълно валиден начин за водене на електронно трудово досие. Що се отнася до анекси и допълнителни споразумения и други по-чувствителни документи, те могат да изискват квалифициран електронен подпис или да се случват на хартия, ако служителят няма такъв. Но заради хипотезата на трудов спор във връзка с подправени документи за изплатени суми, болнични или отпуски, не бива да осакатяваме и свръхрегулираме цялата трудова документация, на практика оставяйки я в хартиения свят.

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

Материалът Електронно трудово досие? е публикуван за пръв път на БЛОГодаря.

Syntactic Sugar Is Not Always Good

Post Syndicated from Bozho original https://techblog.bozho.net/syntactic-sugar-is-not-always-good/

This write-up is partly inspired by a recent post by Vlad Mihalcea on LinkedIn about the recently introduced text blocks in Java. More about them can be read here.

Now, that’s a nice feature. I’ve used it in Scala several years ago, and other languages also have it, so it seems like a no-brainer to introduce it in Java.

But, syntactic sugar (please don’t argue whether that’s precisely syntactic sugar or not) can be problematic and lead to “syntactic diabetes”. It has two possible issues.

The less important one is consistency – if you can do one thing in multiple, equally valid ways, that introduces inconsistency in the code and pointless arguments of “the right way to do things”. In this context – for 2-line strings do you use a text block or not? Should you do multi-line formatting for simple strings or not? Should you configure checkstyle rules to reject one or the other option and in what circumstances?

The second, and bigger problem, is code readability. I know it sounds counter-intuitive, but bear with me. The example that Vlad gave illustrates that – do you want to have a 20-line SQL query in your Java code? I’d say no – you’d better extract that to a separate file, and using some form of templating, populate the right values. This is certainly readable when you browse the code:

String query = QueryUtils.loadQuery("age-query.sql", timestamp, diff, other);
// or
String query = QueryUtils.loadQuery("age-query.sql", 
       Arrays.asList("param1Name", "param2Name"), 
      Arrays.asList(param1Value, param2Value);

Queries can be placed in /src/main/resources and loaded as templates (and cached) by the QueryUtils. And because of the previous lack of text blocks, you would not prefer ugly string concatenated queries inside your code.

But now, with this feature, you are tempted to do that, because, well, it looks good. Same goes for Elasticsearch queries, for JSON templates and whatnot. With this “sugar” you have more incentive to just put them in the code, where they, arguably, make the code less readable. If you really have to debug the query, as opposed to assuming its semantics by its name and relying on a proper implementation, you can easily go to age-query.sql and work with it. Just like when you extract a private method with some implementation details so that it makes the calling method more readable and easy to follow.

Both problems have manifested themselves in my Scala experience, which I’ve summed up in my talk “Scala – the good, the bad and the very ugly” (only slides available). Scala allows you to express things nicely and in multiple ways, which leads to inconsistencies and horrible code readability in some cases.

Counter intuitively, sometimes the syntactic improvements may be worse for code readability. Because they introduce complexity and because they make it easier to do the wrong thing.

That’s not a universal complaint, and certainly syntactic sugar is needed – you don’t have to write List<String> list = new ArrayList<String>() if you can use the diamond operator. But each such feature should be well thought not just for how easy it makes to write the code, but also how easy it is to read it, and more importantly - what type of code it incentivizes.

The post Syntactic Sugar Is Not Always Good appeared first on Bozho's tech blog.

Нужни са ни по-добри данни за COVID-19

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

Смятам за нужно е да се направят две уточнения относно данните за COVID-19 у нас, тъй като напоследък се разпространяват алтернативни тълкувания.

  1. Броят заразени НЕ е достигнал плато и не намалява. Да, това казва официалната статистика за брой заразени, но тук има два фактора. Първият е, че сме на 40% позитивни тестове. Това прави статистиката безполезна – препоръката на СЗО е до 3% позитивни, за да имаш някакво адекватно проследяване на заразата. Също така общият брой тестове намалява, тъй като са скъпи, държавата до съвсем скоро не ги покриваше (а сега ги покрива при определени условия) и хората спряха да си ги правят – не им се изискват за пътуване, за какво да ги правят, като има безплатни антигенни, които обаче не влизат в статистиката. Така че – не, няма спад на заразените, но нямаме реална картина колко са всъщност.
  2. Броят смъртни случаи от COVID също не е достигнал плато. Тук е много важна методиката за отчитане на тези данни, а такава публично достъпна аз поне не намерих. Но допускането ми (и информация, която получавам от различни места) е, че методиката е доста консервативна – т.е. за починал с COVID се счита само ако имаш положителен PCR и си починал скоро след това. Това не включва починали вкъщи, починали в спешна помощ преди да е направен (и излязъл?) PCR. А при това натоварване на болниците, там отиват само спешните случаи, останалите си стоят вкъщи, защото няма места.

И в двата случая (а и при всички данни в реалния свят) и важно какъв е контекстът и какво значат данните в него, а не просто изсипани в ексел.

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

Какво може да се направи, чисто от гледна точка на данните, защото каквото виждаме ние, вероятно това вижда и властта, а то е много подвеждащо и съответно се разчита на разкази и възприятия:

  • да се регистрират (отделно) и позитивните антигенни тестове. Тук се надявам процесът и интерфейсът да са удобни, за да не създава това голяма административна тежест
  • да се публикува методиката за отчитане на смъртни случаи с COVID и тя да се ревизира, така че да включи категория с предполагаемо починали от COVID (т.е. такива, които преди смъртта са имали симптоми или позитивен антигенен тест). Може в отделна графа да се публикува, за да е ясно кое какво е.
  • в периода на епидемичната обстановка, НСИ да публикува данните за смъртността всеки ден или на три дни – данните се вземат от смъртните актове, регистрирани от ГД ГРАО, така че там няма поле за тълкуване, извън факта, че при натоварването на системата, смъртни актове могат да излизат със закъснение. НСИ може да отичта и това – дата на вписване на смъртния акт спрямо дата на смъртта, като по този начин се отчита увеличеното натоварване.

Защо трябва да се занимаваме с числа, вместо да се фокусираме върху лекуването на хората? Не е „вместо“. Но без адекватна картина, всяка управленска мярка е стреляне в тъмното.

И по-важното – създават се алтернативни реалности дори сред над средно интелигентни хора, които не са попаднали още в света на конспирациите с „чипиране с 5G и ваксини“, но не са влезли навътре в естеството на данните. Ако гледаме данните за заразяване и за смъртност от COVID, от локдаун няма нужда – всичко е точно. Само че на тях изобщо не може да се разчита. Това пък е фактор за хората – доколко мотивирани да спазват мерките или да вярват на алтернативните факти, че „то нещата не са толкова тежки“.

Материалът Нужни са ни по-добри данни за COVID-19 е публикуван за пръв път на БЛОГодаря.