This weekly roundup thread is intended for all culture war posts. 'Culture war' is vaguely defined, but it basically means controversial issues that fall along set tribal lines. Arguments over culture war issues generate a lot of heat and little light, and few deeply entrenched people ever change their minds. This thread is for voicing opinions and analyzing the state of the discussion while trying to optimize for light over heat.
Optimistically, we think that engaging with people you disagree with is worth your time, and so is being nice! Pessimistically, there are many dynamics that can lead discussions on Culture War topics to become unproductive. There's a human tendency to divide along tribal lines, praising your ingroup and vilifying your outgroup - and if you think you find it easy to criticize your ingroup, then it may be that your outgroup is not who you think it is. Extremists with opposing positions can feed off each other, highlighting each other's worst points to justify their own angry rhetoric, which becomes in turn a new example of bad behavior for the other side to highlight.
We would like to avoid these negative dynamics. Accordingly, we ask that you do not use this thread for waging the Culture War. Examples of waging the Culture War:
-
Shaming.
-
Attempting to 'build consensus' or enforce ideological conformity.
-
Making sweeping generalizations to vilify a group you dislike.
-
Recruiting for a cause.
-
Posting links that could be summarized as 'Boo outgroup!' Basically, if your content is 'Can you believe what Those People did this week?' then you should either refrain from posting, or do some very patient work to contextualize and/or steel-man the relevant viewpoint.
In general, you should argue to understand, not to win. This thread is not territory to be claimed by one group or another; indeed, the aim is to have many different viewpoints represented here. Thus, we also ask that you follow some guidelines:
-
Speak plainly. Avoid sarcasm and mockery. When disagreeing with someone, state your objections explicitly.
-
Be as precise and charitable as you can. Don't paraphrase unflatteringly.
-
Don't imply that someone said something they did not say, even if you think it follows from what they said.
-
Write like everyone is reading and you want them to be included in the discussion.
On an ad hoc basis, the mods will try to compile a list of the best posts/comments from the previous week, posted in Quality Contribution threads and archived at /r/TheThread. You may nominate a comment for this list by clicking on 'report' at the bottom of the post and typing 'Actually a quality contribution' as the report reason.
Jump in the discussion.
No email address required.
Notes -
I don't think you understand how this works if you think that this is the only necessary step once this becomes an obligation by law.
Since this is a potential liability, someone will have to be responsible for filling that form, and they'll also have to have sufficient means to enforce that the form is true. That person is most likely a lawyer and not technical themselves, which means they'll have to rely on auditors, which means not only that you'll have to pay money to get those audits done, you'll also have to find a company that will do them on the tech stack that you are running and is familiar with the intricacies of the particular legislation you're trying to abide by.
And once the bureaucratic machine gets started like this it doesn't stop, standards will get more complex, there will be people whose whole job is to ensure that they are followed and the costs will balloon accordingly.
Compliance is a huge industry. If following the law was that simple, it would not be.
Like Bastiat says, there is what is seen and what isn't seen.
What is seen is the valuation of established companies that have compliance departments and who'll be able to integrate regulation with a marginal cost change they can pass on to the consumer. What isn't seen is how much harder it is or will be to get funding for a startup that designs novel appliances because the costs to enter the market are now higher.
Weird. I hear about that from my friends in literally every other industry ever. They still seem capable of operating.
I'm always sympathetic to concerns of regulatory capture putting barriers to entry in front of small businesses. Totally agree that this is the single strongest argument against these types of requirements. I just doubt that these particular requirements are that onerous. Plenty of smaller shops that actually care about not being a security clusterfuck already do these kinds of things, and you can do most of them without too much difficulty as a hobbyist. In any event, if you're a start up that can't figure out how to not have a default password on all your devices, I actually kind of don't want you selling stuff, anyway.
Eh... they vary a lot, both on context and use case. Requiring secure storage for persistent storage of security parameters (5.4-1) makes sense and has trivial cost for applications like a network storage device, but it'd break a lot of assumptions on FRAM-heavy low-power devices, and that rule notably isn't conditional or a mere recommendation -- perhaps they didn't think about FRAM, or other persistent memory, but I wouldn't bet against UK compliance checks taking that as an excuse. Making security-focused unique IDs tamper-resistant (5.4-2) isn't too bad on a device with a real MAC (though not costless; there are benefits to software-changeable settings here), but for the more ultra-small or ultra-disposable equipment that's largely going to mandate more and more of program flash be devoted to encryption keys (unless you want to decrypt something on discrete flash every time you're doing an update check). Mandating a network update happen over a trusted relationship (5.3-10) and be timely (5.3-6) and be automatic (5.3-4) isn't too bad for a situation like deploying a bunch of wifi access points or phones, as much as I hate 99% of implementations work, but it's an absolute mess for wide deployment public LoRaWAN devices, and a mess for things like CAN- or LIN-networked embedded devices.
Others vary heavily on interpretation. Mandating that "For constrained devices that cannot have their software updated, the product should be isolable and the hardware replaceable" (5.3-15) could mean almost nothing, or it could require vendors to commit to support any optional part of a product until they retire an entire series. And these all definitely kill EPROM devices that it covers -- I'd expect this ends up with a ton of explicit or implicit exceptions, mostly around the "On devices with several microcontrollers (e.g. one for communication and one for the application) some of them might not be updateable", but it's not really obvious from the text.
That gets worse if they start dialing Mandatory-Conditional or Recommended rules into plain Mandatory ones down the road, and a lot of the text suggests that they're planning it:
In particular, SecureBoot (5.7-1), hardware memory access controls (5.6-8), and guaranteeing cryptographic updates for the life cycle of the product (5.5-3) mean throwing out a lot of existing microcontrollers, microprocessors, and often related code. It's clearly intended for big GHz+ microprocessors, but there's a lot of new (mmu'd!) chips that don't have this capabilities. SecureBoot there's some arguable conclusions for some of the bigger devices, like throwing a ATECC608 after a PIC, but a) I'm not sure if that actually complies with the recommendation, and b) no, god, no. Hardware memory access controls... maybe ESP32 memory protect would cover it (though they're software-settable, though the software settings are code-private?). Wherever these hit, a lot of chips aren't going to pass it, and businesses focused around them are going to have to toss inventory and code -- there's just too much of this stuff that isn't portable.
A number are probably gonna have to start now on the off chance that it happens in a couple years.
Now this is the type of response I was hoping for! Actually engaging with the substance!
Perhaps they'll issue a clarification, but from the note in this section, I think someone could read this as "memory"; it has "memory" right in the name! In general, I do expect there to be some clarifications along these lines as folks like you bring up additional concerns.
This one is conditional, and I imagine ultra-small or ultra-disposable devices won't qualify in the first place.
Same here; conditional. We'd at least have to get down to the level of thinking about each of the devices you've mentioned in terms of the conditions.
Notice how they define isolable:
In the section describing the rule, they continue:
I think I would interpret this as, sure, you need to support any part of a product until you tell the customer that you're not supporting it anymore, and the type of support can vary.
Yeah, I have a feeling that these aren't going to pop into the Mandatory category for a while. The real good news is that concerns are really of the type, "Will they at some point make these Mandatory, when it is still too soon?" Because pre-rule-dropping, I imagine the worry would have been of the type, "Will they make this stuff Mandatory now?" And, they, uh, didn't. I think this document shows a pretty decent level of care in getting some of the really basic stuff right and showing the industry the direction they'd like to go in the future. There's no telling at this point whether it'll all actually go that way; one has to imagine that there are differing worlds where it seems more/less plausible to upgrayyyed these Recommendatations into Mandatory.
Whereas this one, I think is fine, given their explanation:
How easy is that? You don't even have to update it at all. But if you do, then at least make sure your shit isn't trivially broken, at least so long as you're telling the customer that you're still supporting it.
Maybe, but so does CMOS RAM, and that's a central example of where you probably do want this rule to apply, and it's (usually) more volatile than FRAM. 5.4-1 to my read isn't about access modes or media type, but about storage volatility, and that makes some amount of sense for certain attack vectors -- you don't want someone reading cloud passwords by probing random SPI flash, as weird as that particular threat is.
But it also makes a lot of design spaces for low-power devices goofy, in ways that don't make sense. There's probably a class of low-power device where it's a really critical security problem is someone delid the main processors and inspects individual FRAM cells during a toggle-off state, but 99% of the time even if someone could hijack a session id from that it's less big of a deal than having access to the board to start with.
Yeah, but the condition is only that applies where ever "a hard-coded unique per device identity is used for security purposes". I think that includes virtually every LoRaWan (DevEUI) and probably every LoRa device, for one common example, but also technically at least most Bluetooth implementations. There's other places where it's a good idea to use hard-coded unique identities per device for security purposes even where it doesn't 'matter', and that's largely going to result in people just dealing with stupid hacks instead to avoid triggering the requirement whenever possible.
Yeah, but the conditions for 5.3-4 is "an update mechanism is implemented", 5.3-6 "an update mechanism is implemented" and "the device supports automatic updates and/or update notifications", and 5.3-10 that "updates are delivered over a network interface" and "an update mechanism is implemented". These are fine when you're talking a full web-UI/app-equipped device, but twenty sensors on a LIN line that can be updated still hit the requirement for 5.3-4, which is on its own a requirement for automatic updates so you now hit 5.3-6. Then you're trying to figure out how 5.3-10 works for devices that don't have user interfaces (and may not have user physical access!), and now you're either stuck tossing an authentication layer on your LIN, implementing a cryptographic security function for comms on said LIN, or spamming users with update notifications like they were running Arch Linux.
Eh...
Let's take the example of a lightning switches attached to a base station, as a fairly common home automation setup where the switches and adapters are... not actually a central case of the constrained device model (they have wall power!) but are at least arguably close. If you build one of these, you're probably going to support a wide variety of light bulb sockets and switch types, but not all of those are going to make sense over the longer term -- maybe a socket type falls out of popularity, or a new lightbulb tech drops that doesn't play well with dimmer circuits, or a vendor you partner with stops selling a product that makes that particular device make sense.
By the text, is a lighting hub "isolable and hardware replaceable" if the vendor doesn't want to sell every attachment for the hub's life cycle? Removing one attached device doesn't make the attached device 'isolable', because turning on and off that light is its core feature. Nor is removing the entire hub from the internet, since there's no sane way to call that a "self-contained environment with other devices if and only if the integrity of devices within that environment can be ensured", when the especially if the entire reason to pop them off the internet has to do with their ability to communicate securely with the local hub. Would it be hardware replaceable is the only hardware replacement doesn't actually fit into the same socket, just because something attaches to the same hub?
Yes, in practice your interpretation is the sane one, and hopefully it's probably going to end up as the sort of asterisk that just confuses people, like vendors just putting out generic 'support may stop without notice for some devices' clauses. But at best that turns the requirement into aspirational text instead of the actual policy.
I think the interpretation of that standard is closer to page 45-46 here, if not on the exact same timelines, and that quickly turns into an eWaste and version hop mandate for a lot of stuff pretty quickly in order to theoretically prevent the plausibility of certain attack classes, rather than blocking trivial ones. But even for its steelman of "don't use WPA2-only chips in new products", I think it's still costly even if well-intended, and a lot of those costs don't make a ton of sense. There's a number of chips and equipment that can't connect on WPA3 at all, and even where it's something that can be implemented in software that doesn't mean it's exactly easy.
More broadly, though, it seems like overbroad application of a rule. A presumption toward encrypting everything makes sense when it's free or nearly-free, but there are a lot of entire devices where it's just not that relevant. If your equipment does literally nothing but relay temperature and humidity values over ISM bands, you might want some amount of authentication to prevent spoofing, but it's really not that big a deal if someone can listen in. And there's a lot of IoT stuff that goes into that category.
There's some parts of the rules that motion around this -- 5.5-1's "Appropriateness of security controls and the use of best practice cryptography is dependent on many factors including the usage context" or the exceptions for ARP, DHCP, DNS, ICMP, and NTP in 5.5-5 -- but again that turns the requirement into aspirational text.
Fair enough. Hopefully the worst case is that this ends up not being covered, even though it should be.
I think I can agree that there may be tradeoffs here for some devices.
I think these would almost certainly just be classified as "constrained devices", and they also give alternate mechanisms for valid trust relations, which I think will be what the automakers go for. They'll do the verification at a different step and say that the lack of physical or other access is what ensures that presence on the network is sufficient.
I think you're right that some portion of this is aspirational text, but I think it's along the lines of, "If you can just put some reason down on the table for why this should be considered aspirational text, then you're probably fine," and the only people who are at risk are the people who are doing the clearly and obviously boneheaded stuff. Like, I don't think it's going to be hard for the maker of a device that does nothing but relay temperature and humidity values over ISM bands to just say, "It's a constrained device; can't do any of that fancy stuff; pretty much no way in anyway," and we can all mostly go home happy. If we start having major corporate networks brought down by botnets of temperature monitors (uh, how?), then perhaps folks will have to figure out how to make it more than aspirational text.
In any event, thanks a bunch for really thinking through edge cases for a wide variety of really specialized and, for lack of a better term, really constrained devices.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
In the specific case of the UK, most industries are not doing well, I believe in part due to a regulatory environment that makes it very hard for anyone to do anything.
More options
Context Copy link
Sure, and Harrison Bergeron could walk with a junkyard's worth of scrap metal stuck to him. It's a handicap, not necessarily a fatal one (though sometimes it is).
More options
Context Copy link
Where is the innovation in any other industry over the past decades exactly? You know, since they brought these in.
How expensive is it to build a bridge now, versus a hundred years ago, adjusted for inflation? "capable of operating", what a joke.
As Kulak is fond of saying, the reason we don't have flying cars isn't that they haven't been invented, it's that they've been made illegal. They were commonly flown (and shot down) by teenagers in the 1910s.
This is the tired same equivocation that motivates all such regulatory barriers. I complain about having to fill forms, you retort about the justifications for the form existing as if I didn't also have such a concern.
There are other answers to the problems of humanity than increasing the size of the bureaucracy. Just no other that fits into managerialism.
what do you mean by this? A homemade airplane isn't the same as a flying car. I guess it could work if you live in a very rural, but the problem with airplanes is that you need a long runway both to takeoff and land, plus clear airspace. That makes them impractical for anyone living in a city. A flying car could theoretically fit in your garage, take off/land vertically, and fly carefully enough to avoid collisions in the sky.
A Sopwith Camel fits in a garage and can take off and land on a piece of uneven land 300m long. And that's with 1910s technology. Central Park is 13 times longer.
The reason we have long runways for planes these days is because they are optimized for speed and drag, not lift. Which means they have weak landing gear and swept wings.
We had flying cars, we have the technology, they're just illegal to operate.
300m long is more than three football fields! That is an absurd amount of space for anyone in a city, where we fight over parking spaces that are about 3 meters long. The one @ToaKraka linked sounds better, but 75m is still way too much space for most people. You also need enough space in the sky for othem to fly without running into someone else, which can happen at any angle in three dimensions. It could work for a select few, but... we already have that, with private planes and helicopters.
Besides, if we're going this route, why not bring back zeppelins? The Empire State Building was designed with a spire so zeppelins could dock on top, as were several other buildings of the time.
I mean if we're talking theoretical numbers, in STOL competitions the world record for shortest landing is a little over 9ft, in aircraft that look very much like WW1 fighers or WW2 recon planes: high lift extremely light tuboprops. That part of the problem isn't really that difficult, it's more of an engineering and architecture problem than anything else.
The safety thing is the real reason, but valuing that over flying cars is parochial to the modern societies we live in. It's a cultural rather than physical limitation.
You might be joking but people keep saying that will happen since we solved most of the technical issues and helium isn't that expensive anymore.
The problem is that they're slow and their only advantage over planes is fuel efficiency and thus range. Making them only really suited for large scale transport where they don't have enough of an edge over boats or rail.
Helium's gotten cheaper? I thought there was a huge shortage after they finished selling off that absurdly massive strategic helium reserve.
I guess I just meant cheaper than a century ago, but I hadn't heard about the US reserves finally being fully sold this year. I guess I should come to the Motte more often for more helium trading news.
But yeah probably no zeppelins anytime soon. Winged aircraft wins again.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
See also the autogyro/gyroplane/gyrocopter, developed in the 1920s, which can use 75-foot (25-meter) runways.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
Let's go with a simple one - the shale fracking revolution in the oil/gas industry. But nobody is actually going to go counting these things, because no one really has any sort of consistent argument for which sorts of regulations stifle innovation. Again, I totally realize that they do sometimes, in some ways. But what sort of massive innovation is going to be stifled by requiring devices to not have default passwords? Like, surely we can agree on that one. We could at least leave open arguments for other requirements, and I would welcome a wide-ranging debate on them. But if we're stuck with just theoretical arguments, totally disconnected from any specifics, in a way that can't capture basic truths like, "Being forced to not have default passwords is not a significant barrier to innovation," then we're not going to get anywhere.
Ok, so you also have a concern about default passwords. What are you going to do about your concern?
This isn't exactly a revolution. The tech behind shale fracking was known for quite some time, it just wasn't put to use because the costs associated with it meant that it was uneconomical. It wasn't a major shift or technological advance that unlocked shale, but an increase in the cost of energy and a lot of financial chicanery that made it competitive with traditional fuel sources. There's a very plausible case to be made that the technology is ultimately a loser, and that the environmental damage it causes in the long run will be more expensive than the economic value derived from the crap fuels you get out of it.
More options
Context Copy link
Since we are talking about the UK, shale fracking is illegal there. Hardly a revolution.
Irrelevant. Obviously, people can choose to regulate something specific away. The question is whether there has been "any" innovation in "any" other industry (that is, the non-bits ones that have more regulation). Unless you're claiming that the US has no regulation on the oil/gas industry, the shale revolution, which literally has changed the world at a geopolitical scale, is a huge counterexample.
But there are many others. Space X. Ozempic. Etc. It's really hilarious to have all the huge techno-optimists, who think that AI and tech more broadly is going to revolutionize literally everything, and at the same time, they imagine that the tiniest amount of regulation on fucking light bulbs will grind literally everything to a halt.
That you can scoff at the idea that regulation can kill innovation doesn't mean it cannot.
I have never objected to the idea that regulation can kill innovation. Try again. Actually read what I've said and respond to it rather than a strawman. You have to at least try.
I'm following this conversation from the sidelines, and you're sure not making it easy to understand what you're actually saying, or what's it you're interested in debating, beyond generic sneering.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
That is a fair one, but It's also a very good example of just what I'm saying. I was part of the few people on the quite unpopular side of the oil industry here in Europe in the 10s when it was banned, for the same reason I'm on this side of this issue now.
If the UK wants to make such regulations it will reap the same sort of benefits: no toxic chemical pollution or chinese crap botnets, but also no innovation in these respective sectors.
It's a choice.
You can not like that enforcing common sense rules to an industry through state mandates is a barrier to innovation all you want. It's not going to stop being true. The debate is only on the magnitude of the effect.
I don't buy chinese crap that spies on you, I tell people not to buy chinese crap that spies on you and I shame people who do so in my social circles.
Hell, I've spent years of my life writing symbolic execution software used specifically to make edge devices secure, some of which you may be using right now. What have you done?
So, will you then make a prediction along the lines of what I asked for in the OP? Are you predicting that tech companies will pull out of the UK rather than either upgrayyyeding their security practices for the world market or going with a dual product (one version that doesn't make absurdly basic mistakes for the UK market and one that does make those mistakes for the world market)?
And I claimed that being forced to not have default passwords will have an incredibly low magnitude effect on innovation. Do you actually disagree with this, or do we agree?
I do the same, but clearly that is not changing much about the world. Have you succeeded in changing the world through your evangelism?
Then I'm sure you will be pleased that this work won't be going to waste by someone shaving a few cents off of the cost of your product by putting a default password on it. Honestly, hearing this, I'm really not sure what your concern is. Is it that your company's "We're Actually Secure" marketing is going to be slightly less effective, now that the floor has been raised? Did you really think that such marketing was really of all that much value in the first place? @The_Nybbler thinks that it's completely a waste and that no one would spend one red cent more for your secure product. Do you think he's wrong?
I can easily commit to saying that no major IoT startup success is likely to be based in the UK any time soon. But that's saying nothing given they're pretty much all American already for many other reasons.
Maybe some guy at Arm will have to add one more form to some pile or something.
Europe at large is a dying crab bucket that everybody who can make things is leaving because if you try you reap only taxes and lawsuits.
That's my concern. John Galt is my concern.
Yes and no. No chinesium lightbulb maker is ever going to bother with formally proving their code is correct because they don't care. But some connected things actually need to be secure so that you don't explode, catch on fire or get robbed.
I find the actually useful non gimmicky applications of IoT are in this latter category, and that for those the customer and the manufacturer usually know better than to cheap out.
Bruce Schnier noted that California had already implemented at least the number one item. Do you think that this is enough to also say that no major IoT startup success is likely to be based in California any time soon?
I don't believe anything in this requirement is aimed at formal code verification methods. I don't think that's a requirement that is on the table anywhere, except for perhaps some niche customers (e.g., military/space). Probably not even at most "critical infrastructure" places that could blow up or whatever.
I mean, honestly, if that's about all you have to say for what results from this, that no chinesium lightbulb maker is going to meet a standard that hasn't been proposed and that some critical application spaces are going to pay for good stuff anyway, that's kind of a nothingburger? Like, abstract senses about Europe (not even the UK) and wild references to John Galt aren't really "concerns" that can be addressed in context of the very specific document that we have in front of us. It really seems like you just don't have any meaningful concern that we can investigate.
Nah, California has inertia and the funding apparatus there is still stronger than anywhere in the world, which is more meaningful. Not to mention the regulatory framework for innovation in general is looser in the US.
But it's telling that the companies that exist right now that fit the bill are also in Texas and Massachusetts these days, that used to be more rare. I wouldn't be surprised if we see some exodus. But it's probably down to the taxes than line items from small regulation.
You're forgetting automotive and think that energy grid infra is a lot looser than it actually is, but other than that it's broadly correct.
I think we're talking past each other. This regulation in and of itself is a nothingburger. It's the tendency I'm speaking to, which is what was alluded to in the OP.
Regulation is a dynamic process, it never stops at one law and very few of its slopes are not slippery.
In this house we discuss the Bailey, not the Motte.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link