All posts by Bozho

Electronic Signatures Using The Browser

Post Syndicated from Bozho original https://techblog.bozho.net/electronic-signatures-using-the-browser/

Sometimes, especially in government or enterprise context, you need to sign a document in the browser using a smartcard (some may call it “crypto token”). It’s rare, but many people have asked me, in private messages and emails, how to do it. Maybe they’ve seen some of my articles from several years ago, but failed to make it work. And my articles show the evolution (or devolution) of in-browser electronic signing.

First it was possible with javascript, then I even created a library to make things easier. Then CAPICOM and window.crypto were deprecated, so the only option was to use a Java applet. Then Java applets were deprecated and we were out of options. We got the web crytpo API, but it explicitly didn’t support hardware tokens.

For that reason, I wrote a “plea” for smartcard support in browsers, but it hasn’t happened yet and probably won’t in the near future. So what can we do now, that all previous options are deprecated?

A good approach is to have a one-time installation of some custom software (it could be a Java Web Start application or a Java-independent application), which runs a local service that listens to a particular port, and then a javascript library that sends the data to be signed to http://localhost:1234/sign and gets the response. There are such solutions available, notably NexU (thanks to efforts put in the DSS package). There are other attempts, such as this one, using Java Web Start (it’s currently not in English).

You can try NexU’s demo here. It’s also included in the dss-demo-webapp project.

It has some tricky bits that have been recently resolved in browsers, namely, that in order to send an XMLHTTPRequest to the local service, it has to run on HTTPS, and therefor you have to package a private key in your applications (which goes against the requirements of many Certificate Authorities). Now, as far as I know, localhost is exempt from that requirement.

I hope I don’t have to write yet another article in two years explaining that this approach is superseded by yet another hacky approach.

The post Electronic Signatures Using The Browser appeared first on Bozho's tech blog.

Storing Encrypted Credentials In Git

Post Syndicated from Bozho original https://techblog.bozho.net/storing-encrypted-credentials-in-git/

We all know that we should not commit any passwords or keys to the repo with our code (no matter if public or private). Yet, thousands of production passwords can be found on GitHub (and probably thousands more in internal company repositories). Some have tried to fix that by removing the passwords (once they learned it’s not a good idea to store them publicly), but passwords have remained in the git history.

Knowing what not to do is the first and very important step. But how do we store production credentials. Database credentials, system secrets (e.g. for HMACs), access keys for 3rd party services like payment providers or social networks. There doesn’t seem to be an agreed upon solution.

I’ve previously argued with the 12-factor app recommendation to use environment variables – if you have a few that might be okay, but when the number of variables grow (as in any real application), it becomes impractical. And you can set environment variables via a bash script, but you’d have to store it somewhere. And in fact, even separate environment variables should be stored somewhere.

This somewhere could be a local directory (risky), a shared storage, e.g. FTP or S3 bucket with limited access, or a separate git repository. I think I prefer the git repository as it allows versioning (Note: S3 also does, but is provider-specific). So you can store all your environment-specific properties files with all their credentials and environment-specific configurations in a git repo with limited access (only Ops people). And that’s not bad, as long as it’s not the same repo as the source code.

Such a repo would look like this:

project
└─── production
|   |   application.properites
|   |   keystore.jks
└─── staging
|   |   application.properites
|   |   keystore.jks
└─── on-premise-client1
|   |   application.properites
|   |   keystore.jks
└─── on-premise-client2
|   |   application.properites
|   |   keystore.jks

Since many companies are using GitHub or BitBucket for their repositories, storing production credentials on a public provider may still be risky. That’s why it’s a good idea to encrypt the files in the repository. A good way to do it is via git-crypt. It is “transparent” encryption because it supports diff and encryption and decryption on the fly. Once you set it up, you continue working with the repo as if it’s not encrypted. There’s even a fork that works on Windows.

You simply run git-crypt init (after you’ve put the git-crypt binary on your OS Path), which generates a key. Then you specify your .gitattributes, e.g. like that:

secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt
*.properties filter=git-crypt diff=git-crypt
*.jks filter=git-crypt diff=git-crypt

And you’re done. Well, almost. If this is a fresh repo, everything is good. If it is an existing repo, you’d have to clean up your history which contains the unencrypted files. Following these steps will get you there, with one addition – before calling git commit, you should call git-crypt status -f so that the existing files are actually encrypted.

You’re almost done. We should somehow share and backup the keys. For the sharing part, it’s not a big issue to have a team of 2-3 Ops people share the same key, but you could also use the GPG option of git-crypt (as documented in the README). What’s left is to backup your secret key (that’s generated in the .git/git-crypt directory). You can store it (password-protected) in some other storage, be it a company shared folder, Dropbox/Google Drive, or even your email. Just make sure your computer is not the only place where it’s present and that it’s protected. I don’t think key rotation is necessary, but you can devise some rotation procedure.

git-crypt authors claim to shine when it comes to encrypting just a few files in an otherwise public repo. And recommend looking at git-remote-gcrypt. But as often there are non-sensitive parts of environment-specific configurations, you may not want to encrypt everything. And I think it’s perfectly fine to use git-crypt even in a separate repo scenario. And even though encryption is an okay approach to protect credentials in your source code repo, it’s still not necessarily a good idea to have the environment configurations in the same repo. Especially given that different people/teams manage these credentials. Even in small companies, maybe not all members have production access.

The outstanding questions in this case is – how do you sync the properties with code changes. Sometimes the code adds new properties that should be reflected in the environment configurations. There are two scenarios here – first, properties that could vary across environments, but can have default values (e.g. scheduled job periods), and second, properties that require explicit configuration (e.g. database credentials). The former can have the default values bundled in the code repo and therefore in the release artifact, allowing external files to override them. The latter should be announced to the people who do the deployment so that they can set the proper values.

The whole process of having versioned environment-speific configurations is actually quite simple and logical, even with the encryption added to the picture. And I think it’s a good security practice we should try to follow.

The post Storing Encrypted Credentials In Git appeared first on Bozho's tech blog.

За едно дарение

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

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

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

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

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

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

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

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

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

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

The Benefits of Side Projects

Post Syndicated from Bozho original https://techblog.bozho.net/the-benefits-of-side-projects/

Side projects are the things you do at home, after work, for your own “entertainment”, or to satisfy your desire to learn new stuff, in case your workplace doesn’t give you that opportunity (or at least not enough of it). Side projects are also a way to build stuff that you think is valuable but not necessarily “commercialisable”. Many side projects are open-sourced sooner or later and some of them contribute to the pool of tools at other people’s disposal.

I’ve outlined one recommendation about side projects before – do them with technologies that are new to you, so that you learn important things that will keep you better positioned in the software world.

But there are more benefits than that – serendipitous benefits, for example. And I’d like to tell some personal stories about that. I’ll focus on a few examples from my list of side projects to show how, through a sort-of butterfly effect, they helped shape my career.

The computoser project, no matter how cool algorithmic music composition, didn’t manage to have much of a long term impact. But it did teach me something apart from niche musical theory – how to read a bulk of scientific papers (mostly computer science) and understand them without being formally trained in the particular field. We’ll see how that was useful later.

Then there was the “State alerts” project – a website that scraped content from public institutions in my country (legislation, legislation proposals, decisions by regulators, new tenders, etc.), made them searchable, and “subscribable” – so that you get notified when a keyword of interest is mentioned in newly proposed legislation, for example. (I obviously subscribed for “information technologies” and “electronic”).

And that project turned out to have a significant impact on the following years. First, I chose a new technology to write it with – Scala. Which turned out to be of great use when I started working at TomTom, and on the 3rd day I was transferred to a Scala project, which was way cooler and much more complex than the original one I was hired for. It was a bit ironic, as my colleagues had just read that “I don’t like Scala” a few weeks earlier, but nevertheless, that was one of the most interesting projects I’ve worked on, and it went on for two years. Had I not known Scala, I’d probably be gone from TomTom much earlier (as the other project was restructured a few times), and I would not have learned many of the scalability, architecture and AWS lessons that I did learn there.

