All posts by Bozho

Fix Your Crawler

Post Syndicated from Bozho original https://techblog.bozho.net/fix-your-crawler/

Every now and then I open the admin panel of my blog hosting and ban a few IPs (after I’ve tried messaging their abuse email, if I find one). It is always IPs that are generating tons of requests (and traffic) – most likely running some home-made crawler. In some cases the IPs belong to an actual service that captures and provides content, in other cases it’s just a scraper for unknown reasons.

I don’t want to ban IPs, especially because that same IP may be reassigned to a legitimate user (or network) in the future. But they are increasing my hosting usage, which in turn leads to the hosting provider suggesting an upgrade in the plan. And this is not about me, I’m just an example – tons of requests to millions of sites are … useless.

My advice (and plea) is this – please fix your crawlers. Or scrapers. Or whatever you prefer to call that thing that programmatically goes on websites and gets their content.

How? First, reuse an existing crawler. No need to make something new (unless there’s a very specific use-case). A good intro and comparison can be seen here.

Second, make your crawler “polite” (the “politeness” property in the article above). Here’s a good overview on how to be polite, including respect for robots.txt. Existing implementations most likely have politeness options, but you may have to configure them.

Here I’d suggest another option – set a dynamic crawl rate per website that depends on how often the content is updated. My blog updates 3 times a month – no need to crawl it more than once or twice a day. TechCrunch updates many times a day; it’s probably a good idea to crawl it way more often. I don’t have a formula, but you can come up with one that ends up crawling different sites with periods between 2 minutes and 1 day.

Third, don’t “scrape” the content if a better protocol is supported. Many content websites have RSS – use that instead of the HTML of the page. If not, make use of sitemaps. If the WebSub protocol gains traction, you can avoid the crawling/scraping entirely and get notified on new content.

Finally, make sure your crawler/scraper is identifiable by the UserAgent. You can supply your service name or web address in it to make it easier for website owners to find you and complain in case you’ve misconfigured something.

I guess it makes sense to see if using a service like import.io, ScrapingHub, WrapAPI or GetData makes sense for your usecase, instead of reinventing the wheel.

No matter what your use case or approach is, please make sure you don’t put unnecessary pressure on others’ websites.

The post Fix Your Crawler appeared first on Bozho's tech blog.

TEDx: Гражданската активност като инвестиция

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

Бях поканен на TEDxVarna през есента и реших да превърна тази публикация за гражданската активност като инвестиция в презентация/лекция/talk (коя е най-подходящата дума?).

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

Ето видеото:

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

Как да допуснем услуги като Uber? [законопроект]

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

Съдът в Люксембург реши, че Uber е транспортна компания и предоставя таксиметрови услуги. Това е проблем не само за Uber, а за всички по-съвременни начини да предоставяш транспортна услуга, в това число децентрализирани варианти (например чрез блокчейн, въпреки целия ми скептицизъм към публичните такива).

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

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

Поради всичко това реших да напиша законопроект за изменение и допълнение на Закона за автомобилните превози. Докато пишех черновата, видях, че Естония вече е направила нещо такова, с доста сходен подход. Основните цели са:

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

Последните две точки са пожелателни, но според мен принципно важни. Ето и самият текст, с мотиви към всеки параграф:

Закон за изменение и допълнение на Закона за автомобилните превози

§1. В чл. 12а се правят следните изменения и допълнения:
1. В ал. 1, т.5 се изменя както следва: „Данни за моторните превозни средства, с които превозвачът извършва превозите:
а) регистрационен номер
б) дали автомобилът ще извършва таксиметров превоз единствено при повикване чрез диспечерска система
в) общините, в които моторното превозно средство ще извършва превози
2. Ал. 2 се отменя;
3. Създава се нова ал. 6: „(6) Заявления за вписване и за промяна на обстоятелства в регистъра, могат да се подават по автоматизирано и по електронен път по реда на Закона за електронното управление“
4. Създава се нова ал. 7: „(7) Обстоятелства за регистрираните автомобили, определени с наредбата по ал. 5, се извличат автоматично на база на регистрационния номер от националния регистър на пътните превозни средства по реда на Закона за електронното управление“
5. Създава се нова ал. 8: „(8) Изпълнителна агенция „Автомобилна администрация“ извъшва автоматизирани проверки за платен данък за таксиметров превоз на пътници и заличава вписаните в регистъра моторни превозни средства, за които данъкът не е платен за съответната година“
6. Създава се нова ал. 9: „(9) Изискванията към външния вид на автомобилите, които са регистрирани за извършване на таксиметров превоз единствено при повикване чрез диспечерска система могат да са различни от тези за останалите автомобили“
7. Създава се нова ал. 10: „(10) Автомобилите, които са регистрирани за извършване на таксиметров превоз единствено при повикване чрез диспечерска система, нямат право да престояват на местата, обозначени за престояване на таксиметрови автомобили“

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

§2. В чл. 24 се правят следните изменения и допълнения:
1. в ал. 1 след думите „електронен таксиметров апарат с фискална памет“ се добавят думите „или по други начини, позволяващи точно измерване на разстояние и отчитане пред данъчната администрация“, а думите „след издаване на разшрение за таксиметров превоз на пътници“ се заменят с думите „след вписване в регистрите по чл. 12, ал. 2 и по ал. 3, т.5“.
2. в ал. 3, т.5 изменя така: „Вписан е в регистър на водачи, извършващи таксиметров превоз, воден от председателя на Изпълнителна агенция „Автомобилна администрация“
3. ал. 4 се изменя така: „Ръководителят на съответното регионално звено на Изпълнителна агенция „Автомобилна администрация“ вписва лицата, отговарящи на изискванията по ал. 3, т. 1-4 и е декларирало, че се е запознало с обучителна информация, определена с наредбата по чл. 12а, ал. 5. Вписването се подновява на всеки 5 години по заявление на водача.
4. ал. 5 се отменя.
5. ал. 6 се изменя така: „Редът за вписването и подновяването на вписването в регистъра на водачите, извършващи таксиметров превоз, и за доказване на съответствието с изискванията по ал. 3, т. 1-4 се определя с наредбата по чл. 12а, ал. 5., като обстоятелствата, необходими за доказване на изискванията, се събират по служебен път“
6. в ал. 17 думите „отнема със заповед удостоверението на водач на лек таксиметров автомобил“ се заменят с думите „заличава вписването на водач, извършващ таксиметрови превоз“

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

§3. В чл. 24а се правят следните изменения и допълнения:
1. ал. 1 се изменя така: „Водач, вписан в регистъра на водачи, извършващи таксиметров превоз, имат право да извършват такъв с всеки автомобил, вписан в регистъра по чл. 12, ал. 2 в рамките на общините, за които е валидно вписването“
2. ал. 2-9 се отменят
3. ал. 10 се изменя така: „Административните органи нямат право да определят ограничения на броя таксиметрови автомобили, опериращи на територията на дадена община“
4. ал. 11 се изменяе така: „Общинските съвети могат да определят минимални и максимални цени за таксиметров превоз на пътници за един километър пробег и за една минута престой по съответната тарифа, валидни за територията на съответната община“

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

§4. В чл. 24б след думите „таксиметровите апарати“ се добавят думите „или другите допустими технологични средства“

Мотиви: с наредба се определят и условията за използване и отчитане на други технологични средства, например GPS устройства.

