All posts by Bozho

Няколко думи за електронното гласуване на Да, България!

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

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

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

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

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

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

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

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

Друг често задаван въпрос беше как гарантираме, че не са били регистрирани фалшиви профили за гласуване. За съжаление правителството за втора година отлага въвеждането на национална схема за електронна идентификация, в т.ч. с чип в личните карти. Т.е. нямаме правнозначимо средство за електронна идентификация на физически лица, на което да стъпим (ако имаше, то щеше да е базирано на PKI и смарткарти и/или HSM и/или secure storage на по-нови смартфони). Тръгвайки от тази изходна точка, разгледахме четири варианта:

  • използване на КЕП за гласуване. За съжаление твърде малко хора имат квалифициран електронен подпис, а и той не работи с мобилни приложения (в общия случай). Като цяло използването му е доста неудобно и това би било пречка.
  • прикачане на снимка на машинночетимата зона (MRZ) на личната карта – това би работело, но предположихме правилно, че хората са много резервирани към даването на каквито и да било лични данни, без значение колко GDPR-compliant сме. Имахме редица оплаквания и откази за регистрация дори само като искаме последни четири цифри на ЕГН
  • използване на облачен доставчик на eID и/или online enrollment (напр. EvroTrust). Сигурността щеше да е по-висока от тази на сканиране на лична карта, но тъй като всички системи за online enrollment изискват снимка на документ за самоличност (а някои и лицево разпознаване), отказът от регистрация заради ‘твърде много лични данни’ щеше да е масов.
  • настоящият подход с представяне на минимално количество данни и подбиране на случаен принцип и прозвъняване на някои регистрирани с цел проверка за измами.

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

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

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

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

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

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

How to create secure software? Don’t blink! [talk]

Post Syndicated from Bozho original https://techblog.bozho.net/how-to-create-secure-software-dont-blink-talk/

Last week Acronis (famous for their TrueImage) organized a conference in Sofia about cybersecurity for developers and I was invited to give a talk.

It’s always hard to pick a topic for a talk on a developer conference that is not too narrowly focused – if you choose something too high level, you can be uesless to the audience and seen as a “bullshitter”; if you pick something too specific, half of the audience may be bored because it is not their area of work.

So I chose the middle ground – an overview talk with as much specifics as possible in it. I tried to tell interesting stories of security vulnerabilities to illustrate my points. The talk is split in several parts:

  • Purpose of attacks
  • Front-end vulnerabilities (examples and best practices)
  • Back-end vulnerabilities (examples and best practices)
  • Infrastructure vulnerabilities (examples and best practices)
  • Human factor vulnerabilities (examples and best practices)
  • Thoughts on how this fits into the bigger picture of software security

You can watch the 30 minutes video here:

If you would like to download my slides, click here. or view them at SlideShare:

The point is – security is hard and there are a million things to watch for and a million things that can go wrong. You should minimize risk by knowing and following as much best practices as possible. And you should not assume you are secure, as even the best companies make rookie mistakes.

The security mindset, which is partly formalized by secure coding practices, is at the core of having a secure software. Asking yourself constantly “what could go wrong” will make software more secure. It is a whole other topic of how to make all software more secure, not just the ones we are creating, but it is less technical and goes through the topics public policies, financial incentives to invest in security and so on.

For technical people it’s important to know how to make a focused effort to make a system more secure. And to apply what we know, because we may know a lot and postpone it for “some other sprint”.

And as a person from the audience asked me – is not blinking really the way? Of course not, that effort won’t be justified. But if we cover as much of the risks as possible, that will give us some time to blink.

The post How to create secure software? Don’t blink! [talk] appeared first on Bozho's tech blog.

Avoid Lists in Cassandra

Post Syndicated from Bozho original https://techblog.bozho.net/avoid-lists-in-cassandra/

Apache Cassandra is fast and scalable database which over the years became almost as easy to use as a traditional SQL database. At least on the surface.

You an use SQL-like queries, but they have a lot of limitations; you have a schema, but it’s not as flexible to modify it as in a SQL database; you have the same tabular structure with a primary key, but it’s more complicated due to the differentiation between partition key and sorting key. And there are a lot of underlying details that seem irrelevant at first, but are crucial for performance and data consistency, like tombstones, SSTable compaction and so on.

But I want to discuss the “list” column type, as recently we’ve had a very elusive issue with it. We are in the business of guaranteeing data integrity, and that’s why our records are not updated, ever. This is a good fit for Cassandra, as updates are tricky to get right. But on one of our deployments we noticed something strange – very rarely, the hash of the data in a particular entry out of millions would not match upon comparison with the indexed data. Upon investigation, we noticed that a column of type “list” got duplicate values. It was not an issue with the code, because in this particular case the code was always using Collections.singletonList(..)

It appears that Cassandra is trying to be clever and when it sees identical entries in a batch insert, instead of overriding one with the other, it tries to merge them, resulting in a list with duplicate entries. Accounts of the issue are reported here and here.

Now, batches are a difficult topic and one of those things that look straight-forward but aren’t. In most cases, batches are an anti-pattern. There are cases where batches are useful, but it’s more rare than expected. That’s because of the distributed nature of Cassandra. Another complication comes from whether you are using token-aware or toke-unaware client policy, i.e. whether your client knows where each record belongs in order to send the request to it. I won’t go into details about batches, as they are well explained in the two linked articles.

Back to lists – since in our case we don’t have identical records in a batch, the issue was probably manifested because of a network timeout where the client didn’t receive confirmation of the write and re-attempted sending the same statement again. Whether being in a batch or not affects it, I can’t be sure. But it’s probably safer to assume that it might happen with or without a batch. I.e. lists can be merged in unexpected situations.

This is a serious reason for not using lists at all. Additional arguments are given by Walmart

Sets should be preferred to Lists as Sets (and Maps) avoid read-before-write pattern for updates and deletes

And this is just for a small number of items. Using collections for a large number of items (e.g. thousands) is another issue, as you can’t load the items in portions – they are all read at once.

In a Java application, for example, you can easily substitution the List with a Set even if the underlying column is of type List and that would help temporarily avoid the issues – data may still be duplicated in the database, but at least the application will work with unique values. Have in mind though, that ordering is not guaranteed by the Java Set, so if it matters for your logic, make sure you order by some well-defined comparison criteria.

The general advice of “avoid lists” (and “avoid batches”) paints an accurate picture of Cassandra. It looks straightforward to use, but once you get to production, you may realize there were some suboptimal design decisions.

The post Avoid Lists in Cassandra appeared first on Bozho's tech blog.

Борба с фалшиви лекарства по грешния начин

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

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

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

Първото двуминутно проучване показа, че директивата е от 2011-та и какво по дяволите са правили всички 8 години, не им е виновен ЕС за това.

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

