All posts by Bozho

Електронни обществени поръчки – хронология на липсата

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

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

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

Но в следствие на директивата на ЕС за обществените поръчки, би трябвало дс има национална централизирана система за електронни обществени поръчки – електронно обявяване, кандидатстване, отваряне на оферти и т.н.

Да разгледаме, обаче, хронологията на събитията:

2014г: ЕС приема директива за задължителна централизирана платформа за обществени поръчки във всяка държава-членка, срок за транспиниране 19 април 2016. Срокът за въвеждане на е-обществените поръчки е 18 октомври 2018.

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

2016г: (15 април) Българският парламент приема новия Закон за обществени поръчки, като срокът за електронните обществени поръчки е юни 2017г.

2016г стартира процедурата за система за обществени поръчки, но КЗК я „порязва“

2017г процедурата за електронна система за обществени поръчки стартира наново

2017г: парламентът се сеща, че тая няма да я бъде, и отлага влизането в сила за 18 октовмри 2018, т.е. крайният срок по директива

2018г: парламентът се сеща, че и тая няма да я бъде, и изтрива изцяло члена, като прави нов, в който срокът вече е 1 ноември 2019г.

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

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

Всички тия законодателни странности са вероятно за да не е очевидно, че от 1 година сме нарушение на директивата, приета 2014г. За 5 години (а и повече, защото тя се готви по-отдавна) въвеждането на електронни обществени поръчки се оказа невъзможно.

Системата ЦАИС ЕОП работи от известно време. Само че все още на практика никой не я използва. Затова и управляващите искат изпълнителната власт да решава кое министерство кога да я ползва.

Причините за това забавяне са много и разнообразни. Започват с мотането на законодателя (ЗОП е приет няколко дни преди крайния срок по директива), КЗК спира първата процедура със (според моя прочит) не особено убедилни аргументи, новата процедура се забавя повече от очакваното.

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

Заключения няма да правя, те са ясни.

Blockchain Overview – Types, Use-Cases, Security and Usability [slides]

Post Syndicated from Bozho original https://techblog.bozho.net/blockchain-overview-types-use-cases-security-and-usability-slides/

This week I have a talk on a meetup about blockchain beyond the hype – its actual implementation issues and proper use-cases.

The slides can be found here:

The main takeaways are:

  • Think of blockchain in specifics, not in high-level “magic”
  • Tamper-evident data structures are cool, you should be familiar with them – merkle trees, hash chains, etc. They are useful for other things as well, e.g. certificate transparency
  • Blockchain and its cryptography is perfect for protecting data integrity, which is part of the CIA triad of information security
  • Many proposed use-cases can be solved with centralized solutions + trusted timestamps instead
  • Usability is a major issue when it comes to wider adoption

As with anything in technology – use the right tool for the job, as no solution solves every problem.

The post Blockchain Overview – Types, Use-Cases, Security and Usability [slides] appeared first on Bozho's tech blog.

Защо е важен главният прокурор

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

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

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

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

Причината обаче да се слагат хора като Гешев и Цацаров на тия постове е не това кого са обвинили успешно, а четири други неща:

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

Та, да оставим Минюстайковци, Баневи и подобни. Не за тях става дума тук.

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

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

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

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

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

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

The Personal Data Store Pattern

Post Syndicated from Bozho original https://techblog.bozho.net/the-personal-data-store-pattern/

With the recent trend towards data protection and privacy, as well as the requirements of data protection regulations like GDPR and CCPA, some organizations are trying to reorganize their personal data so that it has a higher level of protection.

One path that I’ve seen organizations take is to apply the (what I call) “Personal data store” pattern. That is, to extract all personal data from existing systems and store it in a single place, where it’s accessible via APIs (or in some cases directly through the database). The personal data store is well guarded, audited, has proper audit trail and anomaly detection, and offers privacy-preserving features.

It makes sense to focus one’s data protection efforts predominantly in one place rather than scatter it across dozens of systems. Of course it’s far from trivial to migrate so much data from legacy systems to a new module and then upgrade them to still be able to request and use it when needed. That’s why in some cases the pattern is applied only to sensitive data – medical, biometric, credit cards, etc.

For the sake of completeness, there’s something else called “personal data stores” and it means an architecture where the users themselves store their own data in order to be in control. While this is nice in theory, in practice very few users have the capacity to do so, and while I admire the Solid project, for example, I don’t think it is viable pattern for many organizations, as in many cases users don’t directly interact with the company, but the company still processes large amounts of their personal data.

So, the personal data store pattern is an architectural approach to personal data protection. It can be implemented as a “personal data microservice”, with CRUD operations on predefined data entities, an external service can be used (e.g. SentinelDB, a project of mine), or it can just be a centralized database that has some proxy in front of it to control the access patterns. You an imagine it as externalizing your application’s “users” table and its related tables.

It sounds a little bit like a data warehouse for personal data, but the major difference is that it’s used for operational data, rather than (just) analysis and reporting. All (or most) of your other applications/microservices interact constantly with the personal data store whenever they need to access or update (or “forget”) personal data.

Some of the main features of such a personal data store, the combination of which protect against data breaches, in my view, include:

  • Easy to use interface (e.g. RESTful web services or simply SQL) – systems that integrate with the personal data store should be built in a way that a simple DAO layer implementation gets swapped and then data that was previously accessed form a local database is now obtained from the personal data store. This is not always easy, as ORM technologies add a layer of complexity.
  • High level of general security – servers protected with 2FA, access control, segregated networks, restricted physical access, firewalls, intrusion prevention systems, etc. The good things is that it’s easier to apply all the best practices applied to a single system instead of applying it (and keeping it that way) to every system.
  • Encryption – but not just “data at rest” encryption; especially sensitive data can and should be encrypted with well protected and rotated keys. That way the “honest but curious” admin won’t be able to extract anything form the underlying database
  • Audit trail – all infosec and data protection standards and regulations focus on accountability and traceability. There should not be a way to extract or modify personal data without leaving a trace (and ideally, that trace should be protected as well)
  • Anomaly detection – checking if there is something strange/anomalous in the data access patterns. Such strange access patterns can mean a data breach is happening, and the personal data store can actively block it. There is a lot of software out there that does anomaly detection on network traffic, but it’s much better if the rules (or machine learning) are domain-specific. “Monitor for increased traffic to those servers” is one thing, but it’s much better to be able to say “monitor for out-of-the ordinary accesses to personal data of such and such kind”
  • Pseudonymization – many systems that need the personal data don’t actually need to know who it is about. That includes marketing, including outsourcing to 3rd parties, reporting functionalities, etc. So the personal data store can return data that does not allow a person do be identified, but a pseudo-ID instead. That way, when updates are made back to the personal data store, they can still refer to a particular person, via the pseudonymous ID, but the application that extracted the data in the first place doesn’t get to know who the data was about. This is useful in scenarios where data has to be (temporarily or not) stored in a database that lies outside the personal datastore.
  • Authentication – if the company offers user authentication, this can be done via the personal data store. Passwords, two-factor authentication secrets and other means of authentication are personal data, and an important one as well. An organization may use a single-sign-on internally (e.g. Active Directory), but it doesn’t make sense to put customers there, too, so they are usually stored in a database. During authentication, the personal data store accepts all necessary credentials (username, password, 2FA code), and return a token to be used for subsequent calls or to be used a a session cookie token.
  • GDPR (or CCPA or similar) functionalities – e.g. export of all data about a person, forgetting a person. That’s an often overlooked problem, but “give me all data about me that you have” is an enormous issue with large companies that have dozens of systems. It’s next to impossible to extract the data in a sensible way from all the systems. Tracking all these requests is itself a requirement, so the personal data store can keep track of them to present to auditors if needed.

