Risks of misinformation

Posted Sep 22, 2023 22:14 UTC (Fri) by kleptog (subscriber, #1183)
In reply to: Risks of misinformation by gasche
Parent article: The European Cyber Resilience Act

> I am worried about the risk of misinformation on this matter.

I must say I agree with you. The Apple, Googles, Samsungs, Ciscos, Microsofts, etc of this world have a vested interest to make sure they bear no liability for any software issue in products they release. And they will likely have no problem publishing a lot of FUD about this proposal. We've seen this is previous proposals. I vividly remember when Reddit pushed a big post about the Copyright Directive, whipping up a frenzy, including links to old revisions of the act and complaining about issues that had long been amended out. The readers lapped it up and trying to fight misinformation in that thread was terribly depressing. There were legitimate issues to complain about, but they were snowed under by the misinformation.

So far I haven't seen a lot of noise on the CRA. I think companies are waiting a bit to see what the first round of amendments delivers.

But you are right that we as a community need to put serious thought how we want this to work. We are in a better position to come up with workable solutions and we should, because the status quo isn't working. If we can come up with a workable structure and implement it, then the regulators will fall in behind us. If we don't, we'll get something suboptimal imposed. People are working on this, but the discussion is important.

(I saw a comment about how I may have special inside knowledge about this Act. This is not so. I have however read a lot of EU legislation, including drafts and amendments. I've read the EU treaties and how they interact specifically with Dutch law and it's 4 levels of government and 3 supreme courts and those with each-other. How the EU legislative process works and discussing it friends who study this but don't care about IT. Helping a cooperative work through the evolving regulation of the energy market is an interesting experience. The EU is a complex machine, but it's interesting to watch how people across a massive diverse continent can come to a consensus (or not, as some topics show). But it also has many limits.)

With respect to your point about the the context behind the article, I think what I really missed was info about the author, it was my first comment. Newspapers often include a short bio of guest authors and I think it would have been helpful here. For pure technical articles it doesn't matter so much, but for these topics I think it does.

to post comments

Risks of misinformation

Posted Sep 23, 2023 0:04 UTC (Sat) by pizza (subscriber, #46) [Link] (17 responses)

> The Apple, Googles, Samsungs, Ciscos, Microsofts, etc of this world have a vested interest to make sure they bear no liability for any software issue in products they release.

Sure. But there need to be clear, consistent rules, with potential liabilities and compliance costs that are *proportionate to the income derived from that software*.

> If we can come up with a workable structure and implement it, then the regulators will fall in behind us.

...This seems wildly optimistic to the point of naivety.

Especially as no matter how you cut it, _anything_ other than "no warranty whatsoever" is going to result in mandated unpaid labor (lest they face potentially massive punitive penalities) from F/OSS authors that have nothing to do with how widely (or for what purpose) their software is deployed.

I don't care about the Googles, Apples, or whatnot. I don't even care about the Apaches, FSFs, or other F/OSS-focused organizations that already have lawyers and accountants on retainer. I care about the long tail of one-or-two-person projects whom about the only rational option is to just delete everything and close up shop.

Risks of misinformation

Posted Sep 23, 2023 3:57 UTC (Sat) by pizza (subscriber, #46) [Link] (16 responses)

> I care about the long tail of one-or-two-person projects whom about the only rational option is to just delete everything and close up shop.

To put this in perspective, a basic general liability and E&O insurance policy has historically cost approximately 4x my average gross FOSS-related revenue. In a world where [as-currently-drafted-]CRA-style regulations are in place, those premiums will only go up, on top of the vastly increased costs of compliance (which is likely to eat up a significant portion of the already limited time I can put into F/OSS work to begin with!)

The options I see here are to [1] cease all commercial activity (ie shutter my side business) [2] jack my rates by at least 4x and effectively bring about #1, and/or [3] completely cease any independent F/OSS activities, by which I mean anything that could lead to liability falling onto me. Of course, there's also [4] roll the dice with potential financial ruin.

It's one thing to take a big risk if there's a realistic possibility of a big reward, but this is all risk and no reward. So #4 is out.
#1 would mean making myself entirely dependent on $dayjob, but I've been laid off twice in the past five years, and that side business has meant I could continue to keep a roof over my family's head. That leaves #3 as the only rational choice.

Risks of misinformation

Posted Sep 23, 2023 16:06 UTC (Sat) by kleptog (subscriber, #1183) [Link] (15 responses)

> To put this in perspective, a basic general liability and E&O insurance policy has historically cost approximately 4x my average gross FOSS-related revenue

If you're talking about E&O insurance, then it would appear you are delivering *services* in which case the CRA is not relevant to you (directly anyway). My impression is that the vast majority of people working in the open-community are delivering a service, namely, writing code for money. This makes sense, because the product itself can be downloaded for free. There are some exceptions, EnterpriseDB, Redhat, SUSE and Hashicorp come to mind.

I think you're putting too much stress on the liability part, since that's only really an issue if you're making promises about a product you're selling (assuming you're selling one) that leads to actual safety issues. The CRA is just the framework, which defines the terms under which a CE mark can be obtained. The actual details of what that means is not yet determined, and it will be a while before any possible certification becomes mandatory. Until then you can simply sell your product without CE marking and without warranty and you'll be fine. You might not be able to sell your product as part of some public procurement process, but I'm thinking that's not a goal for you.

The GP suggests I'm naive in thinking that the open-source community could get together and formulate the terms of what a "well-run security-conscious open-source project" looks like that the bigger projects could self-certify for. I hope I'm not because the alternative is someone like ANSI/ISO defining it and building a bureaucracy around it. Or worse, FAANG doing it. It's unfortunate, because I think we do, collectively, have a good idea what a "well-run security-conscious open-source project" looks like, we're just unwilling to write it down.

Risks of misinformation

Posted Sep 23, 2023 17:52 UTC (Sat) by Wol (subscriber, #4433) [Link] (4 responses)

> If you're talking about E&O insurance, then it would appear you are delivering *services* in which case the CRA is not relevant to you (directly anyway). My impression is that the vast majority of people working in the open-community are delivering a service, namely, writing code for money. This makes sense, because the product itself can be downloaded for free. There are some exceptions, EnterpriseDB, Redhat, SUSE and Hashicorp come to mind.

Which is why, if you have a decent contract, you should hopefully be able to say "I am writing code at your request, you are responsible for making sure it does what's required". Then they are responsible for getting it certified and paying you to fix it if necessary.

Which is why, for projects of any size, I bang on about trade associations. A couple of developers get together, with a couple of clients each, form a trade association which says "for our members we will fix all known problems and certify them", and then all of a sudden we might have a decent financial basis for developers to make an income - selling certification. :-)

Cheers,
Wol

Risks of misinformation

Posted Sep 23, 2023 21:05 UTC (Sat) by pizza (subscriber, #46) [Link] (3 responses)

> Which is why, if you have a decent contract, you should hopefully be able to say "I am writing code at your request, you are responsible for making sure it does what's required". Then they are responsible for getting it certified and paying you to fix it if necessary.

Sure, and then they'll push back with a "ok, but just in case there's a problem, we want you to carry a $2 million liability policy" and when you inform them that this policy will cost more than the project budget, and you'll have to double your rate to cover the cost.

(This has happened to me, twice)

> Which is why, for projects of any size, I bang on about trade associations. A couple of developers get together, with a couple of clients each, form a trade association which says "for our members we will fix all known problems and certify them", and then all of a sudden we might have a decent financial basis for developers to make an income - selling certification. :-)

In other words, significantly increase the barrier to entry.

Risks of misinformation

Posted Sep 23, 2023 21:17 UTC (Sat) by Wol (subscriber, #4433) [Link] (2 responses)

But at least then, you've had the conversation with them, that these guarantees cost money ...

But yes, I understand what you're getting at, as a sole trader this is going to be difficult (but if you've had that sort of conversation before, why will the CRA make any difference?).

Cheers,
Wol

Risks of misinformation

Posted Sep 24, 2023 0:48 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

> If you've had that sort of conversation before, why will the CRA make any difference?

Because under the CRA, what used to be directly billable has been turned into general overhead that folks will expect me to provide as a matter of course.

If your operation is of sufficient scale then it's not going to be that big of a deal, but my "part time consulting/support services" operation is light years from that point.

Risks of misinformation

Posted Sep 24, 2023 5:13 UTC (Sun) by wtarreau (subscriber, #51152) [Link]

That's exactly the root of the problem: people with development skills will have to stop development to spend 100% of their time on legal stuff and bureaucracy. And the EU is champion on bureaucracy. It needs to remain simple so that one doesn't have to fear a certain interpretation of the rules.

The benefits of F/OSS was recognized to the point that in the last few years, some developers saw their software land on Mars. It would not have been imagined 20 years ago that software developed by random people around the world could be critical to a space mission success. This is thanks to the commitment of these people on delivering as high quality code as possible without the fear of any liability nor anything else: 100% of their focus was on technical excellence. I'm afraid it might be the last time we see F/OSS software on another planet. what if the probe is hacked during it way due to an overflow bug on the deployed software and the mission ruined ? In practice any F/OSS developer would rather decline any request for help in getting their software better integrated because they won't know if that's going to expose them to a legal risk.

Risks of misinformation

Posted Sep 23, 2023 20:52 UTC (Sat) by pizza (subscriber, #46) [Link] (2 responses)

> If you're talking about E&O insurance, then it would appear you are delivering *services* in which case the CRA is not relevant to you (directly anyway).

(So this means RHEL is not covered by the CRA? After all, Red Hat is selling "Services", not "software?")

"directly anyway" pretty much is my entire point! By providing *services* associated with the software I also provide, I became a "manufacturer" and thus am on the hook for compliance, liability for security issues, noncompliance, etc. The "commercial activity" is the gating factor.

> I think you're putting too much stress on the liability part, since that's only really an issue if you're making promises about a product you're selling (assuming you're selling one) that leads to actual safety issues.

I use "liability" to refer to the penalties for noncompliance with the CRA -- this can be direct penalties (eg government/court-ordered fines) or indirect penalties (the "cost" of fixing issues that may arise, and/or the cost of being sued). These penalties/liabilites/etc are the kudgel that the CRA uses to achieve its goals.

And the CRA is intended to cover far more than "safety issues" -- Anything connected to the internet needs to be kept up-to-date for security issues that might result in ransomware attacks, data breaches, botnet/etc participation, and more. And sure, potential safety issues too, but there's not a lot of things that can be done with software running on a general-purpose computer that could lead to a physical safety threat.

Risks of misinformation

Posted Sep 24, 2023 5:23 UTC (Sun) by wtarreau (subscriber, #51152) [Link]

> Anything connected to the internet needs to be kept up-to-date for security issues that might result in ransomware attacks, data breaches, botnet/etc participation, and more.

Which is another problem nowadays with few vendors providing long term support. Even if new software versions are provided, very often the user will experience some breakage, which is the very first cause why users don't apply updates. Many of us know the same with an old laptop having a nice combination of a properly tuned window manager, editor and various settings that we don't want to lose across an upgrade. I know people still using Windows XP because it just works and newer versions completely changed the way everything is organized and they don't understand it. Result: as long as XP works, let's not touch it. That's why I consider it important that most of the time the hardware dies before the software, especially for devices connected to the internet. And BTW we should avoid connecting devices that don't strictly require it. When I see the printer we have at work which sends requests to AWS for each button you press and that sends your scans there, it's unacceptable as it exposes the internal network to possible risks on these clients. And from a consumer perspective, who knows how long it will work, if the vendor can shut down the service when they want ?

Risks of misinformation

Posted Sep 24, 2023 22:01 UTC (Sun) by kleptog (subscriber, #1183) [Link]

> (So this means RHEL is not covered by the CRA? After all, Red Hat is selling "Services", not "software?")

Possibly. What would you like the answer to this question to be and why? This is the sort of discussion we as a community should be having. Does it matter that the precise source code they're shipping is not available to non-customers?

Should Firefox/Chrome be held to a higher standard than OpenOffice or Gimp? How and why?

> By providing *services* associated with the software I also provide, I became a "manufacturer"

Sorry, I don't see this supported by any text, and it doesn't make any sense either. A manufacturer is someone that amongst other things, markets a product under a trademark they own. Whether you provide services associated with it is not relevant. What's really relevant here: the manufacturer is the person that can fix any problems.

> And the CRA is intended to cover far more than "safety issues"

Sure, this is confusing two things: when it comes to liability with respect to some (security) event, that's only relevant when talking about safety issues. The CRA covers many more things, but then you're only talking about non-conformity which is something else.

I guess the thing that surprises me most about this whole discussion is that I thought one of the big things about open-source is that people publishing/distributing code did so with a sense of "I made an effort to produce good code, as free of (security) bugs as I could manage". It seems that a sizable portion of the community doesn't feel this, or at least isn't willing to state it publically. That makes me sad, but I guess explains the dismal state of the software industry.

It's basically the "This is fine" meme, while the building burns down around you.

Risks of misinformation

Posted Sep 23, 2023 20:58 UTC (Sat) by pizza (subscriber, #46) [Link] (3 responses)

> I hope I'm not because the alternative is someone like ANSI/ISO defining it and building a bureaucracy around it.

I'd argue that creating these certification bureaucracies is one of the goals of the CRA. It doesn't matter if it's a "FOSS organization", or ISO or whatever, they're going to have to jump through whatever hoops the EU sets up to provide certifications (on an ongoing basis) which will of course require staff and ongoing funding.

Risks of misinformation

Posted Sep 24, 2023 22:09 UTC (Sun) by kleptog (subscriber, #1183) [Link] (2 responses)

CE certifications are mostly done on the basis of self-assessment. There are products that require a third-party audit, but most don't. I would not expect software under the CRA to require an external party to assess them since most electrical devices (ie the computer they run on) don't either.

Third-party certification

Posted Sep 25, 2023 16:58 UTC (Mon) by ghodgkins (subscriber, #157257) [Link] (1 responses)

> I would not expect software under the CRA to require an external party to assess them since most electrical devices (ie the computer they run on) don't either.

You seem to have more knowledge about EU law than me, but from a plain reading of the current CRA text this seems at least slightly incorrect. Section 5, chapter 3 states that manufacturers must get external certification for "critical" class II products. Class II products are listed in Annex III; the category includes routers and CPUs along with several types of software: operating systems, hypervisors, container runtimes, public key infrastructure, and firewalls.

The question then becomes whether the product is "critical" - I believe that's a case-by-case decision made by a panel of bureaucrats. So it seems likely that the CRA will require third-party certification for at least some software, as well as the electronic devices it runs on.

Third-party certification

Posted Sep 26, 2023 8:51 UTC (Tue) by kleptog (subscriber, #1183) [Link]

I can see how what I said may have been confusing. I should have qualified "software" with most.

The computer/laptop you're using (if you didn't build it yourself) came with a CE mark. Many parts inside it also came with a CE mark. It's CE marks all the way down. The CE mark for the computer as a whole basically amounts to an assertion that the integrator checked all the components had a CE mark and that they were put together in accordance with the guidelines of those components. No third party checked whether they actually wired everything up correctly.

It's true that there maybe be components in there that had a third party audit (the WiFi chip?) but that's not something the builder of the computer needs to worry about. They just need to check the documentation of the chip and that they followed the guidelines.

It will be interesting to see which components in Annex III survive, the list was severly shortened by the Council.

> The question then becomes whether the product is "critical" - I believe that's a case-by-case decision made by a panel of bureaucrats

Hardly. The EU doesn't have the manpower and the regulators (all 27 of them) will be chronically underfunded, regulators always are. Bureaucrats are not your problem. The way this usually works is that whether a component is "critical" is agreed buy the buyer/seller when the contract is signed. The only time this will be checked is by a judge in the case of some liability suit. Then all the CE marks will be checked in the process of determining who is liable for what. If you think you can convince an uninvolved third party (aka a judge) you're not a critical product, you're good.

If a judge determines you are a critical product and you don't have the requisite audit, even the most underfunded regulator is going to see a chance for money. The idea behind all this is to try to configure the market to regulate itself via market forces, so governments can save money on the regulators themselves.

But you are right in a sense: many products will get third-party audits... by their customers doing due diligence on their suppliers. As long as you make clear agreements with your customers about who is responsible for what, you're set.

Risks of misinformation

Posted Sep 25, 2023 8:11 UTC (Mon) by ballombe (subscriber, #9523) [Link] (2 responses)

> Or worse, FAANG doing it. It's unfortunate, because I think we do, collectively, have a good idea what a "well-run security-conscious open-source project" looks like, we're just unwilling to write it down.

I am not sure. Consider the original IJG libjpeg library. It has not has a single serious vulnerability in 25 years.
On the other hand, libwebp from 2011 has had tons of serious vulnerabilities.
Is it that Google programmers are incompetent and do not know how to write safe code ? Certainly not.
The fact is that security is not seen as a real priority even by "well-run security conscious open-source project"
and issuing updates to fix vulnerabilities instead of writing correct code from the start is seen as acceptable
if this allows for faster development or faster code, despite claims to the contrary.

Risks of misinformation

Posted Sep 25, 2023 9:45 UTC (Mon) by Wol (subscriber, #4433) [Link]

> and issuing updates to fix vulnerabilities instead of writing correct code from the start is seen as acceptable

THIS!!! IN SPADES!!!

Cheers,
Wol

Risks of misinformation

Posted Sep 26, 2023 5:01 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> I am not sure. Consider the original IJG libjpeg library.

Uhh... Whut?

There are some CVEs for it: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libjpeg

Looking deeper, it looks like nobody is actually using the original libjpeg, everyone seems to be using libjpeg-turbo. Debian even uses it to provide libjpeg, they seem to have switched some time in the previous decade.

So it looks more like the case of nobody really caring about it.