site banner
PaperclipPerfector  6mo ago (text post)   24829 thread views

Culture War Roundup for the week of May 6, 2024

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.

6
Top Bottom Old Controversial Comments
Jump in the discussion.

No email address required.

The "S" in IoT stands for Secure

Boy, looong ago now, I broached the topic of security standards for techno-mabobs. At that time, I mentioned that the UK was considering some legislative proposals on the matter. I can't find the comment where I described what I viewed as the core driver of the tension over the topic - the culture of tech folks. That is, they are so used to the 90s consensus that software is gee wiz magic that is pure and sanctified, is the solution to world peace and all of life's problems, and can never possibly be the cause of anything bad, ever. The 90s conclusion was that government absolutely can. not. touch it. Hands off. No regulation whatsoever. No liability whatsoever. No matter what happens, they must have an absolute immunity stronger than even the strongest version that Donald Trump could have ever dreamed of claiming.

Justifications for this view have shifted, but I've always felt they've had a flavor of, "We can't be regulated! We're autistsartists! We make unique snowflake masterpieces! We have to move fast and break stuff! If we're ever held accountable for breaking anything, even for the most egregious of practices, then the entire economy will grind to a halt!" Whelp, after years of incident after incident exploiting the IoT-of-Least-Resistance, including things like ransomware takedowns of major corporate networks and huge botnets of smart refrigerators, we're about to see how true that really is.