§5. В чл. 95, се правят следните допълнения:
1. В ал. 1 след думите „таксиметров апарат“ се добавят думите „или друго допустимо технологично средство за отчитане на разстояние“
2. В ал. 2 се създава нова т.3: „3. извършва таксиметрови услуги в община, за която автомобилът, който управлява, не е регистриран в регистъра по чл. 12, ал 2“
§6. В чл. 96, ал. 4 след думите „таксиметров апарат“ се добавят думите „или друго допустимо технологично средство за отчитане на разстояние“

Разбира се, по-сложната част ще бъде коригирането на наредбите след това, включително намирането на начин за признаване на GPS координатите – ясно е, че както такситата имат „помпички“, така и GPS-ите на телефоните могат да бъдат „лъгани“.

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

Има ли проблем с приетия от правителство план за управление на Пирин?

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

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

В правителствената информационна система още не са качили документите (обикновено го правят с малко закъснение), но все пак на сайта на правителството има качен проектът на решението: ето тук http://www.government.bg/fce/001/0228/files/T_13.doc . Правя уговорката, че това не е приетото решение, та може да има корекции в последния момент (случват се такива неща с подмяна на листчета в папки минути преди заседание).
Действащият план за управление, който се изменя, е тук (важната част започва от стр. 182): http://pirin.bg/wp-content/uploads/2017/07/Plan-za-uprav.pdf

Промените правят общо взето едно нещо: разрешава се строителството на ски писти и съоръжения в т.нар. „зона за строителство“ и „зона за туризъм“, които са 0,6%+2,2% от територията на парка. Строителството става само след екологична оценка (или поне така пише; дали такава няма да бъде правена проформа е друг въпрос)

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

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

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

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

Тук трябва да се добави и решение на ВАС (Решение № 7214 от 2.10.2001), че ски зоната включва „съоръжения за обслужване на посетители“. Решението е спорно, обаче, тъй като приема, че законът допуска строеж на спортни и други съоръжения, но законът предвижда само техния ремонт. Което тълкуване пък се потвърждава от решение на ВАС по друг казус (№6883 от 09.06.2008 г. на ВАС по адм. д. № 4543 / 2008).

Та, в заключение:
– Зона IIa няма как да е допустима за строителство на писти и лифтове, а ако такова е било намерението, то не е било реализирано, тъй като в текста липсва.
– Измененият план противоречи на чл. 21 от Закона за защитените територии, тъй като позволява строителство на съоръжения, които законът не допуска.

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

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

Така че протестът е обоснован и той е протест както за Пирин, така и за законност.

(Заб.: сега навлизам в темата с Пирин, така че моля коригирайте грешни допускания и заключения, ако видите такива.)

OWASP Dependency Check Maven Plugin – a Must-Have

Post Syndicated from Bozho original https://techblog.bozho.net/owasp-dependency-check-maven-plugin-must/

I have to admit with a high degree of shame that I didn’t know about the OWASP dependency check maven plugin. And seems to have been around since 2013. And apparently a thousand projects on GitHub are using it already.

In the past I’ve gone manually through dependencies to check them against vulnerability databases, or in many cases I was just blissfully ignorant about any vulnerabilities that my dependencies had.

The purpose of this post is just that – to recommend the OWASP dependency check maven plugin as a must-have in practically every maven project. (There are dependency-check tools for other build systems as well).

When you add the plugin it generates a report. Initially you can go and manually upgrade the problematic dependencies (I upgraded two of those in my current project), or suppress the false positives (e.g. the cassandra library is marked as vulnerable, whereas the actual vulnerability is that Cassandra binds an unauthenticated RMI endpoint, which I’ve addressed via my stack setup, so the library isn’t an issue).

Then you can configure a threshold for vulnerabilities and fail the build if new ones appear – either by you adding a vulnerable dependency, or in case a vulnerability is discovered in an existing dependency.

All of that is shown in the examples page and is pretty straightforward. I’d suggest adding the plugin immediately, it’s a must-have:

<plugin>
	<groupId>org.owasp</groupId>
	<artifactId>dependency-check-maven</artifactId>
	<version>3.0.2</version>
	<executions>
		<execution>
			<goals>
				<goal>check</goal>
			</goals>
		</execution>
	</executions>
</plugin>

Now, checking dependencies for vulnerabilities is just one small aspect of having your software secure and it shouldn’t give you a false sense of security (a sort-of “I have my dependencies checked, therefore my system is secure” fallacy). But it’s an important aspect. And having that check automated is a huge gain.

The post OWASP Dependency Check Maven Plugin – a Must-Have appeared first on Bozho's tech blog.

Политики, основани на данни [презентация]

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

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

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

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

Видеото можете да видите тук:

А слайдовете – тук:

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

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

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

Using Trusted Timestamping With Java

Post Syndicated from Bozho original https://techblog.bozho.net/using-trusted-timestamping-java/

Trusted timestamping is the process of having a trusted third party (“Time stamping authority”, TSA) certify the time of a given event in electronic form. The EU regulation eIDAS gives these timestamps legal strength – i.e. nobody can dispute the time or the content of the event if it was timestamped. It is applicable to multiple scenarios, including timestamping audit logs. (Note: timestamping is not sufficient for a good audit trail as it does not prevent a malicious actor from deleting the event altogether)

There are a number of standards for trusted timestamping, the core one being RFC 3161. As most RFCs it is hard to read. Fortunately for Java users, BouncyCastle implements the standard. Unfortunately, as with most security APIs, working with it is hard, even abysmal. I had to implement it, so I’ll share the code needed to timestamp data.

The whole gist can be found here, but I’ll try to explain the main flow. Obviously, there is a lot of code that’s there to simply follow the standard. The BouncyCastle classes are a maze that’s hard to navigate.

The main method is obviously timestamp(hash, tsaURL, username, password):

public TimestampResponseDto timestamp(byte[] hash, String tsaUrl, String tsaUsername, String tsaPassword) throws IOException {
    MessageImprint imprint = new MessageImprint(sha512oid, hash);

    TimeStampReq request = new TimeStampReq(imprint, null, new ASN1Integer(random.nextLong()),
            ASN1Boolean.TRUE, null);

    byte[] body = request.getEncoded();
    try {
        byte[] responseBytes = getTSAResponse(body, tsaUrl, tsaUsername, tsaPassword);

        ASN1StreamParser asn1Sp = new ASN1StreamParser(responseBytes);
        TimeStampResp tspResp = TimeStampResp.getInstance(asn1Sp.readObject());
        TimeStampResponse tsr = new TimeStampResponse(tspResp);

        checkForErrors(tsaUrl, tsr);

        // validate communication level attributes (RFC 3161 PKIStatus)
        tsr.validate(new TimeStampRequest(request));

        TimeStampToken token = tsr.getTimeStampToken();
            
        TimestampResponseDto response = new TimestampResponseDto();
        response.setTime(getSigningTime(token.getSignedAttributes()));
        response.setEncodedToken(Base64.getEncoder().encodeToString(token.getEncoded()));
           
        return response;
    } catch (RestClientException | TSPException | CMSException | OperatorCreationException | GeneralSecurityException e) {
        throw new IOException(e);
    }
}

