All posts by Bozho

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

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 е публикуван за пръв път на БЛОГодаря.

Как наистина да получим електронна идентификация

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

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

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

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

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

Трябва изпълнителят да реализира този процес удобно, със стандартни приложения за различните мобилни операционни системи, така че процесът да бъде: 1. натискане на бутон „идентифицирай се“ при заявяване на услуга 2. Излизане на съобщение на телефона за очаквана идентификация 3. допиране на картата и написване на PIN (може и в обратен ред, за по-голямо удобство) 4. Успешна идентификация. Трябва да се обърне внимание и на сигурността на безконтакното четене. Към 2016 стандартите по темата не бяха масово възприети, така че изпълнителят и възложителят трябва да преценят кой е най-актуалният начин.

Персонализиране на други носители – електронната идентификация не е само „чип в личната карта“. Всъщност чипът в личната карта е само една от много възможности. Трябва в рамките на издаването на удостоверение за електронна идентичност да се даде опция за записването му (заедно с частния ключ) на смартфон или на друга карта. Записването на частен ключ на телефон към 2016 г. не беше сигурно (имаше известни атаки), но 4 години по-късно вече е. И в нормативната уредба, и в заданието е заложена възможност за издаване на eID чрез вече съществуващо eID. Т.е. може с еднократно използване на личната карта да се създаде нов частен ключ и удостоверение на телефона и всяка следваща идентификация да не изисква докосване на картата и писане на PIN (а използване на сензора за пръстов отпечатък). Тези опции са заложени и напълно възможни, но трябва и възложителят, и изпълнителят да съблюдават те да се случат по този начин.

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

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

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

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

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

Не на последно място, трябва да бъде реализирана идентификация на юридически лица чрез връзка в реално време с Търговския регистър (и РЮЛНЦ, и Булстат), за да се избегнат проблемите, които произтичат от настоящото решение с КЕП. Това предполага надграждане на системи и понякога промяна на процеси.

Цялостна архитектура на федерираната идентификация – националната схема за електронна идентификация е само една от няколко опции. Вече има частни схеми за идентификация, отдавна има всевъзможни ПИК-ове, които макар и от ниско ниво, минават за идентификация по Регламент 910/2014. Има и необходимост да се поддържат електронните идентификации на всички държави членки. Трябва максимално бързо да бъде разписана архитектура на федерирана идентификация, която да позволява на гражданите да ползват всяка услуга с подходящо за целта средство. Първо, с надграждането на административния регистър (което също трябваше да е станало отдавна) трябва да се добавят нивата на осигуреност на идентификацията, която дадена услуга изисква. След това трябва да има т.нар. eIDAS възел, който да позволява интеграция с европейските схеми.

Трябва да бъде подготвена архитектура и на местно ниво – как частни схеми и/или частни центрове за електронна идентификация да си общуват с националната схема. Къде в картинката стои и настоящата система за е-автентикация на ДАЕУ, която от временно решение се превръща във все по-устойчиво такова. За щастие всички тези системи „говорят“ (и трябва да говорят според нормативните изисквания) на един „език“ – протоколът SAML 2.0. Но кой кого извиква, с какви параметри, кой какви регистри държи и какво позволява; как се извършва подписване при схеми, които не са националната (напр. чрез съхраняване на SAML 2.0 assertions) и не на последно място – как да бъде осъвременена нормативната уредба с всичко това. Сложни въпроси, които трябва да намерят отговор в следващите 6 месеца, за да не се окажем в батак, в който всичко е толкова фрагментирано, че много малко хора да могат да ползват услугите, които искат със средството за идентификация, което имат.

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

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

Creating a CentOS Startup Screen

Post Syndicated from Bozho original https://techblog.bozho.net/creating-a-centos-startup-screen/

When distributing bundled software, you have multiple options, but if we exclude fancy newcomers like Docker and Kubernetes, you’re left with the following options: an installer (for Windows), a package (rpm or deb) for the corresponding distro, tarball with a setup shell script that creates the necessary configurations, and a virtual machine (or virtual appliance).

All of these options are applicable in different scenarios, but distributing a ready-to-deploy virtual machine image is considered standard for enterprise software. Your machine has all the dependencies it needs (because it might not be permitted to connect to the interenet), and it just has to be fired up.