But the very same project had an even more important follow-up. Because if its “civic hacking” flavour, I was invited to join an informal group of developers (later officiated as an NGO) who create tools that are useful for society (something like MySociety.org). That group gathered regularly, discussed both tools and policies, and at some point we put up a list of policy priorities that we wanted to lobby policy makers. One of them was open source for the government, the other one was open data. As a result of our interaction with an interim government, we donated the official open data portal of my country, functioning to this day.

As a result of that, a few months later we got a proposal from the deputy prime minister’s office to “elect” one of the group for an advisor to the cabinet. And we decided that could be me. So I went for it and became advisor to the deputy prime minister. The job has nothing to do with anything one could imagine, and it was challenging and fascinating. We managed to pass legislation, including one that requires open source for custom projects, eID and open data. And all of that would not have been possible without my little side project.

As for my latest side project, LogSentinel – it became my current startup company. And not without help from the previous two mentioned above – the computer science paper reading was of great use when I was navigating the crypto papers landscape, and from the government job I not only gained invaluable legal knowledge, but I also “got” a co-founder.

Some other side projects died without much fanfare, and that’s fine. But the ones above shaped my “story” in a way that would not have been possible otherwise.

And I agree that such serendipitous chain of events could have happened without side projects – I could’ve gotten these opportunities by meeting someone at a bar (unlikely, but who knows). But we, as software engineers, are capable of tilting chance towards us by utilizing our skills. Side projects are our “extracurricular activities”, and they often lead to unpredictable, but rather positive chains of events. They would rarely be the only factor, but they are certainly great at unlocking potential.

The post The Benefits of Side Projects appeared first on Bozho's tech blog.

История за един контрапротестен автобус

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

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

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

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

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

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

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

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

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

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

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

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

Седем мита за GDPR

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

GDPR, или новият Общ регламент относно защитата на данните, е гореща тема, тъй като влиза в сила на 25-ти май. И разбира се, публичното пространство е пълно с мнения и заключения по въпроса. За съжаление повечето от тях са грешни. На база на наблюденията ми от последните месеци реших да извадя 7 мита за Регламента.

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

1. „GDPR ми е ясен, разбрал съм го“

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

От мита, че познаваме GDPR, произлизат и всички останали митове. Част от вината за това е и на самия Регламент. Дълъг е, чете се трудно, има лоши законодателни практики (3 различни хипотези в едно изречение??) и нито Европейската Комисия, нито някоя друга европейска институция си е направила труда да го разясни за хората, за които се отнася – а именно, за почти всички. Т.нар. „работна група по чл. 29 (от предишната Директива)“ има разяснения по някои въпроси, но те са също толкова дълги и трудно четими ако човек няма контекст. При толкова широкообхватно законодателство е голяма грешка то да се остави нерязяснено. Да, в него има много нюанси и много условности (което е друг негов минус), но е редно поне общите положения да бъдат разказани ясно и то от практическа гледна точка.

Така че не – да не си мислим, че сме разбрали GDPR.

2. „Личните данни са тайна“

Определението за лични данни в Регламента може би характеризира целия Регламент – трудно четима и „увъртяно“:

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

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

Разграничаването, което GDPR не прави ясно, за разлика от едно разяснение на NIST – има лични данни, на база на които хората могат да бъдат идентифицирани, и такива, с които не могат, но се отнасят за тях. По цвят на косата не можем да бъдем идентифицирани. Но цветът на косата представлява лични данни. По професия не можем да бъдем идентифицирани. (По три имена и професия обаче – евентуално може и да можем). И тук едно много важно нещо, посочено в последните изречения на съображение 26 – данни, които са лични, но не могат да бъдат отнесени към конкретно лице, и на база на които не може да бъде идентифицирано такова, не попадат в обхвата на регламента. И съвсем не са тайна – „имаме 120 клиента на възраст 32 години, които са си купили телефон Sony между Април и Юли“ е напълно окей.

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

3. „GDPR не се отнася за мен“

Няма почти никакви изключения в Регламента. Компании под 250 души не са длъжни да водят едни регистри, а компании, които нямат мащабна обработка и наблюдение на субекти на данни нямат задължение за длъжностно лице по защита на данните (Data protection officer; тази точка е дискусионна с оглед на предложенията за изменения на българския закон за защита на личните данни, които разширяват прекалено много изискванията за DPO). Всичко останало важи за всички, които обработват лични данни. И всички граждани на ЕС имат всички права, посочени в Регламента.

4. „Ще ни глобят 20 милиона евро“

Тези глоби са единствената причина GDPR да е популярен. Ако не бяха те, на никого нямаше да му дреме за поредното европейско законодателство. Обаче заради плашещите глоби всякакви консултанти ходят и обясняват как „ами те глобите, знаете, са до 20 милиона“.

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

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

5. „Трябва да спрем да обработваме лични данни“

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

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

6. „Трябва да искаме съгласие за всичко“

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

Усещането ми обаче е, че ще плъзнат едни декларации и чекбоксове за съгласие, които ще са напълно излишни…но вж. т.1. А дори когато трябва да ги има, ще бъдат прекалено общи, а не за определени цели (съгласявам се да ми обработвате данните, ама за какво точно?).

7. „Съответсвието с GDPR е трудно и скъпо“

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

Ако например досега в една болница данните за пациентите са били на незащитен по никакъв начин сървър и всеки е имал достъп до него, без това да оставя следа, и също така е имало още 3-4 сървъра, на които никой не е знаел, че има данни (щото „IT-то“ е напуснало преди 2 години), то да, ще трябват малко усилия.

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

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


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

И както става винаги със законодателства, обхващащи много хора и бизнеси – в началото ще има не само 7, а 77 мита, които с времето и с практиката ще се изяснят. Ще има грешки на растежа, има риск (особено в по-малки и корумпирани държави) някой „да го отнесе“, но гледайки голямата картинка, смятам, че с този Регламент след 5 години ще сме по-добре откъм защита на данните и откъм последици от липсата на на такава защита.

Bad Software Is Our Fault

Post Syndicated from Bozho original https://techblog.bozho.net/bad-software-is-our-fault/

Bad software is everywhere. One can even claim that every software is bad. Cool companies, tech giants, established companies, all produce bad software. And no, yours is not an exception.

Who’s to blame for bad software? It’s all complicated and many factors are intertwined – there’s business requirements, there’s organizational context, there’s lack of sufficient skilled developers, there’s the inherent complexity of software development, there’s leaky abstractions, reliance on 3rd party software, consequences of wrong business and purchase decisions, time limitations, flawed business analysis, etc. So yes, despite the catchy title, I’m aware it’s actually complicated.

But in every “it’s complicated” scenario, there’s always one or two factors that are decisive. All of them contribute somehow, but the major drivers are usually a handful of things. And in the case of base software, I think it’s the fault of technical people. Developers, architects, ops.

We don’t seem to care about best practices. And I’ll do some nasty generalizations here, but bear with me. We can spend hours arguing about tabs vs spaces, curly bracket on new line, git merge vs rebase, which IDE is better, which framework is better and other largely irrelevant stuff. But we tend to ignore the important aspects that span beyond the code itself. The context in which the code lives, the non-functional requirements – robustness, security, resilience, etc.

We don’t seem to get security. Even trivial stuff such as user authentication is almost always implemented wrong. These days Twitter and GitHub realized they have been logging plain-text passwords, for example, but that’s just the tip of the iceberg. Too often we ignore the security implications.

“But the business didn’t request the security features”, one may say. The business never requested 2-factor authentication, encryption at rest, PKI, secure (or any) audit trail, log masking, crypto shredding, etc., etc. Because the business doesn’t know these things – we do and we have to put them on the backlog and fight for them to be implemented. Each organization has its specifics and tech people can influence the backlog in different ways, but almost everywhere we can put things there and prioritize them.

The other aspect is testing. We should all be well aware by now that automated testing is mandatory. We have all the tools in the world for unit, functional, integration, performance and whatnot testing, and yet many software projects lack the necessary test coverage to be able to change stuff without accidentally breaking things. “But testing takes time, we don’t have it”. We are perfectly aware that testing saves time, as we’ve all had those “not again!” recurring bugs. And yet we think of all sorts of excuses – “let the QAs test it”, we have to ship that now, we’ll test it later”, “this is too trivial to be tested”, etc.

