All posts by Bozho

Writing Big JSON Files With Jackson

Post Syndicated from Bozho original https://techblog.bozho.net/writing-big-json-files-with-jackson/

Sometimes you need to export a lot of data to JSON to a file. Maybe it’s “export all data to JSON”, or the GDPR “Right to portability”, where you effectively need to do the same.

And as with any big dataset, you can’t just fit it all in memory and write it to a file. It takes a while, it reads a lot of entries from the database and you need to be careful not to make such exports overload the entire system, or run out of memory.

Luckily, it’s fairly straightforward to do that, with a the help Jackson’s SequenceWriter and optionally of piped streams. Here’s how it would look like:

    private ObjectMapper jsonMapper = new ObjectMapper();
    private ExecutorService executorService = Executors.newFixedThreadPool(5);

    @Async
    public ListenableFuture<Boolean> export(UUID customerId) {
        try (PipedInputStream in = new PipedInputStream();
                PipedOutputStream pipedOut = new PipedOutputStream(in);
                GZIPOutputStream out = new GZIPOutputStream(pipedOut)) {
        
            Stopwatch stopwatch = Stopwatch.createStarted();

            ObjectWriter writer = jsonMapper.writer().withDefaultPrettyPrinter();

            try(SequenceWriter sequenceWriter = writer.writeValues(out)) {
                sequenceWriter.init(true);
            
                Future<?> storageFuture = executorService.submit(() ->
                       storageProvider.storeFile(getFilePath(customerId), in));

                int batchCounter = 0;
                while (true) {
                    List<Record> batch = readDatabaseBatch(batchCounter++);
                    for (Record record : batch) {
                        sequenceWriter.write(entry);
                    }
                }

                // wait for storing to complete
                storageFuture.get();
            }  

            logger.info("Exporting took {} seconds", stopwatch.stop().elapsed(TimeUnit.SECONDS));

            return AsyncResult.forValue(true);
        } catch (Exception ex) {
            logger.error("Failed to export data", ex);
            return AsyncResult.forValue(false);
        }
    }

The code does a few things:

  • Uses a SequenceWriter to continuously write records. It is initialized with an OutputStream, to which everything is written. This could be a simple FileOutputStream, or a piped stream as discussed below. Note that the naming here is a bit misleading – writeValues(out) sounds like you are instructing the writer to write something now; instead it configures it to use the particular stream later.
  • The SequenceWriter is initialized with true, which means “wrap in array”. You are writing many identical records, so they should represent an array in the final JSON.
  • Uses PipedOutputStream and PipedInputStream to link the SequenceWriter to a an InputStream which is then passed to a storage service. If we were explicitly working with files, there would be no need for that – simply passing a FileOutputStream would do. However, you may want to store the file differently, e.g. in Amazon S3, and there the putObject call requires an InputStream from which to read data and store it in S3. So, in effect, you are writing to an OutputStream which is directly written to an InputStream, which, when attampted to be read from, gets everything written to another OutputStream
  • Storing the file is invoked in a separate thread, so that writing to the file does not block the current thread, whose purpose is to read from the database. Again, this would not be needed if simple FileOutputStream was used.
  • The whole method is marked as @Async (spring) so that it doesn’t block execution – it gets invoked and finishes when ready (using an internal Spring executor service with a limited thread pool)
  • The database batch reading code is not shown here, as it varies depending on the database. The point is, you should fetch your data in batches, rather than SELECT * FROM X.
  • The OutputStream is wrapped in a GZIPOutputStream, as text files like JSON with repetitive elements benefit significantly from compression

The main work is done by Jackson’s SequenceWriter, and the (kind of obvious) point to take home is – don’t assume your data will fit in memory. It almost never does, so do everything in batches and incremental writes.

The post Writing Big JSON Files With Jackson appeared first on Bozho's tech blog.

Няма консервативна вълна?

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

В своя статия тези дни, д-р Петър Николов (зам.министър на образованието и кандидат за народен представител на патриотите) направи опит да затвърди разпространената теза, че има консервативна вълна в света. Аз, обаче, не съм съгласен.

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

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

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

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

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

