All posts by Bozho

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“, дали ще има още апартаменти и къщи за гости на фона на срутващи се ремонти, и т.н. и т.н. Дали ще продължаваме да сме най-корумпираната, бедна и несвободна държава в Европа.

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

Цацаров и Имотният регистър

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

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

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

Само че данните са си там – при други търсения излизат. Т.е. едва ли става дума за заличаване на данни, а по-скоро за проблем при визуализацията ми. Дали пък някой не е добавил тайно в кода условие if (Цацаров) скрий данни;? Оказва се, че не.

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

„акт №196, том 8 от 2007 г. е въведен в стара информационна система през 2007 г (…). В старата система са се въвеждали поотделно данни за всеки имот и лице, свързано с него, т.е. не е имало възможност да се отразяват връзки между страните в акта и имота. От приложената справка/снимка от медията ясно се виждат 3 отделни записа/генерирани справки. Това е така поради начина на въвеждане на данни в старата информационна система, а именно три отделни записа за всяка страна“

Ще опитам да го обясня на човешки език – вместо в базата данни всеки имот да е уникален запис, а всеки участник в сделката да бъде свързан към този запис, системата явно е била направена така че за сделката на Цацаров (която е била с един дарител/продавач и двама надарени/купувачи) е имало три записа – един запис „имот – Цацаров“, един запис „имот – жената на Цацаров“ и един запис „имот – дарителя/продавача“.

Пиша „дарител/продавач“, защото според Бивол и Капитал преди 7 години това е било променено в имотния регистър. Т.е. от дарение се е превърнало в продажба (защо и как е друга тема).

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

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

Казано на шега – лош модел на данните води до политически скандал. Но всъщност това е част от големия проблем тук. Че данните в един от най-важните регистри в държавата с в такъв вид вече над 10 години. И че агенцията не е предприела никакви мерки да ги „почисти“. Цацаров не е изолиран случай и регистърът реално не предоставя адекватна справочна информация.

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

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

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

JKS: Extending a Self-Signed Certificate

Post Syndicated from Bozho original https://techblog.bozho.net/jks-extending-a-self-signed-certificate/

Sometimes you don’t have a PKI in place but you still need a key and a corresponding certificate to sign stuff (outside of the TLS context). And after the certificate in initially generated jks file expires, you have few options – either generate an entirely new keypair, or somehow “extend” the existing certificate. This is useful mostly for testing and internal systems, but still worth mentioning.

Extending certificates is generally not possible – once they expire, they’re done. However, you can have a new certificate with the same private key and a longer period. This sounds like something that should be easy to do, but it turns it it isn’t that easy with keytool. Even with my favourite tool, keystore explorer, it’s not immediately possible.

In order to reuse the private key to have a new, longer certificate, you need to do the following:

  1. Export the private key (with keytool & openssl or through the keystore-explorer UI, which is much simpler)
  2. Make a certificate signing request (with keytool or through the keystore-explorer UI)
  3. Sign the request with the private key (i.e. self-signed)
  4. Import the certificate in the store to replace the old (expired) one

The last two steps seem to be not straightforward with keytool or keystore exporer. If you try to sign the request with your existing keystore keypair, the current certificate is used as the root of the chain (and you don’t want that). And you can’t remove the certificate and generate a new one.

So you need to use OpenSSL:

x509 -req -days 3650 -in req.csr -signkey private.key -sha256 -extfile extfile.cnf -out result.crt

The extfile.cnf is optional and is used if you want to specify extensions. E.g. for timestamping, the extension file looks like this:

extendedKeyUsage=critical,timeStamping

After that “simply” create a new keystore and import the private key and the newly generated certificate. This is straightforward through the keystore-explorer UI, and much less easy through the command line.

You’ve noticed my preference for keytool-explorer. It is a great tool that makes working with keys and keystores easy and predictable, as opposed to command-line tools like keytool and openssl, which I’m sure nobody is able to use without googling every single command. Of course, if you have to do very specific or odd stuff, you’ll have to revert to command line, but for most operations the UI is sufficient (unless you have to automate it, in which case, obviously, use the CLI).

You’d rarely need to do what I’ve shown above, but in case you have to, I hope the hints above were useful.

The post JKS: Extending a Self-Signed Certificate appeared first on Bozho's tech blog.

Скучно за стратегиите

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Multiple Cache Configurations with Caffeine and Spring Boot

Post Syndicated from Bozho original https://techblog.bozho.net/multiple-cache-configurations-with-caffeine-and-spring-boot/

Caching is key for performance of nearly every application. Distributed caching is sometimes needed, but not always. In many cases a local cache would work just fine and there’s no need for the overhead and complexity of the distributed cache.