And you may say it’s not our job. We don’t define what has do be done, we just do it. We don’t define the budget, the scope, the features. We just write whatever has been decided. And that’s plain wrong. It’s not our job to make money out of our code, and it’s not our job to define what customers need, but apart from that everything is our job. The way the software is structured, the security aspects and security features, the stability of the code base, the way the software behaves in different environments. The non-functional requirements are our job, and putting them on the backlog is our job.

You’ve probably heard that every software becomes “legacy” after 6 months. And that’s because of us, our sloppiness, our inability to mitigate external factors and constraints. Too often we create a mess through “just doing our job”.

And of course that’s a generalization. I happen to know a lot of great professionals who don’t make these mistakes, who strive for excellence and implement things the right way. But our industry as a whole doesn’t. Our industry as a whole produces bad software. And it’s our fault, as developers – as the only people who know why a certain piece of software is bad.

In a talk of his, Bob Martin warns us of the risks of our sloppiness. We have been building websites so far, but we are more and more building stuff that interacts with the real world, directly and indirectly. Ultimately, lives may depend on our software (like the recent unfortunate death caused by a self-driving car). And I’ll agree with Uncle Bob that it’s high time we self-regulate as an industry, before some technically incompetent politician decides to do that.

How, I don’t know. We’ll have to think more about it. But I’m pretty sure it’s our fault that software is bad, and no amount of blaming the management, the budget, the timing, the tools or the process can eliminate our responsibility.

Why do I insist on bashing my fellow software engineers? Because if we start looking at software development with more responsibility; with the fact that if it fails, it’s our fault, then we’re more likely to get out of our current bug-ridden, security-flawed, fragile software hole and really become the experts of the future.

The post Bad Software Is Our Fault appeared first on Bozho's tech blog.

Критика към новия Закон за движението по пътищата

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

Прочетох предложението за нов Закон за движение по пътищата, в частта с административното наказване, връчване на наказателни постановления и фишове, електронни фишове, камери.

С две думи – никаква реформа.

Буквално текстовете са преписани от стария закон. И то текстове, които са омазани, хаотични, неработещи и непокриващи 50% от хипотезите в реалния живот. По същество:

  • не се дефинират възможности за електронно връчване
  • малоумният анахронизъм „контролен талон“ остава. Тоя син парцал ще си го носим и като се върнем от някое пътуване до Марс след 50 години.
  • процесът по връчване на електронен фиш (което е тъпо наименование; трябва да е „електронно-съставен фиш“, щото фишът си е хартиен) оставя същите вратички за измъкване с даване на копие на чужда книжка или лична карта на чужденец. Познайте в google images дали няма такива. И дали тарикатите не ги ползват. Специфични случаи като „фирма с повече от един управител“, „електронен фиш издаден от орган различен от МВР“ изобщо не са засегнати.
  • в ЗАНН продължава да се говори за „препис“, а административният съд е обявявал, че разпечатките не са преписи – трябвало индиго. В тази връзка вероятно е въведна глупостта „връчване на разпечатка за издадени, но невръчени наказателни постановления“. WAT. Ако наказателното постановление е в електронен вид, ще може да му се връчи самото то на пътя, няма нужда от „разпечатки“, че после да ходиш да си вземаш и постановлението. Да не говорим, че не е покрита хипотезата на НП, което е връчено, но е платено след принудително събиране от НАП. Сега излиза, че талонът не се връща.
  • електронното управление значи да не се изискват копия на всевъзможни документи, които държавата има (напр. трудови договори). Но ЗДвП изисква „копие от“ на доста места
  • доомазали са Закона за българските лични документи, но са пропуснали важна подробност – че макар на книжката да няма адрес, сме длъжни да си я сменим, ако си сменим адреса. Чл. 81 иска корекция, ама кой да се сети

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

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

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

Audit Trail Overview

Post Syndicated from Bozho original https://techblog.bozho.net/audit-trail-overview/

As part of my current project (secure audit trail) I decided to make a survey about the use of audit trail “in the wild”.

I haven’t written in details about this project of mine (unlike with some other projects). Mostly because it’s commercial and I don’t want to use my blog as a direct promotion channel (though I am doing that at the moment, ironically). But the aim of this post is to shed some light on how audit trail is used.

The survey can be found here. The questions are basically: does your current project have audit trail functionality, and if yes, is it protected from tampering. If not – do you think you should have such functionality.

The results are interesting (although with only around 50 respondents)

So more than half of the systems (on which respondents are working) don’t have audit trail. While audit trail is recommended by information security and related standards, it may not find place in the “busy schedule” of a software project, even though it’s fairly easy to provide a trivial implementation (e.g. I’ve written how to quickly setup one with Hibernate and Spring)

A trivial implementation might do in many cases but if the audit log is critical (e.g. access to sensitive data, performing financial operations etc.), then relying on a trivial implementation might not be enough. In other words – if the sysadmin can access the database and delete or modify the audit trail, then it doesn’t serve much purpose. Hence the next question – how is the audit trail protected from tampering:

And apparently, from the less than 50% of projects with audit trail, around 50% don’t have technical guarantees that the audit trail can’t be tampered with. My guess is it’s more, because people have different understanding of what technical measures are sufficient. E.g. someone may think that digitally signing your log files (or log records) is sufficient, but in fact it isn’t, as whole files (or records) can be deleted (or fully replaced) without a way to detect that. Timestamping can help (and a good audit trail solution should have that), but it doesn’t guarantee the order of events or prevent a malicious actor from deleting or inserting fake ones. And if timestamping is done on a log file level, then any not-yet-timestamped log file is vulnerable to manipulation.

I’ve written about event logs before and their two flavours – event sourcing and audit trail. An event log can effectively be considered audit trail, but you’d need additional security to avoid the problems mentioned above.

So, let’s see what would various levels of security and usefulness of audit logs look like. There are many papers on the topic (e.g. this and this), and they often go into the intricate details of how logging should be implemented. I’ll try to give an overview of the approaches:

  • Regular logs – rely on regular INFO log statements in the production logs to look for hints of what has happened. This may be okay, but is harder to look for evidence (as there is non-auditable data in those log files as well), and it’s not very secure – usually logs are collected (e.g. with graylog) and whoever has access to the log collector’s database (or search engine in the case of Graylog), can manipulate the data and not be caught
  • Designated audit trail – whether it’s stored in the database or in logs files. It has the proper business-event level granularity, but again doesn’t prevent or detect tampering. With lower risk systems that may is perfectly okay.
  • Timestamped logs – whether it’s log files or (harder to implement) database records. Timestamping is good, but if it’s not an external service, a malicious actor can get access to the local timestamping service and issue fake timestamps to either re-timestamp tampered files. Even if the timestamping is not compromised, whole entries can be deleted. The fact that they are missing can sometimes be deduced based on other factors (e.g. hour of rotation), but regularly verifying that is extra effort and may not always be feasible.
  • Hash chaining – each entry (or sequence of log files) could be chained (just as blockchain transactions) – the next one having the hash of the previous one. This is a good solution (whether it’s local, external or 3rd party), but it has the risk of someone modifying or deleting a record, getting your entire chain and re-hashing it. All the checks will pass, but the data will not be correct
  • Hash chaining with anchoring – the head of the chain (the hash of the last entry/block) could be “anchored” to an external service that is outside the capabilities of a malicious actor. Ideally, a public blockchain, alternatively – paper, a public service (twitter), email, etc. That way a malicious actor can’t just rehash the whole chain, because any check against the external service would fail.
  • WORM storage (write once, ready many). You could send your audit logs almost directly to WORM storage, where it’s impossible to replace data. However, that is not ideal, as WORM storage can be slow and expensive. For example AWS Glacier has rather big retrieval times and searching through recent data makes it impractical. It’s actually cheaper than S3, for example, and you can have expiration policies. But having to support your own WORM storage is expensive. It is a good idea to eventually send the logs to WORM storage, but “fresh” audit trail should probably not be “archived” so that it’s searchable and some actionable insight can be gained from it.
  • All-in-one – applying all of the above “just in case” may be unnecessary for every project out there, but that’s what I decided to do at LogSentinel. Business-event granularity with timestamping, hash chaining, anchoring, and eventually putting to WORM storage – I think that provides both security guarantees and flexibility.