Та, това на пръв поглед просто за техническа реализация решение, е толкова усложнено, че според мен едвам е заработило и поддръжката му ще бъде ужас. Направили са централен EU Hub, и 28 национални системи, които да се синхронизирт с този hub. Защо това е нужно и защо е задължително? На теория, защото държавите-членки са суверенни и трябва да имат базата си данни. На практика няма нужда. Която държава желае, може да има копие „за четене“ на данните. Така или иначе производителите ги публикуват в централната система. Ако пък идеята е била да се разтовари централната система от заявки за проверка – не звучи като добра идея да създадеш организационно усложнение, за да си спестиш централизираното управление на няколко десетки сървъра.

Българската организация, която въвежда системата си е свършила прилично работата – една от първите държави сме, която въвежда националната система, използвали са одобрен доставчик, провели са кампании, изпращали са писма, отчели са колко са получени и по какви причини. С URL-а не са се справили, де.. nbsbgiqe1.emvs-nbs.eu:8637 не е точно удобен за въвеждане.

Но тук идва фундаменталният проблем – би трябвало една такава система да има интерфейси, базирани на отворени стандарти (или дори да не са стандарти, да са публично-достъпни и утвърдени от ЕК).

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

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

Само че такова няма. Пардон, има едно, но то е от доставчик, който се връзва не към националната система директно, а към своя, от която пък изпраща данните на националните. И иска пари за това, разбира се. 220 лв годишно (за до 1000 лекарства на месец) и 660 лв годишно без ограничения може и да е добра оферта. (Но не съм сигурен има ли български превод). Приложението го няма в play store-a. А, има и един сайт на фирмата-доставчик на националната система, откъдето можели да се правят проверки. verilite.eu .. ако намерите бутон за регистрация, кажете.

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

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

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

Certificate Transparency Verification in Java

Post Syndicated from Bozho original https://techblog.bozho.net/certificate-transparency-verification-in-java/

So I had this naive idea that it would be easy to do certificate transparency verification as part of each request in addition to certificate validity checks (in Java).

With half of the weekend sacrificed, I can attest it’s not that trivial. But what is certificate transparency? In short – it’s a publicly available log of all TLS certificates in the world (which are still called SSL certificates even though SSL is obsolete). You can check if a log is published in that log and if it’s not, then something is suspicious, as CAs have to push all of their issued certificates to the log. There are other use-cases, for example registering for notifications for new certificates for your domains to detect potentially hijacked DNS admin panels or CAs (Facebook offers such a tool for free).

What I wanted to do is the former – make each request from a Java application verify the other side’s certificate in the certificate transparency log. It seems that this is not available out of the box (if it is, I couldn’t find it. In one discussion about JEP 244 it seems that the TLS extension related to certificate transparency was discussed, but I couldn’t find whether it’s supported in the end).

I started by thinking you could simply get the certificate, and check its inclusion in the log by the fingerprint of the certificate. That would’ve been too easy – the logs to allow for checking by hash, however it’s not the fingerprint of a certificate, but instead a signed certificate timestamp – a signature issued by the log prior to inclusion. To quote the CT RFC:

The SCT (signed certificate timestamp) is the log’s promise to incorporate the certificate in the Merkle Tree

A merkle tree is a very cool data structure that allows external actors to be convinced that something is within the log by providing an “inclusion proof” which is much shorter than the whole log (thus saving a lot of bandwidth). In fact the coolness of merkle trees is why I was interested in certificate transparency in the first place (as we use merkle trees in my current log-oriented company)

So, in order to check for inclusion, you have to somehow obtain the SCT. I initially thought it would be possible with the Certificate Transparency Java library, but you can’t. Once you have it, you can use the client to check it in the log, but obtaining it is harder. (Note: for server-side verification it’s fine to query the log via HTTP; browsers, however, use DNS queries in order to preserve the anonymity of users).

Obtaining the SCT can be done in three ways, depending on what the server and/or log and/or CA have chosen to support: the SCT can be included in the certificate, or it can be provided as a TLS extension during the TLS handshake, or can be included in the TLS stapling response, again during the handshake. Unfortunately, the few certificates that I checked didn’t have the SCT stored within them, so I had to go to a lower level and debug the TLS handshake.

I enabled TLS hadnshake verbose output, and lo and behold – there was nothing there. Google does include SCTs as a TLS extension (according to Qualys), but the Java output didn’t say anything about it.

Fortunately (?) Google has released Conscrypt – a Java security provider based Google’s fork of OpenSSL. Things started to get messy…but I went for it, included Conscrypt and registered it as a security provider. I had to make a connection using the Conscrypt TrustManager (initialized with all the trusted certs in the JDK):

KeyStore trustStore = KeyStore.getInstance("JKS");
trustStore.load(new FileInputStream(System.getenv("JAVA_HOME") + "/lib/security/cacerts"), "changeit".toCharArray());
ctx.init(null,new TrustManager[] {new TrustManagerImpl(trustStore, 
    null, null, null, logStore, null, 
    new StrictCTPolicy())}, new SecureRandom());
        

URL url = new URL("https://google.com");
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
conn.setSSLSocketFactory(ctx.getSocketFactory());
conn.connect();
conn.getInputStream();
conn.disconnect();

And of course it didn’t work initially, because Conscrypt doesn’t provide implementations of some core interfaces needed – the CTLogStore and CTPolicy classes. The CTLogStore actually is the important bit that holds information about all the known logs (I still find it odd to call a “log provider” simply “log”, but that’s the accepted terminology). There is a list of known logs, in JSON form, which is cool, except it took me a while to figure (with external help) what are exactly those public keys. What are they – RSA, ECC? How are they encoded? You can’t find that in the RFC, nor in the documentation. It can be seen here that it’s ” DER encoding of the SubjectPublicKeyInfo ASN.1 structure “. Ugh.

BouncyCastle to the rescue. My relationship with BouncyCastle is a love-hate one. I hate how unintuitive it is and how convoluted its APIs are, but I love that it has (almost) everything cryptography-related that you may ever need. After some time wasted with trying to figure how exactly to get that public key converted to a PublicKey object, I found that using PublicKeyFactory.createKey(Base64.getDecoder().decode(base64Key)); gives you the parameters of whatever algorithm is used – it can return Elliptic curve key parameters or RSA key parameters. You just have to then wrap them in another class and pass them to another factory (typical BouncyCastle), and hurray, you have the public key.

Of course now Google’s Conscrypt didn’t work again, because after the transformations the publicKey’s encoded version was not identical to the original bytes, and so the log ID calculation was wrong. But I fixed that by some reflection, and finally, it worked – the certificate transparency log was queried and the certificate was shown to be valid and properly included in the log.

The whole code can be found here. And yes, it uses several security providers, some odd BouncyCastle APIs and some simple implementations that are missing in Google’s provider. Known certificates may be cached so that repeated calls to the log are not performed, but that’s beyond the scope of my experiment.

Certificate transparency seems like a thing that’s core to the internet nowadays. And yet, it’s so obscure and hard to work with.

Why the type of public key in the list is not documented (they should at least put an OID next to the public key, because as it turns out, not all logs use elliptic curves – two of them use RSA). Probably there’s a good explanation, but why include the SCT in the log rather than the fingerprint of the certificate? Why not then mandate inclusion of the SCT in the certificate, which would require no additional configuration of the servers and clients, as opposed to including it in the TLS handshake, which does require upgrades?