So, in many applications, including plain Spring and Spring Boot, you can use @Cacheable on any method and its result will be cached so that the next time the method is invoked, the cached result is returned.

Spring has some default cache manager implementations, but external libraries are always better and more flexible than simple implementations. Caffeine, for example is a high-performance Java cache library. And Spring Boot comes with a CaffeineCacheManager. So, ideally, that’s all you need – you just create a cache manager bean and you have caching for your @Cacheable annotated-methods.

However, the provided cache manager allows you to configure just one cache specification. Cache specifications include the expiry time, initial capacity, max size, etc. So all of your caches under this cache manager will be created with a single cache spec. The cache manager supports a list of predefined caches as well as dynamically created caches, but on both cases a single cache spec is used. And that’s rarely useful for production. Built-in cache managers are something you have to be careful with, as a general rule.

There are a few blogposts that tell you how to define custom caches with custom specs. However, these options do not support the dynamic, default cache spec usecase that the built-in manager supports. Ideally, you should be able to use any name in @Cacheable and automatically a cache should be created with some default spec, but you should also have the option to override that for specific caches.

That’s why I decided to use a simpler approach than defining all caches in code that allows for greater flexibility. It extends the CaffeineCacheManager to provide that functionality:

/**
 * Extending Caffeine cache manager to allow flexible per-cache configuration
 */
public class FlexibleCaffeineCacheManager extends CaffeineCacheManager implements InitializingBean {
    private Map<String, String> cacheSpecs = new HashMap<>();

    private Map<String, Caffeine<Object, Object>> builders = new HashMap<>();

    private CacheLoader cacheLoader;

    @Override
    public void afterPropertiesSet() throws Exception {
        for (Map.Entry<String, String> cacheSpecEntry : cacheSpecs.entrySet()) {
            builders.put(cacheSpecEntry.getKey(), Caffeine.from(cacheSpecEntry.getValue()));
        }
    }

    @Override
    @SuppressWarnings("unchecked")
    protected Cache<Object, Object> createNativeCaffeineCache(String name) {
        Caffeine<Object, Object> builder = builders.get(name);
        if (builder == null) {
            return super.createNativeCaffeineCache(name);
        }

        if (this.cacheLoader != null) {
            return builder.build(this.cacheLoader);
        } else {
            return builder.build();
        }
    }

    public Map<String, String> getCacheSpecs() {
        return cacheSpecs;
    }

    public void setCacheSpecs(Map<String, String> cacheSpecs) {
        this.cacheSpecs = cacheSpecs;
    }

    public void setCacheLoader(CacheLoader cacheLoader) {
        super.setCacheLoader(cacheLoader);
        this.cacheLoader = cacheLoader;
    }
}

In short, it create one caffeine builder per spec and uses that instead of the default builder when a new cache is needed.

Then a sample XML configuration would look like this:

<bean id="cacheManager" class="net.bozho.util.FlexibleCaffeineCacheManager">
    <property name="cacheSpecification" value="expireAfterWrite=10m"/>
    <property name="cacheSpecs">
        <map>
            <entry key="statistics" value="expireAfterWrite=1h"/> 
       </map>
    </property>
</bean>

With Java config it’s pretty straightforward – you just set the cacheSpecs map.

While Spring has already turned into a huge framework that provides all kinds of features, it hasn’t abandoned the design principles of extensibility.

Extending built-in framework classes is something that happens quite often, and it should be in everyone’s toolbox. These classes are created with extension in mind – you’ll notice that many methods in the CaffeineCacheManager are protected. So we should make use of that whenever needed.

The post Multiple Cache Configurations with Caffeine and Spring Boot appeared first on Bozho's tech blog.

Електронното управление срещу корупцията

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Positive Side-Effects of Blockchain

Post Syndicated from Bozho original https://techblog.bozho.net/the-positive-side-effects-of-blockchain/

Blockchain is a relatively niche technology at the moment, and even thought there’s a lot of hype, its applicability is limited. I’ve been skeptical about its ability to solve all the world’s problems, as many claim, and would rather focus it on solving particular business issues related to trust.

But I’ve been thinking about the positive side-effects and it might actually be one of the best things that have happened to software recently. I don’t like big claims and this sound like one, but bear with me.

Maybe it won’t find its place in much of the business software out there. Maybe in many cases you don’t need a distributed solution because the business case does not lend itself to one. And certainly you won’t be trading virtual coins in unregulated exchanges.

But because of the hype, now everyone knows the basic concepts and building blocks of blockchain. And they are cryptographic – they are hashes, digital signatures, timestamps, merkle trees, hash chains. Every technical and non-technical person in IT has by now at least read a little bit about blockchain to understand what it is.