That’s all easier said than done. In organizations that have already many systems working alongside and processing personal data, migration can be costly. So it’s a good idea to introduce it as early as possible, and have a plan (even if it lasts for years) to move at least sensitive personal data to the well protected silo. This silo is a data engineering effort, a system refactoring effort and an organizational effort. The benefits, though, are reduced long-term cost and reduced risks for data breaches and non-compliance.

The post The Personal Data Store Pattern appeared first on Bozho's tech blog.

Без фалшиви дилеми на първи тур

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

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

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

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

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

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

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

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

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

Remote Log Collection on Windows

Post Syndicated from Bozho original https://techblog.bozho.net/remote-log-collection-on-windows/

Every organization needs to collect logs from multiple sources in order to put them in either a log collector or SIEM (or a dedicated audit trail solution). And there are two options for that – using an agent and agentless.

Using an agent is easy – you install a piece of software on each machine that generates logs and it forwards them wherever needed. This is however not preferred by many organizations as it complicates things – upgrading to new versions, keeping track of dozens of configurations, and potentially impacting performance of the target machines.

So some organizations prefer to collect logs remotely, or use standard tooling, already present on the target machine. For Linux that’s typically syslog, where forwarding is configured. Logs can also be read remotely via SCP/SSH.

However, on Windows things are less straightforward. You need to access the Windows Event Log facility remotely, but there is barely a single place that describes all the required steps. This blogpost comes close, but I’d like to provide the full steps, as there are many, many things that one may miss. It is a best practice to use a non-admin, service account for that and you have to give multiple permissions to allow reading the event logs remotely.