It prepares the request by creating the message imprint. Note that you are passing the hash itself, but also the hashing algorithm used to make the hash. Why isn’t the API hiding that from you, I don’t know. In my case the hash is obtained in a more complicated way, so it’s useful, but still. Then we get the raw form of the request and send it to the TSA (time stamping authority). It is an HTTP request, sort of simple, but you have to take care of some request and response headers that are not necessarily consistent across TSAs. The username and password are optional, some TSAs offer the service (rate-limited) without authentication.

When you have the raw response back, you parse it to a TimeStampResponse. Again, you have to go through 2 intermediate objects (ASN1StreamParser and TimeStampResp), which may be a proper abstraction, but is not a usable API.

Then you check if the response was successful, and you also have to validate it – the TSA may have returned a bad response. Ideally all of that could’ve been hidden from you. Validation throws an exception, which in this case I just propagate by wrapping in an IOException.

Finally, you get the token and return the response. The most important thing is the content of the token, which in my case was needed as Base64, so I encode it. It could just be the raw bytes as well. If you want to get any additional data from the token (e.g. the signing time), it’s not that simple; you have to parse the low-level attributes (seen in the gist).

Okay, you have the token now, and you can store it in a database. Occasionally you may want to validate whether timestamps have not been tampered with (which is my usecase). The code is here, and I won’t even try to explain it – it’s a ton of boilerplate that is also accounting for variations in the way TSAs respond (I’ve tried a few). The fact that a DummyCertificate class is needed either means I got something very wrong, or confirms my critique for the BouncyCastle APIs. The DummyCertificate may not be needed for some TSAs, but it is for others, and you actually can’t instantiate it that easily. You need a real certificate to construct it (which is not included in the gist; using the init() method in the next gist you can create the dummy with dummyCertificate = new DummyCertificate(certificateHolder.toASN1Structure());). In my code these are all one class, but for presenting them I decided to split it, hence this little duplication.

Okay, now we can timestamp and validate timestamps. That should be enough; but for testing purposes (or limited internal use) you may want to do the timestamping locally instead of asking a TSA. The code can be found here. It uses spring, but you can instead pass the keystore details as arguments to the init method. You need a JKS store with a keypair and a certificate, and I used KeyStore Explorer to create them. If you are running your application in AWS, you may want to encrypt your keystore using KMS (Key Management Service), and then decrypt it on application load, but that’s out of the scope of this article. For the local timestamping validation works as expected, and for timestamping – instead of calling the external service, just call localTSA.timestamp(req);

How did I get to know which classes to instantiate and which parameters to pass – I don’t remember. Looking at tests, examples, answers, sources. It took a while, and so I’m sharing it, to potentially save some trouble of others.

A list of TSAs you can test with: SafeCreative, FreeTSA, time.centum.pl.

I realize this does not seem applicable to many scenarios, but I would recommend timestamping some critical pieces of your application data. And it is generally useful to have it in your “toolbox”, ready to use, rather than trying to read the standard and battling with BouncyCastle classes for days in order to achieve this allegedly simple task.

The post Using Trusted Timestamping With Java appeared first on Bozho's tech blog.

Пет мита за електронното гласуване

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

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

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

„Много държави го забраниха или се отказаха“ – тук посланието е „всички се отказват от него, ние къде сме тръгнали“. Разбира се, това е невярно. Половината от държавите, които се изреждат, не са и опитвали дистанционно електронно гласуване, а само машинно. И поради машини „черни кутии“ (със затворен код) и висока цена, наистина се отказват от тях. Но когато говорим за дистанционно електронно гласуване, картинката е по-различна. Експертимент, след който не е пристъпено към реално гласуване, е имало в Норвегия. Причината за да не се пристъпи нататък? В официалния доклад техническият проблем е тривиален – функцията за генериране на случайни числа не е била добра. Но по-важният фактор е, че на власт е дошла опозицията (социалистическата партия) и тя е спряла проекта на предишното правителство. Германският Конституционен съд пък е взел решение – експерименти е нямало, та докато нашия Конституционен съд не вземе такова решение за действащия изборен кодекс, нямаме такъв проблем (има решения за предишни текстове в кодекса, но това е по вина на текстовете – новите адресират мотивите на съда). Холандия е забранила машини, не дистанционно електронно, и то по много специфични за конкретната машина съображения, така че не е по темата с дистанционно електронно. „Франция го забрани/се отказа“ също не е вярно. Франция позволява дистанционно електронно гласуване от 2012-та, но конкретно на тазгодишните избори реши да не позволява този канал за гласуване, заради потенциалната руска намеса. Това не значи, че на следващите избори няма да имат електронно гласуване, нито, че решението е било мотивирано с нещо различно от страх. В нашия изборен кодекс тази опция е предвидена – ЦИК може да вземе решение да не прилага дистанционно електронно гласуване, ако мотивира това с технически доклад за неизбежни и непосредствени рискове. Това обаче не е „винаги“. Та, като някой тръгне да ви изрежда държави, които го били „забранили“…не приемайте това като чиста истина.

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

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

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

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

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

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

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

Изхарчени са милиарди за електронно управление?

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

Излязоха данни на БСК за разходите за електронно управление, сравнени с Естония. Изхарчени са милиарди от 2001-ва до 2016-та.

Като цяло данните най-вероятно са верни.

Е, Естония не е похарчила само 50 милиона. Всъщност, притеснително е, че БСК не е проверила тези данни и няма източник (Евростат дава разбивка по функции, но там няма е-управление/информационните технологии). Ето един очевиден източник през Google: https://www.nytimes.com/2014/10/09/business/international/estonians-embrace-life-in-a-digital-world.html (Естония харчи 60 милиона годишно за информационните технологии).

Но да оставим настрана тази грешка – тя прави нещата по-бомбастични, но не прави останалите наблюдения неверни. Всъщност, в доклада, с който внесохме пакета от реформи през 2015-та, имаше почти същите числа. И тогава, след заседание на парламентарната комисия по транспорт, излязоха новини колко много е похарчено. И пак бяхме недоволни за половин ден, и пак ги забравихме.

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

Но важни са причините – похарченото няма да се върне.

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

Другата фундаментална разлика е електронната идентификация. БСК правилно посочват, че естонците имат електронна лична карта от 2001-ва. Според естонският президент това е ключов фактор и без него нищо не става. Затова и прокарахме законови изменения, за да имаме и ние електронна лична карта, макар и 17 години по-късно. През август правителството обаче ги отложи с още една година.

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

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

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

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

Просто начин на мислене. Който не се санкционира на избори, така че продължава да се възпроизвежда.

GDPR – A Practical Guide For Developers

Post Syndicated from Bozho original https://techblog.bozho.net/gdpr-practical-guide-developers/

You’ve probably heard about GDPR. The new European data protection regulation that applies practically to everyone. Especially if you are working in a big company, it’s most likely that there’s already a process for gettign your systems in compliance with the regulation.

The regulation is basically a law that must be followed in all European countries (but also applies to non-EU companies that have users in the EU). In this particular case, it applies to companies that are not registered in Europe, but are having European customers. So that’s most companies. I will not go into yet another “12 facts about GDPR” or “7 myths about GDPR” posts/whitepapers, as they are often aimed at managers or legal people. Instead, I’ll focus on what GDPR means for developers.