I hope the overview is useful and the results from the survey shed some light on how this aspect of information security is underestimated.

The post Audit Trail Overview appeared first on Bozho's tech blog.

Всички са маскари?

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

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

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

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

У доста хора има осезаем негативизъм към това обединение. Всеки със своята причина, с която не мога да споря. но този негативизъм кулминира в крайно множество твърдения за обединението и за партиите в него, които твърдения мога да опитам да оспоря. И целта не е да кажа „аха! не сте прави да не ни харесвате“ (защото това е субективно и всеки има право да не харесва каквото си иска), а по-скоро да допълня картината, която всеки има за политическия пейзаж. Ще разгледам 10 твърдения/коментара, които са преобладаващи. И не за да влизам в „обяснителен режим“, а за да вляза в своеобразен диалог с по-скептичните.

Обединяватe се само за да минете 4-процентовата бариера

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

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

Късно е либе за китка / защо чак сега

…или продължаващото вече година обвинение срещу Да, България, че „е разцепила дясното“. Както имах случай да спомена днес – предишните избори не бяха успех, но решението за явяване като „Да, България“ все пак беше правилно. По много причини, които тук само ще маркирам – след изборите направих един анализ на екзит половете и от него излезе, че макар да не е постигнала желания резултата, Да, България е привлякла най-голям процент нови избиратели и гласуващи за първи път. Взела е повече от ГЕРБ, отколкото от РБ(2014). В „дългата нива“, която имаме да орем, това всичко е от значение. Дали от по-голямо значение от едно евентуално влизане в парламента, не знам. Но в момента имаме Да, България със собствено лице и послания, която влиза в продуктивен диалог и обединения. Която привлича нови хора в местни структури из страната. Да, България на 2 седмици, влизаща в „поредното дясно обединение“ (както несъмнено щеше да бъде наречена евентуална коалиция тогава), не е ясно дали щеше да има същата съдба. Наскоро някой ми каза, че е приятно изненадан, че не сме умрели след изборите. И да, не сме.

Оставете жълтите павета и ходете из страната

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

Леви сте, не сте десни!

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

Ама Зелените са леви!

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

Поредното механично обединение без смисъл

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

Сорос, Америка за България и Прокопиев ви финансират!

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

Защо не говорите за (проблем Х, който за мен е важен)

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

Само говорите, а нищо не правите

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

Със стари к*рви, нов бардак!

Кой е стара к*рва бе?? 🙂 А сериозно – в лицата, обявени днес има някои познати (с по един-два мандата в парламента, например), и доста непознати на широката публика. Така че това е по-скоро клише по инерция, отколкото базирано на някакви обективни факти. Естествено, че трябва да има хора с опит и естествено, че има много нови лица.

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

А иначе, всички са маскари, то е ясно.

Има ли електронно управление?

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

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

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

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

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

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

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

Де факто всичко правя онлайн. Тогава какво се оплакваме, че няма електронно управление?

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

Да, декларирам си данъците, ама да се оправиш с данъчната декларация на НАП е близо до ракетна наука. Като си платих осигуровките, на следващия ден се генерираха стотинки лихва, дето пак трябваше да ги платя и пак да се генерират. Удостоверението за липса на задължение го заявих електронно, но го получих в най-близкия офис на НАП, а не в този по постоянен адрес, и то само защото проведох 10 минутен разговор със служителка, която накрая капитулира и призна, че са в нарушение на закона и предложи да ми го прати до близък до мен офис. Постоянния си адрес успях да го сменя само защото знам за конкретен бъг в електронните услуги на Столична община и мога да го заобиколя. Личната си карта получих, но не пишеше къде трябва да отида да я получа, а като отидох най-накрая на правилното място, опрях до фразата „не ви трябва да ви давам удостоверение, системата го е проверила автоматично, аз съм я внедрявал и съм писал закона“. Декларацията ми по ЗПУКИ мина през една итерация с фразата „това не е истински електронен подпис“. А за повечето изредени неща ми трябва квалифициран електронен подпис, за който плащам 10-15 лева годишно, и който и аз понякога се затруднявам да подкарам в правилния браузър с правилната версия на Java.

Т.е. нещата ги има, ама не съвсем. Работят, ама трябва да инвестираш време да разбереш как работят. И това не е окей. Но какво може да се направи?

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

Има обаче едно нещо, което със сигурност е отключващ фактор – електронната идентификация. Ако няма лесно и удобно средство да се идентифицираме онлайн и да заявяваме услуги, ще ги ползваме шепа хора. (И счетоводителите и юристите, на които им се налага). Но след Закона за електронната идентификация нищо не се е случило. В 2017-та новите лични карти с е-идентификация не станаха, бяха отложени за 2018-та, ама Капитал тези дни писа, че нещата отиват към 2020-та. Масово и достъпно средство не е само личната карта, но знаейки, че тя така или иначе идва, няма смисъл да се инвестира в нещо друго. Т.е. ще си останем с КЕП още известно време. Появяват се частни схеми (в България и Европа), които обаче най-вероятно също ще са платени, а и не е ясно дали ще поддържат подписване на заявления (ЗЕУ допуска подписване с усъвършенстван електронен подпис, но ифраструктурата за е-идентификация, предвидена от ЕС, не предвижда всички схеми да могат да се ползват и за подпис; дори напротив).