Съвсем естествен е сблъсъкът на консервативните и либералните тези в контекста на това „кое е по-добро за дългосрочното развитие на обществото“ и отговорът най-вероятно е „по малко и от двете“. Твърде бързата промяна носи рискове, твърде бавната промяна носи изоставане. Но какво общо има това с консервативната вълна, каквато аз твърдя, че няма?

Консерватизмът в Европа се възприема чрез изборните победи на консервативни партии в Австрия, Полша, Унгария, Италия, както и Брекзит и високия резултат на националистите във Франция и Германия. Местните специфики настрана, какво е общото между изредените? Антимигрантската реторика. Всяка от консервативтните партии, спечелили или засилили влиянието си през последните години разчита именно на това – да капитализира неспряването с мигрантската криза. Пикът на тази криза беше 2015-та и оттогава намалява, но не намалява усещането за нея, отчасти благодарение на използването ѝ като политическо послание.

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

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

Преди няколко години Microsoft представиха в МВР свое решение за консолидиране на източниците на информация с цел разкриване и превенция на престъпления, в т.ч. атентати. Това, което отбелязаха в презентацията си е, че след анализ през 2001-ва година е станало ясно, че правоохранителните органи в САЩ са имали цялата необходима информация за предотвратяване на атентата от 11-ти септември. Просто информацията е била пръсната между федерални, щатски и общински служби и органи, които не са я обменяли помежду си. Атентатът подейства отрезвително и администрацията на Буш реформира тази система, така че да е по-ефективна и по-информирана. Да, в щатите това носи със себе си „орязване“ на някои граждански свободи, но според мен и според експерти постиганият резултат е възможен и без масовото следене.

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

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

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

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

Франция избра либерал за президент; Ирландия, силно религиозна, католическа страна, гласува за гей браковете и абортите; в Германия най-голямо увеличение в гласовете получиха националистите, но веднага след тях е либералната партия; в Чехия пиратската партия е трета в парламента с 8% ръст; на последните местни избори в Холандия най-голям ръст имат Зелените и либералната партия (част от ALDE в Европейския парламент). Португалия продължава вече почти 20 години с успешната си политика за декриминализиране на наркотиците и няма изгледи това да се промени. Дали има консервативна вълна в европейските общества е много спорно.

Не е спорно обаче, че има опортюнистична вълна. Или както е казал Бай Ганьо:

„А бе, бай Иречек, я ми кажи твоя милост леберал ли си, консерватор ли си? Май-май, че си консерва, както виждам. И аз, ако питаш, не мога да ги разбера нито едните, нито другите, ама хайде, да не им остане хатъра… Знайш, алъш-вериш е то, не е шега… Па и мене нали ми се иска – я депутат да ме изберат, я кмет. Келепир има в тия работи. Хората пара натрупаха, ти знаеш ли… Тъй е! Аз съм врял и кипял в тия работи, че ги разбирам…“

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

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

Хората не са глупави, но при толкова опити да бъдат манипулирани и етикетирани, плашени и екстремизирани, могат да бъдат подведени към друга крилата фраза на Бай Ганьо – „всички са маскари“. Но краткосрочните политически „интрижки“ не са големият проблем. Големият проблем е, че малка група опортюнисти искат да набутат хората в кутийки, да им сложат етикетчета, и да си ги „приберат“ електорално. Да ги плашат с бежанци и „джендъри“, да ги разделят.

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

Това не е консервативно или либерално, това е просто безотговорно.

Proving Digital Events (Without Blockchain)

Post Syndicated from Bozho original https://techblog.bozho.net/proving-digital-events-without-blockchain/

Recently technical and non-technical people alike started to believe that the best (and only) way to prove that something has happened in an information system is to use a blockchain. But there are other ways to achieve that that are arguably better and cheaper. Of course, blockchain can be used to do that, and it will do it well, but it is far from the only solution to this problem.

The way blockchain proves that some event has occurred by putting it into a tamper-evident data structure (a hash chain of the roots of merkle trees of transactions) and distributing that data structure across multiple independent actors so that “tamper-evident” becomes “tamper-proof” (sort-of). So if an event is stored on a blockchain, and the chain is intact (and others have confirmed it’s intact), this is a technical guarantee that it had indeed happened and was neither back-dated, nor modified.

