The EU is about to tell us how to code
March 6, 2023 5:43 AM   Subscribe

Bert Huber describes a new law working its way though the EU parliament that may have massive implications for how code is written and regulated. There are potentially great things in the law (no more devices shipped with admin/admin default credentials!) and potentially terrible things in the law (open source maintainers slapped with 15 million euro minimum fines). (via @edwtjo
posted by rockindata (32 comments total) 22 users marked this as a favorite
 
Despite the clickbait title, the author seems to take a nuanced view of the topic, and finds a lot to like in the proposed regulation.

Overall, I’m really glad that the EU is starting to take action on computer security regulation in general. I share the author’s concerns about how the standard-setting process will work, and I’d like a stronger carve-out for open source or community-developed software. Both of those issues could potentially cause huge problems, but I’m encouraged by a lot of the rest of the analysis.
posted by learning from frequent failure at 6:06 AM on March 6, 2023 [2 favorites]


Thank you for posting this. I'm currently working on a Linux-based IoT project here in the US for an EU corporation and I'm 100% positive we will start getting questions about this. The advance notice is good.

It kind of makes me wonder if Mercedes knew this was on the horizon when they announced their own operating system recently. Or maybe they were just fed up with Linux security holes.
posted by JoeZydeco at 6:20 AM on March 6, 2023


(And/or GPLv3. That's another massive headache on every project I do now.)
posted by JoeZydeco at 6:33 AM on March 6, 2023


As a programmer I think it's long past time that somebody seized the nettle. Also I predict that implementation will be a shitshow no matter what comes out of the process. With luck I will be retired by the time this hits the road.
posted by Aardvark Cheeselog at 7:10 AM on March 6, 2023 [1 favorite]


Does this means I’ll have to accept more cookies or other annoyances? They have a talent for making everybody’s live more miserable with very little upside sometimes.

In the abstract, laws requiring IoT devices to not be complete security messes aren’t so bad (so much of that stuff is just terrible), but I agree with the author this is casting a very wide and vague net. It would be better to go for an iterative approach, both on the what it applies to and on what is required, to regulating this.

This will be a boon for various consulting firms & lawyers!
posted by WaterAndPixels at 7:17 AM on March 6, 2023 [3 favorites]


As mentioned upthread, the title is definitely click-bait-y, and some of the claims don't survive even a moment's scrutiny. How is the EU going to enforce a 15 million euro fine against an open-source repo's maintainers, most of whom don't reside in the EU? GDPR mostly accomplished its goal, which is "if you want to serve customers in the EU, you have to follow some basic privacy rules, and if we catch you breaking those rules, here's the framework for how we'll come after you for damages." I would imagine this proposal will work much the same way. And it's about time, too. Software development is the wild goddamned west, because currently it's cheaper to deal with the fallout from a major breach than it is to dedicate the resources it would take to prevent one. The market ain't gonna fix that. US regulatory agencies ain't gonna fix that. The EU is really the only group with the stones and political will to address it head-on, and the enforcement protocols to make tech companies pay attention.
posted by Mayor West at 7:48 AM on March 6, 2023 [7 favorites]


This will be a boon for various consulting firms & lawyers

If it's like my experience with other EU regulatory frameworks, you will spend a shitload of money on consultants that don't know jack, than have to do all your work over again in 2 years after you figure out you aren't in compliance.
posted by Dr. Twist at 7:52 AM on March 6, 2023 [9 favorites]


It would be better to go for an iterative approach, both on the what it applies to and on what is required, to regulating this.

I agree. Starting with larger entities, higher risk products, and the more easily agreed-upon and enforceable standards seems like it would be better than essentially "everything, everywhere, all at once", if for no other reason than compliance will be a massive undertaking. To be at all efficient the compliance entities would have to hire almost as many software engineers as there currently are in the market, which is a) flatly impossible given the shortage of developers, let alone ones with enough experience to do security-focused work and b) cause salaries to go up, leading to a double whammy of cost increases: compliance costs plus higher wages. This is not necessarily a bad thing, but it's all the more reason to start small and build up rather than trying to do everything all at once.

I guess a hybrid approach would be for compliance to be done by random audit, following a well-documented protocol so that companies can prepare in advance in case they are selected. That makes staffing manageable and will cause most companies to be proactive.