As far as I know, the certificate transparency initiative is now facing scalability issues because of the millions of Let’s encrypt certificates out there. Every log (provider) should serve the whole log to everyone that requests it. It is not a trivial thing to solve, and efforts are being put in that direction, but no obvious solution is available at the moment.

And finally, if Java doesn’t have an easy way to do that, with all the crypto libraries available, I wonder what’ the case for other languages. Do they support certificate transparency or they need upgrades?

And maybe we’re all good because browsers supports it, but browsers are not the only thing that makes HTTP requests. API calls are a massive use-case and if they can be hijacked, the damage can be even bigger than individual users being phished. So I think more effort should be put in two things:
1. improving the RFC and 2. improving the programming ecosystem. I hope this post contributes at least a little bit.

The post Certificate Transparency Verification in Java appeared first on Bozho's tech blog.

Да поговорим за ИТ фирмите и обществените поръчки

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

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

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

А този въпрос е важен, защото в крайна сметка реализацията

  • Некадърни фирми – да, ясно е, че има такива и то немалко – фирма с 1 старши разработчик и 7-8 младши за колкото може по-малки заплати, да наливат код, и все нещо ще излезе. Старшият разработчик ще следи процеса, и готово. Той самият може да не е достатъчно добър, но поне има опит. След това тези младши разработчици се изстрелват при първа по-адекватна възможност, защото виждат какъв ужас е. Има и други фирми – които си имат разработчици и мениджъри с опит, но просто никога не са правили софтуер както трябва. Винаги е било с процес „каубойско писане на код“, и „мазане“ – без оглед за производителност, информационна сигурност, удобство… и все някой друг е виновен. Някои не ползват контрол на версиите, не знаят какво е уеб-услуга и като цяло – останали са в 90-те. Виждал съм такива неща, че и за курсов проект не стават.
  • „Окопани“ фирми – когато „гаражна“ фирма е направила някакъв софтуер преди 20 години, който е успяла с някакви връзки да пробута я на някоя община, я на някоя областна или централна администрация, и после само тя може да го надгражда или поддържа. Промяната така или иначе е трудна, но дори при опит от страна на администрацията да се смени софтуера, има тежък отпор, който понякога стига до това да не се дава базата данни за миграция към евентуална нова система или пък до абсурдни твърдения, че фирмата има авторско право върху информацията в базата данни. Такива примери има твърде много и те са сериозен фактор.
  • Корупция – да, ясно е, че корупция има. И то доста. Някои фирми са „установени“ в някои администрации не просто заради предишен опит, ами и по линия на някакви политически връзки. Това го разбрах с почти челен сблъсък със системата на корупция – в една фирма, в която работех за кратко, едни шеф ме помоли да отида в едно министерство и да участвам в работна група по писане на задание. За поръчка, която явно е трябвало да спечелим. Трябваше ми около половин ден да загрея за какво точно става дума, но на въпроса „значи аз трябва да се правя на независим експерт и да напиша задание, по което после ние да кандидатстваме и да спечелим“ отговорът беше „Ами да. Те всички така правят“. Отказах да го направя (имайки лукса на гъвкавия и гладен софтуерен пазар), и в крайна сметка поръчката така и не се случи, но важното беше, че „всички така правят“. В случаите, когато фирмите не си пишат сами заданията, им ги пишат приятелски фирми, а след това се редуват. И после като резултатът е зле – „ами то така пишеше в заданието“. (Периодично има по някой скандал с това, че в метаданните на документите за някоя поръчка пише като автор – служител на някой от кандидатите). Противно на очакванията, обаче, не мисля, че ако махнем корупцията, всичко ще цъфне и върже. Останалите проблеми ще са налице и няма да позволят магическия прогрес (това не значи, че не трябва да се борим против нея, естествено). Корупцията има и друг аспект – фирми, които не са „в играта“ не кандидатстват, защото не знаят дали поръчката не е нагласена за някого. Нерядко стои въпросът „абе тая поръчка гласена ли е за някого или да участвам?“.
  • Недостатъчен капацитет – някоя фирма може да е добра, но да се е надценила и е кандидатствала по повече поръчки, отколкото може да поеме, но пък е взела, че ги е спечелила, и сега се чуди как да ги изпълни. Приоритизира един, забавя друг, наема хора „от кол и въже“, колкото да спази сроковете.
  • Остарели основни системи – когато основните ти системи са остарели и нямам как да направиш адекватна интеграция с тях, задачи, които са изглеждали лесни, стават доста трудни. Примери много, но да вземем МВР, където доскоро имаше стара система за регистрация в КАТ. На база на тази система нови функционалности, оптимизиране на процеси и други неща нямаше как да станат, или поне не лесно. Имаше един регистър, който е правен през 90-те. Доста неща зависеха от него, но просто нямаше как да се интегрират. И съответно интеграцията с него става „ръчно“. Примерите с носене на флашки рядко са заради липса на мрежда – по-често са заради стари системи без никакви точки за интеграция
  • Лоши задания – дори когато сме извън сценария „изпълнителят сам си пише заданието“, заданията са лоши. Администрацията рядко има капацитет да напише адекватно задание. Или копира от стари задания, или възлага на някой консултант да го напише (който я разбере за какво е поръчката, я не…а и да разбере, предава нещо полу-грамотно, което после трябва да се пише от нулата). А резултатът зависи в немалка степен от заданието – фирмите, разбираемо, често си дават зор повече от това, което се изисква от тях (има и похвални изключения). И съответно могат да свършат и чудесна работа, и никаква работа – зависи какво им се търси. Именно заради проблема със заданията въведохме две мерки. Едната е шаблонно задание с всички настъпвани през годините „мотики“, така че да не се правят нещата грешно. Разбира се, шаблонът допуска редакции за конкретния случаи (напр. ако системата не предполага пълнотекстово търсене, такова няма нужда да се изисква), но като цяло ограничава полето за ТНТМ-та. Другата мярка беше Държавно предприятие „Единен системен оператор“, което да поеме писането на задания (както и други дейности по проектите). Второто така и не се е случило все още.
  • Лошо управление на проектите от възложителя – това често е голям проблем. Може фирмата да има доброто желание и капацитета да направи проекта както трябва, но в администрацията просто няма никой, който да знае как се движи проект. Това беше още една причина, поради която въведохме Държавно предприятие, а също така и кратко преживял Project management office в Администрацията на Министерския сътвет. И двете в момента отсъстват и затова нещата се движат от редови служители в администрацията, които в добрия случаи са викали неволята достатъчно много пъти и горе-долу знаят как се управлява проект. В лошия (и вероятно по-масов) случай просто разписват протоколи и приемат проекта. Има десетки неща, за които възложителят има задължения – да осигури права за интеграция с други системи, да осигури хардуер (ако такъв не е заложен), да осигури помещения за хардуера (ако такъв е заложен), да осигури уточнения по изискванията на нормативната уредба в частта с бизнес анализа, и т.н. Има и друг тип проблеми – възложителят да има необмислени изисквания и да държи на тях, въпреки съветите на изпълнителя – напр. „това на уебсайта трябва да е точно както е на хартия“.
  • Независещи от никого обстоятелства – често срещан пример е срокове по някой закон (или Регламент на ЕС), които администрацията е опитала да спази в срок, ама заради тромави процедури, обжалвания, събаряне на търгове, КЗК, ВАС (малко корупцийка, съответно), нещата не са се получили. И когато все пак се стигне до изпълнение на проект, сроковете вече са „за вчера“, обаче политическият натиск расте, и съответно резултатът се приема с едно затворено око и едно гледащо в другата посока.
  • Липса на политическа подкрепа – един проект може да бъде неглижиран от политическото ръководство и това да го направи невъзможен за изпълнение. Например често се налага изменение на някоя наредба или заповед, за да може да се използват всички възможности на софтуера. Обаче ако никой от политическият кабинет „не даде едно рамо“, наредбата си остава от 94-та и програмистите псуват какви глупости ги карат да правят
  • ЗОП – на последно място, но изобщо не по важност, Законът за обществените поръчки е неподходящ за софтуерни проекти. Прекалено е бюрократичен и предполага до голяма степен т.нар. waterfall модел, което предполага много ниска гъвкавост. Освен всичко друго, за кандидатстване по процедура по ЗОП, фирмата трябва да има хора, които могат да се оправят с бюрократичния процес (който с новата директива е малко по-добър, но все пак изисква познаване на процедурите и опит с писане на документи). Как да напишеш офертата и техническото предложение, така че да покрият критериите за оценка, как да се вместиш в сроковете за кандидатстване. Ако нямаш опит със ЗОП, т.е. ако предимно работиш за частни клиенти, например извън България, то едва ли имаш голям шанс в една процедура по ЗОП. Съответно пък по ЗОП не можеш да оцениш реално кандидатите – всичките имат сертификати, всичките имат годишен оборот и всички ще напишат в техническото си предложение, че ще изпълнят всичко. И особено ако администрацията не е достатъчно технически грамотна, няма да може да оцени кой е вникнал повече в заданието и е разписал по-адекватно предложение. Бях предложил преди време като част от документацията по кандидатстване, да се представя код от предходни проекти, на база на който да се извличат някакви метрики – качество на кода, покритие с тестове и др. Само че „по ЗОП не може“.

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

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

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

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

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