Hitting the wire last week, the UK has dropped regulation for smart devices that are sold there. In my original comments five years ago, they were proposing three items; I had only asked for one (the most incredibly basic one - don't have every bloody device have the same default password). I really feel like it's a case of, "If you resist and throw enough of a shitfit over the really simple stuff, it's going to come back around in a much stronger way that you really won't like." The full document of "Baseline Requirements" speaks to fourteen items:

● No universal default passwords

● Implement a means to manage reports of vulnerabilities

● Keep software updated

● Securely store sensitive security parameters

● Communicate securely

● Minimize exposed attack surfaces

● Ensure software integrity

● Ensure that personal data is secure

● Make systems resilient to outages

● Examine system telemetry data

● Make it easy for users to delete user data

● Make installation and maintenance of devices easy

● Validate input data

● Data protection provisions for consumer IoT

Each area is broken down into one or more specifics. There's a helpful table on page 32, detailing whether the requirement is Mandatory, Recommended, and/or Conditional. This is important to know, because a bunch of them are truly just recommendations, but even many of the ones that are Capital M Mandatory are also Conditional, which is actually displaying quite a sense of care about the diversity of devices and possible situations. For example, they acknowledge things like "constrained devices", which is a "device which has physical limitations in either the ability to process data, the ability to communicate data, the ability to store data or the ability to interact with the user, due to restrictions that arise from its intended use". Here, they give some explicit examples, like "The device cannot have its software updated due to storage limitations, resulting in hardware replacement or network isolation being the only options to manage a security vulnerability."

I think this truly is a culture war between the culture of technokings and the culture of They Can't Keep Getting Away With This, and no culture war offensive ever comes without a counteroffensive. Will major corporations, either American or Chinese, bow the knee? Will they pull out of the UK in a weird, polar opposite anti-security stance to the position that has led other companies to pull products like Signal/Telegram from countries that threatened to make them less secure? The UK may be the sixth largest economy in the world by GDP, but that's still only about 4%. Will they go full tizzy and make separate products, where the secure versions go to the UK and the less secure versions go elsewhere? If they don't pull out and don't make different versions, than everyone in the world just got a huge security upgrayyyed. If they don't pull out and make different versions, other countries have a green light to mandate that they should also get the good stuff. So, if they're even thinking about pulling out, they've gotta rally the troops, punish any defectors, and really make the UK feel blockaded as a warning shot to the rest of the world.

My guess is that they'll bow the knee and just do this stuff for everyone. It's pretty much all stuff that everyone has known that they should be doing for quite a while now. Will it cost a little extra? Sure. Will they have to deal with some annoyed developers who feel constrained by law, as basically every other industry ever does, and eventually have to bring their culture into the Industrial Age? Sure. I doubt that having to pay $9 for a smart plug instead of $6 is going to change much about the economics of wiz bang gizmos... but it just might be a step toward not having newspapers filled with nightmare exploits causing millions in damage... at least not every week.

Humans are part of the Internet of Things.

I'm not going to use this as an argument to say that we should or shouldn't be having the elites lock down these devices more. But we should be very careful and aware. Most people see a greater distinction between human and non-human devices than actually exists.

As a result they have a huge blindspot. The average citizen thinks that it is possible to create new technologies for controlling machines without creating new technologies for controlling people. But this is not the case, because we are living on the same Fractal Godelian Battlefield as our devices.

In related UK news, the head of Cybersecurity for the treasury earns... 57K Pounds or 12% of comparable positions in business: https://twitter.com/jontafkasi/status/1641193954778697728?s=46

Just the other day the MoD was hacked: https://www.independent.co.uk/news/uk/home-news/china-mod-uk-hack-data-breach-b2540489.html

I don't think they're solving their cyber problems any time soon. Joke country.

I'd expect it's more likely that the UK just gets flooded with more CE crap, while the bottom end of the domestic or near-business market lifts its skirt up over the floodwaters, same as the rest of the EU user privacy data stuff. Sorry if that's cynical, but the last time I went to the UK a coworker got zapped because none of the three-prong power adapters he'd locally-purchased actually had connections between the input and output ground plugs.

Some of these restrictions, even some of the good ones, aren't that readily implemented. SecureBoot is only a recommendation, which is good, given that even a lot of mid-range microprocessors don't support it, nevermind the microcontroller world where it's gfl. I've got two projects I'm running now (STM32F103Cx- and Nuvoton NUC980) that don't support it at all, and these aren't exactly ancient PICs. Same, maybe even worse, for the recommendation for memory access controls. Mandating a default-off mode for any debug interface is understandable from a Serious IT Perspective, but it also makes a lot of stuff e-waste in a wide variety of circumstances, and makes a lot of useful prosumer and enthusiast concepts unavailable.

More broadly, this reads a bit like it was written by a mid-studies electrical engineering student, for better or worse. There's a lot of good recommendations, but trying to make a clear distinction between IoT and 'constrained' devices as a simple binary... it's bad enough trying to split microcontrollers from microprocessors, but from a quick read this reg would put harder restrictions on an ESP32 lighting controller than solar-powered NVR system.

On net, it's probably not bad to have a document people can look at, even if they end up shrugging on actual implementations at points, but it's frustrating.

I genuinely cannot think of a single "smart" device that has made my life better but it's easy to think of a ton that have made my life a little bit worse. This isn't a privacy or security thing. The devices are genuinely pointless and annoying. We recently unplugged our Alexa because it was pointless and annoying. There was probably a week where I could come up with contrived tasks for it to help with so I could pretend it wasn't completely stupid. I'm tired of tech people telling me I need this or that and making it impossible to find a house in the Bay Area with a normal boring thermostat. It's an immense treat that the used grill I just bought has no electronics built in.

The best argument for IoT devices was that they were a lot cheaper than normal devices because a VC was spending some pension fund's money to "build market share."

I hate IoT shit, but being able to close/open garage doors without the receiver when leaving the house without a car, set my thermostat to vacation mode, monitor my dogs, etc., have been beneficial enough for me not to rip out the haphazard automation put in the house by the previous owner.

Still cannot believe Google just gave up on Nest tooling and decided to leave home automation to a dozen Chinesium applications instead. It's embarrassing.

The smartphone map features are genuinely useful and I use them all the time to figure out what bus I need to take where, for example.

  • I can turn off my thermostat from bed if I forgot to do it before turning in

  • I can have my lamp gradually turn on and brighten before I need to wake up, which is nicer than the alarm

I like Alexa in the kitchen only, then I can set timers, play music, get recipes and the like while I am wrists deep in a turkey. Just saves a bit of time is all.

That's about it.

while I am wrists deep

Both wrists in there?

Fucking savage, man!

Mr. Bean knows how it's really done.

You should see me injecting butter under the skin..My wife thinks I could give BBLs down in Mexico.

I'm convinced a lot of it is malinvestment due to loose monetary policy. If we weren't in ZIRP for years, those VCs would have to fund stuff that actually has a chance of turning a profit rather than something that just sounds like a good idea.

There are legit IoT things that are useful but they don't really fit into the kitchen-widget-but-with-computer framework. Smart grids, automotive communications, logistics, medical, agriculture; there's lots of actual applications of cheap networked MCUs that people don't think about and rely on every day. Your car's backup camera was probably sold to the investors as "IoT" at some point.

But somehow "IoT" came to mean either gimmicky chinese lightbulbs or kitchen appliances that make you pay a subscription. Probably because you have to use fancy buzzwords to make people swallow that crap.

I am not sure that government providing long detailed lists of how to do security is going to help anyone.

My solution would be to simply make vendors liable for damages caused by security flaws of their devices, up to say 10 times the sticker price. Or impose a fine per vulnerable unit per day. An authentication bypass for a cloud-enabled webcam might cost 10% per day it is known for an exploit which allows recording if the fact that the camera is recording is visible from an LED, or 30% if the camera-on LED can be bypassed.

In Germany, the BSI is a federal agency tasked with enhancing computer security (except for when they are tasked with breaking computer security). The gist I get from German IT blogger fefe is that most of their security recommendations serve more to cover the backside of the company than actually prevent incidents. 'We were running two different anti-virus programs plus a Cisco Firewall, and our Windows+ActiveDirectory network was still compromised by ransomware. This simply shows the immense criminal energy of our attackers, we are the victims here!"

Again, laws should not try to specify the process, they should specify the outcomes. In this case, minimizing the time a device is exploitable.

Ensure software integrity

In practice, this will mean Tivotization. Personally, I am following the philosophy of "if you did not install the operating system, it is not your device". Owning a mobile phone is a lot of hassle. First you pick a vendor which supports OEM unlocks at all, then you find out that their dreadful unlocking process does not actually work, send the phone back, order a phone from a different vendor, request the unlock code, wait a week and finally unlock it. Give me a PC with a legacy boot option or a RasPi any day instead.

On the other hand, if it is no longer possible to sell Rasbian in the UK, I will consider that a win. "Let us just put a default user+password usable via fucking ssh on the image, YOLO" is so far from any responsible security mindset that I can hardly fathom it.

My solution would be to simply make vendors liable for damages caused by security flaws of their devices, up to say 10 times the sticker price.

I suspect 1x the sticker price would be more than sufficient if it happened reliably.

In Germany, the BSI is a federal agency tasked with enhancing computer security (except for when they are tasked with breaking computer security).

This sounds like the role NIST plays in the US. But those are also contractually enforced on companies doing business with the government.

I understand the worry some people have towards IoT devices, and I like a lot of the rules in that document, but ultimately the issue rests with the users. The issue is the idea that network devices, outside of standard end user devices like a computers and phones (and even then), can be secure by default, without thought. At this point, people need to be responsabilized with regards to their network security, and you can't mandate away all the ways that someone can shoot themselves in the foot with consumer devices.

Users need to learn to keep shit behind their firewall, in their home network, and access it via VPN if they need to access it remotely. They should learn to NOT ask for cloud services where they are not strictly necessary.

Sure, I'm a professional and it may sound like wishful thinking that users will learn to do this or hire professionals. But there's a lot of stuff inside a home I wouldn't do, like plumbing and electricity. We don't mandate that plumbing fixtures be impossible to fuck up. And while we have standardized power outlets, everything other than plugging in something, to do with electricity inside a home expects some degree of expertise.

Totally get where you're coming from. However, the last paragraph has I think the most important bit:

everything other than plugging in something

Most IoT devices are billed as, "You just plug it in, and it just works!" No one anywhere is standing at a store, looking at the baby monitors, seeing that one of the options lets them listen to it from their phone, and thinking, "Ya know, I really better not think about buying this and plugging it in unless I become an expert in network security." Just how no one stands in a store looking at toasters, thinking, "Ya know, I better not think about buying this and plugging it in unless I become an expert electrician." Like, should people learn more about network security and how their electrical system works? Yeah, sure. But while the breaker boxes in the store might have some sort of warning on them or cultural expectation saying that they mayyyyyybe shouldn't buy it and try to install it on their own without any expertise while the toaster doesn't have anything of the sort, nobody's internet devices have any such warning or cultural expectation. Even effin' routers, people just buy the box and plug the box in; it's easy! It's magic! Best case, they have the guy from the ISP show up to plug in the modem and the router, but he's not going to be fiddling with the security settings for them, either. Everyone is perfectly happy just letting it seem like plug-and-play magic.

Most IoT devices are billed as, "You just plug it in, and it just works!" No one anywhere is standing at a store, looking at the baby monitors, seeing that one of the options lets them listen to it from their phone, and thinking, "Ya know, I really better not think about buying this and plugging it in unless I become an expert in network security."

Let's say you were in charge of fixing this from the advertising side of things. What warnings would you add to this device so that even tech-illiterate users understand the risks of e.g. connecting this baby monitor up to the internet? Simple stuff you can fit on a pop-up or side of the box, because the user isn't reading the 100-page manual that probably already warns about this.

A big part of why you can just hand a toaster to someone with no further explanation is that people actually do know a lot about electricity and household appliances and can avoid the biggest problems. Nobody's dumping a live toaster into the sink to clean it.

Manufacturers should probably take this lower level of knowledge into account, but it's not as easy as "just make the device idiot-proof, like toasters!"

Let's say you were in charge of fixing this from the advertising side of things.

I guess manufacturers are in a tough position there because the lower level of knowledge means that quite uncomfortable things have to be put on the packaging. They can get away with putting the warnings in the 100 page manual for the toaster; it would put off buyers if the toaster they were looking at proeminently displayed "This toasted WILL kill you if you plug it in and take it for a bath!". Similarly, a baby monitor whose box said something like "Unless properly secured, this monitor can allow strangers to connect and listen in or talk to your child" will find itself selling less than the one that omits it.

I suppose the best move is to spin it as a feature. Put it proudly on the box! "Crowdsource your child's safety with the default password mode!"

the user isn't reading the 100-page manual that probably already warns about this.

I don't believe any user manuals actually warn about any of these things. The manufacturers simply do not care about security, because they don't have to, be it built-in, in manuals, or in advertisements.

it's not as easy as "just make the device idiot-proof, like toasters!"

Totally and completely agreed. I started off saying that one way we could fix this is to do something extremely simple, like banning default passwords. No manufacturer is going to put on their box whether they have a default password or not, so many consumers aren't going to know.

There has been some efforts in the US to create a Cyber Trust mark, where that is an indication that they have been built to some sort of standards (that aren't that far off from these regulations). This is a plausible approach, though we likely won't see whether it would have been effective (are consumers going to be paying close attention for this mark on a box full of ten other certification marks?), because they're probably just all going to bring their devices up to the UK standard. Could have been an approach, though.

I mean ideally people should be aware of the issues around network security to the point of being able to make reasonable decisions on whether a given networking device is safe to use much like they do every day with other devices and vehicles and activities. No one looking at a lot full of cars doesn’t make sure the car has airbags and seatbelts and antilock brakes. That’s not a super deep understanding of automotive technology, it’s pretty basic. And in home network security I think you should know enough to look for the basic security features. I wouldn’t buy a networked baby monitor that didn’t have at minimum password protection and encryption. I’m not an expert but I know enough to know that unencrypted information can be viewed by anyone with the appropriate receiver and that a device not protected by a fairly strong password is open to hacking. I think people are treating PNP devices differently than they treat other similar devices. It’s not that they are incapable of due diligence, it’s that they see computer devices and the systems around them as too complex to understand. They aren’t.

In the negligent users defense, users checking for features like "password protection and encryption" is more the source of the issue than the solution. Network security is a process, not a feature. I feel safer putting up a camera with no encryption and password protection that serve a standard video feed on the network than one that requires a cloud service with SSL, password, 2FA, etc... to function. The former would be forbidden to talk to anything outside of my internal network, and there would also be restriction to what it can talk inside the network. Security features are a very distant concern after proper access control. But cloud services I just have to trust. If you take the most secure device and give the whole planet a surface to attack it, it's a matter of when, not of if, it can be cracked. To its credit, the document does address some of this, but what happens when the company decides to discontinue the product line and deprioritize security updates on the cloud services for their baby monitor? The document does say they have to precommit to a support period, but there's support and Support.

Even then people can and do learn. And I don’t see why people assume that computer and network issues are that much more complicated to learn than any other security or safety concerns for anything else you might do or use. People can be taught this stuff. We managed to learn electrical safety and gas safety and safe driving and thousands of other problems that came along with new technology.

And I don’t see why people assume that computer and network issues are that much more complicated to learn than any other security or safety concerns for anything else you might do or use.

Well, that's because you trust yourself to get out of anything you get yourself into.

The problem with learning how to use computers is that, quite literally, everything's behind glass. The efforts to ameliorate this in the early '90s (and to a point, why early versions of iOS had the design language they did) were all attempts at solving this problem, and the reason the more famous ones failed (specifically Microsoft Bob) was because this problem is intractable outside of maybe VR- it's just side-grading from one "this is all behind glass, weirdly artificial, and I'm not truly in control of this machine's states" to "that, but at least it looks like a house".

With other forces of nature, such as electricity, gas, driving, etc., you're interacting with a physical thing. Human beings are exceptionally good at manipulating and understanding physical things- for electricity, you can physically guarantee that the current isn't going to go anywhere but where the wires conduct it. Same thing with driving (or at least, before we stuck shitty tablets in the dash).

Take away the state they're supposed to be directly manipulating, though, and make it both abstract and only accessible through a very specific set of fragmented language? And make it clear that (just like how people claim drivers would be better if there was a gigantic spike sticking out of the steering wheel) there are a bunch of [metaphorical, but sometimes very literal] loaded guns sitting inside the box? I don't blame anyone who hasn't had time/motivation to practice that in a safe environment for giving up pre-emptively.

(And the industry has done itself no favors- yes, there is an undo button, but the contexts in which it is useful and the powers it has within those contexts are not obvious even though with a plain-English reading they should be. Plus, now you have mobile-first design, which has to hide that functionality as a limitation of the user interface if it even has it at all... and every redesign that's made without actually proving it out, which UX designers love to do for some reason, chips away at the established knowledge base of a user little by little until there's nothing left.)

it’s that they see computer devices and the systems around them as too complex to understand. They aren’t.

I don't think it's that people are unwilling or unable- though there are certainly plenty of men and women who very blatantly refuse to use their eyes- but there's no obvious observable demonstration of "input A results in desired state 1", and that's coupled with "input B-Z results in undesired states 2 through 2000 and there's no easy way to go back to before making that input". So yes, "basic stupidity" is a thing that keeps people from understanding these devices, but I don't think it's the primary cause.

Speaking of physical interfaces... you ever seen what PLC programming interfaces look like? Ladder logic is arguably the most intuitive programming environment ever invented and most software developers have no idea it exists; its entire design goal is to make it as obvious as possible what input will result in what output. The only real thing you have to deal with there is the logic; more advanced things like functions become much more obvious when you can physically [or at least, as close to physically as possible- in this case, tracing a line with your eyes or finger] see what's happening and why.

No one looking at a lot full of cars doesn’t make sure the car has airbags and seatbelts and antilock brakes.

Since they're all mandated now, no one bothers. And when they weren't, people indeed chose cars without them. But those are a different issue; those are safety, and what we're talking about with IoT devices is security. Think door locks and immobilizers, not airbags and seat belts.

I think it’s a distinction without much of a difference. Security in IOT is safety from crime and hacking and so on. The point being that because of the fact that people learned about those features and why they were important, people did due diligence on making sure that those features were in the cars they bought. Sure some poorer people had to do without airbags in the early 1990s, but that was a cost issue.

I still think that it’s better to educate and demand due filling simply because the law moves much too slowly to keep up with technology and even then people making the rules often have no idea what the dangers are or how the things being regulated actually work. Having an octogenarian who has trouble with emails try to anticipate the issues of an IOT camera in your kids bedroom isn’t going to work well. Teaching parents to make sure their devices have strong password protection, good encryption, and virus protection is easier and would keep up with the field.

I also suspect that even someone who intentionally chose a car based on it having airbags and seatbelts would be incompetent at deciding which cars had better airbags and seatbelts and which cars had worse airbags and seatbelts.

As a topic expert (despite myself, embedded is both fun and hell) I did not want and continue not to want any government standardization of software because:

  1. I know they'll fuck it up, because they fucked it up before
  2. It's the one high paying career left that you can bootstrap yourself into with just smarts and a computer, no expensive certification and years of guild dues needed
  3. It opens the door to further regulation of what I'm allowed to do with compute, and I happen to enjoy my freedoms
  4. I see no demonstrated need for intervention that can't be addressed by private society

Just make IoT doodad manufacturers liable for bad things that happen with them and the problem will sort itself out, no state intervention with the potential for universal surveillance and totalitarian control needed.

The real reasons people want to do this shit are economic and strategic, they don't like that the Chinese are beating everyone at the doodad game and want protectionism through the backdoor. It's the same reason you can't easily buy American ETFs in the EU, because they don't care to include the handful of made up documents that are mandated by law at the advice of European financial institutions that enjoy proximity to the rule makers.

Let us not mince words: nobody gives a shit about the end user here. This whole game of being "regulatory leaders" only works if the major players of the industry you are regulating actually want to help you prevent further competition.

You can have protectionism and regulation if you want, but you can't get that and innovation. You have to choose.

Just make IoT doodad manufacturers liable for bad things that happen with them and the problem will sort itself out, no state intervention with the potential for universal surveillance and totalitarian control needed.

How about a government funded Red Team who's raison d'etre is taking out insecure household devices? Could be a nice cyber-warfare bootcamp; I can certainly think of worse uses for government funds. The problem with letting the market take its course is that IoT devices are a low-value target for black hattery -- classic case for governments protecting the commons!

How about a government funded Red Team who's raison d'etre is taking out insecure household devices?

I think this is a great idea, though I'm sure China and Russia are doing it already.

I actually kind of like the idea of this; you wake up one day, your doodad has been pwned, and the screen on it says "if you are seeing this, please call [govt. number]."

Govt. number: DO NOT REDEEM THE CARD SIR. You think that idea would be to a net benefit of the normies?

The government isn't going to find the security holes and report them; they're going to find the security holes, report a couple, and save the rest for their own use.

Isn't this the reason the NSA is supposed to exist on paper too?

Security for devices for the defense industry is one of those reasons, but I think household devices would be mostly outside their purview.

Just make IoT doodad manufacturers liable for bad things that happen with them and the problem will sort itself out, no state intervention with the potential for universal surveillance and totalitarian control needed.

This is a very common opinion, but if you delegate the assignment of liability to the court, then you will get even more problems about state overreach.

Consider the following scenario: A consumer buys some smart lights for their house. The smart lights are hacked, and hacker uses these smart lights as a proxy to launch ransom-ware attacks against hospitals. The hospitals are collectively "forced" to pay $100 million in ransom to continue their operations. Who is liable in this case? The consumer who didn't put the smart lights behind a firewall? The hospitals who had employees fall for phishing emails? Or the IOT company for not updating the security of their devices? If you don't have legislation defining what makes someone liable, then unaccountable judges will be forced to legislate from the bench about who is liable and who is not. If you don't like the decision, then you can't just vote them out of office the same way you can with legislators.

Just cap the liability costs at 10x the costs of the device. This should be enough to get vendors to take security seriously without having to worry about black swan outcomes.

Also, a hospital getting attacked by ransomware should obviously not only be liable for the ransom they elected to pay, but be fined on top of that if it turned out that any patient files were accessible to attackers.

Of course the problem of codifying responsibility doesn't magically dissolve if we oppose someone doing it.

Most of the issues raised by your hypothetical can be resolved by the content of the contract signed by the parties.

The only crucial thing that isn't there is what the standard for being negligent about your security is, and while I get the argument that it's easier to resolve if codified by politicians, I actually think it's fuzzy and contextual enough that it is better left to the courts.

I also am under no such delusion as to believe that I could vote legislators out of doing the bidding of the interests that pay for all of their campaigns. Judges might at least accidentally stumble upon some good sense and integrity. Politicians are constitutionally incapable of such things.

Most of the issues raised by your hypothetical can be resolved by the content of the contract signed by the parties.

I do not want to live in a word where people buying a $10 device from walmart have to sign a contract.

To some extent we do live in that world already: your $10 electronic device from Walmart probably already has a click wrap license that you have to accept to use the product. The validity of those is perhaps subject to question, but they aren't, to my knowledge in the US, categorically invalid.

Funny you mention clickwrap, because this whole topic reminds me of Ross Scott's campaign on stopping the destruction of live-service-type games, and the legal precedents in the US that basically give consumers no rights over software publishers.

That's too bad, because you already live in one.

I too hate that we don't distinguish strongly enough between computers bolted onto appliances and regular appliances. It's confusing. But when your fridge is actually a computer with a delivery service that happens to come with a free fridge, we have to deal with the complexities of the former, not the latter.

I think a big problem that has come up for IOT products is that they’re much more common than they were in the 1990s and are often connected to critical infrastructure either for private homes or to cameras inside the home. It might not have mattered how hack able a system attached to a dorm refrigerator is when it counts the beers removed and orders more. It’s not a well known system in 1998, and even if someone got into it, the worst that you could do is either change the program to never order beer, or maybe order a lot of beer. Attach the same system to 100,000 homes and have it use your credit card to order food from Amazon and you have a lot of actual damage you can do. You can steal credit cards. You can order stuff and have the address changed to your address. You can muck with whatever system it’s using to order from Amazon. Connect an automated door lock on a dorm room that can be opened by smartphone isn’t as dangerous as the same system on the doors of a business or government building.

The cost of compliance -- which is to say, the reams of paperwork and signoffs necessary -- will make this impractical for startups. The large companies making this stuff will do it -- eventually, with the UK getting delayed releases. The Chinese knockoffs will continue to be sold unlawfully, and a lot of new stuff just won't appear in the UK at all.

Justifications for this view have shifted, but I've always felt they've had a flavor of, "We can't be regulated! We're autistsartists! We make unique snowflake masterpieces! We have to move fast and break stuff! If we're ever held accountable for breaking anything, even for the most egregious of practices, then the entire economy will grind to a halt!"

Sneer all you want (I guess you're a Real Engineer), but I think a big reason bits have continued to grow while everything else has stagnated is the regulators haven't caught up with the bits yet.

Presumably bits continue to grow because you can throw more bits faster these days, compared to 5 years ago. That seems like a field that hasn’t stagnated.

Sneer all you want (I guess you're a Real Engineer), but I think a big reason bits have continued to grow while everything else has stagnated is the regulators haven't caught up with the bits yet.

I've thought about this a lot in trying to bootstrap something in the bio space. Even if I moved to Prospera tomorrow to escape the oppressive FDA, the CapEx required to get something off the ground is absurd. Simplest of animal studies is 10k a pop for really simple studies and more like 50-100k for the real disease relevant models, renting a single lab bench a month for myself is ~3.5-5k (maybe cheaper now that the biotech market has cratered), basic reagents run from a few thousand/month to 10s of thousands depending on what you're doing. Anything with human cells necessarily requires a bunch of infrastructure to do cell culture. There's also very few projects that lend themselves to producing an MVP and moving some units to fund more R&D; these are all decades-long slogs.

I joined a bunch of DIYbio mailing lists, discords and slack groups and the kinds of projects they do are just sad. More fit for high school ed than tackling any real problem.

The fact that you can buy a nice desktop for a few thousand and hack away in a fetid, windowless apartment for a few months or years to build a functional product seems to uniquely support innovation and, most importantly, give aggressive young founders a chance to lead a company. I'm interested to see whether the shift to training giant, prohibitively expensive AI models will lead to the same dynamics we see in biotech.

the reams of paperwork and signoffs necessary

My read is that they literally just need to fill in that table that I mentioned on page 32. That's not a lot of reams.

I guess you're a Real Engineer

I am most decidedly not a Real Engineer.

I think a big reason bits have continued to grow while everything else has stagnated is the regulators haven't caught up with the bits yet

Like I mentioned, we will see if the economy of bits will grind to a halt... or if they'll take the couple days necessary to not have a default password and to write "Yes, we don't have a default password" in the table on page 32. Perhaps you could formulate your prediction in numerical terms? Maybe something about growth rates in the tech sector over the next ten years? Maybe something about stock prices and how they'll reflect this immense stagnation? Or maybe an explanation for why the market hasn't already priced this in and had a massive drop in valuations in the past week in response to oppressive new regulation?

if they'll take the couple days necessary to not have a default password and to write "Yes, we don't have a default password" in the table on page 32

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.

maybe an explanation for why the market hasn't already priced this in and had a massive drop in valuations in the past week in response to oppressive new regulation

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.

Compliance is a huge industry.

Weird. I hear about that from my friends in literally every other industry ever. They still seem capable of operating.

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.

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.

I just doubt that these particular requirements are that onerous.

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:

As consumer IoT products become increasingly secure, it is envisioned that future revisions of the present document will mandate provisions that are currently recommendations in the present document.

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!

FRAM

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.

5.4-2 (unique IDs)

This one is conditional, and I imagine ultra-small or ultra-disposable devices won't qualify in the first place.

5.3.4/6/10 (updates)

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.

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.

Notice how they define isolable:

isolable: able to be removed from the network it is connected to, where any functionality loss caused is related only to that connectivity and not to its main function; alternatively, able to be placed in a self-contained environment with other devices if and only if the integrity of devices within that environment can be ensured

EXAMPLE: A Smart Fridge has a touchscreen-based interface that is network-connected. This interface can be removed without stopping the fridge from keeping the contents chilled.

In the section describing the rule, they continue:

There are some situations where devices cannot be patched. For constrained devices a replacement plan needs to be in place and be clearly communicated to the consumer. This plan would typically detail a schedule for when technologies will need to be replaced and, where applicable, when support for hardware and software ends

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.

SecureBoot (5.7-1), hardware memory access controls (5.6-8)

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.

guaranteeing cryptographic updates for the life cycle of the product (5.5-3)

Whereas this one, I think is fine, given their explanation:

For devices that cannot be updated, it is important that the intended lifetime of the device does not exceed the recommended usage lifetime of cryptographic algorithms used by the device (including key sizes).

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.

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!

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.

5.4-2 (unique IDs) : This one is conditional, and I imagine ultra-small or ultra-disposable devices won't qualify in the first place.

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.

5.3.4/6/10 (updates): 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.

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.

5.3-15: 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.

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.

(5.5-3) 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.

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.

CMOS RAM

Fair enough. Hopefully the worst case is that this ends up not being covered, even though it should be.

5.4-2 (unique IDs)

I think I can agree that there may be tradeoffs here for some devices.

twenty sensors on a LIN line

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.

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.

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.

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.

Compliance is a huge industry.

Weird. I hear about that from my friends in literally every other industry ever. They still seem capable of operating.

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).

They still seem capable of operating.

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.

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

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.

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.

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.

More comments

A Sopwith Camel fits in a garage and can take off and land on a piece of uneven land 300 m long. And that's with 1910s technology.

See also the autogyro/gyroplane/gyrocopter, developed in the 1920s, which can use 75-foot (25-meter) runways.

Where is the innovation in any other industry over the past decades exactly?

You know, since they brought these in.

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.

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.

Ok, so you also have a concern about default passwords. What are you going to do about your concern?

Let's go with a simple one - the shale fracking revolution in the oil/gas industry.

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.

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.

More comments

shale fracking revolution in the oil/gas industry

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.

"Being forced to not have default passwords is not a significant barrier to innovation,"

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.

What are you going to do about your concern?

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?

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.

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)?

The debate is only on the magnitude of the effect.

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 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.

I do the same, but clearly that is not changing much about the world. Have you succeeded in changing the world through your evangelism?

Hell, I've spent years of my life writing symbolic execution software used specifically to make edge devices secure.

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?

More comments

My read is that they literally just need to fill in that table that I mentioned on page 32. That's not a lot of reams.

I don't think the "detail" required is going to fit in that table. So it's going to be a reference to some much longer document which explains each item, in language understandable to regulators. And then all this will have to be reviewed by a lawyer specializing in UK regulations. And every time a change is made to the device, the document will have to be audited to ensure there's still compliance.

Of course just this one document isn't going to do much, aside from make new IoT devices less available in the UK and other countries adopting it as mandatory. The more regulation in more countries, the more the works get gummed up.

The good news is that it reads like they're expecting that companies will just publish this document on their website along with other support documentation. So, it won't be long until we get to see some and find out whose prediction is closer to accurate. As for the prediction of availability, would you like to predict anything specific about companies pulling out of the UK market?

If it's really so easy there won't be any problems. But I'm pretty sure, given the absolute glee expressed in your original post, you know it isn't.

I don't follow your line of reasoning. Can you speak plainly, please?

Your original post expresses considerable contempt for "tech folks" and demonstrates absolute joy for us having regulation "dropped" on us "in a much stronger way that you really won't like." This really doesn't fit with an idea that you think the regulations will be anything like easy or simple to follow -- rather, you actually think they will be difficult and painful to follow and are joyfully anticipating the pain it will cause.

Yeah, regulation sucks. It's terrible that in the "real" engineering professions, you need a minimum 10 years of experience before you're allowed to do anything more than turn the crank on well-tested models to determine if some very slight variation of an existing thing meets all the requirements, and then fill in all the boxes on the paperwork to maintain traceability. Doing that has high costs; applying those costs to the software industry as a whole will cause it to stagnate.

Your original post expresses considerable contempt for "tech folks" and demonstrates absolute joy for us having regulation "dropped" on us "in a much stronger way that you really won't like." This really doesn't fit with an idea that you think the regulations will be anything like easy or simple to follow

This does not follow. It's just a non sequitur. It can be easy and simple to follow, but incredibly grating to the personality of "artists". They don't like coloring inside the lines, even if it's easy and simple to follow.

More comments

What is this place?

This website is a place for people who want to move past shady thinking and test their ideas in a court of people who don't all share the same biases. Our goal is to optimize for light, not heat; this is a group effort, and all commentators are asked to do their part.

The weekly Culture War threads host the most controversial topics and are the most visible aspect of The Motte. However, many other topics are appropriate here. We encourage people to post anything related to science, politics, or philosophy; if in doubt, post!

Check out The Vault for an archive of old quality posts. You are encouraged to crosspost these elsewhere.


Why are you called The Motte?

A motte is a stone keep on a raised earthwork common in early medieval fortifications. More pertinently, it's an element in a rhetorical move called a "Motte-and-Bailey", originally identified by philosopher Nicholas Shackel. It describes the tendency in discourse for people to move from a controversial but high value claim to a defensible but less exciting one upon any resistance to the former. He likens this to the medieval fortification, where a desirable land (the bailey) is abandoned when in danger for the more easily defended motte. In Shackel's words, "The Motte represents the defensible but undesired propositions to which one retreats when hard pressed."

On The Motte, always attempt to remain inside your defensible territory, even if you are not being pressed.


New post guidelines

If you're posting something that isn't related to the culture war, we encourage you to post a thread for it. A submission statement is highly appreciated, but isn't necessary for text posts or links to largely-text posts such as blogs or news articles; if we're unsure of the value of your post, we might remove it until you add a submission statement. A submission statement is required for non-text sources (videos, podcasts, images).

Culture war posts go in the culture war thread; all links must either include a submission statement or significant commentary. Bare links without those will be removed.

If in doubt, please post it!


Rules


Recommended Posts And Communities

Recommended Realtime Chats