Why am I qualified to do that? A few reasons – I was advisor to the deputy prime minister of a EU country, and because of that I’ve been both exposed and myself wrote some legislation. I’m familiar with the “legalese” and how the regulatory framework operates in general. I’m also a privacy advocate and I’ve been writing about GDPR-related stuff in the past, i.e. “before it was cool” (protecting sensitive data, the right to be forgotten). And finally, I’m currently working on a project that (among other things) aims to help with covering some GDPR aspects.

I’ll try to be a bit more comprehensive this time and cover as many aspects of the regulation that concern developers as I can. And while developers will mostly be concerned about how the systems they are working on have to change, it’s not unlikely that a less informed manager storms in in late spring, realizing GDPR is going to be in force tomorrow, asking “what should we do to get our system/website compliant”.

The rights of the user/client (referred to as “data subject” in the regulation) that I think are relevant for developers are: the right to erasure (the right to be forgotten/deleted from the system), right to restriction of processing (you still keep the data, but mark it as “restricted” and don’t touch it without further consent by the user), the right to data portability (the ability to export one’s data), the right to rectification (the ability to get personal data fixed), the right to be informed (getting human-readable information, rather than long terms and conditions), the right of access (the user should be able to see all the data you have about them), the right to data portability (the user should be able to get a machine-readable dump of their data).

Additionally, the relevant basic principles are: data minimization (one should not collect more data than necessary), integrity and confidentiality (all security measures to protect data that you can think of + measures to guarantee that the data has not been inappropriately modified).

Even further, the regulation requires certain processes to be in place within an organization (of more than 250 employees or if a significant amount of data is processed), and those include keeping a record of all types of processing activities carried out, including transfers to processors (3rd parties), which includes cloud service providers. None of the other requirements of the regulation have an exception depending on the organization size, so “I’m small, GDPR does not concern me” is a myth.

It is important to know what “personal data” is. Basically, it’s every piece of data that can be used to uniquely identify a person or data that is about an already identified person. It’s data that the user has explicitly provided, but also data that you have collected about them from either 3rd parties or based on their activities on the site (what they’ve been looking at, what they’ve purchased, etc.)

Having said that, I’ll list a number of features that will have to be implemented and some hints on how to do that, followed by some do’s and don’t’s.

  • “Forget me” – you should have a method that takes a userId and deletes all personal data about that user (in case they have been collected on the basis of consent, and not due to contract enforcement or legal obligation). It is actually useful for integration tests to have that feature (to cleanup after the test), but it may be hard to implement depending on the data model. In a regular data model, deleting a record may be easy, but some foreign keys may be violated. That means you have two options – either make sure you allow nullable foreign keys (for example an order usually has a reference to the user that made it, but when the user requests his data be deleted, you can set the userId to null), or make sure you delete all related data (e.g. via cascades). This may not be desirable, e.g. if the order is used to track available quantities or for accounting purposes. It’s a bit trickier for event-sourcing data models, or in extreme cases, ones that include some sort of blcokchain/hash chain/tamper-evident data structure. With event sourcing you should be able to remove a past event and re-generate intermediate snapshots. For blockchain-like structures – be careful what you put in there and avoid putting personal data of users. There is an option to use a chameleon hash function, but that’s suboptimal. Overall, you must constantly think of how you can delete the personal data. And “our data model doesn’t allow it” isn’t an excuse.
  • Notify 3rd parties for erasure – deleting things from your system may be one thing, but you are also obligated to inform all third parties that you have pushed that data to. So if you have sent personal data to, say, Salesforce, Hubspot, twitter, or any cloud service provider, you should call an API of theirs that allows for the deletion of personal data. If you are such a provider, obviously, your “forget me” endpoint should be exposed. Calling the 3rd party APIs to remove data is not the full story, though. You also have to make sure the information does not appear in search results. Now, that’s tricky, as Google doesn’t have an API for removal, only a manual process. Fortunately, it’s only about public profile pages that are crawlable by Google (and other search engines, okay…), but you still have to take measures. Ideally, you should make the personal data page return a 404 HTTP status, so that it can be removed.
  • Restrict processing – in your admin panel where there’s a list of users, there should be a button “restrict processing”. The user settings page should also have that button. When clicked (after reading the appropriate information), it should mark the profile as restricted. That means it should no longer be visible to the backoffice staff, or publicly. You can implement that with a simple “restricted” flag in the users table and a few if-clasues here and there.
  • Export data – there should be another button – “export data”. When clicked, the user should receive all the data that you hold about them. What exactly is that data – depends on the particular usecase. Usually it’s at least the data that you delete with the “forget me” functionality, but may include additional data (e.g. the orders the user has made may not be delete, but should be included in the dump). The structure of the dump is not strictly defined, but my recommendation would be to reuse schema.org definitions as much as possible, for either JSON or XML. If the data is simple enough, a CSV/XLS export would also be fine. Sometimes data export can take a long time, so the button can trigger a background process, which would then notify the user via email when his data is ready (twitter, for example, does that already – you can request all your tweets and you get them after a while).
  • Allow users to edit their profile – this seems an obvious rule, but it isn’t always followed. Users must be able to fix all data about them, including data that you have collected from other sources (e.g. using a “login with facebook” you may have fetched their name and address). Rule of thumb – all the fields in your “users” table should be editable via the UI. Technically, rectification can be done via a manual support process, but that’s normally more expensive for a business than just having the form to do it. There is one other scenario, however, when you’ve obtained the data from other sources (i.e. the user hasn’t provided their details to you directly). In that case there should still be a page where they can identify somehow (via email and/or sms confirmation) and get access to the data about them.
  • Consent checkboxes – this is in my opinion the biggest change that the regulation brings. “I accept the terms and conditions” would no longer be sufficient to claim that the user has given their consent for processing their data. So, for each particular processing activity there should be a separate checkbox on the registration (or user profile) screen. You should keep these consent checkboxes in separate columns in the database, and let the users withdraw their consent (by unchecking these checkboxes from their profile page – see the previous point). Ideally, these checkboxes should come directly from the register of processing activities (if you keep one). Note that the checkboxes should not be preselected, as this does not count as “consent”.
  • Re-request consent – if the consent users have given was not clear (e.g. if they simply agreed to terms & conditions), you’d have to re-obtain that consent. So prepare a functionality for mass-emailing your users to ask them to go to their profile page and check all the checkboxes for the personal data processing activities that you have.
  • “See all my data” – this is very similar to the “Export” button, except data should be displayed in the regular UI of the application rather than an XML/JSON format. For example, Google Maps shows you your location history – all the places that you’ve been to. It is a good implementation of the right to access. (Though Google is very far from perfect when privacy is concerned)
  • Age checks – you should ask for the user’s age, and if the user is a child (below 16), you should ask for parent permission. There’s no clear way how to do that, but my suggestion is to introduce a flow, where the child should specify the email of a parent, who can then confirm. Obviosuly, children will just cheat with their birthdate, or provide a fake parent email, but you will most likely have done your job according to the regulation (this is one of the “wishful thinking” aspects of the regulation).