Integrating Applications As Heroku Add-Ons

Post Syndicated from Bozho original https://techblog.bozho.net/integrating-applications-as-heroku-add-ons/

Heroku is a popular Platform-as-a-Service provider and it offers vendors the option to be provided as add-ons. Add-ons can be used by Heroku customers in different ways, but a typical scenario would be “Start a database”, “Start an MQ”, or “Start a logging solution”. After you add the add-on to your account, you can connect to the chosen database, MQ, logging solution or whatever.

Integrating as Heroku add-on is allegedly simple, and Heroku provides good documentation on how to do it. However, there are some pitfalls and so I’d like to share my experience in providing our services (Sentinel Trails and SentinelDB) as Heroku add-ons.

Both are SaaS (one is a logging solution, the other one – a cloud datastore), and so when a Heroku customer wants to add it to their account, we have to just create an account for them on our end.

In order to integrate with Heroku, you need to implement several endpoints:

  • provisioning – the initial creation of the resources (= account)
  • plan change – since Heroku supports multiple subscription plans, this should also be reflected on your end
  • deprovisioning – if a user stops using your service, you may want to free some resources
  • SSO – allows users to log in your service by clicking an icon in the Heroku console.

Implementing these endpoints following the tutorial should be straightforward, but it isn’t exactly. Hence I’m sharing our Spring MVC controller that handles it – you can check it here.

A few important bits:

  • You may choose not to obtain a token if you don’t plan to interact with the Heroku API further.
  • We are registering the user with a fake email in the form of <resourceId>@heroku.com. However, you may choose to use the token to fetch the emails of team members and collaborators, as described here.
  • The most important piece of data is the resource_id – store it in your users (or organizations) table and consider adding an index to be able to retrieve records by it quickly.
  • Return your keys and secrets as part of the provisioning request. They will be set as environment variables in Heroku
  • All of the requests are made from the Heroku servers to your server directly, except the SSO call. It is invoked in the browsers and so you should set the session cookie/token in the response. That way the user will be logged in your service.
  • When you generate your addon manifest, make sure you update the endpoint URLs

After you’re done, the alpha version appears in the marketplace (e.g. here and here). You should then have some alpha users to test the add-ons before it can be visible in the marketplace.