But personally I favor a more market-based solution driven by liability. Rather than mandate that development be done a certain way and certified by a compliance organization, simply make the no-warranty, no-liability license illegal for commercial products, including commercial products integrating open source software. The liability doesn't reach back to the open source project, but commercial companies will suddenly have a very, very strong financial incentive to make sure that open source projects are highly secure and well tested.
posted by jedicus at 7:57 AM on March 6, 2023 [10 favorites]


I know this will be an unpopular opinion. I benefit from open source software, too.

A carve out for open source will result in a land rush to found open-source-in-name-only organizations to insulate the actual externalizers, making an already fraught space worse while not materially increasing security. And open source doesn't actually mean more secure (as we keep finding out, despite the best of intentions).

I'd love some penalties combined with compulsory funded independent review, where civic projects might effectively find government funding to take over abandoned systems that remain critical infrastructure (and systems rife with issues where the commercial developer has been shut down due to the appropriately punitive fines). Sure, they can open source it and get many eyes, but the liability should remain consistent, just the funding offset the burden.
posted by abulafa at 8:15 AM on March 6, 2023 [4 favorites]


It sounds like they want to impose something like SOC2 or FEDRAMP certification, but European. That is probably good for the profession. If companies are already doing these things it probably won’t be much of a lift over existing requirements.
posted by interogative mood at 8:20 AM on March 6, 2023


I'd like to see some commitments to Right to Repair embedded in this framework.
posted by seanmpuckett at 8:21 AM on March 6, 2023 [8 favorites]


man, the w3c standards body for html alone was/is a shitshow. i agree with (a) the liability approach jedicus prefers. I've long thought that companies who sell or use packaged private data should have a remarkably high liability for data loss. (b) incremental impl of anything like this. otherwise the false starts and disruptions will be massive.

they could make us all code in rust #lolsob-no
posted by j_curiouser at 8:55 AM on March 6, 2023


The poor guy who maintains core-js can't even get basic funding, and the EU thinks that fining an author like him 15 million is gonna help?
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 9:39 AM on March 6, 2023 [9 favorites]


I like rust...

This has a lot of possible shitshow written on it, especially with the open source maintainer liabilities. I mean, that one reads "you better not retire or you'll owe us mega-euros", so if someone sends a "whoops, sounds like compelled work" they might backpedal on it.
posted by mephron at 9:45 AM on March 6, 2023 [2 favorites]


Mercedes knew this was on the horizon when they announced their own operating system recently

I would never consider buying such a product. Best case it is just skinned openBSD.
posted by a robot made out of meat at 9:49 AM on March 6, 2023 [3 favorites]


*I would never consider buying such a product. *

Pretty tough to by a car without a computer in it, since, oh, the 90s. And since OBSD isn't hard-realtime among other deficiencies for the use case, I don't think I want it running my car. I say that as I load OBSD on my new routers.
posted by kjs3 at 10:02 AM on March 6, 2023 [1 favorite]


We've been discussing this as we use a ton of OSS and we do business in the EU. It's a deceptively complicated issue.

My personal hope is that it's used to kill the 'OSS is free and we don't have to devote resources to it' mentality that is *way* to common among businesses. In a perfect world, I think the regulatory burden should be on the people who are building products and selling them, not of some poor dev who just put a library up on github that got popular.
posted by kjs3 at 10:07 AM on March 6, 2023 [9 favorites]


I would never consider buying such a product.

You wouldn't by MBOS, or you wouldn't buy a Mercedes from now on?

I mean, all of these cars are running some crusty 8-year-old version of some O/S that was spec'ed by Visteon or Delphi or Continental or whomever back when the platform was designed and finally made it through OEM validation into a product, which is now in the third year of a six year design cycle. And they don't update it unless it's a recall, otherwise you get a chunk of owners that are clogging up your expensive service bays asking for software upgrades for free.

There must have been some long insane amount of teeth gnashing inside of MB to decide it's cheaper to write our own brand new O/S than to fuck with Linux or BSD. Or, pay for a Green Hills license? Schiẞe!

The sad part is that we're still trying to cram 50 pounds of Linux sausage into a 5 pound casing when making embedded devices. Amazon and Microsoft bought the two possible contenders (FreeRTOS and ThreadX, respectively) and really haven't done much with either at this point in time.
posted by JoeZydeco at 11:37 AM on March 6, 2023 [1 favorite]