Now some “do’s”, which are mostly about the technical measures needed to protect personal data. They may be more “ops” than “dev”, but often the application also has to be extended to support them. I’ve listed most of what I could think of in a previous post.

  • Encrypt the data in transit. That means that communication between your application layer and your database (or your message queue, or whatever component you have) should be over TLS. The certificates could be self-signed (and possibly pinned), or you could have an internal CA. Different databases have different configurations, just google “X encrypted connections. Some databases need gossiping among the nodes – that should also be configured to use encryption
  • Encrypt the data at rest – this again depends on the database (some offer table-level encryption), but can also be done on machine-level. E.g. using LUKS. The private key can be stored in your infrastructure, or in some cloud service like AWS KMS.
  • Encrypt your backups – kind of obvious
  • Implement pseudonymisation – the most obvious use-case is when you want to use production data for the test/staging servers. You should change the personal data to some “pseudonym”, so that the people cannot be identified. When you push data for machine learning purposes (to third parties or not), you can also do that. Technically, that could mean that your User object can have a “pseudonymize” method which applies hash+salt/bcrypt/PBKDF2 for some of the data that can be used to identify a person
  • Protect data integrity – this is a very broad thing, and could simply mean “have authentication mechanisms for modifying data”. But you can do something more, even as simple as a checksum, or a more complicated solution (like the one I’m working on). It depends on the stakes, on the way data is accessed, on the particular system, etc. The checksum can be in the form of a hash of all the data in a given database record, which should be updated each time the record is updated through the application. It isn’t a strong guarantee, but it is at least something.
  • Have your GDPR register of processing activities in something other than Excel – Article 30 says that you should keep a record of all the types of activities that you use personal data for. That sounds like bureaucracy, but it may be useful – you will be able to link certain aspects of your application with that register (e.g. the consent checkboxes, or your audit trail records). It wouldn’t take much time to implement a simple register, but the business requirements for that should come from whoever is responsible for the GDPR compliance. But you can advise them that having it in Excel won’t make it easy for you as a developer (imagine having to fetch the excel file internally, so that you can parse it and implement a feature). Such a register could be a microservice/small application deployed separately in your infrastructure.
  • Log access to personal data – every read operation on a personal data record should be logged, so that you know who accessed what and for what purpose
  • Register all API consumers – you shouldn’t allow anonymous API access to personal data. I’d say you should request the organization name and contact person for each API user upon registration, and add those to the data processing register. Note: some have treated article 30 as a requirement to keep an audit log. I don’t think it is saying that – instead it requires 250+ companies to keep a register of the types of processing activities (i.e. what you use the data for). There are other articles in the regulation that imply that keeping an audit log is a best practice (for protecting the integrity of the data as well as to make sure it hasn’t been processed without a valid reason)

Finally, some “don’t’s”.

  • Don’t use data for purposes that the user hasn’t agreed with – that’s supposed to be the spirit of the regulation. If you want to expose a new API to a new type of clients, or you want to use the data for some machine learning, or you decide to add ads to your site based on users’ behaviour, or sell your database to a 3rd party – think twice. I would imagine your register of processing activities could have a button to send notification emails to users to ask them for permission when a new processing activity is added (or if you use a 3rd party register, it should probably give you an API). So upon adding a new processing activity (and adding that to your register), mass email all users from whom you’d like consent.
  • Don’t log personal data – getting rid of the personal data from log files (especially if they are shipped to a 3rd party service) can be tedious or even impossible. So log just identifiers if needed. And make sure old logs files are cleaned up, just in case
  • Don’t put fields on the registration/profile form that you don’t need – it’s always tempting to just throw as many fields as the usability person/designer agrees on, but unless you absolutely need the data for delivering your service, you shouldn’t collect it. Names you should probably always collect, but unless you are delivering something, a home address or phone is unnecessary.
  • Don’t assume 3rd parties are compliant – you are responsible if there’s a data breach in one of the 3rd parties (e.g. “processors”) to which you send personal data. So before you send data via an API to another service, make sure they have at least a basic level of data protection. If they don’t, raise a flag with management.
  • Don’t assume having ISO XXX makes you compliant – information security standards and even personal data standards are a good start and they will probably 70% of what the regulation requires, but they are not sufficient – most of the things listed above are not covered in any of those standards

Overall, the purpose of the regulation is to make you take conscious decisions when processing personal data. It imposes best practices in a legal way. If you follow the above advice and design your data model, storage, data flow , API calls with data protection in mind, then you shouldn’t worry about the huge fines that the regulation prescribes – they are for extreme cases, like Equifax for example. Regulators (data protection authorities) will most likely have some checklists into which you’d have to somehow fit, but if you follow best practices, that shouldn’t be an issue.

I think all of the above features can be implemented in a few weeks by a small team. Be suspicious when a big vendor offers you a generic plug-and-play “GDPR compliance” solution. GDPR is not just about the technical aspects listed above – it does have organizational/process implications. But also be suspicious if a consultant claims GDPR is complicated. It’s not – it relies on a few basic principles that are in fact best practices anyway. Just don’t ignore them.

The post GDPR – A Practical Guide For Developers appeared first on Bozho's tech blog.

Отворено законодателство [лекция]

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

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

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

Видео от лекцията може да видите тук:

А слайдовете са тук:

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

А ако проектът бъде реализиран, ще имаме не просто по-удобно и достъпно законодателство (каквото lex.bg до известна степен дава), но и реализирани компоненти и взети технически решения, чрез които държавата (в лицето или на Народното събрание, или на Министерския съвет) да поддържа законодателството в електронен, машинно-четим вид. А самият законодателен процес да не минава през разпечатване, сканиране и разпращане на doc файлове с 10 цвята в допълнение на track changes, а да бъде структуриран и да позволява съвместна работа на много участници. Това би предполагало технически грамотни депутати, разбира се. Ама и до там ще стигнем все някой ден.

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

The Problem Solver

Post Syndicated from Bozho original https://techblog.bozho.net/the-problem-solver/

I’ll start this post with a quote:

Good developers are good problem solvers. They turn each task into a series of problems they have to solve. They don’t necessarily know how to solve them in advance, but they have their toolbox of approaches, shortcuts and other tricks that lead to the solution. I have outlined one such set of steps for identifying problems, but you can’t easily formalize the problem-solving approach.

But is really turning a task into a set of problems a good idea? Programming can be seen as a creative exercise, rather than a problem solving one – you think, you ponder, you deliberate, then you make something out of nothing and it’s beautiful, because it works. And sometimes programming is that, but that is almost always interrupted by a series of problems that stop you from getting the task completed. That process is best visualized with the following short video:

That’s because most things in software break. They either break because there are unknowns, or because of a lot of unsuspected edge cases, or because the abstraction that we use leaks, or because the tools that we use are poorly documented or have poor APIs/UIs, or simply because of bugs. Or in many cases – all of the above.

So inevitably, we have to learn to solve problems. And solving them quickly and properly is in fact, one might argue, the most important skill when doing software. One should learn, though, not to just patch things up with duct tape, but to come up with the best possible solution with the constraints at hand. The library that you are using is missing a feature you really need? Ideally, you should propose the feature and wait for it to be implemented. Too often that’s not an option. Quick and dirty fix – copy-paste a bunch of code. Proper, elegant solution – use design patterns to adapt the library to your needs, or come up with a generic (but not time-wasting) way of patching libraries. Or there’s a memory leak? Just launch a bigger instance? No. Spend a week live-profiling the application? To slow. Figure out how to simulate the leaking scenario in a local setup and fix it in a day? Sounds ideal, but it’s not trivial.