Второто нещо е т.нар. UX (User Experience). Това не значи просто потребителския интерфейс да е удобен – значи процесите зад този интерфейс да са оптимизирани и удобни. Не в рамките на процеса по заявяване да минаваш през 4 стъпки и 2 имейла, защото така било според вътрешна наредба от 96-та (#truestory). UX-ът е причината никой (дори хора с КЕП) да не използват услугите. Защото в UX-а влиза и това гражданите да знаят, че има такива услуги. Кога последно Столична община ви каза, че има електронни услуги? Никога. Доскоро бяха скрити на сайта дотолкова, че и аз не можех да ги открия. Тестове с реални потребители въведохме като задължително изискване както в наредба, така и в условия за финансиране. Само че ако и изпълнителят, и възложителят не знаят какво е UX, то ще бъде отчетено като изпълнено и пак ще получим някоя деветдесетарска грозотия.

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

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

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

User Authentication Best Practices Checklist

Post Syndicated from Bozho original https://techblog.bozho.net/user-authentication-best-practices-checklist/

User authentication is the functionality that every web application shared. We should have perfected that a long time ago, having implemented it so many times. And yet there are so many mistakes made all the time.

Part of the reason for that is that the list of things that can go wrong is long. You can store passwords incorrectly, you can have a vulnerably password reset functionality, you can expose your session to a CSRF attack, your session can be hijacked, etc. So I’ll try to compile a list of best practices regarding user authentication. OWASP top 10 is always something you should read, every year. But that might not be enough.

So, let’s start. I’ll try to be concise, but I’ll include as much of the related pitfalls as I can cover – e.g. what could go wrong with the user session after they login:

  • Store passwords with bcrypt/scrypt/PBKDF2. No MD5 or SHA, as they are not good for password storing. Long salt (per user) is mandatory (the aforementioned algorithms have it built in). If you don’t and someone gets hold of your database, they’ll be able to extract the passwords of all your users. And then try these passwords on other websites.
  • Use HTTPS. Period. (Otherwise user credentials can leak through unprotected networks). Force HTTPS if user opens a plain-text version.
  • Mark cookies as secure. Makes cookie theft harder.
  • Use CSRF protection (e.g. CSRF one-time tokens that are verified with each request). Frameworks have such functionality built-in.
  • Disallow framing (X-Frame-Options: DENY). Otherwise your website may be included in another website in a hidden iframe and “abused” through javascript.
  • Have a same-origin policy
  • Logout – let your users logout by deleting all cookies and invalidating the session. This makes usage of shared computers safer (yes, users should ideally use private browsing sessions, but not all of them are that savvy)
  • Session expiry – don’t have forever-lasting sessions. If the user closes your website, their session should expire after a while. “A while” may still be a big number depending on the service provided. For ajax-heavy website you can have regular ajax-polling that keeps the session alive while the page stays open.
  • Remember me – implementing “remember me” (on this machine) functionality is actually hard due to the risks of a stolen persistent cookie. Spring-security uses this approach, which I think should be followed if you wish to implement more persistent logins.
  • Forgotten password flow – the forgotten password flow should rely on sending a one-time (or expiring) link to the user and asking for a new password when it’s opened. 0Auth explain it in this post and Postmark gives some best pracitces. How the link is formed is a separate discussion and there are several approaches. Store a password-reset token in the user profile table and then send it as parameter in the link. Or do not store anything in the database, but send a few params: userId:expiresTimestamp:hmac(userId+expiresTimestamp). That way you have expiring links (rather than one-time links). The HMAC relies on a secret key, so the links can’t be spoofed. It seems there’s no consensus, as the OWASP guide has a bit different approach
  • One-time login links – this is an option used by Slack, which sends one-time login links instead of asking users for passwords. It relies on the fact that your email is well guarded and you have access to it all the time. If your service is not accessed to often, you can have that approach instead of (rather than in addition to) passwords.
  • Limit login attempts – brute-force through a web UI should not be possible; therefore you should block login attempts if they become too many. One approach is to just block them based on IP. The other one is to block them based on account attempted. (Spring example here). Which one is better – I don’t know. Both can actually be combined. Instead of fully blocking the attempts, you may add a captcha after, say, the 5th attempt. But don’t add the captcha for the first attempt – it is bad user experience.
  • Don’t leak information through error messages – you shouldn’t allow attackers to figure out if an email is registered or not. If an email is not found, upon login report just “Incorrect credentials”. On passwords reset, it may be something like “If your email is registered, you should have received a password reset email”. This is often at odds with usability – people don’t often remember the email they used to register, and the ability to check a number of them before getting in might be important. So this rule is not absolute, though it’s desirable, especially for more critical systems.
  • Make sure you use JWT only if it’s really necessary and be careful of the pitfalls.
  • Consider using a 3rd party authentication – OpenID Connect, OAuth by Google/Facebook/Twitter (but be careful with OAuth flaws as well). There’s an associated risk with relying on a 3rd party identity provider, and you still have to manage cookies, logout, etc., but some of the authentication aspects are simplified.
  • For high-risk or sensitive applications use 2-factor authentication. There’s a caveat with Google Authenticator though – if you lose your phone, you lose your accounts (unless there’s a manual process to restore it). That’s why Authy seems like a good solution for storing 2FA keys.

I’m sure I’m missing something. And you see it’s complicated. Sadly we’re still at the point where the most common functionality – authenticating users – is so tricky and cumbersome, that you almost always get at least some of it wrong.

The post User Authentication Best Practices Checklist appeared first on Bozho's tech blog.

Tracking Cookies and GDPR

Post Syndicated from Bozho original https://techblog.bozho.net/tracking-cookies-gdpr/

GDPR is the new data protection regulation, as you probably already know. I’ve given a detailed practical advice for what it means for developers (and product owners). However, there’s one thing missing there – cookies. The elephant in the room.

Previously I’ve stated that cookies are subject to another piece of legislation – the ePrivacy directive, which is getting updated and its new version will be in force a few years from now. And while that’s technically correct, cookies seem to be affected by GDPR as well. In a way I’ve underestimated that effect.

When you do a Google search on “GDPR cookies”, you’ll pretty quickly realize that a) there’s not too much information and b) there’s not much technical understanding of the issue.

What appears to be the consensus is that GDPR does change the way cookies are handled. More specifically – tracking cookies. Here’s recital 30:

(30) Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.

How tracking cookies work – a 3rd party (usually an ad network) gives you a code snippet that you place on your website, for example to display ads. That code snippet, however, calls “home” (makes a request to the 3rd party domain). If the 3rd party has previously been used on your computer, it has created a cookie. In the example of Facebook, they have the cookie with your Facebook identifier because you’ve logged in to Facebook. So this cookie (with your identifier) is sent with the request. The request also contains all the details from the page. In effect, you are uniquely identified by an identifier (in the case of Facebook and Google – fully identified, rather than some random anonymous identifier as with other ad networks).

Your behaviour on the website is personal data. It gets associated with your identifier, which in turn is associated with your profile. And all of that is personal data. Who is responsible for collecting the website behaviour data, i.e. who is the “controller”? Is it Facebook (or any other 3rd party) that technically does the collection? No, it’s the website owner, as the behaviour data is obtained on their website, and they have put the tracking piece of code there. So they bear responsibility.

What’s the responsibility? So far it boiled down to displaying the useless “we use cookies” warning that nobody cares about. And the current (old) ePrivacy directive and its interpretations says that this is enough – if the users actions can unambiguously mean that they are fine with cookies – i.e. if they continue to use the website after seeing the warning – then you’re fine. This is no longer true from a GDPR perspective – you are collecting user data and you have to have a lawful ground for processing.

For the data collected by tracking cookies you have two options – “consent” and “legitimate interest”. Legitimate interest will be hard to prove – it is not something that a user reasonably expects, it is not necessary for you to provide the service. If your lawyers can get that option to fly, good for them, but I’m not convinced regulators will be happy with that.

The other option is “consent”. You have to ask your users explicitly – that means “with a checkbox” – to let you use tracking cookies. That has two serious implications – from technical and usability point of view.

  • The technical issue is that the data is sent via 3rd party code as soon as the page loads and before the user can give their consent. And that’s already a violation. You can, of course, have the 3rd party code be dynamically inserted only after the user gives consent, but that will require some fiddling with javascript and might not always work depending on the provider. And you’d have to support opt-out at any time (which would in turn disable the 3rd party snippet). It would require actual coding, rather than just copy-pasting a snippet.
  • The usability aspect is the bigger issue – while you could neatly tuck a cookie warning at the bottom, you’d now have to have a serious, “stop the world” popup that asks for consent if you want anyone to click it. You can, of course, just add a checkbox to the existing cookie warning, but don’t expect anyone to click it.

These aspects pose a significant questions: is it worth it to have tracking cookies? Is developing new functionality worth it, is interrupting the user worth it, and is implementing new functionality just so that users never clicks a hidden checkbox worth it? Especially given that Firefox now blocks all tracking cookies and possibly other browsers will follow?

That by itself is an interesting topic – Firefox has basically implemented the most strict form of requirements of the upcoming ePrivacy directive update (that would turn it into an ePrivacy regulation). Other browsers will have to follow, even though Google may not be happy to block their own tracking cookies. I hope other browsers follow Firefox in tracking protection and the issue will be gone automatically.

To me it seems that it will be increasingly not worthy to have tracking cookies on your website. They add regulatory obligations for you and give you very little benefit (yes, you could track engagement from ads, but you can do that in other ways, arguably by less additional code than supporting the cookie consents). And yes, the cookie consent will be “outsourced” to browsers after the ePrivacy regulation is passed, but we can’t be sure at the moment whether there won’t be technical whack-a-mole between browsers and advertisers and whether you wouldn’t still need additional effort to have dynamic consent for tracking cookies. (For example there are reported issues that Firefox used to make Facebook login fail if tracking protection is enabled. Which could be a simple bug, or could become a strategy by big vendors in the future to force browsers into a less strict tracking protection).

Okay, we’ve decided it’s not worth it managing tracking cookies. But do you have a choice as a website owner? Can you stop your ad network from using them? (Remember – you are liable if users’ data is collected by visiting your website). And currently the answer is no – you can’t disable that. You can’t have “just the ads”. This is part of the “deal” – you get money for the ads you place, but you participate in a big “surveillance” network. Users have a way to opt out (e.g. Google AdWords gives them that option). You, as a website owner, don’t.

Facebook has a recommendations page that says “you take care of getting the consent”. But for example the “like button” plugin doesn’t have an option to not send any data to Facebook.

And sometimes you don’t want to serve ads, just track user behaviour and measure conversion. But even if you ask for consent for that and conditionally insert the plugin/snippet, do you actually know what data it sends? And what it’s used for? Because you have to know in order to inform your users. “Do you agree to use tracking cookies that Facebook has inserted in order to collect data about your behaviour on our website” doesn’t sound compelling.