it's cheaper to write our own brand new O/S than to fuck with Linux or BSD. Or, pay for a Green Hills license? Schiẞe!

I do embedded hardware stuff for a living and I've been absolutely convinced that embedded linux is not fit for purpose, for any value of "purpose".
posted by Dr. Twist at 12:46 PM on March 6, 2023 [6 favorites]


This will be a boon for various consulting firms & lawyers!

Most likely. But let the record show that y'all came for our jobs first.
posted by Not A Thing at 1:20 PM on March 6, 2023 [1 favorite]


This has a lot of possible shitshow written on it, especially with the open source maintainer liabilities.

It's obvious that the status quo, where open source maintainers do work for free that vast ecosystems rely on without any support, is not sustainable. The EU lopping off all of the useful little libraries that everyone relies on is not great, but maybe it's the sort of creative destruction the industry needs to get its shit together.
posted by Merus at 4:53 PM on March 6, 2023


"FEDRAMP certification, but European. That is probably good for the profession"

I'm really, honestly, trying to curb my curmugeonliness. I really am. I swear. But when people are beating drums that could drastically affect how computing works for wide swaths of the planet, it's important to be loud sometimes.

As someone who operates in this space I would assert that the more literal this statement is, the less true it would be. FedRAMP as a framework is, to put it charitably, hot garbage that seems to make much of what it touches worse with its preposterous implicit assumptions. The requirement language for many controls is hilariously inapplicable for anything that isn't a room full of Windows machines with dudes sitting in front of them, talking to another Windows machine over a LAN. For others, it's just simply predicated on baffling misunderstandings of how anything actually works.

Leaving aside, of course, the massive allergy the thing seems to have towards, you know, doing anything securely. Looking super secure and having a lot of paperwork is secure, right? Being actually secure, well, that's out of scope. Better scan those kernel modules for word macros!

So, yeah, in my opinion, it's a very bad idea to ask some dude with a GitLab repo to apply a hideously expensive, incredibly complex, regulatory regime that requires massive ongoing compliance work. Let's prefer, perhaps strongly, to base any future regulatory approach on something almost entirely unlike the FedRAMP program if possible, please.
posted by majick at 11:06 PM on March 6, 2023 [3 favorites]


GDPR mostly accomplished its goal, which is "if you want to serve customers in the EU, you have to follow some basic privacy rules, and if we catch you breaking those rules, here's the framework for how we'll come after you for damages."

Sure, as long as you have the eight figures to spend on figuring out exactly how the EU was going to define the terms "customers", "in the EU", "follow", "basic", "privacy", "rules", "catch", "you", "rules", "framework", "we'll", "come after", and "damages", because it's not like the actual regulations told you any of that.
posted by Back At It Again At Krispy Kreme at 8:33 AM on March 7, 2023 [1 favorite]


I'd skip this posted article since NLnet, Eclipse, etc. have more concise and more precise discussions.

We've no standards bodies who understand security, although the IRTF tries, so a standards model just means they'll wind up blind sided. Active adversaries, mathematics, etc. won't obey the assumptions you bake into your standards.

IoT devices need better security, likely liability for manufacturers and retailers, but really overall solutions should look more like the right to repair, or requiring their code be open source.

I also dislike how open source software lags security in some respects, but there is a wider tapestry of security in which open source plays a really central role. You're software actually becomes less secure if open source projects face liability.

As Brian Fox of Sonatype stated “…the consequence of this would be [Maven] Central, npm, PyPi and countless other repositories being suddenly inaccessible to the European Union.”

It's not only crap like npm that'll block EU users, but also rust's crates.io repository, so you're back doing C again, not Rust, well not patched anyways. Also no formal verification tools because academics write those. Any new OS you build now brings exploits galore. :)

We should preemptively change licenses from merely "There is NO WARRANTY, to the extent permitted by law" to whatever language outright excludes jurisdictions where developers become liable.  Yay GPLv4 :)
posted by jeffburdges at 2:41 PM on March 7, 2023 [1 favorite]


IoT devices need better security, likely liability for manufacturers and retailers, but really overall solutions should look more like the right to repair, or requiring their code be open source.

I don't really agree. I'd go so far as to say 'right to repair' and 'better security' are almost at complete odds.

I also don't have a lot of faith in open source software as it pertains to large corporate software, as open source just means you have to buy an expensive support contract from one of the major providers. How is that better?


