France developed their own matrix protocol based network called tchap. Great idea for a nation that wants to stay independent in an increasingly american/chinese tech dependent world.
My favorites was the "special email inbox for lawyers".
So, I am somewhat hesitant to let the EU develop a chat client.
I hated working there because I felt like a parasite just making the world worse. The in-hosue IT of our customer would probably have done a better job if they had just been allowed to hire some guys instead of having to go through an easily gameable procurement procedure. Not because they would have been more competent, but because they would have not have had perverse incentives.
I mean, we've got this nice secure login system for government sites: DigiD, which works fine. So you need that to submit your taxes. A few years ago, it turned out you needed any valid DigiD to submit your taxes, not necessarily your own. There are tons of other sites that cost many millions, and resulted in an atrocious user experience. And some projects simply failed after going way over budget.
Estonia has a similar solution, but "Smart-ID" was created after PKI was fully rolled out, it's terrible compared to that. Centralized, unverifiable, stores secrets insecurely, does some cryptographic bullshit. The two solutions somehow seem very related.
But my point is that even if DigiD is secure, that's still not going to help you when the tax service uses it incorrectly.
I haven't heard any such criticism about that system before, so it would be interesting to hear. I've been using it for years, it's easy to use and there haven't been any security problems with it. The company that developed it is trying to export it to other countries as well.
It doesn't utilize a hardware-backed secure secret storage on Android (~80% of marketshare in EE if I remember correctly). This means vital key material is unsafe from any compromise, just a plain file somewhere. This means that they have to go into a lot of effort to detect clones, which is also certainly not infallible. Cloning or compromising an ID-card of Mobile-ID is way way harder with it's audited security.
The technical overview describes how key is generated on the device and half of it is sent to AS SK's servers. There's no security benefit in that (they can't really verify you've deleted their half of the key from your device), except that now AS SK has half of your private key. In general their technical overview gives the feeling that like they want to pull wool over people's eyes, it's IMHO a bad sign.
It also totally lacks any privacy, every login you do is logged and counted. SK AS shouldn't mandatorily have that metadata.
It relies completely on their centralized servers, they go down, your authentication and signing goes totally down. Neither service owners or their clients can do anything about that. Identity mustn't be like that.
It's totally proprietary, thus their claims about security can't be easily verified, and it's limited to their blessed OSs (and versions). If they go bankrupt or similar, the identities of all those people are in jeopardy.
It's also expensive for server administrators and thus has a high barrier of entry. Identity and security shouldn't be behind a paywall for neither side. The web has LetsEncrypt and now a lot more sites are protected, the web is better off, SK AS has done the opposite.
In comparison, ID-card's PKI is usable for free, supported in every system (that can do TLS basically), entirely FOSS if you wish, the hardware is much more secure (EAL6+), it doesn't mandatorily leak metadata, doesn't rely on a centralized proprietary server to work.
Then use that for the competition to get the contract.
Preselection is hot garbage, as proven time and time again. Of course mechanism to mitigate the upfront cost of participating in such a competition should be implemented but in the end it should turn out cheaper/more worthwhile since a working MVP already exists by time of selection.
And anyway most costs are incurred during the lifetime of the project, after you proved yours is the best solution, with endless change requests, delays that require additional money, etc. The companies bidding usually have far more experience at syphoning money than the client has at holding on to it.
The development is also more expensive than in other areas since there is need for documentation.
And then there is a flaw in the process: Producing the software has to be done via some bidding process. For writing the requirements documents they already rely on companies, which can add clauses making it hard for competitors, after that the lowest bidder wins. In case there is a competitor and not some big player like T-Systems as the only one the offers typically are "optimistic" meaning that at some point in time the budget will run out and extra budget has to be granted (or the project would fail, which doesn't look good and they'd have to restart the whole process, thus wait another two years) and there a "smart" company can find quite a few extra costs. ("Oh wait, you updated from windows XP to 10, we have to redo a lot and then re-twst and re-certify")
It's a game some companies can play quite well.
That all said: Software is expensive. Gathering requirements is hard. Bureaucracy, which among other things tries to prevent corruption, causes extra work.
When, say, the national Police asks companies to come up with sofware to manage contact details for all employees, you could come up with "Install and Configure SomeOpenSourceCRM on a VPS" for €3000.
Whereas typically some Enterprise Consultancy quotes a factor hundred of that to "integrate" it in a crappy way.
I've worked in such projects, for governments. The overhead is ridiculous. the NIH-syndrome is rampant. The specs and "but this is how we do things"-requirements are cut in stone.
Very often a evening of tuning some Open Source tool could suffice; But either some rule disallowing the language/server/deploy-speed, or some manager disliking it because last year they decided that from now on everything must be Java+XML, or you need at least three weeks of meetings before you are allowed to even start.
This is not a joke. I've had a simple off-the-shelve Rails tool cut down, because "we don't allow dynamic languages". I've had projects delayed with 3+ weeks because "we require a deploy-window to be announced 21 days in advance" and I've worked as only developer on a project with four(!) managers managing me.
That is why government projects are expensive: a catch22: "Because they are".
> we don't allow dynamic languages
I would translate as "we have now experience in running and maintaining those platforms, which causes issues"
> require a deploy-window to be announced 21 days in advance"
This sounds a bit like ITIL or similar processes in oalce, which are there to ensure the systems are in defined state.
> with four(!) managers managing me.
Usually those should have different roles. Like technical oversight, communicating with the actual users and getting their requirements, then the IT management for operations and than oversight (variance exists, but lots of things, different stakeholders and as they spent public money they have to do extra documentation of processes for accountability reasons)
While I also feel the temptation to yell "I could do it for 1/100th of that" at a screen when I read/hear about these projects, just basic probability suggests that I'm probably wrong. It's me (with as little enterprise" experience as I could manage) vs a whole lot of people that don't strike me as particularly stupid and who have lots of incentives to keep costs down.
When you try to buy software like this through conventional state procurement mechanism you'll inevitably waste a lot of money, but it would be really cheap to "grow" it through supporting an environment where that can happen. Why doesn't Werner Koch have a position in academia? Third party funding of whole departments is commonplace and is always a blind bet trusting that the grantees will come up with something rewarding.
[0] (In German) https://www.heise.de/newsticker/meldung/Open-Source-Bundeswe...
I can think of many comparable situations in other countries (some EU ones as well) in which the person finding the issue would of very easily been locked up.
The actual bug was thanks to a long-standing bug in python's standard email.utils library, which finally got fixed: https://bugs.python.org/issue34155, combined with insufficiently-defensive coding and testing on my side. (I wrote the auth code in question).
It does not really say that the app is "super not secure". Just that people make mistakes, and it's not even shameful the way they reacted to it.