All posts by Bozho

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 (втората директива за платежни услуги) така или иначе задължава банките да имат програмен интерфейс за достъп до сметки на клиенти, просто НАП ще трябва да получават такъв и да интегрират системите си. Тази стъпка е доброволна, разбира се – за улеснение на страните. Ако някой бизнес не желае да дава достъп до сметката си, НАП не може да го задължи.

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

Audit Trail in IT Context

Post Syndicated from Bozho original https://techblog.bozho.net/audit-trail-in-it-context/

An audit trail (or audit log) is something both intuitive and misleading at the same time. There are many definitions of an audit trail, and all of them give you an idea of what it is about:

A system that traces the detailed transactions relating to any item in an accounting record.

A record of the changes that have been made to a database or file.

An audit trail (also called audit log) is a security-relevant chronological record, set of records, and/or destination and source of records that provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, or event.

An audit trail is a step-by-step record by which accounting or trade data can be traced to its source

The definitions are clear, but they rarely give enough detail on how they apply to a particular IT setup. The Wikipedia article is pretty informative, but I prefer referring to the NIST document about audit trail. This relatively short document from more than 20 years ago covers many the necessary details.

I won’t repeat the NIST document, but I’d like to focus on the practical aspects of an audit trail in order to answer the question in the title – what is an audit trail? In the context of a typical IT setup, the audit trail includes all or some of the following:

  • Application-specific audit trail – ideally, each application records business-relevant events. They may be logged in text files or in separate database tables. They allow reconstructing the history much better than the arbitrary noisy logging that is usually in place
  • Application logs – this is a broader category as it includes logs that are not necessarily part of the audit trail (e.g. debug messages, exception stacktraces). Nevertheless, they may be useful, especially in case there is no dedicated application-specific audit trail functionality
  • Database logs – whether it is logged queries, change data capture or change tracking functionality, or some native audit trail functionality
  • Operating system logs – for Linux that would include the /var/log/audit/audit.log (or similar files), /var/log/auth.log. For Windows it would include the Windows Event logs for the Security and System groups.
  • Access logs – access logs for web servers can be part of the audit trail especially for internal systems where a source IP address can more easily be mapped to particular users.
  • Network logs – network equipment (routers, firewalls) generate a lot of data that may be seen as part of the audit trail (although it may be very noisy)

All of these events can (and should) be collected in a central place where they can be searched, correlated and analyzed.

Ideally, an audit trail event has an actor, an action, details/payload and optionally an entity (type + id) which is being accessed or modified. Having this information in a structured form allows for better analysis and forensics later.

Once the audit trails is collected, it has two other very important properties:

  • Availability – is the audit trail available at all times, and how far back in time can it be accessed (also referred to as “retention”). Typically application, system and network logs are kept for shorter periods of time (1 to 3 months), which is far from ideal for an audit trail. Many standards and regulation require higher retention periods of up to 2 years
  • Integritydata integrity is too often ignored. But if you can’t prove the integrity of your logs, both internally and to third parties (auditors, courts), then they are of no use.

Many organizations understand that the integrity of their audit trail is important only after a security incident takes place and they realize they cannot rely on their audit logs. It is better to protect the audit trail before something bad happens. And not just for some abstract reasons like “best practices” or “improved security”. A secure audit trail allows organizations to:

  • Identify that something wrong has happened. If the audit trail is not protected, a malicious actor can make it seem like nothing anomalous has taken place
  • Prove what happened and who did it. Digital forensics is important for large organizations. Especially in cases where lawsuits are involved.
  • Reconstruct the original data. The audit trail is not a replacement for a full backup, but it can allow you to reconstruct the data that was modified and the time it was modified, so that either you know which backup to use, or to avoid restoring form the backup altogether by just relying on the data provided in the audit trail.
  • Be compliant. Because of all the reasons stated above, many standards and regulations require a secure audit trail. Simple logs are usually not compliant, even though auditors may turn a blind eye.

The audit trail is an important concept, and has very practical implications. It is a widely researched topic, but in practice many IT setups lack sufficient audit trail capabilities. Partly because the risks are not immediately obvious, and partly because it is a technically challenging task.