But typically you’d want some initial configuration or at least have the ability to show the users how to connect to your (typically web-based) application. And so creating a startup screen is what many companies choose to do. Below is a simple way to do that on CentOS, which is my distro of preference. (There are other resources on the topic, e.g. this one, but it relies on /etc/inittab which is deprecated in CentOS 8).

useradd startup -m
yum -y install dialog

sed -i -- "s/-o '-p -- \\u' --noclear/--autologin startup --noclear/g" /usr/lib/systemd/system/[email protected]

chmod +x /install/startup.sh
echo "exec /install/startup.sh" >> /home/startup/.bashrc

systemctl daemon-reload

With the code above you are creating a startup user and auto-logging that user in before the regular login prompt. Replacing the Exec like in the [email protected] is doing exactly that.

Then the script adds the invocation of a startup bash script to the .bashrc which gets run when the user is logged in. What this script does is entirely up to you, below is a simple demo using the dialog command (that we just installed above):

#!/bin/sh
# Based on https://askubuntu.com/questions/1705/how-can-i-create-a-select-menu-in-a-shell-script

HEIGHT=15
WIDTH=70
CHOICE_HEIGHT=4
BACKTITLE="Your Company"
TITLE="Your Product setp"
BIND_IP=`ifconfig | sed -En 's/127.0.0.1//;s/.*inet (addr:)?(([0-9]*\.){3}[0-9]*).*/\2/p'`
INFO="Welcome to MyProduct.\n\n\nWeb access URL: https://$BIND_IP\n\n\n\nFor more information visit https://docs.example.com"

CHOICE=$(dialog --clear \
                --backtitle "$BACKTITLE" \
                --title "$TITLE" \
                --msgbox "$INFO" \
                $HEIGHT $WIDTH \
                2>&1 >/dev/tty)

clear
echo 'Enter password for user "root":'
su root

This dialog shows just some basic information, but you can extend it to allow users making choices and input some parameters. More importantly, it gets the current IP address and shows it to the user. That’s not something they can’t do themselves in other ways, but it’s friendlier to show it like that. And you can’t hard-code that, because in each installation it will have a different IP (even if not using DHCP, you should let the user set the static IP that they’ve assigned rather than forcing one on them). At the end of the script it switches to the root user.

Security has to be considered here – your startup user should not be allowed to do anything meaningful in the system, because it is automatically logged in without password. According to this answer exec sort-of solves that problem (e.g. when you mistype the root password, you are back to the startup.sh script rather than to the console).

I agree that’s a rare use-case but I thought I’d share this “arcane” knowledge.

The post Creating a CentOS Startup Screen appeared first on Bozho's tech blog.

Let’s Kill Security Questions

Post Syndicated from Bozho original https://techblog.bozho.net/lets-kill-security-questions/

Let’s kill security questions

Security questions still exist. They are less dominant now, but we haven’t yet condemned them as an industry hard enough so that they stop being added to authentication flows.

But they are bad. They are like passwords, but more easily guessable, because you have a password hint. And while there are opinions that they might be okay in certain scenarios, they have so many pitfalls that in practice we should just not consider them an option.

What are those pitfalls? Social engineering. Almost any security question’s answer is guessable by doing research on the target person online. We share more about our lives and don’t even realize how that affects us security-wise. Many security questions have a limited set of possible answers that can be enumerated with a brute force attack (e.g. what are the most common pet names; what are the most common last names in a given country for a given period of time, in order to guess someone’s mother’s maiden name; what are the high schools in the area where the person lives, and so on). So when someone wants to takeover your account, if all they have to do is open your Facebook profile or try 20-30 options, you have no protection.

But what are they for in the first place? Account recovery. You have forgotten your password and the system asks you some details about you to allow you to reset your password. We already have largely solved the problem of account recovery – send a reset password link to the email of the user. If the system itself is an email service, or in a couple of other scenarios, you can use a phone number, where a one-time password is sent for recovery purposes (or a secondary email, for email providers).

So we have the account recovery problem largely solved, why are security questions still around? Inertia, I guess. And the five monkeys experiment. There is no good reason to have a security question if you can have recovery email or phone. And you can safely consider that to be true (ok, maybe there are edge cases).