An important note here – I’m stressing on “digital” events, because no physical event can be truly guaranteed electronically. The fact that someone has to enter the physical event into a digital system makes this process error-prone and the question becomes “was the event correctly recorded” rather than “was it modified once it was recorded”. And yes, you can have “certified” / “approved” recording devices that automate transferring physical events to the digital realm, e.g. certified speed cameras, but the certification process is a separate topic. So we’ll stay purely in the digital realm (and ignore all provenance use cases).

There are two aspects to proving digital events – technical and legal. Once you get in court, it’s unlikely to be able to easily convince a judge that “byzantine fault tolerance guarantees tamper-proof hash chains”. You need a legal framework to allow for treating digital proofs as legally binding.

Luckily, Europe has such a legal framework – Regulation (EU) 910/2014. It classifies trust services in three categories – basic, advanced and qualified. Qualified ones are always supplied by a qualified trust service provider. The benefit of qualified signatures and timestamps is that the burden of proof is on the one claiming that the event didn’t actually happen (or was modified). If a digital event is signed with a qualified electronic signature or timestamped with a qualified timestamp, and someone challenges that occurrence of the event, it is they that should prove that it didn’t happen.

Advanced and basic services still bear legal strength – you can bring a timestamped event to court and prove that you’ve kept your keys securely so that nobody could have backdated an event. And the court should acknowledge that, because it’s in the law.

Having said that, the blockchain, even if it’s technically more secure, is not the best option from a legal point of view. Timestamps on blocks are not put by qualified trust service providers, but by nodes on the system and therefore could be seen as non-qualified electronic time stamp. Signatures on transactions have a similar problem – they are signed by anonymous actors on the network, rather than individuals whose identity is linked to the signature, therefore making them legally weaker.

On the technical side, we have been able to prove events even before blockchain. With digital signatures and trusted timestamps. Once you do a, say, RSA signature (encrypt the hash of the content with your private key, so that anyone knowing your public key can decrypt it and match it to the hash of the content you claim to have signed, thus verifying that it is indeed you who signed it), you cannot deny having signed it (non-repudiation). The signature also protects the integrity of the data (it can’t be changed without breaking the signature). It is also known who signed it, owning the private key (authentication). Having these properties on an piece of data (“event”) you can use it to prove that this event has indeed occurred.

You can’t, however, prove when it occurred – for that you need trusted timestamping. Usually a third-party provider signing the data you send them, and having the current timestamp in the signed response. That way, using public key cryptography and a few centralized authorities (the CA and the TSA), we’ve been able to prove the existence of digital events.

And yes, relying on centralized infrastructure is not perfect. But apart from a few extreme cases, you don’t need 100% protection for 100% of your events. That is not to say that you should go entirely unprotected and hope that an event has occurred simply because it is in some log file.

Relying on plain log files for proving things happened is a “no-go”, as I’ve explained in a previous post about audit trail. You simply can’t prove you didn’t back-date or modify the event data.

But you can rely on good old PKI to prove digital events (of course, blockchain also relies on public key cryptography). And the blockchain approach will not necessarily be better in court.

In a private blockchain you can, of course, utilize centralized components, like a TSA (Time stamping authority) or a CA to get the best of both worlds. And adding hash chains and merkle trees to the mix is certainly great from a technical perspective (which is what I’ve been doing recently). But you don’t need a distributed consensus in order to prove something digital happened – we’ve had the tools for that even before proof-of-work distributed consensus existed.

The post Proving Digital Events (Without Blockchain) appeared first on Bozho's tech blog.

Гадната европейска бюрокрация

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

Гадните евро-бюрократи (еврократи) само измислят глупости и ги налагат на суверенните държави! Никой не е гласувал за тях, а определят каква форма да имат краставиците! Огромната брюкселска бюрокрация взема милиони и опитва да оправдае съществуването си!

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

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

Каква обаче е целта не европейските регулации? И кой ги „измисля“, кой ги приема?

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

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