So as a side effect, most developers and managers are now trust-conscious, and by extension – security conscious. I know it may sound far-fetched, but before blockchain how many developers and managers knew what a digital signature is? Hashes were somewhat more prevalent mostly because of their (sometimes incorrect) use to store passwords, but the PKI was mostly arcane knowledge.

And yes, we all know how TLS certificates work (although, do we?) and that a private key has to be created and used with them, and probably some had a theoretical understanding of digital signatures. And we knew encryption was kind of a good idea at rest and in transit. But putting that in the context of “trust”, “verifiability” and “non-repudiation” was, in my view, something that few people have done mentally.

And now, even by not using blockchain, developers and managers would have the trust concept lurking somewhere in the back of their mind. And my guess would be that more signatures, more hashes and more trusted timestamps will be used just because someone thought “hey, we can make this less prone to manipulation through this cool cryptography that I was reminded about because of blockchain”.

Blockchain won’t be the new internet, but it already has impact on the mode of thinking of people in the software industry. Or at least I hope so.

The post The Positive Side-Effects of Blockchain appeared first on Bozho's tech blog.

Нюансирано за Асандж

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

Арестуваха Джулиан Асандж.

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

За други е герой на свободното слово, който е разобличил американските власти нееднократно.

За първите той е прислужник на Кремъл, който използва свободата на словото като претекст да атакува Америка.

За вторите той е самоотвержен инструмент за на т.нар. whistleblowers (хора, които издават тайни, защото смятат, че е важно, обществото да ги знае), с които западните държави да поддържат нивото си на демократичност и прозрачност.

Реално… е по-сложно. Да, изтичането на класифицирана информация винаги крие рискове, ако не се прави внимателно, да, особено в последните години WikiLeaks и Кремъл работеха ръка за ръка, да, whistleblowers трябва да имат инструмент, с който да правят публично достояние силно спорни практики, като напр. Prism, и да, WikiLeaks имаше дисциплиниращ ефект.

Трябва ли обществото да знае всичко? По-скоро не. Концепцията за „класифицирана информация“ същество по обективни причини. Но определено има случаи, в които обществото трябва да знае за дадена класифицирана информация. Трябваше ли да знаем за това как американски войници застрелват цивилни и репортери на Ройтерс в Ирак, знаейки много добре, че не представляват опасност? Трябваше ли да знаем, че американското правителство е изградило сложна система за следене на всичко, което правим онлайн? Трябваше ли да знаем за писмата на Сурков (висшестоящ сътрудник в Кремъл), според които Русия има стратегическа цел да дестабилизира Украйна? Според мен и в трите случая, а и в много други – да. Неслучайно тези разкрития излязоха и през реномирани издания като The New York Times и The Guardian.

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

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

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

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

Command-line SQL Client for IBM i 7.x (AS/400)

Post Syndicated from Bozho original https://techblog.bozho.net/command-line-sql-client-for-ibm-i-7-x-as-400/

In the category of “niche blogposts”, this is probably the “nichest”. But it might be useful, so I’ll share it.

Recently I had to interface an IBM i system (think “mainframe”, though not exactly) from a command-line-only Linux environment. The interesting part is that you can access the IBM i files through SQL syntax, as they are tabular in nature. However, I failed to find a proper tool for that. There are UI tools by IBM but they don’t work in a headless environment.

So I decided to write my own simple tool – a command line SQL client for IBM i 7.x. It relies on an IBM-provided library (which, by the way, fails in some cases in headless environments as well, as it tries to prompt for certain data using awt/swing). The tool can be used after building it with maven and by simply executing SQL queries after connecting:

java -jar as400-sql-client.jar <connectionString> <username> <password>

It can be can be fond here. Apart from being useful in navigating the IBM system, it relies in the jline project which allows you to create rich command line tools that support autocomplete, history, coloring, etc.

I hope that nobody will need this tool, but in the rare case that someone does need it, I hope to save them hours of struggle.

The post Command-line SQL Client for IBM i 7.x (AS/400) appeared first on Bozho's tech blog.

Грешната посока на НАП с Наредба Н-18

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

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

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

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

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

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

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

Т.е. проблемите са сложност, непредсказуемост, висока цена за бизнеса, липса на адекватна оценка от страна на НАП.

А каква е целта? Целта е събиране на пари в бюджета, като оценката, която съм чувал (но не можах да намеря в мотивите) е 300 милиона на година.

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

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

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

Посоката трябва да бъде към опростяване на нормативната уредба и опростяване на инфраструктурата. И ето няколко предложения за правилна посока:

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

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