There are certain types of account recovery measures that resemble security questions and can be implemented as an additional layer, on top of a phone or email recovery. For more important services (e.g. your Facebook account or your main email), it may not be safe to consider just owning the phone or just having access to the associated email to be enough. Phones get stolen, emails get “broken into”. That’s why a security-like set of questions may serve as additional protection. For example – guessing recent activity. Facebook does that sometimes by asking you about your activity on the site or about your friends. This is not perfect, as it can be monitored by the malicious actor, but is an option. For your email, you can be asked what are the most recent emails that you’ve sent, and be presented with options to choose from, with some made up examples. These things are hard to implement because of geographic and language differences, but “guess your recent activity among these choices”, e.g. dynamically defined security questions, may be an acceptable additional step for account recovery.

But fixed security questions – no. Let’s kill those. I’m not the first to argue against security questions, but we need to be reminded that certain bad security practices should be left in the past.

Authentication is changing. We are desperately trying to get rid of the password itself (and still failing to do so), but before we manage to do so, we should first get rid of the “bad password in disguise”, the security question.

The post Let’s Kill Security Questions appeared first on Bozho's tech blog.

Дигитализацията на публичния сектор с европейски средства става все по-труднa

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

В рамките на националния план за възстановяване и устойчивост дигитализацията на публичния сектор е слабо и откъслечно застъпена. Коментирахме темата с Христо Иванов, Иво Мирчев и Боян Юруков миналата седмица, но ми се ще да развия темата.

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

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

След присъединяването ни към ЕС, има два програмни периода. В първия (2007-2013) програмата за електронно управление е „Административен капацитет“, а във втория (2014-2020) – „Добро управление“. В рамките на тези оперативни програми са предвидени около милиард лева, като немалка част от тях са похарчени (макар реално усвоените по ОПДУ да са около 1/3 в последната година, в която може да се кандидатства за проекти, то остават три години за довършване на проекти и тяхното изплащане).

В рамките на тези два програмни периоди трябваше да сме направили много неща. Обаче не сме. Отчели сме ги проформа, или сме ги изградили системи, които не се използват, или са се използвали, но са изоставени. Или не сме направили неща, които сме обещали, че ще направим. И проблемът е в това, че ЕК няма основание да ни даде трети път пари за същото.

Но нека вляза в конкретика:

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

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

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

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

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

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

Материалът Дигитализацията на публичния сектор с европейски средства става все по-труднa е публикуван за пръв път на БЛОГодаря.

My Advice To Developers About Working With Databases: Make It Secure

Post Syndicated from Bozho original https://techblog.bozho.net/my-advice-to-developers-about-working-with-databases-make-it-secure/

Last month Ben Brumm asked me for the one advice I’d like to give to developers that are working with databases (in reality – almost all of us). He published mine as well as many others’ answers here, but I’d like to share it with my readers as well.

If I had to give developers working with databases one advice, it would be: make it secure. Every other thing you’ll figure in time – how to structure your tables, how to use ORM, how to optimize queries, how to use indexes, how to do multitenancy. But security may not be on the list of requirements and it may be too late when the need becomes obvious.

So I’d focus on several things:

  • Prevent SQL injections – make sure you use an ORM or prepared statements rather than building queries with string concatenation. Otherwise a malicious actor can inject anything in your queries and turn them into a DROP DATABASE query, or worse – one that exfiltrates all the data.
  • Support encryption in transit – this often has to be supported by the application’s driver configuration, e.g. by trusting a particular server certificate. Unencrypted communication, even within the same datacenter, is a significant risk and that’s why databases support encryption in transit. (You should also think about encryption at rest, but that’s more of an Ops task)
  • Have an audit log at the application level – “who did what” is a very important question from a security and compliance point of view. And no native database functionality can consistently answer the question “who” – it’s the application that manages users. So build an audit trail layer that records who did what changes to what entities/tables.
  • Consider record-level encryption for sensitive data – a database can be dumped in full by those who have access (or gain access maliciously). This is how data breaches happen. Sensitive data (like health data, payment data, or even API keys, secrets or tokens) benefits from being encrypted with an application-managed key, so that access to the database alone doesn’t reveal that data. Another option, often used for credit cards, is tokenization, which shifts the encryption responsibility to the tokenization providers. Managing the keys is hard, but even a basic approach is better than nothing.

Security is often viewed as an “operations” responsibility, and this has lead to a lot of tools that try to solve the above problem without touching the application – web application firewalls, heuristics for database access monitoring, trying to extract the current user, etc. But the application is the right place for many of these protections (although certainly not the only place), and as developers we need to be aware of the risks and best practices.

The post My Advice To Developers About Working With Databases: Make It Secure appeared first on Bozho's tech blog.