Sometimes there are not too many problems and development goes smoothly. Then the good problem solver identifies problems proactively – this implementation is slow, this is too memory-consuming, this is overcomplicated and should be refactored. And these can (and should) be small steps that don’t interfere with the development process, leaving you 2 days in deep refactoring for no apparent reason. The skill is to know the limit between gradual improvement and spotting problems before they occur, and wasting time in problems that don’t exist or you’ll never hit.

And finally, solving problems is not a solo exercise. In fact I think one of the most important aspects of problem solving is answering questions. If you want to be a good developer, you have to answer the questions of others. Your colleagues in most cases, but sometimes – total strangers on Stackoverflow. I myself found that answering stackoverflow questions actually turned me into a better problem solver – I could solve others problems in a limited time, with limited information. So in many case I was the go-to person on the team when a problem arises, even though I wasn’t the most senior or the most familiar with the project. But one could reasonably expect that I’ll be able to figure out a proper solution quickly. And then the loop goes on – you answer more questions and get better at problem solving, and so on, and so forth. By the way, we shouldn’t assume we are good unless we are able to solver others’ problems in addition to ours.

Problem-solving is a transferable skill. We might not be developers forever, but our approach to problems, the tenacity in fixing them, and the determination to get things done properly, is useful in many contexts. You could, in fact, view each task, not just programming ones, as a problem-solving exercise. And having the confidence that you can fix it, even though you have never encountered it before, is often priceless.

What’s my ultimate point? We should see ourselves as problem solvers and constantly improve our problem solving toolbox. Which, among other things, includes helping others. Otherwise we are tied to our knowledge of a particular technology or stack, and that’s frankly boring.

The post The Problem Solver appeared first on Bozho's tech blog.

Уличка в дъжда

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

Отдавна не съм публикувал поезия, но ето нещо малко, за разнообразие:

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

Хора във дъжда.
Малки и невзрачни.
Хорица със своя собствен страх.
Щъкат из града
С погледи прозрачни.
С бъдеще обгърнато от прах.

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

I Still Prefer Eclipse Over IntelliJ IDEA

Post Syndicated from Bozho original https://techblog.bozho.net/still-prefer-eclipse-intellij-idea/

Over the years I’ve observed an inevitable shift from Eclipse to IntelliJ IDEA. Last year they were almost equal in usage, and I have the feeling things are swaying even more towards IDEA.

IDEA is like the iPhone of IDEs – its users tell you that “you will feel how much better it is once you get used to it”, “are you STILL using Eclipse??”, “IDEA is so much better, I thought everyone has switched”, etc.

I’ve been using mostly Eclipse for the past 12 years, but in some cases I did use IDEA – when I was writing Scala, when I was writing Android, and most recently – when Eclipse failed to be ready for the Java 9 release, so after half a day of trying to get it working, I just switched to IDEA until Eclipse finally gets a working Java 9 version (with Maven and the rest of the stuff).

But I will get back to Eclipse again, soon. And I still prefer it. Not just because of all the key combinations I’ve internalized (you can reuse those in IDEA), but because there are still things I find worse in IDEA. Of course, IDEA has so much more cool features like code improvement suggestions and actually working plugins for everything. But at least some of the problems I see have to do with the more basic development workflow and experience. And you can’t compensate for those with sugarcoating. So here they are:

  • Projects are not automatically built (by default), so you can end up with compilation errors that you don’t see until you open a non-compiling file or run a build. And turning the autobild on makes my machine crawl. I know I need an upgrade, but that’s not the point – not having “build on change” was a huge surprise to me the first time I tried IDEA. I recently complained about that on twitter and it turns out “it’s a feature”. The rationale seems to be that if you use refactoring, that shouldn’t happen. Well, there are dozens of cases when it does happen. Refactoring by adding a method parameter, by changing the type of a parameter, by removing a parameter (where the IDE can’t infer which parameter is removed based on the types), by changing return types. Also, a change in maven/gradle dependencies may introduces compilation issues that you don’t get to see. This is not a reasonable default at all, and I think the performance issues are the only reason it’s still the default. I think this makes the experience much worse.
  • You can have only one project per screen. Maybe there are those small companies with greenfield projects where you only need one. But I’ve never been in a situation, where you don’t at least occasionally need a separate project. Be it an “experiments” one, a “tools” one, or whatever. And no, multi-module maven projects (which IDEA handles well) are not sufficient. So each time you need to step out of your main project, you launch another screen. Apart from the bad usability, it’s double the memory, double the fun.
  • Speaking of memory, It seems to be taking more memory than Eclipse. I don’t have representative benchmarks of that, and I know that my 8 GB RAM home machine is way to small for development nowadays, but still.
  • It feels less responsive and clunky. There is some minor delay that I can’t define well, but “I feel it”. I read somewhere that they were excessively repainting the screen elements, so that might be the explanation. Eclipse feels smoother (I know that’s not a proper argument, but I can’t be more precise)
  • Due to some extra cleverness, I have “unused methods” and “never assigned fields” all around the project. It uses spring, so these methods and fields are controller methods and autowired fields. Maybe some spring plugin would take care of that, but spring is not the only framework that uses reflection. Even getters and setters on POJOs get the unused warnings. What’s the problem with those warnings? That warnings are devalued. They don’t mean anything now. There isn’t a “yellow” indicator on the class either, so you don’t actually see the amount of warnings you have. Eclipse displays warnings better, and the false positives are much less.
  • The call hierarchy is slightly worse. But since that’s the most important IDE feature for me (alongside refactoring), it matters. It doesn’t give you the call hierarchy of default constructors that are not explicitly defined. Also, from what I’ve seen IDEA users don’t often use the call hierarchy feature. “Find usage” I think predates the call hierarchy, and is also much more visible through the UI, so some of the IDEA users don’t even know what a call hierarchy is. And repeatedly do “find usage”. That’s only partly the IDE’s fault.
  • No search in the output console. Come one, why I do I have an IDE, where I have to copy the output and paste it in a text editor in order to search. Now, to clarify, the console does have search. But when I run my (spring-boot) application, it outputs stuff in a panel at the bottom that is not the console and doesn’t have search.
  • CTRL+arrows by default jumps over whole words, and not camel cased words. This is configurable, but is yet another odd default. You almost always want to be able to traverse your variables word by word (in camel case), rather than skipping over the whole variable (method/class) name.
  • A few years ago when I used it for Scala, the project never actually compiled. But I guess that’s more Scala’s fault than of the IDE

Apart from the first two, the rest are not major issues, I agree. But they add up. Ultimately, it’s a matter of personal choice whether you can turn a blind eye to these issues. But I’m getting back to Eclipse again. At some point I will propose improvements in the IntelliJ IDEA backlog and will check it again in a few years, I guess.

The post I Still Prefer Eclipse Over IntelliJ IDEA appeared first on Bozho's tech blog.

За сексуалните посегателства и ценностите

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

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

Разбира се, немалка част от мъжката част от населението е склонна да подмине всички случаи на сексуални посегателства, разказани в станалия „вайръл“ хештаг #MeТoo. Явно част и от женската, които (за щастие) не са ставали жертва на такива действия. А какви са те – ами всякакви, нежелани от жертвата действия със сексуален елемент.

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

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

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