Регламент 910/2014 пък унифицира електронните подписи и електронната идентификация. Благодарение на това, електронен подпис, издаден в една държава, важи във всички останали. Така ако искаме да подпишем договор между българска и немска фирма, и да сме сигурни, че договорът да има стойност и в двете държави, няма нужда българската фирма да купува немски електронен подпис. Същият регламент, обаче, въвежда възможност за предоставяне на електронни услуги на граждани от други държави. Това е друг аспект на европейското законодателство – предоставяне на свързаност и интегриране на държавите членки.

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

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

Понякога, все пак, се предлагат и изцяло нови неща, които ги е нямало в ничие законодателство. Директивите за платежните услуги (PSD, PSD2), например, създават възможности за небанкови инстутиции да предлагат все повече платежни услуги. Предлагането на нови идеи невинаги е гладко – понякога Европейската комисия (и то на политическо ниво, не „бюрократите“) измисля някоя глупост, като автоматичното филтриране на съдържание, което го е нямало в ничие законодателство преди това. Или недообмисля някой детайл, като закривеността на краставици и банани (което е частично мит, но общо взето е базирано на международна класификация на плодовете и зеленчуците).

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

Процесът е дълъг и сложен, данни, които извлякох от EUR-LEX):

Първата представя Регламентите и Директивите приети по процеса, описан по-горе – както от Парламента, така и от Съвета. Те намаляват от 2014-та година насам, което е добър тренд.

На втората са Регламентите и Директивите, приети само от съвета. Те видимо намаляват през годините.

На третата са актовете на Комисията. Те също значително намаляват.

(Съществуват още няколко вида актове на институциите на ЕС, но можем да ги определим като по-маловажни и да не се спираме на тях)

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

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

Гадната европейска бюрокрация е толкова гадна, колкото са държавите-членки. Има какво да се желае от Брюксел, но 40-те хиляди еврократи не са виновни за кризата на доверието, която назрява в ЕС.

Вината е в липсата на лидерство и в тесния национален интерес, който някои държави преследват. Да, държавите в ЕС са суверенни (и са доста по-суверенни от американските щати), но уеднаквяването на правилата не значи отказ от суверенитет.

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

Ще има ли електронно гласуване?

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

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

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

  • Референдум – гласувахме „за“
  • Решение на Народното събрание дали да признае референдума – призна го
  • Законодателни промени – в работна група в НС работихме по измененията в Изборния кодекс, той беше приет и предвижда 2019-та да се гласува електронно на европейските избори
  • Вкарване на проекта като приоритетен в стратегически документ (пътна карта) и осигуряване на финансиране – това го направихме 2016-та, няколко месеца след приемането на измененията в Изборния кодекс. Финансиранетоп е по оперативна програма „Добро управление“
  • Разписване на проекта, одобряването му управляващия орган на оперативната програма и пускане на първа обществена поръчка – случи се в първата половина на 2017-та
  • Извършване на анализ на добрите практики по света – стана във втората половина на 2017-та и завърши с представяне на резултатите в началото на декември
  • Пускане на поръчка и избор на изпълнител за написване на техническото задание на база на анализа – беше завършено в края на 2017-та или началото на 2018-та
  • Изготвяне на техническо задание и приемането му от ЦИК и ДАЕУ – това отне 6-7 месеца, като доколкото ми е известно самото задание е било готово доста бързо
  • Обществено обсъждане на заданието – юли-август 2018-та
  • Обявяване на обществена поръчка и избор на изпълнител – надявам се до края на годината
  • Разработка (или доработка на съществуващо решение) и внедряване – поне 6 месеца
  • Експериментални гласувания – трябва да са поне 3
  • Действително гласуване

Виждаме, че натрупаното изоставане е доста – то е най-вече в периода 2017-2018, в който липсва ясна политическа визия и воля, че това трябва да се случи.

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

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

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

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

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

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

През 2019-та политическата класа ще опита да си измие ръцете с ЦИК. Но реалността е, че ЦИК е само изпълнител. А за последните две години никой в законодателната власт и политическия „елит“ не е направил стъпка към това да има електронно гласуване. Мълчанието по темата и оставянето ѝ по течението на административните процедури е това, което ще доведе до забавянето. Защото ако имаше политическо желание, нямаше да се чака по 6-7 (или в случая с електронната идентификация – 12-13) месеца в чудене „да напишем ли тоя проект“ и „да пуснем ли тая поръчка“.

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