There are also multiple ways to read the logs remotely:

  • Through the Event Viewer UI – it’s the simplest to get right, as only one domain group is required for access
  • Through Win32 native API calls (and DCOM) – i.e. EvtOpenSession and the related methods
  • Through PowerShell Get-WinEvent (Get-EventLog is a legacy cmdlet that doesn’t support remoting)
  • Through WMI directly (e.g. this or this. To be honest, I don’t know whether the native calls and the powershell commands don’t use WMI and/or CIM underneath as well – probably.

So, in order to get these options running, the following configurations have to be done:

  1. Allow the necessary network connections to the target machines (through network rules and firewall rules, if applicable)
  2. Go to Windows Firewall -> Inbound rules and enable the rules regarding “Remote log management”
  3. Create a service account and configure it in the remote collector. The other option is to have an account on the collector machine that is given the proper access, so that you can use the integrated AD authentication
  4. Add the account to the following domain groups: Event log readers, Distributed COM users. The linked article above mentions “Remote management users” as well, but that’s optional if you just want to read the logs
  5. Give the “Manage auditing and security log” privilege to the service account through group policies (GPO) or via “local security policy”. Find it under User Rights Assignment > Manage auditing and security log
  6. Give WMI access – open “wmimgmt” -> right click -> properties > Security -> Advanced and allow the service account to “Execute Methods”, “Provider Write”, “Enable Account”, “Remote Enable”. To be honest, I’m not sure exactly which folder that should be applied to, and applying it to the root may be too wide, so you’d have to experiment
  7. Give registry permissions: Regedit -> Local machine -> System\CurrentControlSet\Services\eventlog\Security -> right click -> permissions and add the service account. According to the linked post you also have to modify a particular registry entry, but that’s not required just for reading the log. This step is probably the most bizarre and unexpected one.
  8. Make sure you have DCOM rights. This comes automatically wit the DCOM group, but double check via DCOMCnfg -> right click -> COM security
  9. Grant permissions for the service account on c:\windows\system32\winevt. This step is not required for “simple” reading of the logs, but I’ve seen it in various places, so in some scenarios you might need to check it
  10. Make sure the application or service that is reading the logs remotely has sufficient permissions – it can usually run with admin privileges, because it’s on a separate, dedicated machine.
  11. Restart services – that is optional, but can be done just in case: Restart “Windows Remote Management (WS-Management)” and “Windows Event Log” on the target machine

As you can see, there are many things that you can miss, and there isn’t a single place in any documentation to list those steps (though there are good guides like this that go in a slightly different direction).

I can’t but make a high-level observation here – the need to do everything above is an example of how security measures can “explode” and become really hard to manage. There are many service, groups, privileges, policies, inbound rules and whatnot, instead of just “Allow remote log reading for this user”. I know it’s inherently complex, but maybe security products should make things simpler by providing recipes for typical scenarios. Following guides in some blog is definitely worse than running a predefined set of commands. And running the “Allow remote access to event log” recipe would do just what you need. Of course, knowing which recipe to run and how to parameterize it would require specific knowledge, but you can’t do security without trained experts.

The post Remote Log Collection on Windows appeared first on Bozho's tech blog.

Административно престъпление

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

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

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

Та какво става, когато нарушиш закона? Зависи от много неща. Но те са разделени в групи:

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

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

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

ОтговорностКъде са описани нарушенията?Къде е описан редът за налагане?Кой инициира процеса?Изпълнение без участие на съд?
НаказателнаНаказателен кодексНаказателно-процесуален кодексПрокуратурата или частен тъжителНе
АдминистративнонаказателнаГлава „Административнонаказателни разпоредби“ (или подобна) във всеки законЗакон за административните нарушения и наказанияНаказващият административен орган, определен със законаДа
Гражданска и имущественаГраждански процесуален кодексВсяко физическо или юридическо лицеНе
ДисциплинарнаКодекс на труда, Закон за държавния служител, трудови договориКодекс на труда, Закон за държавния служителРаботодателДа

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

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

Cybersecurity Is Very Important

Post Syndicated from Bozho original https://techblog.bozho.net/cybersecurity-is-very-important/

A few months ago an essay titled “Cybersecurity is not very important” appeared. The essay is well written and interesting but I’d like to argue against its main point.

And that is actually hard – the essay has many good points, and although it has a contrarian feel, it actually isn’t saying anything outrageous. But I still don’t agree with the conclusion. I suggest reading it (or skimming it) first before continuing here, although this article is generally self-sufficient.

I agree with many things in the essay, most importantly that there is no 100% protection and it’s all about minimizing the risk. I also agree that cybersecurity is a complex set of measures that span not only the digital world, but he physical one as well. And I agree that even though after watching a few videos from DEF CON, BlackHat or CCC, one feels that everything is fundamentally broken and going to live in the mountains is the only sane strategy to survive an impending digital apocalypse, this is not the case – we have a somewhat okayish level of protection for the more important parts of the digital world. Certainly exploitable, but not trivially so.

There are, though, a few main claims that I’d like to address:

  • There has not been any catastrophic cybersecurity event – the author claims that the fact that there was no digital Pearl Harbor or 9/11 suggests that we’ve been investing just the right amount of effort in cybersecurity. I don’t think that’s a fair comparison. Catastrophic events like that cost human lives as an immediate result of a physical action. No digital event can cause immediate loss of human life. However, it can cause indirect loss of human life, and it probably has already – take a famous data breach in an extramarital affair dating site – do we know how much people were killed in Pakistan or Saudi Arabia because infidelity (or homosexuality) was exposed? How many people died because hospitals were victims of ransomware? How many people died when the Ukranian power grid was attacked, leaving 20% of of Kyiv without power and therefore without heat, light or emergency care? What about the (luckily unsuccessful) attempt to sabotage a Saudi Arabia petro-chemical plant and cause an explosion? There are many more of these events, and they are already a reality. There are no visible explosions yet, which would make it easier to compare them to Pearl Harbor or 9/11, but they are serious and deadly nonetheless. And while natural disasters, road incidents and other issues claim more victims, there isn’t a trivial way to calculate the “return of life on investment”. And isn’t a secure charity for improving hurricane protection in third world nations better than one that gets hacked and all of its funds get stolen?
  • People have not adopted easy security measures because they were minor inconveniences – for example 2-factor authentication has been around for ages, but only recently we began using it. That is true, of course, but the reason for that might not be that it has been mostly fine to not have 2FA so far, but that society hasn’t yet realized the risks. Humans are very bad at intuitively judging risk, especially when they don’t have enough information. Now that we have more information, we are slightly better at estimating that, yes, adding a second factor is important for some systems. Security measures get adopted when we realize the risk, not only when there is more of it. Another reason people have not adopted cybersecurity measures is that they don’t know about them. Because the area is relatively recent, expertise is rare. This discrepancy between the ubiquity of information technology and the lacks of technical expertise (not to mention security expertise) has been an issue for a long time.
  • The digital world plays too small a role in our world when we put things in perspective – humans play a small role in the world if you put them in a big enough perspective, that doesn’t mean we are not important. And the digital world is playing an increasingly important role in our world – we can’t that easily continue to claim that cybersecurity is not important. And overall, the claim that so far everything has been (almost) smooth sailing can’t be transformed into the argument that it is going to be the same, only with gradual improvement over time. If IT is playing an exponentially more important role (and it is), then our focus on information security can’t grow linearly. I know you can’t plot these things on a graph without looking stupid, but you get the gist.
  • We have managed to muddle through without too much focus on cybersecurity – yes, we have. But we will find it increasingly harder to do so. Also, we have successfully muddled through many eras of human history because we have done things wrong (For example the Maya civilization collapsed partly because they handled the the environment wrong). Generally, the fact that something hasn’t gone terribly wrong is a bad argument that we are doing fine. Systemic issues get even more entrenched while on the surface it may look like we are successfully muddling through. I’m not saying that is certainly the case for cybersecurity, but it might very well be.

While arguing with the author’s point is an interesting task, it doesn’t directly prove the point that cybersecurity is indeed important.

First, we don’t have good comparisons of estimates of the cost – to the economy and to human life – of investment in cybersecurity as opposed to other areas, so I don’t think we can claim cybersecurity is not important. There are, for example, estimates of the cost of a data breach, and it averages several million dollars. If you directly and indirectly lose several million dollars with a likelihood of 30% (according to multiple reports), I guess you should invest a few hundred thousands.

Second, it is harder to internalize the risk of incidents in the digital world compared to those in the physical world. While generally bad at evaluating risk, I think the indirection that the digital world brings, contributes negatively to our ability to make risk-based decisions. The complexity of the software complicates things even further – even technical people can’t always imagine the whole complexity of the systems they are working with. So we may not feel cybersecurity is important even though facts and figures show otherwise.

But for me the most important reason for the importance of cybersecurity is that we are currently laying a shaky foundation for our future world. Legacy software, legacy protocols and legacy standards are extremely hard to get rid of once they are ubiquitous. And if they are insecure by design, because they are not built with security in mind, there is no way that software that relies on them can be secure.

If we don’t get cybersecurity right soon, everything that relies on the foundations that we build today will be broken. And no, you can’t simply replace your current set of systems with new, more secure ones. Organizations are stuck with old systems not because they don’t want to get new and better ones, but because it’s hard to do that – it involves migration, user training, making sure all edge cases are covered, informing customers, etc. Protocols and standards are even hard to change – see how long it took for TLS 1.3 to come along, for example. But network standards still have vulnerabilities that don’t have good mitigation (or didn’t have until recently) – take an SS7 attack on a mobile network, or ARP spoofing, or BGP hijacking.

If we don’t agree that cybersecurity is very important, future technology will be based on an insecure layer that it will try to fix with clumsy abstractions. And then at some point everything may collapse, at a moment when we are so dependent on it, that the collapse will be a major disruption in he way humanity operates. That may sound futuristic, but with technology you have no option but to be futuristic. We must build systems today that will withstand the test of time. And this is already very hard – maybe because we didn’t think cybersecurity is important enough.

I’m not saying we should pour millions into cybersecurity starting tomorrow. But I’d be happy to see a security mindset in everyone that works with technology as well as in everyone that takes decisions that involve technology. Not paranoid, but security conscious. Not “100% secure or bust”, but taking all known protection measures.

Cybersecurity is important. And it will be even more important in he upcoming decades.

The post Cybersecurity Is Very Important appeared first on Bozho's tech blog.

Киберсигурна работа

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

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

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

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

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

В допълнение на въпроса по-горе, ще отговоря и на още три: „защо системите са уязвими“, „кой може да злоупотреби с това“ и „какво може да се направи“

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

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

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

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

Лесно решениие няма. Със сигурност съвет по киберсгурност, еврокомисар по киберсигурност, закон за киберсигурност и други подобни не са решението. Някои от тях са небезполезни стъпки, други – отбиване на номера, трети – политически опортюнизъм.

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

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

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

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

Protecting JavaScript Files (From Magecart-Style Attacks)

Post Syndicated from Bozho original https://techblog.bozho.net/protecting-javascript-files-from-magecart-attacks/

Most web pages now consist of multiple JavaScript files that are included in various ways (via >script< or in some more dynamic fashion, bundled and minified or not). But since these scripts interact with everything on the page, they can be a security risk.

And Magecart showcased that risk – the group attacked multiple websites, including British Airways and Ticketmaster, and stole a few hundred thousand credit card numbers.

It is a simple attack where attacker inserts a malicious javascript snippet into a trusted javascript file, collects credit card details entered into payment forms and sends them to an attacker-owned website. Obviously, the easy part is writing the malicious javascript; the hard part is getting it on the target website.

Many websites rely on externally hosted assets (including scripts) – be it a CDN, or a dedicated asset server (as in the case of British Airways). These externally hosted assets may be vulnerable in several ways:

  • Asset servers may be less protected than the actual server, because they are just static assets, what could go wrong?
  • Credentials to access CDN configuration may be leaked which can lead to an attacker replacing the original source scripts with their own
  • Man-in-the-middle attacks are possible if the asset server is misconfigured (e.g. allowing TLS downgrade attack)
  • The external service (e.g. CND) that was previously trusted can go rogue – that’s unlikely with big providers, but smaller and cheaper ones are less predictable

Once the attackers have replaced the script, they are silently collecting data until they are caught. And this can be a long time.

So how to protect against those attacks? A typical advice is to introduce a content security policy, which will allow scripts from untrusted domains to be executed. This is a good idea, but doesn’t help in the scenario where a trusted domain is compromised. There are several main approaches, and I’ll summarize them below:

  • Subresource integrity – this is a browser feature that lets you specify the hash of a script file and validates that hash when the page loads. If it doesn’t match the hash of the actually loaded script, the script is blocked. This sounds great, but has several practical implications. First, it means you need to complicate your build pipeline so that it calculates the hashes of minified and bundled resources and inject those hashes in the page templates. It’s a tedious process, but it’s doable. Then there are the dynamically loaded scripts where you can’t use this feature, and there are the browsers that don’t support it fully (Edge, IE and Safari on mobile). And finally, if you don’t have a good build pipeline (which many small websites don’t), a very small legitimate change in the script can break your entire website.
  • Don’t use external services – that sounds straightforward but it isn’t always. CDNs exist for a reason and optimize your site loading speeds and therefore ranking, internal policies may require using a dedicated asset server, sometimes plugins (e.g. for WordPress) may fetch external resources. An exception to this rule is allowed if you somehow sandbox the third party script (e.g. via iframe as explained in the link above)
  • Secure all external servers properly – if you can do that, that’s great – upgrade the supported cipher suites, monitor for 0days, use only highly trusted CDNs. Regardless of anything, you should obviously always strive to do that. But it requires expertise and resources, which may not be available to every company and every team.

There is one more scenario that may sound strange – if an attacker hacks into your main application server(s), they can replace the scripts with whatever they want. It sounds strange at first, because if they have access to the server, it’s game over anyway. But it’s not always full access with RCE – might be a limited access. Credit card numbers are usually not stored in plain text in the database, so having access to the application server may not mean you have access to the credit card numbers. And changing the custom backend code to collect the data is much more unpredictable and time-consuming than just replacing the scripts with malicious ones. None of the options above protect against that (as in this case the attacker may be able to change the expected hash for the subresource integrity check)

Because of the limitations of the above approaches, at my company we decided to provide a tool to monitor your website for such attacks. It’s called Scriptinel.com (short for Script Sentinel) and is currently in early beta. It’s mainly targeted at small website owners who can’t get any of the above 3 points, but can be used for sophisticated websites as well.

What it does is straightforward – it scans a given URL, extracts all scripts from it (even the dynamic ones), and starts monitoring them for changes with periodic requests. If it discovers a change, it notifies the website owner so that they can react.

This means that the attacker may have a few minutes to collect data, but time is an important factor here – this is not a “SELECT *” data breach; it relies on customers using the website. So a few minutes minimizes the damage. And it doesn’t break your website (I guess we can have a script to include that blocks the page if scriptinel has found discrepancies). It also doesn’t require changes in the build process to include hashes. Of course, such a reactive approach is not perfect, especially if there is nobody to react, but monitoring is a good idea regardless of whether other approaches are used.

There is the issue of protected pages and pages that are not directly accessible via a GET request – e.g. a payment page. For that you can enter your javascript files individually, rather than having the tool scan the page. We can add a more sophisticated user journey scan, with specifying credentials and steps to reach the protected pages, but for now that seems unnecessary.

How does it solve the “main server compromised” problem? Well, nothing solves that perfectly, as the attacker can do changes that serve the legitimate version of the script to your monitoring servers (identifying them by IP) and the modified scripts to everyone else. This can be done on the compromised external asset servers as well (though not with leaked CDN credentials). However this implies the attacker knows that Scriptinel is used, knows the IP addresses of our scanners, and has gained sufficient control to server different versions based on IP. This raises the bar significantly, and can even be made impossible to pull off if we regularly change the IP addresses in a significantly large IP range.

Such functionality may be available in some enterprise security suites, though I’m not aware of it (if it exists somewhere, please let me know).

Overall, the problem is niche, but tough, and not solving it can lead to serious data breaches even if your database is perfectly protected. Scriptinel is a simple to use, good enough solution (and one that’s arguably better than the other options).

Good information security is the right combination of knowledge, implementation of best practices and tools to help you with that. And I maybe Scriptinel is one such tool.

The post Protecting JavaScript Files (From Magecart-Style Attacks) appeared first on Bozho's tech blog.

Let’s Annotate Our Methods With The Features They Implement

Post Syndicated from Bozho original https://techblog.bozho.net/lets-annotate-our-methods-with-the-features-they-implement/

Writing software consists of very little actual “writing”, and much more thinking, designing, reading, “digging”, analyzing, debugging, refactoring, aligning and meeting others.

The reading and digging part is where you try to understand what has been implemented before, why it has been implemented, and how it works. In larger projects it becomes increasingly hard to find what is happening and why – there are so many classes that interfere, and so many methods participate in implementing a particular feature.

That’s probably because there is a mismatch between the programming units (classes, methods) and the business logic units (features). Product owners want a “password reset” feature, and they don’t care if it’s done using framework configuration, custom code split in three classes, or one monolithic controller method that does that job.

This mismatch is partially addressed by the so called BDD (behaviour driven development), as business people can define scenarios in a formalized language (although they rarely do, it’s still up to the QAs or developers to write the tests). But having your tests organized around features and behaviours doesn’t mean the code is, and BDD doesn’t help in making your way through the codebase in search of why and how something is implemented.

Another issue is linking a piece of code to the issue tracking system. Source control conventions and hooks allow for setting the issue tracker number as part of the commit, and then when browsing the code, you can annotate the file and see the issue number. However, due the the many changes, even a very strict team will end up methods that are related to multiple issues and you can’t easily tell which is the proper one.

Yet another issue with the lack of a “feature” unit in programming languages is that you can’t trivially reuse existing projects to start a new one. We’ve all been there – you have a similar project and you want to get a skeleton to get thing running faster. And while there are many tools to help that (Spring Boot, Spring Roo, and other scaffolding utilities), they can rarely deliver what you need – you always have to tweak something, delete something, customize some configuration, as defaults are almost never practical.

And I have a simple proposal that will help with the issues above. As with any complex problem, simple ideas don’t solve everything, but are at least a step forward.

The proposal is in the title – let’s annotate our methods with the features they implement. Let’s have @Feature(name = "Forgotten password", issueTrackerCode="PROJ-123"). A method can implement multiple features, but that is generally discouraged by best practices (e.g. the single responsibility principle). The granularity of “feature” is something that has to be determined by each team and is the tricky part – sometimes an epic describes a feature, sometimes individual stories or even subtasks do. A definition of a feature should be agreed upon and every new team member should be told what to do and how to interpret it.

There is of course a lot of complexity, e.g. for generic methods like DAO methods, utility methods, or methods that are reused in too many places. But they also represent features, it’s just that these features are horizontal. “Data access layer” is a feature – a more technical one indeed, but it counts, and maybe deserves a story in the issue tracker.

Your features can actually be listed in one or several enums, grouped by type – business, horizontal, performance, etc. That way you can even compose features – e.g. account creation contains the logic itself, database access, a security layer.

How does such a proposal help?

  • Consciousnesses about the single responsibility of methods and that code should be readable
  • Provides a rationale for the existence of each method. Even if a proper comment is missing, the annotation will put a method (or a class) in context
  • Helps navigating code and fixing issues (if you can see all places where a feature is implemented, you are more likely to spot an issue)
  • Allows tools to analyze your features – amount, complexity, how chaotic a feature is spread across the code base, test coverage per feature, etc.
  • Allows tools to use existing projects for scaffolding for new ones – you specify the features you want to have, and they are automatically copied

At this point I’m supposed to give a link to a GitHub project for a feature annotation library. But it doesn’t make sense to have a single-annotation project. It can easily be part of guava or something similar Or can be manually created in each project. The complex part – the tools that will do the scanning and analysis, deserve separate projects, but unfortunately I don’t have time to write one.

But even without the tools, the concept of annotating methods with their high-level features is I think a useful one. Instead of trying to deduce why is this method here and what requirements does it have to implement (and were all necessary tests written at the time), such an annotation can come handy.

The post Let’s Annotate Our Methods With The Features They Implement appeared first on Bozho's tech blog.

Либра – новата криптовалута на Фейсбук

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

Фейсбук обяви, че през 2020 ще пусне своя криптовалута. Само по себе си пускането на криптовалута е тривиално, но когато го направи компания с милиардна пазарна капитализация, и то подкрепена от още десетина такива, заявката става сериозна.

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

Пред това, обаче, има няколко предизвикателства и не е ясно дали Фейсбук ще може да ги преодолее:

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

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

Технологичната е, че избраният протокол запазва връзката между наредителя и транзакцията и Фейсбук има информация за тази връзка. Регулаторната е, че на много места по света е задължителен т.нар. „know your customer“ процес, в който се установява точно кой стои отсреща при финансови операции (с цел пресичане на прането на пари, финансирането на тероризъм и др.) Т.е. Фейсбук ще разполага с тези данни и не е ясно дали някой би им се доверил, че няма да ги използват в рекламната си платформа.

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

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

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

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

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

(Статията е публикувана първоначално в сп. Мениджър)

Обобщение на теча на данни в НАП

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

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

Инцидентът

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

По информация на хора, които са разгледали данните, вътре има ЕГН-та, три имена и осигурителни доходи на милиони граждани, номера на лични карти, както и данъчни декларации, граждански договори, а също и данни от други инстутуции – Агенция по заетостта, Агенция Митници, Агенция за социално подпомагане. Има данни за чуждестранни юридически лица, и любопитни данни, като напр. файл, озаглавен QneQnev.

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

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

Как?

Няма официална информация как е станал пробивът, но на няколко места излезе слух, че е т.нар. SQL инжекция. Това звучи правдоподобно, така че ще коментирам него. SQL инжекциите са сред най-простите уязвимости – хакерът вкарва специално подготвен текст в дадена поле и получава контрол над базата данни, защото разработчикът не е „почистил“ входните данни (и не използва т.нар. prepared statements). Ако например искаме да използваме формата за вход в системата, то можем да допуснем, че проверката на потребителското име и паролата би изглеждало така: SELECT * FROM users WHERE username={params.username} AND password={transform(params.password)}. (transform, защото паролите никога не трябва да се пазят в явен вид).

Това е псевдо-код, с който виждаме, че параметрите, подадени от потребителя се „залепят“ за заявка, която се изпълнява към базата. Е, ако хакерът вместо потребителско име попълни друга валидна заявка в полето, тя ще се изпълни. Напр. след въвеждане, заявката би изглеждала така: SELECT * FROM users WHERE username=1;CREATE PROCEDURE exfiltrate …;–AND password=…. Създадената процедура може да бъде с произволен код, който да обхожда всички бази данни и техните таблици и да ги изпраща към определен IP адрес.

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

Защо?

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

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

Паралелно това, с измененията в Закона за електронното управление направихме две неща. По-маловажното беше, че създадохме опция Държавна агенция „Електронно управление“ да създаде програма за привличане на експерти от частния сектор, които краткосрочно да помагат за ИТ услугите на държавата. Нещо, което и аз правех тогава, но в мащаб. Нещо подобно на американските 18F/USDS. Това, излишно е да казвам, не се случва вече 3-та година.

По-важното беше създаването със закон на Държавно предприятие „Единен системен оператор“. Идеята му е да може да дава пазарни ИТ заплати, като предоставя определени услуги на държавната администрация – технически задания, проектен контрол, тестове, в т.ч. за уязвимости, управление на поддръжката на инфраструктурата, консултиране на ключови проекти, спешни мерки по „закърпване“ на проблеми, и др. Това предприятие също 3-та година е блокирано и не се случва. Изпълнителната власт и Горанов в т.ч. като че ли осъзнаха нуждата от нещо такова след срива на Търговския регистър миналата година, но явно просветлението е било краткотрайно. И това не сме си го измислили ние – BRZ (Австрия) и GDS (Великобритания) са едни от примерите за подобни структури в Европа.

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

Информационна сигурност

Причините за ниското ниво на информационна сигурност са човешкия фактор, който е следствие на политическа неадекватност. Но все пак има начин нещата да станат малко по-добре дори само с подходящо структурирани правила. С промени в наредбите към Закона за електронното управление въведохме редица изисквания за информационна сигурност, в т.ч. шаблон за задание за всички нови проекти. В този шаблон изрично се говори за информационна сигурност и за уязвимости от тип SQL инжекция и XSS, така че проекти, създадени по този шаблон, да са съзнателно проверени за такива уязвимости, а наличието им да се явява неизпълнение на договор. Между другото, тогава НАП бяха против някои текстове, защото те вътрешно си пишели някои системи и някои изисквания не важали за тях.

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

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

GDPR

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

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

Дали КЗЛД ще наложи глоба на НАП или не, не знам. Дали има смисъл да се прехвърлят едни публични средства между институциите (и накрая – пак в бюджетната сметка) – също не знам. Но със сигурност НАП е трябвало да уведоми КЗЛД навреме, и съответно трябва да уведоми гражданите за теча. За целта НАП готви приложение, където всеки може да се провери дали данни са изтекли, което е добре.

Проблемът със защитата на данните е голям в световен мащаб. Всеки ден текат данни от всякакви компании. Това не е оправдание за елементарните грешки на НАП, но поставя нещата в перспектива. А GDPR е опит да намали риска това да се случи. Разбира се, GDPR не може да спре теча на данни поради немарливост. Целта му е да направи такива течове по-малко вероятни и с по-малък ефект чрез редица мерки и по-важното – чрез няколко основни принципа, с които всички участващи в изграждането и оперирането на софтуер да са наясно. Засега не е ясно дали успява да намали този риск.

Мерките?

Какви мерки могат да се вземат на този етап. Краткосрочните: спиране на уязвимата услуга (вече направено), пълен одит на сигурността на всички системи не само в системата на Министерство на финансите, ами в цялата държава. Проверка дали всички информационни системи са включени в одита на Държавна агенция „Електронно управление“ и последователната им автоматизирана проверка за уязвимости.

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

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

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

Комуникацията

Комуникацията на официалните лица може да се раздели на две части – от една страна тази на експертите в НАП, начело с пиара Росен Бъчваров, и от друга страна всички останали.

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

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

Хакерът

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

Дали заловеният наистiна е извършител ще реши съдът. ГДБОП трябва да събере доказателства и от тях да следва еднозначно, че той е извършителят. Дали намереният файл, в който се съдържа името му е истински или не – не можем да кажем. Има много варианти, в които е истински. И такива, в които не е.

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

Дали хакерът е „магьосник“, обаче, е сравнително ясно – не е. Злоупотреба с SQL инжекция може да направи почти всеки. Ако е оставил да бъде открит, значи не си е покрил добре следите.

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

Заключение

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

За такива инциденти трябва да се носи политическа отговорност. Дали чрез оставки или на избори, не знам. Но всеки инцидент е следствие от нечие действие или бездействие.

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

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

Консервативно ми е…

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

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

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

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

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

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

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

Как така съм консервативен, нали съм либерал? Ами… да караме по списък. Вярвам в Бог, макар да не съм ритуално-религиозен. Чел съм Библията няколко пъти. Що се отнася до традиционното семейство – преди 5 месеца ни се роди едно прекрасно дете.

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

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

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

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

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

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

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

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

Idea: A Generic P2P Network Client

Post Syndicated from Bozho original https://techblog.bozho.net/idea-a-generic-p2p-network-client/

Every now and then one has a half-baked idea about some project that they aren’t likely to be able to do because of lack of time. I’ve written about such random app ideas before, but they were mostly about small apps.

Here I’d like to share an idea for something a bit bigger (and therefor harder to spare time for) – a generic P2P network client. P2P networks are popular in various domains, most notably file sharing and cryptocurrencies. However, in theory they can be applied to many more problems, social networks, search engines, ride sharing, distributed AI, etc. All of these examples have been implemented in p2p context, and they even work okay, but they lack popularity.

The popularity is actually the biggest issue with these applications – in order to get a service to be popular, in many cases you need a network effect – a p2p file sharing with 100 users doesn’t benefit from being p2p. A social network with 100 users is, well, useless. And it is hard to get traction with these p2p services because they require an additional step – installing software. You can’t just open a webpage and register, you have to install some custom software that will be used to join the p2p network.

P2P networks are distributed, i.e. there is no central node that has control over what happens. That control is held over the binary that gets installed – and it’s usually open source. And you need that binary in order to establish an overlay network. These networks reuse the internet’s transport layer, but do not rely on the world wide web standards, and most importantly, don’t rely heavily on DNS (except, they actually do when run for the first time in order to find a few known seed nodes). So once you are connected to the network, you don’t need to make HTTP or DNS queries, everything stays in the specifics of the particular protocol (e.g. bittorrent).

But the fact that not only you have to trust and install some piece of software, you have to be part of the network and exchange data regularly with peers. So it really doesn’t scale if you want to be part of dozens of p2p networks – each of them might be hungry for resources, you have to keep dozens of applications running all the time (and launching on startup).

So here’s the idea – why don’t we have a generic p2p client. A software that establishes the link to other peers and is agnostic on what data is going to be transferred. From what I’ve seen, the p2p layer is pretty similar in different products – you try to find peers in your immediate network, if none are found, you connect to a known seed node (first by DNS which uses DNS round-robin and then by a list of hardcoded IPs), and when you connect the seed node gives you a list of peers to connect to. Each of those peers has knowledge of other peers, so you can quickly be connected to a significant number of peer nodes (I’m obviously simplifying the flow, but that’s roughly how it works).

Once you have an established list of peers, you start doing the application-specific stuff – sharing files, downloading a cryptocurrency ledger, sharing search indexes, sharing a social network profile database, etc. But the p2p network part can be, I think, generalized.

So we can have that generic client and make it pluggable – every application developer can write their own application ontop of it. The client will not only be a single point for the user, but can also manage resources automatically – inbound and outbound traffic, CPU/GPU usage (e.g. in case of cryptocurrency mining). And all of these applications (i.e. plugins) can either be installed by downloading them from the vendor’s website (which is somewhat similar to the original problem), or can be downloaded from a marketplace available within the client itself. That would obviously mean a centralized marketplace, unless the marketplace itself is a p2p application that’s built-in the client.

So, effectively, you’d be able to plug-in your next file sharing solution, you next cryptocurrency, encrypted messaging, or your next distributed social network. And your users won’t have the barrier of installing yet another desktop app. That alone does not solve the network effect, as you still need enough users to add your plugin to their client (and for many to have the client to begin with), but it certainly makes it easier for them. Imagine if we didn’t have Android and Apple app stores and we had to find relevant apps by other means.

This generic client can possibly be even a browser plugin, so that it’s always on when you are online. It doesn’t have to be, but it might ease adoption. And while it will be complicated to write it as a plugin, it’s certainly possible – there are already p2p solutions working as browser plugins.

Actually, many people think of blockchain smart contracts as a way to do exactly that – have distributed applications. But they have an unnecessary limitation – they work on data that’s shared on a blockchain. And in some cases you don’t need that. You don’t need consensus in the cryptocurrency sense. For example in file sharing, all you need to do is compute the hash of the file (and of its chunks) and start sending them to interested peers. No need to store the file on the blockchain. Same with instant messaging – you don’t need to store the message on a shared immutable database, you only need to send it to the recipients. So smart contracts are not as generic solution as what I’m proposing.

Whether a generic client can accommodate an unlimited amount of different protocols and use cases, how would the communication protocol look like, what programming languages it should support and what security implications that has for the client (e.g. what’s the sandbox that the client provides), what UI markup will be used, are all important operational details, but are besides the point of this post.

You may wonder whether there isn’t anything similar done already. Well, I couldn’t find one. But there’s a lot done that can support such a project: Telehash (a mesh protocol), JXTA (a p2p protocol) and its Chaupal implementation, libp2p and Chimera (p2p libraries), Kademlia (a distributed hash table).

Whether such a project is feasible – certainly. Whether its adoption is inevitable – not so certainly, as it would require immediate usefulness in order to be installed in the first place. So, as every “platform” it will face a chicken-and-egg problem – will people install it if there are no useful plugins, and will people write plugins if there are no user installations. That is solvable in a number of ways (e.g. paying developers initially to write plugins, bundling some standard applications (e.g. file sharing and instant messaging). It could be a business opportunity (monetized through the marketplace or subscriptions) as well as a community project.

I’m just sharing the idea, hoping that someone with more time and more knowledge of distributed networks might pick it up and make the best of it. If not, well, it’s always nice to think about what can the future of the internet look like. Centralization is inevitable, so I don’t see p2p getting rid of centralized services anytime soon (or ever), but some things arguably work better and safer when truly decentralized.

The post Idea: A Generic P2P Network Client appeared first on Bozho's tech blog.

Привижда ли ни се руска заплаха?

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

Когато се спомене „хибридна война“, или заплаха от руски хакери, или фалшиви новини, или по-общо вмешателство във вътрешните работи на други държави, някои хора го подминават пренебрежително. „Само Русия ви се привижда“, „не е Русия проблемът“, „каква е тая измислена хибридна война“ и т.н.

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

  • Хакване на политически организации – Дали Тръмп победи Хилър Клинтън заради руската подкрепа или не, и дали е искал и координирал тази подкрепа или не не са теми на тази статия. Но руски хакери, пряко или непряко свързани с руските служби, атакуват мрежите на Демократическата партия, както и отделни членове на кампанията на Клинтън. Това е детайлно описано в обвинението на Робърт Мълър срещу 12 руски агенти (и е доста интересно да се прочете). Компанията CrowdStrike първа идентифицира атаката. Същото стана с френските избори и имейлите на кампанията на Макрон. Руски агенти опитваха да хакнат и международната организация, която следи за неизползването на химически оръжия. И това са само случаи, за които знаем.
  • DDoS или т.нар. „отказ от услуга“. След като Естония през 2007-ма сваля съветски монумент, всички институции в страната са засипани от фалшив трафик и държавата на практика спира. Атаката срещу българските институции по време на изборите през 2015-та също с голяма вероятност е с руски източник. Общо взето, когато целта не е да се придобие информация, а да се създаде хаос, този метод е „за предпочитане“
  • Фалшиви новини – това е доста по-масирана кампания, отколкото изглежда на пръв поглед. Преди година беше публикуван доклад за руската пропаганда в България. Там могат да се прочетат много интересни неща, като например как се разпространяват фалшиви новини чрез 3500 уебсайт. Някои се появяват, друг изчезват, копират съдържание един от друг, а по определени параметри може да се определи, че повечето от тях се оперират от едно и също място. Темите там са „упадъчният запад“, руската мощ и други. В някои такива сайтове можем да проследим началото на пропагандата по теми като „ювеналната юстиция“ (която стана популярна наскоро).

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

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

  • Тролове и фалшиви акаунти – това е допълнителен канал за създаване на фалшива реалност. Десетки хиляди фалшиви акаунти в социални мрежи и новинарски сайтове създават фалшива съдържание, което нищо неподозиращи потребители консумират. Чрез този канал се разпространяват ефективно и фалшивите новини. В много интересна статия Washington Post разказва за реакциите в САЩ на дезинформационната кампания по време на изборите през 2016. „Internet research agency“, или фабриката за тролове край Петербург, е най-популярната такава, но съвсем не единствена. Те заливат социалните мрежи с добре подбрано и таргетирано съдържание, което да подчертава разделенията между хората по определени теми и така да разруши обществената среда и обществения дебат. Редица научни изследвания показват връзките между фалшивите профили – час на регистриране, еднотипни грешки в писането на английски, часове, в които са активни, общи акаунти, които следват (в туитър) и т.н.
  • Финансиране на политически партии – тук официални данни няма, но за повечето крайно-десни европейски партии има обосновани предположения, че се финансират от Кремъл. За българската „Атака“ е горе-долу очевидно, а тази година беше публикувана информация, че Кремъл финансира италианската Лига на Салвини през сложна схема с дизелово гориво. Френските националисти пък са получили заем от руска банка, а Лю Пен не крие симпатиите си към Путин. Преди години The Economist разгледа темата, подчертавайки, че рядко има доказателства за пряко финансиране, но все пак вероятността е доста голяма
  • Директна намеса – понякога руските агенти действат директно – при опита за преврат в Черна гора, анексирането на Крим, подкрепата на сепаратистите в източна Украйна, в следствие на което беше свален малайзийския самолет (и само преди седмица Холандия повдигна обвинения срещу четирима души, трима от които „бивши“ служители на руските служби). Предполагаемото отравяне на българския бизнесмен Гебрев от един от агентите, които след това отровиха Скрипал във Великобритания пък показва, че тези примери за директна намеса неизбежно стигат и до нашата територия

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

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

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

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

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

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

First Thoughts About Facebook’s Libra Cryptocurrency

Post Syndicated from Bozho original https://techblog.bozho.net/first-thoughts-about-facebooks-libra-cryptocurrency/

Facebook announced today that by 2020 they will roll out Libra – their blockchain-based cryptocurrency. It is, of course, major news, as it has the potential to disrupt the payment and banking sector. If you want to read all the surrounding newsworthy details, you can read the TechCrunch article. I will instead focus on a few observations and thoughts about Libra – from a few perspectives – technical, legal/compliance, and possibly financial.

First, replacing banks and bank transfers and credits cards and payment providers and ATMs with just your smartphone sounds appealing. Why hasn’t anyone tried to do that so far – well, many have tried, but you can’t just have the technology and move towards gradual adoption. You can’t even do it if you are Facebook. You can, however, do it, if you are Facebook, backed by Visa, Mastercard, Uber, and many, many more big names on the market. So Facebook got that right – they made a huge coalition that can drive such a drastic change forward.

I have several reservations, though. And I’ll go through them one by one.

  • There is not much completed – there is a website and a technical paper and an open-source prototype. It’s not anywhere near production. The authors of the paper write that the Move language is still being designed (and it’s not that existing move language). The opensource prototype is still a prototype (and one that’s a bit hard to read, thought that might be because of the choice of Rust). This means they will work with tight schedules to make this global payment system operational. The technical paper is a bit confusing hard to follow. Maybe they rushed it out and didn’t have time to polish it, and maybe it’s just a beginning of a series of papers. Or maybe it’s my headache and the paper is fine.
  • The throughput sounds insufficient – the authors of the paper claim that they don’t have any performance results yet, but they expect to support around 1000 transactions per second. This section of the paper assumes that state channels will be used and most transactions won’t happen on-chain, but that’s a questionable assumption, as the use of state channels is not universally applicable. And 1000 TPS is too low compared to the current Visa + mastercard transactions (estimated to be around 5000 per second). Add bank transfers, western union, payment providers and you get a much higher number. If from the start you are presumably capped at 1000, would it really scale to become a global payment network? Optimizing throughput is not something that just happens – other cryptocurrencies have struggled with that for years.
  • Single merkle tree – I’m curious whether that will work well in practice. A global merkle tree that is being concurrently and deterministically updated is not an easy task (ordering matters, timestamps are tricky). Current blockchain implementations use one merkle tree per block and it’s being constructed based on all transactions that fall within that block when the block is “completed”. In Libra there will be no blocks (so what does “blockchain” mean anyway), so the merkle tree will always grow (similar to the certificate transparency log).
  • How to get money in? – Facebook advertises Libra as a way for people without bank accounts to do payments online. But it’s not clear how they will get Libra tokens in the first place. In third world countries, consumers’ interaction is with the telecoms where they get their cheap smartphones and mobile data cards. The realistic way for people to get Libra tokens would be if Facebook had contracts with Telecoms, but how and whether that is going to be arranged, is an open question.
  • Key management – key management has always been, and will probably always be a usability issue for using blockchain by end users. Users don’t want to to manage their keys, and they can’t do that well. Yes, there are key management services and there are seed phrases, but that’s still not as good as getting a centralized account that can be restored if you lose your password. And if you lose your keys, or your password (from which a key is derived to encrypt your keys and store them in the cloud), then you can lose access to your account forever. That’s a real risk and it’s highly undesirable for a payment system
  • Privacy – Facebook claims it won’t associate Libra accounts with facebook accounts in order to target ads. And even if we can trust them, there’s an inherent privacy concern – all payments will be visible to anyone who has access to the ledger. Yes, a person can have multiple accounts, but people will likely only use one. It’s not a matter of what can be done by tech savvy users, but what will be done in reality. And ultimately, someone will have to know who those addresses (public keys) belong to (see the next point). A zcash-basedh system would be privacy preserving, but it can’t be compliant
  • Regulatory compliance – if you are making a global payment system, you’d have to make regulators around the world, especially the SEC, ESMA, ECB. That doesn’t mean you can’t be distruptive, but you have to take into account real world problems, like KYC (know your customer) processes as well as other financial limitations (you can’t print money after all). Implementing KYC means people being able to prove who they are before they can open an account. This isn’t rocket science, but it isn’t trivial either, especially in third world countries. And money launderers are extremely inventive, so if Facebook (or the Libra association) doesn’t get its processes right, it risks becoming very lucrative for criminals and regime officials around the world. Facebook is continuously failing to stop fake news and disinformation on the social network despite the many urges from the public and legislators, I’m not sure we can trust them with being “a global compliance officer”. Yes, partners like Visa and Mastercard can probably help here, but I’m not sure how involved they’ll be.
  • Oligarchy – while it has “blockchain” in the tagline, it’s not a democratizing solution. It’s a private blockchain based on trusted entities that can participate in it. If it’s going to be a global payment network, it will be a de-facto payment oligarchy. How is that worse from what we have now? Well now at least banks are somewhat independent power players. The Libra association is one player with one goal. And then antitrust cases will follow (as they probably will immediately, as Facebook has long banned cryptocurrency ads on the website only to unveil its own)

Facebook has the power to make e-commerce website accept payments in Libra. But will consumers want it. Is it at least 10 times better than using your credit card, or is it marginally better so that nobody is bothered to learn yet another thing (and manage their keys). Will third world countries really be able benefit from such a payment system, or others will prove more practical (e.g. the m-pesa)? Will the technology be good enough or scalable enough? Will regulators allow it, or will Facebook be able to escape their graps with a few large fines until they’ve conquered the market?

I don’t know the answers, but I’m skeptical about changing the money industry that easily. And given Facebook’s many privacy blunders, I’m not sure they will be able to cope well in a much more scrutinized domain. “Move fast and break things” and easily become “Move fast and sponsor terrorism”, and that’s only partly a joke.

I hope we get fast and easy digital payments, as bank transfers and even credit cards feel too outdated. But I’m sure it’s not easy to meet the complex requirements of reality.

The post First Thoughts About Facebook’s Libra Cryptocurrency appeared first on Bozho's tech blog.

Reflection is the most important Java API

Post Syndicated from Bozho original https://techblog.bozho.net/reflection-is-the-most-important-java-api/

The other day I was wondering – which is the most important Java API. Which of the SE and EE APIs is the one that makes most of the Java ecosystem possible and that could not have just been recreated as a 3rd party library.

And as you’ve probably guessed by the title – I think it’s the Reflection API. Yes, it’s inevitably part of every project, directly or indirectly. But that’s true for many more APIs, notably the Collection API. But what’s important about the Reflection API is that it enabled most of the popular tools and frameworks today – Spring, Hibernate, a ton of web frameworks.

Most of the other APIs can be implemented outside of the JDK. The Collections API could very well be commons-collect or guava. It’s better that it’s part of the JDK, but we could’ve managed without it (it appeared in Java 1.2). But the reflection API couldn’t. It had to almost be an integral part of the language.

Without reflection, you could not have any of the fancy tools that we use today. Not ORM, not dependency injection frameworks, and not most of the web frameworks. Well, technically, you could at some point have theme – using SPI, or using java-config only. One may argue that if it wasn’t for reflection, we’d have skipped the whole XML configuration era, and wend directly to code-based configuration. But it’s not just configuration that relies on reflection in all these frameworks. Even if Spring could have its beans instantiated during configuration and initialized by casting them to InitalizingBean, how would you handle the autowired injection without reflection (“manually” doesn’t count, as it’s not autowiring)? In hibernate, the introspection and java bean APIs might seem sufficient, but when you dig deeper, they are not. And handling annotations would not be possible in general.

And without these frameworks, Java would not have been the widespread technology that it is today. If we did not have the huge open-source ecosystem, Java would have been rather niche [citation needed]. Of course, that’s not the only factor – there are multiple things that the language designers and then the JVM implementors got right. But reflection is, I think, one of those things.

Yes, using reflection feels hacky. Reflection in the non-framework code feels like a last resort thing – you only use it if a given library was not properly designed for extension but you need to tweak it a tiny bit to fit your case. But even if you have zero reflection code in your codebase, your project is likely full of it and would not have been possible without it.

The need to use reflection might be seen as one of the deficiencies of the language – you can’t do important stuff with what the language gives you, so you resort to a magic API that gives you unrestricted access to otherwise (allegedly) carefully designed APIs. But I’d say that even having reflection is a de-facto language feature. And it is one that probably played a key role in making Java so popular and widespread.

The post Reflection is the most important Java API appeared first on Bozho's tech blog.

Време е да се откажем от машинното гласуване

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

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

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

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

  • Секционната комисия не въвежда резултата от машинното гласуване в протокола и изпраща машината директно в РИК. В секциите, в които имаше наши застъпници, последва сигнал до РИК и впоследствие резултатите бяха въведени в протоколите. Не мога да съм сигурен обаче за секции, където е нямало грамотни застъпници.
  • Преференциите от машинното гласуване липсват в много от секциите, како писа „Отворен парламент“
  • В една секция машината е извадила 88 гласа в протокола, а в кутията с разписки е имало 93 подадени гласа. В друга секция в разписката е била маркирана преференция при глас за независим кандидат. И двата случая изглеждат като бъгове в софтуера.

Тези конкретни проблеми са следствие от множество принципни такива:

  • Секционните комисии не са достатъчно обучени, за да се справят с изборния процес. Въпреки методическите указания, масово се правят пропуски при попълването на протоколите. Последващите процеси на корекции в РИК изглежда невинаги са достатъчни
  • Резултатът от машинното трябва да се прибави ръчно към резултата от хартиеното и да се впише в съответната графа в протокола – т.е. дори машината да брои правилно, накрая пак хора преписват. И при грешка при това пренасяне няма как последващи проверки да установят проблема. Този процес е заложен в Изборния кодекс и няма лесно поправяне
  • ЦИК е постоянно действащ орган, но може да обявява обществени поръчки само след указа на президента за съответните избори. Т.е. по дефиниция поръчката за машини е „в последния момент“ и няма време да бъде установено тяхното качество
  • Липсва процедура по проверка на машините (преди, по време и след изборите) – бъговете, споменати преди малко са един проблем, но ако кодът не е публично достъпен, в един момент може машините да се ползват и за манипулиране на изборите. И макар формално да има одит, той се случва в твърде кратки срокове, за да е адекватен. В момента нямаме гаранции дори че машините отговарят на изискванията на обществената поръчка
  • Цената е прекалено висока за много малкото полза от машините и за проблемите, които създават. 9 милиона само за европейските избори. Да, машините са под наем. Но купуването също води до усложнения – как се съхраняват, как се поддържат, как се подменят.

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

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

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

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

Ефектът на демократичната пеперуда

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

В неделя предстоят европейски избори. И ми се искаше да напиша нещо много мотивиращо за това, че трябва да се гласува. Но единствените мисли, които ми идваха, бяха в числа. Че българите избираме 2.26% от евродепутатите, докато избирателите от Ямбол, Винин или Габрово избират само 1.6% от българските депутати. Или колко процента е европейското законодателство и затова не е безсмислено да се гласува. Или колко бихме спечелили от разни предстоящи европейски политики, като единната енергийна политика.

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

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

И в този ред на мисли се чудех какъв е ефектът от евроизборите, какво променят. Освен европейския политически пейзаж, евроизборите променят и местния такъв. Кой колко гласа ще вземе на европейските избори има значение за управлението на страната. След предните европейски избори ДПС се оттегли от властта и Орешарски подаде оставка. Да, бяха само повод, а не и причина за схизмата в управлението, но това също не е малко. В момента имаме сходна ситуация – скандал с махленска корупция и разединени коалиционни партньори в управлението. Европейските избори могат да бъдат повод за преконфигуриране на властта.

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

Ясно е, че тази публикация ще завърши с това да ви агитирам да гласувате за Демократична България (номер 13), от която съм част. Обаче това не е онлайн анкета или гласуване с sms-и в риалити шоу. Не искам просто „да викаме за наш’те“.

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

Демокрацията, а и историята като цяло, понякога демонстрират ефекта на пеперудата. Малко действие, малка промяна в условията води до големи промени.

Най-популярният пример за това е може би изборът на Джордж Буш с няколкостотин гласа във Флорида. Тези няколкостотин гласа влияят силно на човешката история и (може би) водят до войни в Афганистан и Ирак, съответно години по-късно (може би) до мигрантска вълна към Европа и съответно ръст на популизма. Тези няколкостотин гласа разлика пък вероятно са дошли заради избора на вид бюлетина (иронично, тип „пеперуда“) и на съмнителни машини за гласуване, като този избор вероятно е направен от някоя местна комисия, чието назначаване е било следствие от някакви „незначителни“ избори във Флорида.

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

Няма значение дали Радан Кънев и Стефан Тафров ще отидат в Брюксел (макар че съм убеден, че ще бъдат най-адекватните ни европейски депутати). Няма значение дали Пеевски ще стане този път евродепутат или пак ще се откаже. Няма значение дали въпреки промените в изборния кодекс пак ще има ефект „15/15“ при БСП или не.

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

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