К: Къде е границата? Не може ли да се натискат хора в дискотека?
О: Може, докато е доброволно. Да, под влияние на алкохола вероятно е по-трудно човек да разбере намеци на несъгласие, но „като се напия ставам свиня“ не е никакво оправдание. Някой като се напие може да взема пушката и да почва да стреля. Границата в някои случаи наистина е трудно да се установи, но тези случаи според мен са сравнително малко.

К: Какво сега, да подписваме декларации за всеки флирт ли?
О: Залитането в крайности е грешно. Граничните случаи, в които е трудно да се определи съгласие, са малко, и няма нужда процесът да бъде бюрократизиран

К: Жените трябва да са по-силни психически, ако искат да имат равни права!
О: Психическата стабилност, т.е. възможността да се справиш с едно такова посегателство без то да ти се отрази и без да те травмира е спектър, а не само две точки „мъж“ и „жена“. Някои са по-чувствителни, други – не. Но това колко си чувствителен по никакъв начин не трябва да влияе върху това какви права имаш. Ако не се съгласим по този въпрос, имаме по-сериозен проблем.

К: Преувеличават, изобщо няма толкова много случаи…
О: Дали е 50%, „всяка трета жена“ или „всяка пета“, разликата не е толкова съществена. На първо място, статистиката няма как да е напълно достоверна, защото много жени не си казват (защо – виж няколко отговора по-нагоре). Но дори и 5 процента да са – това пак е прекалено много. И трябва да посочим проблема, да четем за проблема, да знаем за него. За да не прекрачваме границата, и да не позволяваме прекрачването на границата да бъде „нормално“. А всъщност, всеки познава поне по една жена, която е била жертва на сексуално посегателство (дори да не се е стигнало до насилие).

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

К: С тия истории целят само да придобият популярност
О: Ако ми кажете някой, който „е станал известен като жертвата на Х“, може и да започнем да спорим по тая хипотеза. Но едва ли има такива случаи. Не на последно място, кой точно иска да стане известен с това, че някой го е използвал за сексуално удовлетворение?

К: Те в Африка и някои мюсюлмански държавни са по-зле…
О: Е, и? В Саудитска арабия убиват с камъни, ама това не значи, че е окей ние да убиваме с Итонг (че сме по-развити). Да, в развитите общества жените имат значително повече права и са в много по-добра позиция отколкото в (част от) ислямския свят и в държави от третия свят. Но това не значи, че няма проблеми.

К: Не се ли превръщат тези скандали в лов на вещици?
О: Това винаги е риск. Махалото да отиде в другата посока; покрай сухото да изгори и суровото. Затова не трябва да оставяме нагнетяването на такова напрежение, което да избухне по определен повод. Може би Дъстин Хофман просто има вулгарен език, може би някой друг е имал зле изразени романтични намерения. Но може и да е унижаване от позиция на силния. Може да е сексуално посегателство. Да, социалните мрежи имат способността да заклеймяват прибързано, да демонизират. Но това е друг проблем (че трябва да се научим да ползваме технологиите не като средство за избиване на комплексите си, а за по-удобна комуникация).

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

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

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

Blockchain? It’s All Greek To Me…

Post Syndicated from Bozho original https://techblog.bozho.net/blockchain-its-all-greek-to-me/

The blockchain hype is huge, the ICO craze (“Coindike”) is generating millions if not billions of “funding” for businesses that claim to revolutionize basically anything.

I’ve been following all of that for a while. I got my first (and only) Bitcoin several years ago, I know how the technology works, I’ve implemented the data structure part, I’ve tried (with varying success) to install an Ethereum wallet since almost as soon as Ethereum appeared, and I’ve read and subscribed to newsletters about dozens of projects and new cryptocurrencies, including storj.io, siacoin, namecoin, etc. I would say I’m at least above average in terms of knowledge on how the cryptocurrencies, blockchain, smart contracts, EVM, proof-of-wahtever operates. And I’ve voiced my concerns about the technology in general.

Now it’s rant time.

I’ve been reading whitepapers of various projects, I’ve been to various meetups and talks, I’ve been reading the professed future applications of the blockchain, and I have to admit – it’s all Greek to me. I have no clue what these people are talking about. And why would all of that make any sense. I still think I’m not clever enough to understand the upcoming revolution, but there’s also a cynical side of me that says “this is all a scam”.

Why “X on the blockchain” somehow makes it magical and superior to a good old centralized solution? No, spare me the cliches about “immutable ledger”, “lack of central authority” and the likes. These are the phrases that a person learns after reading literally one article about blockchain. Have you actually written anything apart from a complex-sounding whitepaper or a hello-world smart contract? Do you really know how the overlay network works, how the economic incentives behind that network work, how all the cryptography works? Maybe there are many, many people that indeed know that and they know it better than me and are thus able to imagine the business case behind “X on the blockchain”.

I can’t. I can’t see why it would be useful to abandon a centralized database that you can query in dozens of ways, test easily and scale trivially in favour of a clunky write-only, low-throughput, hard-to-debug privacy nightmare that is any public blockchain. And how do you imagine to gain a substantial userbase with an ecosystem where the Windows client for the 2nd most popular blockchain (Ethereum) has been so buggy, I (a software engineer) couldn’t get it work and sync the whole chain. And why would building a website ontop of that clunky, user-unfriendly database has any benefit over a centralized competitor?

Do we all believe that somehow the huge datacenters with guarnateed power backups, regular hardware and network checks, regular backups and overall – guaranteed redundancy – will somehow be beaten by a few thousand machines hosting a software that has the sole purpose of guaranteeing integrity? Bitcoin has 10 thousand nodes. Ethereum has 22 thousand nodes. And while these nodes are probably very well GPU-equipped, they aren’t supercomputers. Amazon’s AWS has a million servers. How’s that for comparison. And why would anyone take seriously 22 thousand non-servers. Or even 220 thousand, if we believe in some inevitable growth.

Don’t get me wrong, the technology is really cool. The way tamper-evident data structures (hash chains) were combined with a consensus algorithm, an overlay network and a financial incentive is really awesome. When you add a distributed execution environment, it gets even cooler. But is it suitable for literally everything? I fail to see how.

I’m sure I’m missing something. The fact that many of those whitepapers sound increasingly like Greek to me might hint that I’m just a dumb developer and those enlightened people are really onto something huge. I guess time will tell.

But I happen to be living in a country that saw a transition to capitalism in the years of my childhood. And there were a lot of scams and ponzi schemes that people believed in. Because they didn’t know how capitalism works, how the market works. I’m seeing some similarities – we have no idea how the digital realm really works, and so a lot of scams are bound to appear, until we as a society learn the basics.

Until then – enjoy your ICO, enjoy your tokens, enjoy your big-player competitor with practically the same business model, only on a worse database.

And I hope that after the smoke of hype and fraud clears, we’ll be able to enjoy the true benefits of the blockchain innovation.

The post Blockchain? It’s All Greek To Me… appeared first on Bozho's tech blog.

Enabling Two-Factor Authentication For Your Web Application

Post Syndicated from Bozho original https://techblog.bozho.net/enabling-two-factor-authentication-web-application/

It’s almost always a good idea to support two-factor authentication (2FA), especially for back-office systems. 2FA comes in many different forms, some of which include SMS, TOTP, or even hardware tokens.