Implementing White-Labelling

Post Syndicated from Bozho original https://techblog.bozho.net/implementing-white-labelling/

Sometimes (very often in my experience) you need to support white-labelling of your application. You may normally run it in a SaaS fashion, but some important or high profile clients may want either a dedicated deployment, or an on-premise deployment, or simply “their corner” on your cloud deployment.

White-labelling normally includes different CSS, different logos and other images, and different header and footer texts. The rest of the product stays the same. So how do we support white-labelling in the least invasive way possible? (I will use Spring MVC in my examples, but it’s pretty straightforward to port the logic to other frameworks)

First, let’s outline the three different ways white-labelling can be supported. You can (and probably should) implement all of them, as they are useful in different scenarios, and have much overlap.

  • White-labelled installation – change the styles of the whole deployment. Useful for on-premise or managed installations.
  • White-labelled subdomain – allow different styling of the service is accessed through a particular subdomain
  • White-labelled client(s) – allow specific customers, after logging in, to see the customized styles

To implement a full white-labelled installation, we have to configure a path on the filesystem where the customized css files and images will be placed, as well as the customized texts. Here’s an example from a .properties file passed to the application on startup:

styling.dir=/var/config/whitelabel
styling.footer=&copy;2018 Your Company
styling.logo=/images/logsentinel-logo.png
styling.css=/css/custom.css
styling.title=Your Company

In spring / spring boot, you can server files from the file system if a certain URL pattern is matched. For example:

@Component
@Configuration
public class WebMvcCustomization implements WebMvcConfigurer {
  @Value("${styling.dir}")
  private String whiteLabelDir;

  @Override
  public void addResourceHandlers(ResourceHandlerRegistry registry) {
    registry.addResourceHandler("/whitelabel/**").addResourceLocations(whiteLabelDir);
  }
}

And finally, you need to customize your HTML templates, but we’ll get to that at the end, when all the other options are implemented as well.

Next, are white-labelled subdomain. For me this is the best option, as it allows you to have a single installation with multiple customers with specific styles. The style depends solely on the domain/subdomain the service is accessed through.

For that, we’d need to introduce an entity, WhitelabelStyling and a corresponding database table. We can make some admin UI to configure that, or configure it directly in the database. The entity may look something like this:

@Table("whitelabel_styling")
public class WhitelabelStyling {
    @PrimaryKey
    private String key;
    @Column
    private String title;
    @Column
    private String css;
    @Column
    @CassandraType(type = DataType.Name.BLOB)
    private byte[] logo;
    @Column
    private String footer;
    @Column
    private String domain;

   // getters and setters
}

The key is an arbitrary string you choose. It may be the same as the (sub)domain or some other business-meaningful string. The rest is mostly obvious. After we have this, we need to be able to serve the resources. For that we need a controller, which you can see here. The controller picks up a white-label key and tries to load the corresponding entry from the database, and then serves the result. The controller endpoints are in this case /whitelabel-resources/logo.png and /whitelabel-resources/style.css.

In order to set the proper key for the particular subdomain, you need a per-request model attribute (i.e. a value that is set in the model of all pages being rendered). Something like this (which refreshes the white-label cache once a day; the cache is mandatory if you don’t want to hit the database on every request):

@ModelAttribute("domainWhitelabel")
public WhitelabelStyling perDomainStyling(HttpServletRequest request) {
    String serverName = request.getServerName();
    if (perDomainStylings.containsKey(serverName)) {
        return perDomainStylings.get(serverName);
    }
    return null;
}

@Scheduled(fixedRate = DateTimeConstants.MILLIS_PER_DAY)
public void refreshAllowedWhitelabelDomains() {
     perDomainStylings = whitelabelService.getWhitelabelStyles()
            .stream()
            .collect(Collectors.toMap(WhitelabelStyling::getDomain, Function.identity()));
}