(The article is originally published on our corporate blog, but I think it can be interesting here as well, so I copied most of it, leaving out the corporate references and calls to action)

The post Audit Trail in IT Context appeared first on Bozho's tech blog.

Пет политически клишета

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

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

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

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

Задължителни пръстови отпечатъци в личните карти в ЕС?

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

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

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

  • Какво толкова, те и сега МВР събират отпечатъци – МВР събират отпечатъци само за нужните на международните паспорти. Или поне така е по закон. Ако са ви взели отпечатъци при издаване на лична карта, това е превратно тълкуване на Закона за българските лични документи. Според действащите текстове на закона, за новите лични карти, които ще имат чип и ще позволяват записване на такива данни, ще се снемат отпечатъци само при изрично желание на гражданите. Това беше дълго обсъждан текст, в чието писане съм участвал. Причината за opt-in модела е, че няма особена полза от ICAO стандарта за електронни документи за пътуване що се отнася до лични карти, тъй като почти няма терминали за автоматично преминаване (e-gates), които да поддържат формат „лична карта“. А рисковете са немалки. Европейската комисия не е отчела този нюанс, между другото, и е писала, че България ще има задължителни отпечатъци в личните карти. Може и колегите им от МВР да с ги подвели. Щото кой да чете закона, пък и мотивите, с които е бил внесен.
  • Какво толкова ще стане, като ни запишат отпечатъците? – това е дълга техническа тема, но накратко – отпечатъците могат да изтекат. Дали през централизираната база данни, за която трябва да се грижи държавата, или през отделните носители. ICAO стандартът предвижда четене на отпечатъци без въвеждане на парола/PIN (за целите на граничните проверки), което води със себе си сложна и „чуплива“ система, в която участва всички държави, издаващи документи по този стандарт. Лошото е, че през годините стандартът е имал множество проблеми със сигурността, които са били коригирани, но някои от тях остават и на теория (надявам се да не видим скоро и на практика) някой може да ви прочете отпечатъците от личната карта в джоба както си стоите в метрото. Не е тривиално, поради ред причини, но е възможно. След това може да направи фалшив отпечатък, с който да излъже сензора на телефона ви, и да получи достъп до важни неща като имейл или дори банкова сметка. Как така фалшив отпечатък? Напълно изпълнимо е, както е показано тук, а сензорите макар да се подобряват, не мисля, че някога ще предотвратят тази възможност напълно. Има домашни брави, които се отварят с отпечатък. Има контролирани зони в офиси и предприятия, които се отварят отпечатък. Всички те стават по-уязвими.
  • Нали няма да има централна база данни с отпечатъци? Регламентът не предвижда задължително такава, но оставя на държавите членки да решат. Нашата вече е решила, тъй като съхранява в база данни отпечатъците, които е снела за паспортите ни. Дали това нарушава гражданските свободи – по-скоро да. Особено когато е ненужно и необосновано.
  • Всеки може да ни снеме отпечатъка от чаша, ако иска, каква е разликата? Разликата е в качеството на снетия отпечатък. В личните документи той е с висока резолюция и е пълен. Отпечатък от чаша няма да е достатъчен за качествен фалшив отпечатък, но този от личната карта ще е предостатъчеб.
  • Биометричната идентификация не е ли бъдещето? Надявам се не. Има много материали по темата, но заключението е, че ако биометричната идентификация е единственият компонент, то това не е достатъчно сигурно. Фундаменталният проблем е, че няма механизъм за промяна. Докато можете да си смените паролата, частния ключ или да си рестартирате OTP token устройсвото, отпечатъкът ви не подлежи на промяна – веднъж изтече ли, няма връщане.
  • Европейсеката Комисия не е ли оценила аспектите на информационната сигурност? Не, не е. В първоначалната оценка на въздейсетвието липсва анализ на ифнромационната сигурност. След като в рамките на вътрешното обсъждане получават коментар, че трябва да има такава, добавят едни 5-6 точки, които са непълни и несвързани и изобщо не са убедителни. Още повече, че ICAO след своя анализ правят отпечатъците в паспортите опционални. Преди години, когато обсъждахме въвеждането на стандарта в българските лични документи, изпратихме писмо до Европейската комисия и до ICAO с въпрос дали сигурността на стандарта е достатъчно висока. От ЕК отговориха с не особено адекватното „ами нямали сме проблеми досега“, а от ICAO отговориха с въпрос – може ли да предложите експерт за работна група. Стандартът е типичен „дизайн от комисия“ и има много потенциални проблеми. Надявам се те да бъдат изчистени някои от тези проблеми, а ЕК да не позволи обратно-съвместими документи (т.е. поддържащи „счупени“ версии на стандарта), но остава фундаменталният архитектурен проблем, който не знам има ли решение.
  • Какво мислят другите държави за биометричните документи? Не всички са щастливи. Когато преди години ЕС задължава всички паспорти да имат отпечатъци, Холандия пита съда трябва и личните карти да са с отпечатъци и съдът казва „не, не трябва“. Решението на съда е интересно за четене и с оглед настоящия Регламент, но като резултат Холандия спира да слага отпечатъци в личните си карти.
  • Това не е ли важна мярка за борба с тероризма и нелегалната миграция? Не, отпечатъците не помагат с нищо, в сравнение със снимката и лицевото разпознаване на границата. Няма сценарий, в който отпечатъкът да е решаващ. (А снимката не крие такива рискове
  • Какви са тогава аргументите „за“? И аз това се чудех. В оценката на въздействието Комисията описва някои притеснения и дори казва, че марката може да е непропорционална. Разбрах, че аргумент на държавите-членки е бил, че човек може да донесе фалшифицирана снимка, с която да се „лъжат“ алгоритмите за лицево разпознаване. На въпрос „защо не правите снимката при подаване на документите за лична карта“, отговорът е бил, че е много скъпо. Да, най-бедната държава в ЕС (България) го е направила – във всяка районно управление има цялата техника, необходима за издаване на документа – но за останалите щяло да е скъпо. Освен това как правене на снимка е скъпо, а снемане на отпечатъци – не е (качествените четци не са толкова евтини).
  • Противопоставянето на отпечатъците не пречи ли на електронното управление? Не, двете нямат общо. Отпечатъците са само за граничен контрол и нищо друго – вкъщи няма как да имате устройство, което да прочете отпечатъците от картата, съответно чрез тях да се идентифицирате пред държавен орган онлайн.

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

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

7 Questions To Ask Yourself About Your Code

Post Syndicated from Bozho original https://techblog.bozho.net/7-questions-to-ask-yourself-about-your-code/

I was thinking the other days – why writing good code is so hard? Why the industry still hasn’t got to producing quality software, despite years of efforts, best practices, methodologies, tools. And the answer to those questions is anything but simple. It involves economic incentives, market realities, deadlines, formal education, industry standards, insufficient number of developers on the market, etc. etc.

As an organization, in order to produce quality software, you have to do a lot. Setup processes, get your recruitment right, be able to charge the overhead of quality to your customers, and actually care about that.

But even with all the measures taken, you can’t guarantee quality code. First, because that’s subjective, but second, because it always comes down to the individual developers. And not simply whether they are capable of writing quality software, but also whether they are actually doing it.

And as a developer, you may fit the process and still produce mediocre code. This is why my thoughts took me to the code from the eyes of the developer, but in the context of software as a whole. Tools can automatically catch code styles issues, cyclomatic complexity, large methods, too many method parameters, circular dependencies, etc. etc. But even if you cover those, you are still not guaranteed to have produced quality software.

So I came up with seven questions that we as developers should ask ourselves each time we commit code.

  1. Is it correct? – does the code implement the specification. If there is no clear specification, did you do a sufficient effort to find out the expected behaviour. And is that behaviour tested somehow – by automated tests preferably, or at least by manual testing,.
  2. Is it complete? – does it take care of all the edge cases, regardless of whether they are defined in the spec or not. Many edge cases are technical (broken connections, insufficient memory, changing interfaces, etc.).
  3. Is it secure? – does it prevent misuse, does it follow best security practices, does it validate its input, does it prevent injections, etc. Is it tested to prove that it is secure against these known attacks. Security is much more than code, but the code itself can introduce a lot of vulnerabilities.
  4. Is it readable and maintainable? – does it allow other people to easily read it, follow it and understand it? Does it have proper comments, describing how a certain piece of code fits into the big picture, does it break down code in small, readable units.
  5. Is it extensible? – does it allow being extended with additional use cases, does it use the appropriate design patterns that allow extensibility, is it parameterizable and configurable, does it allow writing new functionality without breaking old one, does it cover a sufficient percentage of the existing functionality with tests so that changes are not “scary”.
  6. Is it efficient? – does work well under high load, does it care about algorithmic complexity (without being prematurely optimized), does it use batch processing, does it read avoid loading big chunks of data in memory at once, does it make proper use of asynchronous processing.
  7. Is it something to be proud of? – does it represent every good practice that your experience has taught you? Not every piece of code is glorious, as most perform mundane tasks, but is the code something to be proud of or something you’d hope nobody sees? Would you be okay to put it on GitHub?

I think we can internalize those questions. Will asking them constantly make a difference? I think so. Would we magically get quality software If every developer asked themselves these questions about their code? Certainly not. But we’d have better code, when combined with existing tools, processes and practices.

Quality software depends on many factors, but developers are one of the most important ones. Bad software is too often our fault, and by asking ourselves the right questions, we can contribute to good software as well.

The post 7 Questions To Ask Yourself About Your Code appeared first on Bozho's tech blog.

Implicit _target=”blank”

Post Syndicated from Bozho original https://techblog.bozho.net/implicit-_targetblank/

The target="_blank" href attributes has been been the subject of many discussions. When is it right to use it, should we use it at all, is it actually deprecated, is it good user experience, does it break user expectations, etc.

And I have a strange proposal for improving the standard behaviour in browsers – implicit target=_blank" in certain contexts. But let’s try to list when target="_blank" is a good idea:

  • On pages with forms when the user may need additional information in order to fill the form but you don’t want them to leave the form and lose their input
  • On homepage-like websites – e.g. twitter and facebook, where your behaviour is “browsing” and opening a link here and there. It may be applied to things like reddit or hacker news, though it’s currently not implemented that way there
  • In comment/review sections where links are user-provided – this is similar to the previous one, as the default behaviour is browsing through multiple comments and possibly following some of them

The typical argument here is that if a user wants to open a new page, they can do that with either the context manu or ctrl+click. Not many users know that feature, and even fewer are using it. And so many of these pages are confusing, and combined with a sometimes broken back-button it becomes a nightmare.

In some of these cases javascript is used to make things better (and more complicated). In the case of forms, javascript is added to warn people against leaving the page with an unfinished form. Javascript is used to turn certain links to target=”_blank” ones. Some people try to open new tabs with javascript.

So my proposal is to introduce a with the following values for open-links and on-form:

  • open-links="new-tab" – open a link tab for each link on the page or in the current div/section/…
  • open-links="new-window" – same as above, but open a new window (almost never a good idea)
  • open-links="new-tab-on-form" – only open a new tab if there a form on the page (possibly another requirement can be that the form is being partially filled)
  • open-links="new-window-on-form" – same as above, but with a new window
  • open-links="warn-on-form" – open the link in the same tab, but if there’s a partially filled form, warn the user they will lose their input

The default value, I think, should be new-tab-on-form.

It might introduce new complexities and may confuse users further. But I think it’s worth trying to fix this important part of the web rather than leaving each website handle it on their own (or forgetting to handle it).

The post Implicit _target=”blank” appeared first on Bozho's tech blog.

Мантрата „ЕНП“

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

Мантрата „ЕНП“ се появи във Фейсбук, съвсем очаквано, преди европейските избори, и отчасти с цел да създаде шум в Демократична България.

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

Но искам да дам друг поглед върху ЕНП – дългосрочният им тренд. От 1999-та досега ЕНП губи подкрепа. По половин процент от 99-та до 2009-та, и 6.5% през 2014. По-интересното е каква е структурата на тази подкрепа. Разбих евродепутатите от последните два избора – 2009 и 2014 на „Източен блок“ и „Западна Европа“ (като Гърция и Кипър са част от „западна Европа“), за да видя как се движи ЕНП в тези два сегмента.

Източният блок има близо 27% от местата в Европейския парламент. Останалите 73% са за западна Европа.

През 2009-та ЕНП има 32.5% от депутатите си от източния блок. През 2014-та този процент расте до 39. ЕНП се превръща в ХДС+източноевропейски Борисовци. (ХДС – немският християндемократически съюз). Германия+Източна Европа правят 65% от депутатите на ЕНП.

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

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

Моят личен избор на европейско политическо семейство е Европейската демократическа партия (която е част от групата на АЛДЕ в парламента в момента, но няма на сметката си греха от приемането на ДПС).

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

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

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

Съмнителни новини

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

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

Забележете, че това не са „фалшиви новини“ – фактологията в тях не е грешна. Непълна е, но не е грешна. Коледният базар в Брюж наистина вече се казва „зимен базар“, а във френския парламент наистина е имало предложение в училищни формуляри да се използва „родител 1“ и „родител 2“.

Но въпреки негрешната фактология, има нещо съмнително в тези новини. Съмнителните неща са три:

  • Защо това е новина? – защо наименованието на коледен базар в Белгия или административни бланки във Франция заслужават място в българските новини? Не е от липса на какво да се каже, тъй като има доста по-значими неща, които се пропускат. Иначе имам и други предложения за новини – това, че лидерът на шотландската партия нарече Тереза Мей лъжкиня в парламента; мерките на немската власт срещу епидемията от морбили; сезирането на конституционния съд на Ямайка дали електронната идентичност е конституционна; изборите в Антигуа и Барбуда през 2018. Да, и тези новини имат малко до никакво значение за България, точно както белгийския коледен базар и френските бланки. Отговорът „защо това е новина“ е именно реакцията, която се очаква да предизвика – реакция, на възмущение. И затвърждаване на тезата за „прогниващия западен свят“. Теза, която се поддържа от пропагандата на Съветския съюз много отдавна и никога не е спирала да се лее от руски сайтове за фалшиви новини. Но вече „цаката“ е намерена и тези новини не са само в конспиративни групи във Фейсбук, в които се споделя как „Швеция легализира кръвосмешението“.
  • Пропуснатите нюанси. Това не е характерно само за този вид новини, но тук е доста ключово. Коледните базари в Брюж, например, се казват „зимни“ от няколко години. И това било така, защото продължават цяла зима. Нещо, което започва от ноември, не върви да е „коледно“. Но новината е представена все едно току-що някой е решил да „клекне“ на мюсюлманите и да се откаже от Християнските традиции (което не е вярно, тъй всички коледни реквизити на един такъв базар са налице). Относно „родител 1“ и „родител 2“ също са пропуснати важни моменти – правителството е внесло друго предложение за маркиране на различните случаи на родители и настойници (в т.ч. от един пол), а депутат е внесла изменение. Правителството дава негативно становище за предложението, а то все още не е окончателно прието, тъй като не е минало през сената. Също така, около година по-рано общината в Париж прави същата промяна в други бланки, или че в Германия бланките са такива отдавна и нищо кой знае какво не е станало, т.е. и това не е новост.
  • Източниците. Такъв тип новини се появяват в местната преса и най-често си остават там, докато някое международно издание (или сайт) не ги подхване и популяризира. В горните два случая това са Breitbart и Russia Today. Russia Today е директно финансирана от Кремъл и редакционната ѝ политика се определя от там. Както отбелязах по-горе, тезата за декадентния запад, който се превръща в Содом и Гомор, не е нова, а консистентно налагана поне откакто аз ползвам съзнателно интернет.

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

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

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