So, what to do? The easiest thing is just not to use any 3rd party ad-related plugins. But that’s obviously not an option, as ad revenue is important, especially in the publishing industry. I don’t have a good answer, apart from “Regulators should pressure ad networks to provide opt-outs and clearly document their data usage”. They have to do that under GDPR, and while website owners are responsible for their users’ data, the ad networks that are in the role of processors in this case (as you delegate the data collection for your visitors to them) also have obligation to assist you in fulfilling your obligations. So ask Facebook – what should I do with your tracking cookies? And when the regulator comes after a privacy-aware customer files a complaint, you could prove that you’ve tried.

The ethical debate whether it’s wrong to collect data about peoples’ behaviour without their informed consent is an easy one. And that’s why I don’t put blame on the regulators – they are putting the ethical consensus in law. It gets more complicated if not allowing tracking means some internet services are no longer profitable and therefore can’t exist. Can we have the cake and eat it too?

The post Tracking Cookies and GDPR appeared first on Bozho's tech blog.

Setting Up Cassandra With Priam

Post Syndicated from Bozho original https://techblog.bozho.net/setting-cassandra-priam/

I’ve previously explained how to setup Cassandra in AWS. The described setup works, but in some cases it may not be sufficient. E.g. it doesn’t give you an easy way to make and restore backups, and adding new nodes relies on a custom python script that randomly selects a seed.

So now I’m going to explain how to setup Priam, a Cassandra helper tool by Netflix.

My main reason for setting it up is the backup/restore functionality that it offers. All other ways to do backups are very tedious, and Priam happens to have implemented the important bits – the snapshotting and the incremental backups.

Priam is a bit tricky to get running, though. The setup guide is not too detailed and not easy to find (it’s the last, not immediately visible item in the wiki). First, it has one branch per Cassandra version, so you have to checkout the proper branch and build it. I immediately hit an issue there, as their naming doesn’t allow eclipse to import the gradle project. Within 24 hours I reported 3 issues, which isn’t ideal. Priam doesn’t support dynamic SimpleDB names, and doesn’t let you override bundled properties via the command line. I hope there aren’t bigger issues. The ones that I encountered, I fixed and made a pull request.

What does the setup look like?

  • Append a javaagent to the JVM options
  • Run the Priam web
  • It automatically replaces most of cassandra.yaml, including the seed provider (i.e. how does the node find other nodes in the cluster)
  • Run Cassandra
  • It fetches seed information (which is stored in AWS SimpleDB) and connects to a cluster

I decided to run the war file with a standalone jetty runner, rather than installing tomcat. In terms of shell scripts, the core bits look like that (in addition to the shell script in the original post that is run on initialization of the node):

# Get the Priam war file and jar file
aws s3 cp s3://$BUCKET_NAME/priam-web-3.12.0-SNAPSHOT.war ~/
aws s3 cp s3://$BUCKET_NAME/priam-cass-extensions-3.12.0-SNAPSHOT.jar /usr/share/cassandra/lib/priam-cass-extensions.jar
# Set the Priam agent
echo "-javaagent:/usr/share/cassandra/lib/priam-cass-extensions.jar" >> /etc/cassandra/conf/jvm.options

# Download jetty-runner to be able to run the Priam war file from the command line
wget http://central.maven.org/maven2/org/eclipse/jetty/jetty-runner/9.4.8.v20171121/jetty-runner-9.4.8.v20171121.jar
nohup java -Dpriam.clustername=LogSentinelCluster -Dpriam.sdb.instanceIdentity.region=$EC2_REGION -Dpriam.s3.bucket=$BACKUP_BUCKET \
-Dpriam.sdb.instanceidentity.domain=$INSTANCE_IDENTITY_DOMAIN -Dpriam.sdb.properties.domain=$PROPERTIES_DOMAIN \
-Dpriam.client.sslEnabled=true -Dpriam.internodeEncryption=all -Dpriam.rpc.server.type=sync \
-Dpriam.partitioner=org.apache.cassandra.dht.Murmur3Partitioner -Dpriam.backup.retention.days=7 \
-Dpriam.backup.hour=$BACKUP_HOUR -Dpriam.vnodes.numTokens=256 -Dpriam.thrift.enabled=false \
-jar jetty-runner-9.4.8.v20171121.jar --path /Priam ~/priam-web-3.12.0-SNAPSHOT.war &

while ! echo exit | nc $BIND_IP 8080; do sleep 10; done

echo "Started Priam web package"

service cassandra start
chkconfig cassandra on

while ! echo exit | nc $BIND_IP 9042; do sleep 10; done

BACKUP_BUCKET, PROPERTIES_DOMAIN and INSTANCE_DOMAIN are supplied via a CloudFormation script (as we can’t know the exact names in advance – especially for SimpleDB). Note that these properties won’t work in the main repo – I added them in my pull request.

In order for that to work, you need to have the two SimpleDB domains created (e.g. by CloudFormation). It is possible that you could replace SimpleDB with some other data storage (and not rely on AWS), but that’s out of scope for now.

The result of running Priam would be that you have your Cassandra nodes in SimpleDB (you can browse it using this chrome extension as AWS doesn’t offer any UI) and, of course, backups will be automatically created in the backup S3 Bucket.

You can then restore a backup by logging to each node and executing:

curl http://localhost:8080/Priam/REST/v1/restore?daterange=201803180000,201803191200&region=eu-west-1&keyspaces=your_keyspace

You specify the time range for the restore. Still not ideal, as one would hope to have a one-click restore, but much better than rolling out your own backup & restore infrastructure.

One very important note here – vnodes are not supported. My original cluster had a default of 256 vnodes per machine and now it has just 1, because Priam doesn’t support anything other than 1. That’s a pity, since vnodes are the recommended way to setup Cassandra. Apparently Netflix don’t use those, however. There’s a work-in-progress branch for that that was abandoned 5 years ago. Fortunately, there’s a fresh pull request with Vnode support that can be used in conjunction with my pull request from this branch.

Priam replaces some Cassandra defaults with other values so you might want to compare your current setup and the newly generated cassandra.yaml. Overall it doesn’t feel super-production ready, but apparently it is, as Netflix is using it in production.

The post Setting Up Cassandra With Priam appeared first on Bozho's tech blog.

Технологиите изпреварват политиките?

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

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

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

Това изоставане има три аспекта. Първият се отнася до вече съществуващи бизнес модели и практики, които биват променяни с развитието на технологиите. Пример за това са таксиметровите и хотелиерските услуги. Uber и Airbnb не са били възможни преди 10-15 години. И съответно законодателството в тези сфери не ги допуска като възможност – такситата трябва да имат таксиметров апарат и да бъдат жълти, а хотелите трябва да са категоризирани и да отговарят на определени изисквания. Новите технологии позволяват създаването на репутационни системи (например за таксита или хотели), базирани на оценката на потребителите, а не на това какво смята държавата. Съответно законодателството изостава от реалностите и трябва да наваксва.

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

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

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

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

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

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

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

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

Using JWT For Sessions

Post Syndicated from Bozho original https://techblog.bozho.net/using-jwt-sessions/

The topic has been discussed many times, on hacker news, reddit, blogs. And the consensus is – DON’T USE JWT (for user sessions).

And I largely agree with the criticism of typical arguments for the JWT, the typical “but I can make it work…” explanations and the flaws of the JWT standard..

I won’t repeat everything here, so please go and read those articles. You can really shoot yourself in the foot with JWT, it’s complex to get to know it well and it has little benefits for most of the usecases. I guess for API calls it makes sense, especially if you reuse the same API in a single-page application and for your RESTful clients, but I’ll focus on the user session usecase.

Having all this criticism, I’ve gone against what the articles above recommend, and use JWT, navigating through their arguments and claiming I’m in a sweet spot. I can very well be wrong.

I store the user ID in a JWT token stored as a cookie. Not local storage, as that’s problematic. Not the whole state, as I don’t need that may lead to problems (pointed out in the linked articles). In fact, I don’t have any session state apart from the user data, which I think is a good practice.