Integrating SaaS solutions with existing cloud providers is a good thing, and I’m happy that Heroku provides an automated way to do that. (AWS, for example, also has a marketplace, but integration there feels a bit strange and unpolished (I’ve hit some issues that were manually resolved by the AWS team).

Since many companies are choosing IaaS or PaaS for their services, having the ability to easily integrate an add-on service is very useful. I’d even go further and propose some level standardization for cloud add-ons, but I guess time will tell if we really need it, or we can spare a few days per provider.

The post Integrating Applications As Heroku Add-Ons appeared first on Bozho's tech blog.

Електронна държава [презентация]

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

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

Слайдовете можете да разгледате тук:

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

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

Types of Data Breaches and How To Prevent Them

Post Syndicated from Bozho original https://techblog.bozho.net/types-of-data-breaches-and-how-to-prevent-them/

Data breaches happen practically every day. Personal, including financial and medical data leak to cyber criminals as well as intelligence agencies. Some notable breaches include the Equifax breach, where dozens of personal data fields were leaked, and the recent Marriott breach, where passports, credit cards and locations of people at a given time were breached.

I’ve been doing some data protection consultancy as well as working on a data protection product and decided to classify the types of data breaches and give recommendations on how they can be addressed. We don’t always get to know how exactly the breaches happen, but from what is published in news articles and post-mortems, we can have a good overview on the breach landscape.

Control over target server – if an attacker is able to connect to a target server and gains full or partial control on it, they can do anything, including running SELECT * FROM ... , copying files, etc. How do attackers gain such control? In many ways, most notably RCE (remote code execution) vulnerabilities and weak admin authentication.

How to prevent it? Follow best security practices – regularly update libraries and software to get security patches, do not run native commands from within the application layer, open only necessary ports (80 and 443) to the outside world, configure 2-factor authentication for administrator login. Aim at having an intrusion detection / prevention system. Encrypt your data, and make the encryption as granular as possible for the most sensitive data (e.g. for SentinelDB we utilize per-record encryption) to avoid SELECT * breaches.

SQL injections – this is a rookie mistake that unfortunately still happens. It allows attackers to manipulate your SQL queries and inject custom bits in them that allows them to extract more data than they are supposed to.

How to prevent it? Use prepared statements for your queries. Never ever concatenate user input in order to construct queries. Run regular code reviews and use code inspection tools to catch such instances.

Unencrypted backups – the main system may be well protected, but attackers are usually after the weak spots. Storing backups might be such – if you store unencrypted backups that are accessible via weak authentication (e.g. over FTP via username/password), then someone may try to attack this weaker spot. Even if the backup is encrypted, the key can be placed alongside it, which makes the encryption practically useless.

How to prevent it? Encrypt you backups, store them in a way that’s as strongly protected as your servers (e.g. 2FA, internal-network/VPN only), and have your decryption key in a hardware security module (or equivalent, e.g. AWS KMS).

Personal data in logs – another weak spot other than the backups may be your logs. They usually lie on separate servers, and are not as well guarded. That’s usually okay, since logs don’t contain personal information, but sometimes they do. I recently stumbled upon a large company’s website that had their directory structure unprotected and they kept their access logs files alongside their static resources. In addition to that, they passed personal information as GET parameters, so you could get a lot of information by just getting the access logs. Needless to say, I did a responsible disclosure and the issue was fixed, but it was a potential breach.

How to prevent it? Don’t store personal information in logs. Avoid submitting forms with a GET method. Regularly review the code to check whether personal data is not logged. Make sure your logs are stored in a way as protected as your production servers and your backups. It could be a cloud service, it could be a local installation of an open source package, but don’t overlook the security of the log collection system.

Data pushed to unprotected storage – a recent Alteryx/Experian leak was just that – data placed on a (somewhat) public S3 bucket was breached. If you place personal data in weakly protected public stores (AWS S3, file sharing services, FTPs), then you are waiting for trouble to happen.

How to prevent it? Don’t put personal data publicly. How to prevent that from happening – always review your S3 buckets and FTP servers policies. Have internal procedures that disallow sharing personal data without protecting it with at least a password shared by a side-channel (messenger/sms).

Unrestricted API calls – that’s what caused the Facebook-Cambridge Analytics issue. No matter how secure your servers are, if you expose the data through your API without access restriction, rate-limiting, fraud-detection, audit trail, then your security is no use – someone will “scrape” your data through the API.

How to prevent it? Do not expose too much personal data over public or easily accessible APIs. Vet API users and inform your users whenever their data is being shared with third parties, via API or otherwise.

Internal actor – all of the woes above can happen due to poor security or due to internal actors. Even if your network is well guarded, an admin can go rogue and leak the data. For many reasons, nonincluding financial. An privileged internal actor has access to perform SELECT *, can decrypt the backups, can pretend to be a trusted API partner.

How to prevent it? Good operational security. A single sentence like that may sound easy, but it’s not. I don’t have a full list of things that have to be in place to guard against internal breaches – there are technical, organizational and legal measures to be taken. Have unmodifiable audit trail. Have your Intrusion prevention system (or logging solution) also detect anomalous internal behaviour. Have procedures that require two admins to work together in order to log in (e.g. split key) to the most. If the data is sensitive, do background checks on the privileged admins. And many more things that fall into the “operational security” umbrella.

Man-in-the-middle attacks – MITM can be used to extract data from active users only. It works on website without HTTPS, or in case the attacker has somehow installed a wildcard certificate on the target machine (and before you say that’s too unlikely – it happens way too often to be ignored). In case of a successful MITM attack, the attacker can extract all data that’s being transferred.

How to prevent it? First – use HTTPS. Always. Redirect HTTP to HTTPS. Use HSTS. Use certificate pinning if you control the updates of the application (e.g. through an app store). The root certificate attack unfortunately cannot be circumvented. Sorry, just hope that your users haven’t installed such shitty software. Fortunately, this won’t lead to massive breaches, only data of active users that are being targeted may leak.

JavaScript injection / XSS – if somehow an attacker can inject javascript into your website, they can collect data being entered. This is what happened in the recent British Airways breach. A remember a potential attack on NSW (Australia) elections, where the piwick analytics script was loaded from an external server that was vulnerable to a TLS downgrade attack which allowed an attacker to replace the script and thus interfere with the election registration website.

How to prevent it? Follow the XSS protection cheat sheet by OWASP. Don’t include scripts from dodgy third party domains. Make sure third party domains, including CDNs, have a good security level (e.g. run Qualys SSL test).

Leaked passwords from other websites – one of the issues with incorrect storage of passwords is password reuse. Even if you store passwords properly, a random online store may not and if your users use the same email and password there, an attacker may try to steal their data from your site. Not all accounts will be compromised, but the more popular your service is, the more accounts will be affected.

How to avoid it? There’s not much you can do to make other websites store passwords correctly. But you can encourage the use of pass phrases , you can encourage 2-factor authentication in case of sensitive data, or you can avoid having passwords at all and use an external OAuth/OpenID provider (this has its own issues, but they may be smaller than those of password reuse). Also have some rate-limiting in place so that a single IP (or an IP range) is not able to try and access many accounts consecutively.

Employees sending emails with unprotected excel sheets – especially non-technical organizations and non-technical employees tend to just want to get their job done, so they may send large excel sheets with personal data to colleagues or partners in other companies. Then once someone’s email account or server is breached, the data gets breached as well.

How to prevent it? Have internal procedures against sending personal data in excel sheets, or at least have people zip them and send passwords through a side channel (messenger/sms). You can have an organization-wide software that scans outgoing emails for attachments with excel sheets that contain personal data and have these email blocked.


Data breaches are prevented by having good information security. And information security is hard. And it’s the right combination of security practices and security products that minimize the risk of incidents. Many organizations choose not to focus on infosec, as it’s not their core business or they estimate that the risk is worth it, viewing breaches, internal actors manipulating data and other incidents as something that can’t happen to them. Until it happens.

The post Types of Data Breaches and How To Prevent Them appeared first on Bozho's tech blog.

Без регистри идва хаос

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

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

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

Регистърът „оцеля“ и ни остави важна поука – че публичните регистри са изключително важни и тяхната липса създава хаос. Търговският регистър е един от най-важните, но далеч не е единствен. Други ключови за държавата регистри са Националната база данни „Население“, поддържана от ГД „ГРАО“, имотният регистър, кадастърът, регистърът на МПС, регистърът на особените залози, кредитният регистър, регистърът на обществените поръчки, регистърът на акционерите към Централния депозитар. И още стотици секторни регистри и регистърчета – в сектор „Здравеопазване“, в сектор „Правосъдие“, в сектор „Туризъм“ и т.н.

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

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

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

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

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

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

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

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

Фактите, Санчо – електронното гласуване според Михаил Константинов

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

Въпреки че знам, че това да оборваш нечие конкретно мнение не винаги е ефективен инструмент за убеждаване на хората, не мога да се сдържа и да не коментирам вчерашната статия на Михаил Константинов в 24 Часа. Статията е пълна с толкова много полуистини и неверни твърдения, че не мога да я оставя без отговор.

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

Ще извадя конкретни цитати и ще обясня защо са или неверни, или опростени до невярност.

И тъй като нямаше как другояче да действат външните сили, ясно е, че [в САЩ] ставаше дума за въздействие върху електронните средства за комуникация – първо, чрез влияние в социалните мрежи и второ – директно върху системите за гласуване.

Няма данни електронни системи за гласуване да са били манипулирани. Доклад на американския National Intelligence Council казва, че машини или компютри, с които е извършвано броене не са били манипулирани. Хакнати са били мейли на някои служители на избирателни комисии и съответно са изтекли данни за регистрирани за гласуване граждани, но това в никакъв случай не е „директно върху системите за гласуване“. А и както се казва в други статии по въпроса – ако можеш да насочиш общественото мнение, защо ти е да хакваш резултата? Защото ако хакнеш резултата, всички ще разберат, че нещо не е наред. Когато „хакнеш“ хората, те ще продължават имат доверие в системата, но тя ще бъде ефективно компрометирана.

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

Проблемът, който електронното гласуване трябва да решава не е, че не можеш да видиш какво става с гласа ти. Всяка електронна система ти позволява това – гласът ти е подписан електронно и съответно можеш да провериш дали е там. Някои от доставчиците на решения за гласуване отдавна имат патенти за използване на криптографски елементи от блокчейн за защита на интегритета на данните (тези елементи, като хеш вериги, ги има много преди биткойн). Проблемът е, че ако можеш да видиш какво става с гласа ти, можеш да го покажеш на друг и така да докажеш, че си гласувал както ти е било наредено/платено, а не както си искал. Затова трудната задача на проверимостта „от край до край“ (end-to-end verifiability) е да ти даде тази сигурност без да разкрива вота ти. Но блокчейн не помага значително в това. Като цяло научната общност е скептична към блокчейн – не защото не е добра технология, а защото не решава сложните проблеми в електронното гласуване. Решава по-простите, които вече имат и други решения, например т.нар. public bulletin boards (публикуване на криптираните гласове в реално време).

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

Блокчейн гласуването в Сиера Леоне беше пиар кампания на фирма, доставчик на решение за е-гласуване (Agora). Централната избирателна комисия отрече да е имало такова нещо с нейно участие. Ако Константинов беше прочел нещо повече от вестникарски заглавия по темата, щеше да разбере, че Agora е била регистриран международен наблюдател в 280 от общо 11200 секции, и след като секционните комисии са изброили бюлетините, наблюдателите също са ги изброили и са ги записали в блокчейна си. Технологията им (която проучих тогава) звучи интересно и разумно, най-вече защото е реализирала останалите компоненти на електронното гласуване съгласно добрите практики. А не просто защото ползва блокчейн.

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

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

Оказва се обаче, че има бърз алгоритъм, който чисто математически пробива този вид криптиране. Затова проблемът не е само технологичен т.е. калпаво изпълнение на картите, а принципен – става дума за фундаментален математически пробив в системата.

Убеден съм, че Константинов разбира математиката зад атаката на Копърсмит много по-добре от мен. Само че за да е успешна, атаката зависи от много фактори и пропуски в реализацията. В конкретния случай, само библиотеката в конкретните карти (RSALib) има този проблем. Други библиотеки, използващи същите алгоритми за генериране на ключове, криптиране и подписване (като OpenSSL), нямат такъв проблем. Освен RSA, за същите цели се ползват и елиптични криви. И те нямат този проблем. Така че твърдението, че има фундаментален математически пробив в системата на криптографията с публичен ключ, на която се базира гласуването (и много други неща, вкл. сигурността в интернет), е силно преувеличено, и даже направо грешно.

Този пробив не е решен, но естонците като спокойни северни хора се примириха с това и изчакват нещата да се оправят.

Това пък е съвсем грешно. Според доклада на естонското правителство историята е следната. На 30 август получават информация, че има потенциален проблем с картите. На 5-ти септември дават пресконференция и публикуват информация, че има риск за някои карти. Следват местни избори, които биват следени изключително внимателно, но проблеми не са открити (това не е 100% гаранция, че е нямало такива, но е сигурно, че не са повлияли на резултата от изборите). След това естонците спират сертификатите на засегнатите карти и дават възможност хората да си обновят ключовете, използвайки елиптични криви вместо RSA (елиптичните криви не са „пробити“), като много хора го правят (та чак системата за подновяване пада за малко от натоварването). Твърдението, че са седели и са чакали нещата да се оправят е напълно невярно.

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

(28) Когато е нарушена сигурността или отказоустойчивостта на системата или когато е налице технологична невъзможност да се гарантират основни избирателни права, Централната избирателна комисия с мотивирано решение временно спира или прекратява дистанционното електронно гласуване или не стартира системата за гласуване. Централната избирателна комисия уведомява избирателите чрез интернет страницата си и средствата за масово осведомяване за причините и публикува подробен отчет не по-късно от 24 часа ден след постановяване на решенето.

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

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

„Фактите“ не са факти, а са истории, прочетени в някой сайт, и попълнени с разбиранията и неразбиранията на автора. Можеше да проучи какво е било гласуването в Сиера Леоне. Можеше да прочете доклада на естонското правителство, можеше да прочете доклада на National Intelligence Council. Но е по-лесно просто да се публикува разхвърляна статия в 24 часа.

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

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

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

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

Blockchain – What Is It Good For? [slides]

Post Syndicated from Bozho original https://techblog.bozho.net/blockchain-what-is-it-good-for-slides/

Last week I gave a 20 minute talk on the way I see blockchain applicability. I’ve always been skeptical of the blockchain hype, having voiced my concerns, my rants and other thoughts on the matter.

I’ve followed actual blockchain projects that didn’t really need blockchain but managed to yield some very good results by digitizing processes, by eliminating human error, and occasionally, by guaranteeing the integrity of data. And recently I read an article that put these observations into perspective – that blockchain is just a tool for digital transformation (a buzzword broadly meaning “doing things on a computer and more efficiently”). That rarely the distributed consensus is needed, let alone public ledgers. But that doesn’t matter, as long as the technology has lead to some processes being digitized and transformed.

So here are the slides from my talk:

And people are usually surprised that I have a blockchain-related company and I’m so skeptical at the same time. But that’s actually logical – I know how the technology works, what problems it solves and how it can be applied in a broad set of domains. And that’s precisely why I don’t think it’s a revolution. It’s a wonderful piece of technological innovation that will no doubt solve some problems much better than they were solved before, but it won’t be the new internet and it won’t change everything.

Doesn’t that skepticism hurt my credibility as a founder of a blockchain-related startup? Not at all – I don’t want to get a project just because of a buzzword – that’s not sustainable anyway. I want to get it because it solves a real problem that the customer has. And to solve it the right way, i.e. with the best technologies available. And blockchain’s underlying mechanisms are a great tool in the toolbox. Just not a revolution.

In order to be revolutionary, something has to bring at least 10 times improvement over existing practices, or make a lot of things possible that weren’t possible before. Blockchain is neither. I got a question from the audience – “well, isn’t it a 10 times innovation in payments?”. My counter-question was: “Have you ever bought something with cryptocurrencies?”. Well, no. It also doesn’t improve 10 times cross-organization integration. Yes, it might help to establish a shared database, but you could’ve done that with existing technology if you needed to.

But if the blockchain hype helped people realize that digital events can be protected, and that stakeholders can exchange data and present proofs to each other that they haven’t modified the data, who cares if the ultimate implementation will be based on Ethereum, Hyperledger, Corda, or just a clever use of digital signatures, timestamps and web services, or perhaps simply merkle trees.

I hope that blockchain gets demystified soon and we all start speaking the same language (so that I don’t need to reassure an audience at a banking summit that – no, we are not doing cryptocurrencies in our blockchain company). Once we get there, we’ll be able to efficiently solve the problems of digital transformation. As for the digital revolution – it is already happening. We are moving everything online. And yes, with centralized services rather than distributed p2p networks, but that’s not a technical issue, it’s a socioeconomic one. And technology by itself is rarely a solution to such problems.

The post Blockchain – What Is It Good For? [slides] appeared first on Bozho's tech blog.

Technical Innovation vs. Process Innovation

Post Syndicated from Bozho original https://techblog.bozho.net/technical-innovation-vs-process-innovation/

We are often talking about “innovation” and “digital innovation” (or “technical innovation”) in particular, when it comes to tech startups. It has, unfortunately, become a cliche, and now “innovation” is devoid of meaning. I’ve been trying to put some meaningful analysis of the “innovation landscape” and to classify what is being called “innovation”.

And the broad classification I got to is “technical innovation” vs “process innovation”. In the majority of cases, tech startups are actually process innovations. They get existing technology and try to optimize some real world process with it. These processes include “communicating with friends online”, “getting in touch with business contacts online”, “getting a taxi online”, “getting a date online”, “ordering food online”, “uploading photos online”, and so on. There is no inherent technical innovation in any of these – they either introduce new (and better) processes, or they optimize existing ones.

And don’t get me wrong – these are all very useful things. In fact, this is what “digital transformation” means – doing things electronically that were previously done in an analogue way, or doing things that were previously not possible in the analogue world. And the better you imagine or reimagine the process, the more effective your company will be.

In many cases these digital transformation tools have to deal with real-world complexities – legislation, entrenched behaviour, edge cases. E.g. you can easily write food delivery software. You get the order, you notify the store, you optimize the delivery people’s routes to collect and deliver as much food as possible, and you’re good to go. And then you “hit” the real world, where there are traffic jams, temporarily closed streets, restricted parking, unreponsive restaurants, unresponsive customers, keeping the online menu and what’s in stock in sync, worsened weather conditions, messed up orders, part-time job regulations that differ by country, and so on. And you have to navigate that maze in order to deliver a digitally transformed food delivery service.

There is nothing technically complex about that – any kid with some PHP and JS knowledge can write the software by finding answers to the programming hurdles on Stackoverflow. In that sense, it is no so technically innovative. The hard part is the processes and the real-world complexities. And of course, turning that into a profitable business.

In the long run, these non-technical innovations end up producing technical innovation. Facebook had nothing interesting on the technical side in the beginning. Then it had millions of users and had to scale, and then it became interesting – how to process so much data, how to scale to multiple parts of the world, how to optimize the storage of so many photos, and so on. Facebook gave us Cassandra, Twitter gave us Snowflake, LinkedIn gave us Kafka. There are many more examples, and it’s great that these companies open source some of their internally developed technologies. But these are side-effects of the scale, not an inherent technical innovation that lead to the scale in the first place.

And then there’s the technical innovation companies. I think it’s a much more rare phenomenon and the prime example is Google – the company started as a consequence of a research paper. Roughly speaking, the paper outlined a technical innovation in search that made all other approaches to search obsolete. We can say that Bitcoin was such an innovation, as well. In some cases it’s not the founders that develop the original research, but they derive their product from existing computer science research. They combine multiple papers, adapt them to the needs of the real world (because, as we know, research papers often rely on a “spherical horse in vacuum”) and build something useful.

As a personal side-note here, some of my (side) projects were purely process innovations – I once made an online bus ticket reservation service (before such a thing existed in my country), then I made a social network aggregator (that was arguably better than existing ones at the time). And they were much less interesting than my more technically innovative projects, like Computoser (which has some original research) or LogSentinel (which combines several research papers into a product).

A subset of the technical innovation is the so called “deep tech” – projects that are supposed to enable future innovation. This can be simplified as “applied research”. Computer vision, AI, biomedical. This is where you need a lot of R&D, not simply “pouring” code for a few months.

Just as “process innovation” companies eventually lead to technical innovation, technical innovation companies eventually (or immediately) lead to process improvements. Google practically changed the way we consume information, so it’s impact on the processes is rather high. And to me, that’s the goal of each company – to get to change behaviour. It’s much more interesting to do that using never-before-done technical feats, but if you can do it without the technical bits (i.e. by simply building a website/app using current web/mobile frameworks), good for you.

If you become a successful company, you’ll necessarily have both types of innovation, regardless of how you started. And in order to have a successful company, you have to improve processes and change behaviour. You have to do digital transformation. In the long run, it doesn’t make that much of a difference which was first – the technology or the process innovation. Although from business and investment perspective, it’s easier for competitors to copy the processes and harder to copy internal R&D.

Whether we should call process innovation “technical innovation” – I don’t think so, but that ship has already sailed – anything that uses technology is now “technical innovation”, even if it’s a WordPress site. But for technical people it’s much more challenging and rewarding to be based on actual technical innovation. We just have to remember that we have to solve real-world problems, improve or introduce processes and change behaviour.

The post Technical Innovation vs. Process Innovation appeared first on Bozho's tech blog.

Отлагат електронното гласуване

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

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

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

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

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

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

Холандия и Германия го били забранили. И двете са се отказали от конкретни реализации на машинно гласуване по различни причини. Т.е. малко общо с темата. Решението на констутуцуонния съд в Германия не изключва да има електронно и машинно гласуване, но поставя високи изисквания. Т.е. хич не е „Германия и Холандия го забраниха“.

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

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

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

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

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

Алгоритмична и технологична прозрачност [презентация]

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

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

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

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

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

А какво като знаем защо и как? Колкото повече знаем, толкова по-информиран избор правим. Толкова по-малко могат да ни манипулират (не че знанието елиминира тези влияния, но поне ни помага да сме нащрек). Толкова по-малки са рисковете да се случи технологична антиутопия.

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

Видеото можете да гледате тук, а тъй като slideshare не работи, слайдовете са качени само на английски тук (или на български в самото видео):

Resources on Distributed Hash Tables

Post Syndicated from Bozho original https://techblog.bozho.net/resources-on-distributed-hash-tables/

Distributed p2p technologies have always been fascinating to me. Bittorrent is cool not because you can download pirated content for free, but because it’s an amazing piece of technology.

At some point I read and researched a lot about how DHTs (distributed hash tables) work. DHTs are not part of the original bittorrent protocol, but after trackers were increasingly under threat to be closed for copyright infringment, “trackerless” features were added to the protocol. A DHT is distributed among all peers and holds information about which peer holds what data. Once you are connected to a peer, you can query it for their knowledge on who has what.

During my research (which was with no particular purpose) I took a note on many resources that I thought useful for understanding how DHTs work and possibly implementing something ontop of them in the future. In fact, a DHT is a “shared database”, “just like” a blockchain. You can’t trust it as much, but proving digital events does not require a blockchain anyway. My point here is – there is a lot more cool stuff to distributed / p2p systems than blockchain. And maybe way more practical stuff.

It’s important to note that the DHT used in BitTorrent is Kademlia. You’ll see a lot about it below.

Anyway, the point of this post is to share the resources that I collected. For my own reference and for everyone who wants to start somewhere on the topic of DHTs.

I hope the list is interesting and useful. It’s not trivial to think of other uses of DHTs, but simply knowing about them and how they work is a good thing.

The post Resources on Distributed Hash Tables appeared first on Bozho's tech blog.

Моята лингвистична история

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

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

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

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

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

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

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

В крайна сметка стигнахме до Москва, кацнахме на Шереметиево посред нощ, и с едни бус организаторите ни извозиха до общежитията на РГГУ. А те бяха запомнящи се общежития – това е история, която разказвам и до ден днешен. Това, че всеки две стаи имаха споделена мивка и че общите бани на етажа нямаха врати – окей. Обаче тоалетните (общи за етажа) имаха резета както отвътре, така и отвън. Както казват руснаците – „нарочно не придумаешь“. Общата стая, с хладилници наредени плътно един до друг и опасващи целите стени, беше мястото, където се събирахме, говорихме, обсъждахме, разказвахме вицове.

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

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

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

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

Все пак на следващия ден спечелих отборното, върху една чудесна задача за виетнамска поезия (song thất lục bát, което изглежда като song that looks bad. След това с Тодор Червенков писахме стихове на български в същата поетична форма; още помня неговото, свързано с това, че без да искам щях да хапна свински език в ресторанта в Слънчев бряг). Защо казвам „спечелих“ – всички мои съученици, с които трябваше да съм в отбор заминаха за София, за да се явят на предварителен кандидатстудентски изпит. В последния момент пратиха при мен едно момче от Хасково, така че все пак да имаме формално отбор. Той се включи, разбира се, така че единственото число не е напълно оправдано. Но когато дойде време за награждаване, той отказа да излезе, така че стоях аз сам, награден с грамота и 4 държача за CD-та насред физкултурния салон на гимназията във Враца.

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

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

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

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

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

В следващите няколко години водех лекции на подготовката и тя продължаваше да е място за среща с приятели. Давах и проверявах задачи на националната олимпиада и на зимните състезания.

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

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

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

има две думи за „сестра“, следователно едната е „медицинска“
носорна съгласна
има удвояване на последната буква от цифрата
tu – представка за минало, тук в значение на умрял
В мъркинския език окончанията седят в края
В началото на всяка дума се поставя наставката о-
чете се отляво надясно – както изречението, така и думите поотделно
когато в едно изречение има три подлога, два глагола и черта над последната гласна на втория глагол…
в 3-та група са си чисто криминални глаголи
забелязваме, че всички подлоги от ж.р. …
според мен отговорите са относителни. Ще напиша различни дати и ще ги обясня
всички глаголни форми са съставени от глагол…
съгласната „ъ“
словоред: сказуемо-подлог-лодка
княгинят (м.р. на „княгинята“ не знам)
княжът (м.р. от княгиня)
чичо ми е вода
флейтата ме чува, че забравям
„еми…тъпа съм“ (на празен лист с нерешена задача)

От 2008-ма насам съм бил в задачната комисия и международното жури почти винаги (с изключение на олимпиадите в САЩ, Словения и Ирландия). В Благоевград през 2015-та бях председател на журито – основно комуникационна и административна работа – хората от организационния комитет ми станаха автоматично „любими номера“ в телефона в рамките на тия 5 дена.

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

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

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

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

Algorithmic and Technological Transparency

Post Syndicated from Bozho original https://techblog.bozho.net/algorithmic-and-technological-transparency/

Today I had a talk on OpenFest about algorithmic and technological transparency. It was a somewhat abstract and high-level talk but I hoped to make it more meaningful than if some random guy just spoke about techno-dystopias.

I don’t really like these kinds of talks where someone who has no idea what a “training set” is, how dirty the data is and how to write five lines in Python talks about an AI revolution. But I think being a technical person let’s me put some details into the high-level stuff and make it less useless.

The problem I’m trying to address is opaque systems – we don’t know how recommendation systems work, why are seeing certain videos or ads, how decisions are taken, what happens with our data and how secure the systems we use are, including our cars and future self-driving cars.

Algorithms have real impact on society – recommendation engines make conspiracy theories mainstream, motivate fascists, create echo chambers. Algorithms decide whether we get loans, welfare, a conviction, or even if we get hit by a car (as in the classical trolley problem).

How do we make the systems more transparent, though? There are many approaches, some overlapping. Textual description of how things operate, tracking the actions of back-office admins and making them provable to third parties, implementing “Why am I seeing this?”, tracking each step in machine learning algorithms, publishing datasets, publishing source code (as I’ve previously discussed open-sourcing some aspects of self-driving cars).

We don’t have to reveal trade secrets and lose competitive advantage in order to be transparent. Transparency doesn’t have to come at the expense of profit. In some cases it can even improve the perception of a company.

I think we should start with defining best practices then move to industry codes and standards, and if that doesn’t work, carefully think of focused regulation (but have in mind politicians are mostly clueless about technology and may do more damage)

The slides from the talk are below (the talk itself was not in English)

It can be seen as our responsibility as engineers to steer our products in that direction. Not all of them require or would benefit from such transparency (rarely anyone cares about how an accounting system works), and it would normally be the product people that can decide what should become more transparent, but we also have a stake and should be morally accountable for what we build.

I hope we start thinking and working towards more transparent systems. And of course, each system has its specifics and ways to become more transparent, but I think it should be a general mode of thinking – how do we make our systems not only better and more secure, but also more understandable so that we don’t become the “masterminds” behind black-boxes that decide lives.

The post Algorithmic and Technological Transparency appeared first on Bozho's tech blog.

Администрацията ще обменя документи електронно

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

От днес администрацията е длъжна да обменя документи електронно. Ще разкажа малко предистория.

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

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

  • Държавна агенция „Електронно управление“ да направи въпросният протокол официален. Да го съгласува, „дооправи“ и да му сложи „печат“, че е официален протокол за комуникация
  • Всички администрации да са длъжни да ползват този протокол за обмен на документи помежду си и нямат право да обменят документи на хартия
  • Това да стане до 1-ви ноември 2018-та (т.е. за срок от две години).

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

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

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

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

Кратък политически коментар

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

И във Фейсбук, и на живо, политическият сезон е в разгара си. Демократична България, обединението на Да, България, ДСБ и Зелените, от което съм част, като най-активната извънпарламентарна опозиция (а и дори сравнена с парламентарната) е подложено и на най-много Фейсбук критика. Тези дни даже премиерът каза, че „само хейтим“. Което, разбира се, не е вярно (заради редица конкретни предложения по различни теми, в т.ч. законопроекти).

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

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

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

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

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

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

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

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

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

За всеки, който казва „станали сте популисти“ има друг, който ще каже „много са ви сложни и нишови посланията“.

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

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

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