Enabling them requires a similar flow:

  • The user goes to their profile page (skip this if you want to force 2fa upon registration)
  • Clicks “Enable two-factor authentication”
  • Enters some data to enable the particular 2FA method (phone number, TOTP verification code, etc.)
  • Next time they login, in addition to the username and password, the login form requests the 2nd factor (verification code) and sends that along with the credentials

I will focus on Google Authenticator, which uses a TOTP (Time-based one-time password) for generating a sequence of verification codes. The ideas is that the server and the client application share a secret key. Based on that key and on the current time, both come up with the same code. Of course, clocks are not perfectly synced, so there’s a window of a few codes that the server accepts as valid.

How to implement that with Java (on the server)? Using the GoogleAuth library. The flow is as follows:

  • The user goes to their profile page
  • Clicks “Enable two-factor authentication”
  • The server generates a secret key, stores it as part of the user profile and returns a URL to a QR code
  • The user scans the QR code with their Google Authenticator app thus creating a new profile in the app
  • The user enters the verification code shown the app in a field that has appeared together with the QR code and clicks “confirm”
  • The server marks the 2FA as enabled in the user profile
  • If the user doesn’t scan the code or doesn’t verify the process, the user profile will contain just a orphaned secret key, but won’t be marked as enabled
  • There should be an option to later disable the 2FA from their user profile page

The most important bit from theoretical point of view here is the sharing of the secret key. The crypto is symmetric, so both sides (the authenticator app and the server) have the same key. It is shared via a QR code that the user scans. If an attacker has control on the user’s machine at that point, the secret can be leaked and thus the 2FA – abused by the attacker as well. But that’s not in the threat model – in other words, if the attacker has access to the user’s machine, the damage is already done anyway.

Upon login, the flow is as follows:

  • The user enters username and password and clicks “Login”
  • Using an AJAX request the page asks the server whether this email has 2FA enabled
  • If 2FA is not enabled, just submit the username & password form
  • If 2FA is enabled, the login form is not submitted, but instead an additional field is shown to let the user input the verification code from the authenticator app
  • After the user enters the code and presses login, the form can be submitted. Either using the same login button, or a new “verify” button, or the verification input + button could be an entirely new screen (hiding the username/password inputs).
  • The server then checks again if the user has 2FA enabled and if yes, verifies the verification code. If it matches, login is successful. If not, login fails and the user is allowed to reenter the credentials and the verification code. Note here that you can have different responses depending on whether username/password are wrong or in case the code is wrong. You can also attempt to login prior to even showing the verification code input. That way is arguably better, because that way you don’t reveal to a potential attacker that the user uses 2FA.

While I’m speaking of username and password, that can apply to any other authentication method. After you get a success confirmation from an OAuth / OpenID Connect / SAML provider, or after you can a token from SecureLogin, you can request the second factor (code).

In code, the above processes look as follows (using Spring MVC; I’ve merged the controller and service layer for brevity. You can replace the @AuthenticatedPrincipal bit with your way of supplying the currently logged in user details to the controllers). Assuming the methods are in controller mapped to “/user/”:

@RequestMapping(value = "/init2fa", method = RequestMethod.POST)
@ResponseBody
public String initTwoFactorAuth(@AuthenticationPrincipal LoginAuthenticationToken token) {
    User user = getLoggedInUser(token);
    GoogleAuthenticatorKey googleAuthenticatorKey = googleAuthenticator.createCredentials();
    user.setTwoFactorAuthKey(googleAuthenticatorKey.getKey());
    dao.update(user);
    return GoogleAuthenticatorQRGenerator.getOtpAuthURL(GOOGLE_AUTH_ISSUER, email, googleAuthenticatorKey);
}

@RequestMapping(value = "/confirm2fa", method = RequestMethod.POST)
@ResponseBody
public boolean confirmTwoFactorAuth(@AuthenticationPrincipal LoginAuthenticationToken token, @RequestParam("code") int code) {
    User user = getLoggedInUser(token);
    boolean result = googleAuthenticator.authorize(user.getTwoFactorAuthKey(), code);
    user.setTwoFactorAuthEnabled(result);
    dao.update(user);
    return result;
}

@RequestMapping(value = "/disable2fa", method = RequestMethod.GET)
@ResponseBody
public void disableTwoFactorAuth(@AuthenticationPrincipal LoginAuthenticationToken token) {
    User user = getLoggedInUser(token);
    user.setTwoFactorAuthKey(null);
    user.setTwoFactorAuthEnabled(false);
    dao.update(user);
}

@RequestMapping(value = "/requires2fa", method = RequestMethod.POST)
@ResponseBody
public boolean login(@RequestParam("email") String email) {
    // TODO consider verifying the password here in order not to reveal that a given user uses 2FA
    return userService.getUserDetailsByEmail(email).isTwoFactorAuthEnabled();
}

On the client side it’s simple AJAX requests to the above methods (sidenote: I kind of feel the term AJAX is no longer trendy, but I don’t know how to call them. Async? Background? Javascript?).

$("#two-fa-init").click(function() {
    $.post("/user/init2fa", function(qrImage) {
	$("#two-fa-verification").show();
	$("#two-fa-qr").prepend($('<img>',{id:'qr',src:qrImage}));
	$("#two-fa-init").hide();
    });
});

$("#two-fa-confirm").click(function() {
    var verificationCode = $("#verificationCode").val().replace(/ /g,'')
    $.post("/user/confirm2fa?code=" + verificationCode, function() {
       $("#two-fa-verification").hide();
       $("#two-fa-qr").hide();
       $.notify("Successfully enabled two-factor authentication", "success");
       $("#two-fa-message").html("Successfully enabled");
    });
});

$("#two-fa-disable").click(function() {
    $.post("/user/disable2fa", function(qrImage) {
       window.location.reload();
    });
});

The login form code depends very much on the existing login form you are using, but the point is to call the /requires2fa with the email (and password) to check if 2FA is enabled and then show a verification code input.

Overall, the implementation if two-factor authentication is simple and I’d recommend it for most systems, where security is more important than simplicity of the user experience.

The post Enabling Two-Factor Authentication For Your Web Application appeared first on Bozho's tech blog.

За един Иван и измислените барикади

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

И аз като Венци Мицов имам един приятел Иван. Дето живее „в провинцията“ (откъдето съм и аз). И който взема, айде не 450 лева, ама твърде малко пари, за да изхранва семейството си.

Иван работи доста за тези пари – не т.нар. работа на хора с бели якички, но работата си е работа.

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

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

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

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

Рисуват картина на две Българии, едната на Иван, а другата на някакъв имагинерен елит.

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

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

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

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

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

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

А в сенките отстрани на тези барикади едни хитри хора потриват ръце.

Господа министри, мерете си данните

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

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

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

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

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

И то, разбира се, се оказа грешно. Ето броя дни, в които нормата е превишена:

Превишена стойност в поне 1 станция: 74 дни
Превишена стойност в поне 2 станции: 48 дни
Превишена стойност в поне 3 станции: 43 дни
Превишена стойност в поне 4 станции: 36 дни
Превишена стойност в поне 5 станции: 15 дни

По спомен, станциите са 6, но последната е на Копитото и там винаги е чисто. С наличните данни (които са качени за 340, а не за 365 дни) не мога да кажа за средната стойност за града, но когато 4 от 5 станции имат превишение 36 дни (1 над европейската норма), министърът просто изнася грешни данни. Или „е имал предвид друго“, в който случай – нека обясни.

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

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

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

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