What I want to avoid in my setup is sharing sessions across nodes. And this is a very compelling reason to not use the session mechanism of your web server/framework. No, you don’t need to have millions of users in order to need your application to run on more than one node. In fact, it should almost always run on (at least) two nodes, because nodes die and you don’t want downtime. Sticky sessions at the load balancer are a solution to that problem but you are just outsourcing the centralized session storage to the load balancer (and some load balancers might not support it). Shared session cache (e.g. memcached, elasticache, hazelcast) is also an option, and many web servers (at least in Java) support pluggable session replication mechanisms, but that introduces another component to the archtecture, another part of the stack to be supported and that can possibly break. It is not necessarily bad, but if there’s a simple way to avoid it, I’d go for it.

In order to avoid shared session storage, you need either the whole session state to be passed in the request/response cycle (as cookie, request parameter, header), or to receive a userId and load the user from the database or a cache. As we’ve learned, the former might be a bad choice. Despite that fact that frameworks like ASP.NET and JSF dump the whole state in the HTML of the page, it doesn’t intuitively sound good.

As for the latter – you may say “ok, if you are going to load the user from the database on every request this is going to be slow and if you use a cache, then why not use the cache for the sessions themselves?”. Well, the cache can be local. Remember we have just a few application nodes. Each node can have a local, in-memory cache for the currently active users. The fact that all nodes will have the same user loaded (after a few requests are routed to them by the load balancer in a round-robin fashion) is not important, as that cache is small. But you won’t have to take any care for replicating it across nodes, taking care of new nodes coming and going from the cluster, dealing with network issues between the nodes, etc. Each application node will be an island not caring about any other application node.

So here goes my first objection to the linked articles – just storing the user identifier in a JWT token is not pointless, as it saves you from session replication.

What about the criticism for the JWT standard and the security implications of its cryptography? Entirely correct, it’s easy to shoot yourself in the foot. That’s why I’m using JWT only with MAC, and only with a particular algorithm that I verify upon receiving the token, thus (allegedly) avoiding all the pitfalls. In all fairness, I’m willing to use the alternative proposed in one of the articles – PASETO – but it doesn’t have a Java library and it will take some time implementing one (might do in the future). To summarize – if there was another easy to use way for authenticated encryption of cookies, I’d use it.

So I’m basically using JWT in “PASETO-mode”, with only one operation and only one algorithm. And that should be fine as a general approach – the article doesn’t criticize the idea of having a user identifier in a token (and a stateless application node), it criticizes the complexity and vulnerabilities of the standard. This is sort of my second objection – “Don’t use JWT” is widely understood to mean “Don’t use tokens”, where that is not the case.

Have I introduced some vulnerability in my strive for architectural simplicity and lack of shared state? I hope not.

The post Using JWT For Sessions appeared first on Bozho's tech blog.

Накратко за киберсигурността

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

През уикенда се проведе събитие в рамките на „Български манифест за Европа“ на тема „Европейски съюз за отбрана и сигурност и неговите черноморски измерения“

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

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

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

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

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

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

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

Критика към анализа на ЦИК за електронното гласуване

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

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

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

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

Чиповете в картите (на естонците) са пробити и това компрометира гласуването

Да, имаше много неприятен бъг в един модел чипове на Infineon, който на практика позволява да се постави електронен подпис (което включва подаване на глас) от ваше име без вие да разберете. Няколко детайла, обаче:

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

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

„Франция прекрати електронното гласуване“

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

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

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

Ето някои откъси от доклада:

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

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

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

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

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

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

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

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

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

С квалифициран електронен подпис, обаче, разполагат сравнително малко на брой граждани

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

Реализацията на проект „Изграждане и внедряване на система за дистанционно електронно гласуване“ [..] проект „Развитие на пилотната система за електронна идентификация и внедряване в продуктивен режим“ [..] и проект “Реализиране на ЦАИС „Гражданска регистрация“ и ЦАИС „Адресен регистър“ [..] трябва да се разглеждат в съвкупност и дейностите по тях да се синхронизират, защото са взаимно свързани. Ако се разглеждат и се развиват поотделно, няма да се получи единна, работеща система. Ето защо в дейност 2 на проекта с бенефициент ДАЕУ и партньор ЦИК е заложено, че системата за дистанционно електронно гласуване трябва да е синхронизирана с националната система за електронна идентификация и Национална база данни „Население“, съответно с ЦАИС „Гражданска регистрация“

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

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

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

В последната точка от анализа си ЦИК предават на практика думите на проф. Константинов, които адресирах по-горе.

Тези критики реално променят анализа и поради това ще опитам да ги сведа до знанието на ЦИК максимално бързо. Съветът ми би бил да се публикува допълнение към анализа с някои уточнения и разглеждане на различни хипотези, така че Народното събрание да не се окаже (или да не се оправдае, че е) подведено.

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

Adding Visible Electronic Signatures To PDFs

Post Syndicated from Bozho original https://techblog.bozho.net/adding-visible-electronic-signatures-pdf/

I’m aware this is going to be a very niche topic. Electronically signing PDFs is far from a mainstream usecase. However, I’ll write it for two reasons – first, I think it will be very useful for those few who actually need it, and second, I think it will become more and more common as the eIDAS regulation gain popularity – it basically says that electronic signatures are recognized everywhere in Europe (now, it’s not exactly true, because of some boring legal details, but anyway).

So, what is the usecase – first, you have to electronically sign the PDF with an a digital signature (the legal term is “electronic signature”, so I’ll use them interchangeably, although they don’t fully match – e.g. any electronic data applied to other data can be seen as an electronic signature, where a digital signature is the PKI-based signature).

Second, you may want to actually display the signature on the pages, rather than have the PDF reader recognize it and show it in some side-panel. Why is that? Because people are used to seeing signatures on pages and some may insist on having the signature visible (true story – I’ve got a comment that a detached signature “is not a REAL electronic signature, because it’s not visible on the page”).

Now, notice that I wrote “pages”, on “page”. Yes, an electronic document doesn’t have pages – it’s a stream of bytes. So having the signature just on the last page is okay. But, again, people are used to signing all pages, so they’d prefer the electronic signature to be visible on all pages.

And that makes the task tricky – PDF is good with having a digital signature box on the last page, but having multiple such boxes doesn’t work well. Therefore one has to add other types of annotations that look like a signature box and when clicked open the signature panel (just like an actual signature box).

I have to introduce here DSS – a wonderful set of components by the European Commission that can be used to sign and validate all sorts of electronic signatures. It’s open source, you can use at any way you like. Deploy the demo application, use only the libraries, whatever. It includes the signing functionality out of the box – just check the PAdESService or the PDFBoxSignatureService. It even includes the option to visualize the signature once (on a particular page).

However, it doesn’t have the option to show “stamps” (images) on multiple pages. Which is why I forked it and implemented the functionality. Most of my changes are in the PDFBoxSignatureService in the loadAndStampDocument(..) method. If you want to use that functionality you can just build a jar from my fork and use it (by passing the appropriate SignatureImageParameters to PAdESSErvice.sign(..) to define how the signature will look like).

Why is this needed in the first place? Because when a document is signed, you cannot modify it anymore, as you will change the hash. However, PDFs have incremental updates which allow appending to the document and thus having a newer version without modifying anything in the original version. That way the signature is still valid (the originally signed content is not modified), but new stuff is added. In our case, this new stuff is some “annotations”, which represent an image and a clickable area that opens the signature panel (in Adobe Reader at least). And while they are added before the signature box is added, if there are more than one signer, then the 2nd signer’s annotations are added after the first signature.

Sadly, PDFBox doesn’t support that out of the box. Well, it almost does – the piece of code below looks hacky, and it took a while to figure what exactly should be called and when, but it works with just a single reflection call:

    for (PDPage page : pdDocument.getPages()) {
        // reset existing annotations (needed in order to have the stamps added)
        page.setAnnotations(null);
    }
    // reset document outline (needed in order to have the stamps added)
    pdDocument.getDocumentCatalog().setDocumentOutline(null);
    List<PDAnnotation> annotations = addStamps(pdDocument, parameters);
			
    setDocumentId(parameters, pdDocument);
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    try (COSWriter writer = new COSWriter(baos, new RandomAccessBuffer(pdfBytes))) {
        // force-add the annotations (wouldn't be saved in incremental updates otherwise)
        annotations.forEach(ann -> addObjectToWrite(writer, ann.getCOSObject()));
				
        // technically the same as saveIncremental but with more control
        writer.write(pdDocument);
    }
    pdDocument.close();
    pdDocument = PDDocument.load(baos.toByteArray());
    ...
}