And finally, per-customer white-labeling is achieved the same way as above, using the same controller, only the current key is not fetched based on request.getServerName() but on a property of the currently authenticated user. An admin (through a UI or directly in the database) can assign a whitelabel key to each user, and then, after login, that user sees the customized styling.

We’ve seen how the Java part of the solution looks, but we need to modify the HTML templates in order to pick the customisations. A simple approach would look like this (using pebble templating):

{% if domainWhitelabel != null %}
  <link href="/whitelabel-resources/style.css?key={{ domainWhitelabel.key }}" rel="stylesheet">
{% elseif user.whitelabelStyling != null and user.whitelabelStyling.css != '' %}
  <link href="/whitelabel-resources/style.css" rel="stylesheet">
{% elseif beans.environment.getProperty('styling.dir') != '' and beans.environment.getProperty('styling.css.enabled') == true %}
  <link href="{{'/whitelabel/'+  beans.environment.getProperty('styling.css')}}" rel="stylesheet">
{% else %}
  <link href="{{ beans.environment.getProperty('styling.css')}}" rel="stylesheet">
{% endif %}

It’s pretty straightforward – if there’s a domain-level white-labelling configured, use that; if not, check if the current user has specific white-label assigned; if not, check if global installation white-labelling is configured; if not, use the default. This snippet makes use of the WhitelabelController above (in the former two cases) and of the custom resource handler in the penultimate case.

Overall, this is a flexible and easy solution that shouldn’t take more than a few days to implement and test even on existing systems. I’ll once again voice my preference for the domain-based styles, as they allow having the same multi-tenant installation used with many different styles and logos. Of course, your web server/load balancer/domain should be configured properly to allow subdomains and let you easily manage them, but that’s offtopic.

I think white-labelling is a good approach for many products. Obviously, don’t implement it until the business needs it, but have in mind that it might come down the line and that’s relatively easy to implement.

The post Implementing White-Labelling appeared first on Bozho's tech blog.

5 Features Eclipse Should Copy From IntelliJ IDEA

Post Syndicated from Bozho original https://techblog.bozho.net/5-features-eclipse-should-copy-from-intellij-idea/

Eclipse Photon has been released a few days ago, and I decided to do yet another comparison with IntelliJ IDEA. Last time I explained why I still prefer Eclipse, but because my current project had problems with Java 9 in Eclipse initially, I’ve been using IntelliJ IDEA in the past half a year. (Still using Eclipse for everything else; partly because of the lack of “multiple projects in one workspace” in IDEA).

This time, though, the comparison will be the other way around – what IDEA features I’d really like to have in Eclipse; features that make work much easier and way more efficient. (Btw, what’s the proper short version to use – IntelliJ? IDEA?)

Isn’t that a departure from my stance “Eclipse is better”? No – I don’t believe there’s a perfect IDE (or perfect anything, for that matter), so any product can try to get the best aspects of the competition. Here I’ll focus on five features of IDEA where Eclipse lags behind.

First, the “Find in path” dialog. The interactivity of the dialog, the fact that you see all the results while typing and being able to navigate the results with the arrows is huge. Compare that to Eclipse’s clunky Search dialog, which (while pretty powerful), has a million tabs (rarely focused on the one you need) and then you actually click “Search” to get a list of results in a search panel, where you double-click in order to see the context…it’s just bad compared to IDEA.

Second is suggesting static imports. Static imports are not used too often, except in tests. Mockito, Hamcrest, test utility methods – in every class you need dozens of static imports. And Eclipse feels miserable with those – you manually go and import the methods you need, then organize imports and suddenly you need another one, and the .* you naively added has been changed to particular imports, so once again, you have to go and manually import. In contrast, IDEA just suggest the most relevant static import in the autocomplete pop-up and handles that for you.

Third is autocomplete. IDEA autocomplete triggers automatically when you start typing; in Eclipse it only triggers after a dot – otherwise you have to CTRL+space. And yes, I know there’s auto-activation setting where you can configure symbols that trigger the auto-complete, but as I’ve previously complained about IDEA’s defaults, it’s Eclipse’s turn. And it’s not even a checkbox – you have to actively type the entire alphabet, lower and upper case, in order to get it working – that’s just bad design. In what scenario would I need autocomplete on a,b,c but not on d,e,f??