Also, software products in large corporate environments may have originally been open source, but they work and edit from within closed libraries, because sending code back to the open source repositories or pulling directly from them is a huge security risk.
posted by The_Vegetables at 3:14 PM on March 7, 2023


And I actually think 'right to repair' software is a good thing, but 'right to repair' means right to modify in any way you as the purchaser choose, as with cars (for example) can make them more dangerous.
posted by The_Vegetables at 3:15 PM on March 7, 2023


I'd expect right-to-repair gets exercised primarily by low value targets in poorer countries, so variants cause negligible economic damage, but the overall knowledge base being larger benefits security.

It's largely how exploits wind up being discovered: There always exists some parties like APTs who discover exploitable bugs even in close source software. If you've open source then you "democratize" exploit finding, which reduces wider economic risks, aka exploits first used by adversaries with less reach. It's economic harm reduction, not "bugs being so shallow [that honest people find them]".

Yes, anyone larger should vendor-until-review dependencies, but really many companies do upstream changes, and benefit from others security changes.
posted by jeffburdges at 4:25 PM on March 7, 2023


Count me in the crowd that thinks Linux/BSD as mission critical RTOS is nuts.

Amazon and Microsoft bought the two possible contenders (FreeRTOS and ThreadX, respectively) and really haven't done much with either at this point in time.

Yeah, but the codebase for them is still available. A shop with modest resources (much less what MB can bring to it) can take that and run with it. FreeRTOS (the one I'm passingly familiar with) is surprisingly accessible. This is an economic decision not technical: people who really understand real time and RTOSes are limited and training new ones takes time; I can recruit a Linux developer out of high school.

I don't really agree. I'd go so far as to say 'right to repair' and 'better security' are almost at complete odds.

Then fuck right of repair I guess. Society needs priorities. The people who actually repair stuff is a small part of the overall market. So if the tradeoff is "minority case gets to repair" versus "IoT vendors get a free pass to ship shitty code which impacts vastly more people", then I'm inclined to protect the majority. I'm sure somehow that makes me a bad person, but my career has pretty much been cleaning up the unintended/unforeseen mess 'noble causes' like this leave behind.

And we're about to get a new disaster with the proposed EU software security legislation. But that's for someones other post.
posted by kjs3 at 7:31 PM on March 7, 2023


We always need priorities but ewaste outweighs the IoT problem being addressed here, and right-to-repair is essential to tackling ewaste.

Anyways, right-to-repair should mean more people understand how the product works, which should reduce the economic harm for reasons given above, even if more total exploits arise.

Although surely better than Linux, FreeRTOS and ThreadX should bring exploits themselves, ditto Zircon / LK. I suppose Xous sounds more promissing, but limited targets so far. It'll face rust's wasteful memory usage.
posted by jeffburdges at 4:08 AM on March 8, 2023


We'll have huge swaths of software become unavailable in the EU under this liability regime.  I think Theo de Raadt already said OpenSSH would alter their future licenses to exclude Europe, but presumably most open source project not owned by FANNGs follows suite.  If Firefox plus derivatives like Tor brrowser disappear from the European market then Google, along with Microsoft and Apple, have de facto control over browser standards. Also, non-Google Chromium derivative like Brave disappearing gives Google far more control over advertising.
posted by jeffburdges at 4:38 AM on March 8, 2023


*right-to-repair is essential to tackling ewaste. *

Oh, please. Tackling it with a spoon, if that. The percentage of people who will say "I shall save the planet by fixing my 2 year old iPad" is vanishingly tiny compared to the number of consumers who say "iPad broke? Best excuse ever to go buy the new iPad++!!!".

You want to tackle ewaste? Force ethings to be recyclable down to the last bit waaaaay before you worry about repairing everything.
posted by kjs3 at 8:13 AM on March 8, 2023


(open source maintainers slapped with 15 million euro minimum fines).

This is not true, that is the maximum fine. Moreover the proposals state:

Where administrative fines are imposed on persons that are not an undertaking, the
competent authority should take account of the general level of income in the Member
State as well as the economic situation of the person when considering the appropriate
amount of the fine.

posted by tallus at 12:10 PM on March 8, 2023


« Older Let Freedom Ding!   |   Yo La Tengo plays the hits TODAY... Newer »


This thread has been archived and is closed to new comments