private void addObjectToWrite(COSWriter writer, COSDictionary cosObject) {
    // the COSWriter does not expose the addObjectToWrite method, so we need reflection to add the annotations
    try {
        Method method = writer.getClass().getDeclaredMethod("addObjectToWrite", COSBase.class);
        method.setAccessible(true);
        method.invoke(writer, cosObject);
    } catch (Exception ex) {
        throw new RuntimeException(ex);
    }
}

What it does is – loads the original PDF, clears some internal catalogs, adds the annotations (images) to all pages, and then “force-add the annotations” because they “wouldn’t be saved in incremental updates otherwise”. I hope PDFBox make this a little more straightforward, but for the time being this works, and it doesn’t invalidate the existing signatures.

I hope that this posts introduces you to:

  • the existence of legally binding electronic signatures
  • the existence of the DSS utilities
  • the PAdES standard for PDF signing
  • how to place more than just one signature box in a PDF document

And I hope this article becomes more and more popular over time, as more and more businesses realize they could make use of electronic signatures.

The post Adding Visible Electronic Signatures To PDFs appeared first on Bozho's tech blog.

Integration With Zapier

Post Syndicated from Bozho original https://techblog.bozho.net/integration-with-zapier/

Integration is boring. And also inevitable. But I won’t be writing about enterprise integration patterns. Instead, I’ll explain how to create an app for integration with Zapier.

What is Zapier? It is a service that allows you tо connect two (or more) otherwise unconnected services via their APIs (or protocols). You can do stuff like “Create a Trello task from an Evernote note”, “publish new RSS items to Facebook”, “append new emails to a spreadsheet”, “post approaching calendar meeting to Slack”, “Save big email attachments to Dropbox”, “tweet all instagrams above a certain likes threshold”, and so on. In fact, it looks to cover mostly the same usecases as another famous service that I really like – IFTTT (if this then that), with my favourite use-case “Get a notification when the international space station passes over your house”. And all of those interactions can be configured via a UI.

Now that’s good for end users but what does it have to do with software development and integration? Zapier (unlike IFTTT, unfortunately), allows custom 3rd party services to be included. So if you have a service of your own, you can create an “app” and allow users to integrate your service with all the other 3rd party services. IFTTT offers a way to invoke web endpoints (including RESTful services), but it doesn’t allow setting headers, so that makes it quite limited for actual APIs.

In this post I’ll briefly explain how to write a custom Zapier app and then will discuss where services like Zapier stand from an architecture perspective.

The thing that I needed it for – to be able to integrate LogSentinel with any of the third parties available through Zapier, i.e. to store audit logs for events that happen in all those 3rd party systems. So how do I do that? There’s a tutorial that makes it look simple. And it is, with a few catches.

First, there are two tutorials – one in GitHub and one on Zapier’s website. And they differ slightly, which becomes tricky in some cases.

I initially followed the GitHub tutorial and had my build fail. It claimed the zapier platform dependency is missing. After I compared it with the example apps, I found out there’s a caret in front of the zapier platform dependency. Removing it just yielded another error – that my node version should be exactly 6.10.2. Why?

The Zapier CLI requires you have exactly version 6.10.2 installed. You’ll see errors and will be unable to proceed otherwise.

It appears that they are using AWS Lambda which is stuck on Node 6.10.2 (actually – it’s 6.10.3 when you check). The current major release is 8, so minus points for choosing … javascript for a command-line tool and for building sandboxed apps. Maybe other decisions had their downsides as well, I won’t be speculating. Maybe it’s just my dislike for dynamic languages.

So, after you make sure you have the correct old version on node, you call zapier init and make sure there are no carets, npm install and then zapier test. So far so good, you have a dummy app. Now how do you make a RESTful call to your service?

Zapier splits the programmable entities in two – “triggers” and “creates”. A trigger is the event that triggers the whole app, an a “create” is what happens as a result. In my case, my app doesn’t publish any triggers, it only accepts input, so I won’t be mentioning triggers (though they seem easy). You configure all of the elements in index.js (e.g. this one):

const log = require('./creates/log');
....
creates: {
    [log.key]: log,
}

The log.js file itself is the interesting bit – there you specify all the parameters that should be passed to your API call, as well as making the API call itself:

const log = (z, bundle) => {
  const responsePromise = z.request({
    method: 'POST',
    url: `https://api.logsentinel.com/api/log/${bundle.inputData.actorId}/${bundle.inputData.action}`,
    body: bundle.inputData.details,
	headers: {
		'Accept': 'application/json'
	}
  });
  return responsePromise
    .then(response => JSON.parse(response.content));
};

module.exports = {
  key: 'log-entry',
  noun: 'Log entry',

  display: {
    label: 'Log',
    description: 'Log an audit trail entry'
  },

  operation: {
    inputFields: [
      {key: 'actorId', label:'ActorID', required: true},
      {key: 'action', label:'Action', required: true},
      {key: 'details', label:'Details', required: false}
    ],
    perform: log
  }
};

You can pass the input parameters to your API call, and it’s as simple as that. The user can then specify which parameters from the source (“trigger”) should be mapped to each of your parameters. In an example zap, I used an email trigger and passed the sender as actorId, the sibject as “action” and the body of the email as details.

There’s one more thing – authentication. Authentication can be done in many ways. Some services offer OAuth, others – HTTP Basic or other custom forms of authentication. There is a section in the documentation about all the options. In my case it was (almost) an HTTP Basic auth. My initial thought was to just supply the credentials as parameters (which you just hardcode rather than map to trigger parameters). That may work, but it’s not the canonical way. You should configure “authentication”, as it triggers a friendly UI for the user.

You include authentication.js (which has the fields your authentication requires) and then pre-process requests by adding a header (in index.js):

const authentication = require('./authentication');

const includeAuthHeaders = (request, z, bundle) => {
  if (bundle.authData.organizationId) {
	request.headers = request.headers || {};
	request.headers['Application-Id'] = bundle.authData.applicationId
	const basicHash = Buffer(`${bundle.authData.organizationId}:${bundle.authData.apiSecret}`).toString('base64');
	request.headers['Authorization'] = `Basic ${basicHash}`;
  }
  return request;
};

const App = {
  // This is just shorthand to reference the installed dependencies you have. Zapier will
  // need to know these before we can upload
  version: require('./package.json').version,
  platformVersion: require('zapier-platform-core').version,
  authentication: authentication,
  
  // beforeRequest & afterResponse are optional hooks into the provided HTTP client
  beforeRequest: [
	includeAuthHeaders
  ]
...
}

And then you zapier push your app and you can test it. It doesn’t automatically go live, as you have to invite people to try it and use it first, but in many cases that’s sufficient (i.e. using Zapier when doing integration with a particular client)

Can Zapier can be used for any integration problem? Unlikely – it’s pretty limited and simple, but that’s also a strength. You can, in half a day, make your service integrate with thousands of others for the most typical use-cases. And not that although it’s meant for integrating public services rather than for enterprise integration (where you make multiple internal systems talk to each other), as an increasing number of systems rely on 3rd party services, it could find home in an enterprise system, replacing some functions of an ESB.

Effectively, such services (Zapier, IFTTT) are “Simple ESB-as-a-service”. You go to a UI, fill a bunch of fields, and you get systems talking to each other without touching the systems themselves. I’m not a big fan of ESBs, mostly because they become harder to support with time. But minimalist, external ones might be applicable in certain situations. And while such services are primarily aimed at end users, they could be a useful bit in an enterprise architecture that relies on 3rd party services.

Whether it could process the required load, whether an organization is willing to let its data flow through a 3rd party provider (which may store the intermediate parameters), is a question that should be answered in a case by cases basis. I wouldn’t recommend it as a general solution, but it’s certainly an option to consider.

The post Integration With Zapier appeared first on Bozho's tech blog.