Fourth is lambda simplification. You sometimes end up with pretty long chain of calls on a stream and they may not be the best way to express what you want. IDEA can suggest improvements so that it is more readable and easier to understand while achieving the same result. As a bonus, you eventually start doing this simplifications yourself.

Fifth – parameter labels. When you call a method foo.bar("Some string", 0, true) it’s not exactly obvious what the parameters are. And while you can rightly argue that this is a bad method signature, primitive (+String) parameters where you just pass a value happen every now and then, and it’s useful to see the name of the parameter at the point of method invocation. IDEA nicely shows that.

There are certainly more things that each of the IDEs can copy from the other one. Hopefully this competition will continue and result in improving both.

The post 5 Features Eclipse Should Copy From IntelliJ IDEA appeared first on Bozho's tech blog.

Авторско право и свободен интернет

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

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

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

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

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

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

Проблемът със свободата на изразяване а е най-големият, но не единственият. За платформи, различни от гигантите (като YouTube и Spotify, напр.), цената за реализиране на такава технология ще бъде твърде висока. Европейската комисия твърди, че е направила проучване… и е намерила едно комерсиално достъпно решение, чийто лиценз обаче не е ясно колко струва. Друг голям проблем за по-малките и съответно за свободния пазар е това, че правоносителските организации отказват да предоставят съдържанието си, така че да може да бъде извършено сравнение. Т.е. доставчикът на услугата има задължение да взема мерки за сваляне, но няма възможност да го направи.

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

Давам пример с YouTube, но това ще важи за текст, снимки, и др. А там проблемите ще са най-разнообразни. Например има риск т.нар. memes няма да могат да бъдат качвани изобщо, тъй като нарушават нечие авторско право. Наскоро четох статия как Фолксваген е поискал сваляне на рисунки на бръмбари, защото нарушавали правата на „Volkswagen Beetle“ (тук не става въпрос точно за авторско право, но все пак е в полето на интелектуалната собственост и примерът е доста показателен). Несъвършени алгоритми, невнимателни юридически отдели, злонамерен конкуренти или репресивни държавни органи – причините за неправомерно сваляне на съдържание са много. И понякога жертви са именно авторите – има редица примери на свалено авторско съдържание, защото алгоритъмът е решил, че то е нечие (напр. при използване на бийтове, за които можеш да си платиш и да включиш в твое произведение – първият, използвал даден бийт може да сваля произведенията на всички останали).

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

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

Член 13 не е единствената глупост в текста на директивата. Член 11, т.нар. „такса линк“ е друго гениално творение, с което уж да се защитят медиите, които произвеждат съдържание. Грубо казано, всеки, на чийто сайт се споделя линк и откъс от дадена новина, ще дължи такса на медията, към чийто сайт води. Би било нарушение ако споделя новина във Facebook и копирам два-три абзаца от нея. Съответно Facebook ще трябва да ми блокира публикацията.

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

Това не е краят на интернет, разбира се. Но такива необмислени и късогледи стъпки не помагат на никого. Гласуването в правната комисия не е и краят на дебатите. Следват много, много стъпки – комисията предлага парламентът да приеме мандат за преговори по директивата, така че да отиде на среща със Съвета и с Европейската комисия (триалог) и да се уточнят финалните текстове. Съветът, в същото време (който ще председателстваме още 5 дни), трябва да излезе със своя версия. За съжаление в нашето председателство не се случи кой знае какво по тази тема, така че Австрийското председателство ще води този процес. Европейската комисия също има роля, в лицето на Мария Габриел. Тя, за съжаление, следва оставеното от Йотингер, който често е бил в ролята на проводник на интересите на немски корпорации и организации.

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

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

Electronic Signatures Using The Browser

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

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

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

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

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

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

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

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

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

Storing Encrypted Credentials In Git

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

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

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

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

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

Such a repo would look like this:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Benefits of Side Projects

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Bad Software Is Our Fault

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Audit Trail Overview

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

User Authentication Best Practices Checklist

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

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

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

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

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

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

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