Avoiding the coming IoT dystopia [LWN.net]

By Jake Edge
February 12, 2019

Bradley Kuhn works for the Software Freedom Conservancy (SFC) and part of what that organization does is to think about the problems that software freedom may encounter in the future. SFC worries about what will happen with the four freedoms as things change in the world. One of those changes is already upon us: the Internet of Things (IoT) has become quite popular, but it has many dangers, he said. Copyleft can help; his talk is meant to show how.

It is still an open question in his mind whether the IoT is beneficial or not. But the "deep trouble" that we are in from IoT can be mitigated to some extent by copyleft licenses that are "regularly and fairly enforced". Copyleft is not the solution to all of the problems, all of the time—no idea, no matter how great, can be—but it can help with the dangers of IoT. That is what he hoped to convince attendees with his talk.

A joke that he had seen at least three times at the conference (and certainly before that as well) is that the "S" in IoT stands for security. As everyone knows by now, the IoT is not about security. He pointed to some recent incidents, including IoT baby monitors that were compromised by attackers in order to verbally threaten the parents. This is "scary stuff", he said.

The IoT web cameras that he uses at his house to monitor his dogs have a "great way" to avoid any firewalls they may be installed behind. They simply send the footage to the manufacturer's servers in China so that he can monitor his dogs from New Zealand or wherever else he might be. So there may be Chinese "hackers" watching his dogs all day; he hopes they'll call if they notice the dogs are out of water, he said to laughter.

As a community, we are quite good at identifying problems, which is why that joke has been repeated so often, for example. And even though we know that the IoT ecosystem is a huge mess, we haven't really done anything about it. Maybe the task just seems too large and too daunting for the community to be able to do something, but Linux has always provided the ultimate counter-example.

Many of us got started in Linux as hobbyists. There was no hardware with Linux pre-installed, so we had to get it running on our desktops and laptops ourselves. That is how he got his start in the Linux community; when Softlanding Linux System (SLS) didn't work on his laptop in 1992, he was able to comment out some code in the kernel, rebuild it, and get it running. Now it is not impossible to find pre-installed Linux on laptops, but, in truth, most people install Linux on their laptops themselves, like in 1992.

The hobbyist culture, where getting Linux on your laptop meant putting it there yourself, is part of what made the Linux community great, Kuhn said. The fact that nearly everyone at his talk was running Linux on their laptop (and only a tiny fraction of those had it come pre-installed) is a testament to the hard work that many have done over the years to make sure we can buy off-the-shelf hardware and run Linux on it. It was the hobbyist culture that made that happen and they did so in spite of, not with the help of, the manufacturers.

If he said that he didn't think it was important that users be able to install Linux on their laptops, no one would think that was a reasonable position—"not at LCA, anyway". But that is exactly what we are being told in IoT-land. The ironic thing is that most of those devices do come with Linux pre-installed. So you still can't buy a laptop with Linux on it, for the most part, but you can't buy a web camera (or baby monitor) without Linux on it.

If, in 1992, we had heard that 90+% of small devices would come with Linux pre-installed in 2019, we would have been ecstatic, he said. But the problem is that to a large extent, there are no re-installs. Some people do install alternative firmware on their devices, but the vast majority do not. And, in fact, most IoT device makers seek to make it impossible for users to re-install Linux.

Help from the GPL

But the GPL is "one of the most forward-looking documents ever written—at least in software", Kuhn said. While the GPL did not anticipate the advent of IoT, it already contains the words needed to help solve the problems that come with IoT: "the scripts used to control compilation and installation of the executable". The freedom to study the code is not enough; the GPL requires more than just the source code so that users can exercise their other software freedoms, which includes the freedom to modify and to install modified versions of the code.

The Linksys WRT54G series of home WiFi routers is one of the first IoT devices to his way of thinking. These devices brought a major change to people's homes. Like Rusty Russell (whose keynote earlier that day clearly resonated with Kuhn), he remembers going to conferences that had no WiFi. He was not surprised to hear that someone printed out the front page of Slashdot at the first LCA.

The WRT54G was the first device where "we did things right": a large group of people and organizations got together and enforced the GPL. That led to the OpenWrt project that is still thriving today. The first commit to the project's repository was the source code that the community had pried out of the hands of Linksys (which, by then, had been bought by Cisco).

But the worry is that OpenWrt is something of a unicorn. There are few devices that even have an alternative firmware project these days. It is, he believes, one of the biggest problems we face in free software. We need to have the ability to effectively use the source code of the firmware running in our devices.

Another example of a project that came about from GPL-enforcement efforts is SamyGO, which creates alternative firmware for Samsung televisions. That project is foundering at this point, he said, which is sad. He does not understand why the manufacturers don't get excited by these projects; at the very least, they will sell a few more devices. As an example, the WRT54G series is the longest-lived router product ever made; it may, in fact, be the longest-lived digital device of any kind.

GPL enforcement can make these kinds of projects happen. But there is a disconnect between two different parts of our community. The Linux upstream is too focused on big corporations and their needs, to the detriment of the small, hobbyist users, he said to applause. Multiple key members of the Linux leadership take the GPL "cafeteria style"; they really only want the C files that have changed and do not care if the code builds or installs.

But all of those leaders, and lots of others, got their start by hacking on Linux on devices they had handy. Kuhn pointed to a 2016 post by Matthew Garrett that described this problem well:

[...] do you want 4 more enterprise clustering filesystems, or another complete rewrite of the page allocator for a 3% performance improvement under a specific database workload, or do you want a bunch of teenagers who grow up hacking this stuff because it's what powers every device they own? Because honestly I think it's the latter that's helped get you where you are now, and they're not going to be there if the thing that matters to you most is making sure that large companies don't feel threatened rather than making sure that the next 19 year old in a dorm room can actually hack the code on their phone and build something better as a result. It's what brought me here in the first place, and I'm hardly the only one.

The next generation of developers will come from the hobbyist world, not from IBM and other corporations, Kuhn said. If all you need to hack on Linux is a laptop and an IoT device, that will allow lots of people, from various income levels, to participate.

Users and developers

In the software world, there is a separation between users and developers, but free software blurs that distinction. It says that you can start out as a user but become a developer if you ever decide you want to; the source code is always there waiting. He worries that our community will suffer if, someday, the only places you can install Linux are in big data centers and, perhaps, in laptops. If all the other devices that run Linux can only be re-installed by their manufacturers, where does the next crop of upstream developers come from? That scenario would be a dystopia, he said; we may have won the battle on laptops, but we're losing it for IoT.

Linux is the most important GPL program ever written, Kuhn said; it may be the most important piece of software ever written, in fact. It was successful because of, not in spite of, its GPL license; he worries that history is being rewritten on that point. Linux was also successful because users could install it on the devices they had access to. He believes that the leaders of upstream Linux are making a mistake by not helping to ensure that users can install their modified code on any and every device that runs Linux. "Tinkering is what makes free software great"; without being able to tinker, we don't have free software.

Upstream does matter, but it does not matter as much as downstream. He said he was sorry to any upstream developers of projects in the audience, but that their users are more important than they are. "It's not about you", he said with a grin.

It is amazing to him, and was unimaginable to him in 1992, that there are many thousands of upstream Linux developers today. But he really did not anticipate that two billion people would have Linux on their devices; that is even more astounding than the number of developers. But most of those two billion potential Linux developers aren't actually able to put code on their devices because those devices are locked down, the process of re-installing is too difficult, or the alternative firmware projects haven't found the time to do the reverse engineering needed to be able to do so.

The upstream Linux developers are important; they are our friends and colleagues. But upstream and downstream can and do disagree on things. Kuhn strongly believes that there is a silent plurality and a loud minority that really want to see IoT devices be hackable, re-installable, changeable, and "study-able". That last is particularly important so that we can figure out what the security and privacy implications of these devices are. Once again, that was met with much applause.

Being able to see just the kernel source is not going to magically solve all of these problems, but it is a "necessary, even if not sufficient condition". We have to start with the kernel; if some device maker wants to put spyware in, the kernel is an obvious place to do so. The kernel's license is fixed, and extremely hard to change as we frequently hear, but it is the GPLv2, which gives downstream users the rights they need. Even if upstream does not prioritize those rights the same way as its downstream users do, it has been quite nice and licensed its code in a way that assures software freedom.

There is no need for a revolution to get what we need for these IoT devices. The GPL already has the words that we need to ensure our ability to re-install Linux on these devices. We simply need to enforce those words, he said.

Call to action

Kuhn put out a call to action for attendees and others in our community. There are some active things that people can do to help this process along. The source code offer needs to be tested for every device that has one. Early on, companies figured out that shipping free software without an offer for the source code was an obvious red flag indicating a GPL violation. So they started putting in these offers with no intention of actually fulfilling them. They believe that almost no one will actually make the request.

That needs to change. He would like everyone to request the source code using the offer made in the manual of any device they buy. It is important that these companies start to learn that people do care about the source code, so even if you do not have the time or inclination to do anything with it, it should still be requested. Every time you buy a Linux-based device, you should have the source code "or something that looks like it" or you should request it.

If you have the time and skills, try to build and install the code on the device. If you don't, see if a friend can help or ask for help on the internet. Re-installing can sometimes brick your device, but that probably means that the company is in violation of the GPL. The idea is to create a culture within our community that publicizes people getting source releases and trying to use them; if they do not work, which is common, that will raise the visibility of these incomplete source releases.

"If it doesn't work, they violated the GPL, it's that simple", Kuhn said. You were promised a set of rights in the GPL and you did not get them. You can report the violation but, unfortunately, SFC is the only organization that is doing enforcement for the community at this point. It has a huge catalog of reports, so it may not be able to do much with the report, but the catalog itself is useful. It shows the extent of the problem and it helps the community recognize that there is a watchdog for the GPL out there; for better or worse, he said, that watchdog is SFC.

But he had an even bigger ask, he said. He is hoping that at least one person in the audience would step up to be the leader of a project to create an alternative firmware for some IoT device. It will have to be done as a hobbyist, because no company will want to fund this work, but it is important that every class of device has an alternative firmware project. Few people are working on this now, but if you are interested in the capabilities of some device, you could become the leader of a project to make it even better. "Revolutions are run by people who show up."

It feels like an insurmountable problem, even to him most days, but it does matter. It only requires that we exercise the rights that we already have, rights that were given to us by the upstream developers by way of the GPL.

Being able to rebuild and re-install Linux on these devices won't magically fix the numerous privacy and security flaws that they have—but it is a start. The OpenWrt project started by getting the source code it was provided running, it then started adding features. Things like VPN support and bufferbloat fixes have improved those devices immeasurably. We can restore the balance of power by putting users back in charge of the operating systems on their devices; we did it once with laptops and servers and we can do it again for IoT devices.

A WebM format video of the talk is available, as is a YouTube version.

[I would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to Christchurch for linux.conf.au.]

Index entries for this article
Conference	linux.conf.au/2019

to post comments

Television sets

Posted Feb 12, 2019 19:34 UTC (Tue) by smurf (subscriber, #17840) [Link] (21 responses)

TV sets are so cheap because they are connected, phone home, serve ads and whatnot, and the revenue from these nefarious activities subsidizes the ridiculously-low hardware cost.

If you use your own firmware they will do no such thing, thereby causing the TV maker to lose money on your sale, thus "selling a few more units" is a non-starter argument here.

Television sets

Posted Feb 12, 2019 20:09 UTC (Tue) by pj (subscriber, #4506) [Link] (6 responses)

I'm pretty sure TV sets are so cheap because they're mass-produced. I see _zero_ ads on my (2018 65" 4k) TV.

Television sets

Posted Feb 12, 2019 20:31 UTC (Tue) by ay (guest, #79347) [Link] (5 responses)

It's not about ads on the device, it's that they're selling information about your viewing habits, etc. to advertisers. There was recently an interview with a Vizio exec and he admitted their low costs are subsidized by this practice and while they'd consider selling "unconnected" TVs that don't do this, consumers wouldn't buy them because of the much higher cost.

Television sets

Posted Feb 13, 2019 8:11 UTC (Wed) by zdzichu (subscriber, #17118) [Link]

Here's the source: https://www.theverge.com/2019/1/7/18172397/airplay-2-home...

Television sets

Posted Feb 13, 2019 16:20 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (3 responses)

Of course, they will usually have a hard time obtaining that data if you don't give your TV the WiFi password (which is probably a Good Idea on general principles, actually).

Television sets

Posted Feb 13, 2019 18:50 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

And if a neighbor has an open WiFi and the TV has Android's "automatically use open WiFi" setting? I'd rather just set up a black-hole AP and attach to that instead. Maybe also synthesize what is necessary for detecting "full" Internet access so that it doesn't go looking for "better" networks on its own.

Television sets

Posted Feb 19, 2019 17:59 UTC (Tue) by jccleaver (guest, #127418) [Link] (1 responses)

It doesn't let you disable that? JFC, that would be a deal breaker for me...

Television sets

Posted Feb 19, 2019 18:34 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

I don't know if such things actually exist (I'm only in the market for dumb screens, so it's a meaningless comparison for me), but they are Android and it has such a flag. If it is exposed in actually shipped devices is something to research.

Television sets

Posted Feb 12, 2019 20:32 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

People always overestimate the advertisement revenue. The information gathered from TVs would work out to at most dollars per user.

Television sets

Posted Feb 12, 2019 20:34 UTC (Tue) by ay (guest, #79347) [Link] (1 responses)

Here's an article discussing this, https://boingboing.net/2019/01/11/telescreens-r-us.html ... I gather it's quite a bit more.

Television sets

Posted Feb 12, 2019 21:20 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Thing is, there isn't much to sell for TV manufacturers. The TV viewing stats are extremely cheap and they don't have much else.

TVs don't show ads (at least so far) and the built-in Crappstores are mostly unused. Though I suspect TV manufacturers might get referral fees from Netflix/Roku if their apps are installed through TV's crappstore.

Now, these couple of dollars might affect the _margin_ quite a bit. The TV market is so commoditized that the margin is often close to zero.

Television sets

Posted Feb 12, 2019 21:37 UTC (Tue) by perennialmind (guest, #45817) [Link]

And wouldn't that be a great thing? If everyone took the subsidized hardware and subverted it for their own ends, the tactic would backfire, as it did with AOL's free floppies and CueCat's free barcode scanners. Let customers be customers and products be products, not the bizarre inversion.

I don't think the pitch is more sales. I think the pitch should be avoiding the race to the bottom which prices out the scrupulous and devalues qualities of engineering, design, and production.

Television sets

Posted Feb 14, 2019 8:12 UTC (Thu) by jimbo (subscriber, #6689) [Link] (9 responses)

There's also the vexed (vexing?) issue of digital restriction management also "DRM" or "digital rights management" How many content providers would be happy about giving out digital restriction keys to a manufacturer who uses full-stack GPL software? Not very many, I suspect.

Television sets

Posted Feb 16, 2019 3:39 UTC (Sat) by murukesh (subscriber, #97031) [Link] (8 responses)

Would that really be a concern? I'd imagine the keys would be in a TPM-like store and not in (or directly accessible to) the software. The hardware will access the store and perform whatever operations are required without revealing the keys. So neither a source code request nor installing our own stack should leak the keys (in theory, at least).

Television sets

Posted Feb 16, 2019 13:17 UTC (Sat) by excors (subscriber, #95769) [Link] (7 responses)

The keys might not be the only things that need protecting. The DRM system might want to protect the decrypted H.264 data (else someone can easily capture the decrypted output and share the perfect-quality video with the world). It might also want to protect the decoded pixels (else someone can digitally capture and recompress the video, which only loses a small amount of quality). (See e.g. the different Widevine security levels: https://www.androidauthority.com/widevine-explained-821935/)

That means the DRM implementation isn't just a TPM, it includes parts of video decoding, display composition, HDCP negotiation, etc, which is a significant amount of functionality and has a large and complex interface with the rest of the software. It's probably too complex to do entirely in hardware, so it needs some kind of trusted firmware that can be certified to follow the DRM system's security requirements. That certification would be meaningless if the user could modify the firmware, so the firmware can't be usefully user-replaceable and can't be GPLv3 (because of anti-tivoization). (Also it may be required to include proprietary code from the DRM provider, so it can't be GPLv2 either, but that's a separate issue.)

Television sets

Posted Feb 18, 2019 16:13 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (6 responses)

> That means the DRM implementation isn't just a TPM, it includes parts of video decoding, display composition, HDCP negotiation, etc, which is a significant amount of functionality and has a large and complex interface with the rest of the software.

In principle all of that could be open-source and user-replaceable, as long as the TPM can verify the software in use and only expose its internal keys for use by officially approved binaries. Users could use modified software with non-DRM media or with media encrypted with keys they install into the TPM themselves. It's still a DRM scheme, and thus evil, but it doesn't seem incompatible with open source—even GPLv3.

Television sets

Posted Feb 18, 2019 17:28 UTC (Mon) by excors (subscriber, #95769) [Link] (5 responses)

In the context of a smart TV, I don't think telling customers "you can replace the firmware, as long as you don't want to watch Netflix or any subscription channels" is much good. I wouldn't consider the firmware to be meaningfully user-replaceable if the user has to sacrifice core features of the device. The goal shouldn't be to have a blank SoC in TV-shaped plastic that you can run your own code on (else you might as well just buy a cheap SoC dev board and glue it onto the TV), the goal should be to have a proper working TV with code that you've modified.

GPLv3 says:

> If you convey an object code work under this section [...] the Corresponding Source conveyed under this section must be accompanied by the Installation Information. [...] "Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

I'm not sure what "continued functioning" legally means, but if your TV is intentionally designed to stop supporting Netflix solely because you made an insignificant modification to the firmware, it seems plausible to argue to the TV has not continued functioning.

On the other hand https://events.linuxfoundation.org/wp-content/uploads/201... argues that GPLv3's anti-tivoization clause doesn't actually prevent what Tivo did - it's okay if a vital part of the product is proprietary code that stops functioning if the GPLv3 code is modified, because it's not the GPLv3 code that has stopped functioning. But that sounds like it's exploiting a bug in the GPLv3, because the rationale was obviously to prevent what Tivo did, so it seems pretty dodgy to rely on that argument.

Television sets

Posted Feb 18, 2019 18:11 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (3 responses)

In the context of a smart TV, I don't think telling customers "you can replace the firmware, as long as you don't want to watch Netflix or any subscription channels" is much good.

I think a lot of people would be OK with that. My personal experience is that the "smart" TV is pretty useless, and I'm much more likely to use features through an add-on device than through the TV. Popular ways of getting smart features not through the TV include dedicated devices like Roku or Chromecast, video game consoles, home media PCs, and smart DVRs. In my experience, all of those things have better UIs than smart TVs, and many people are going to get them for the convenience and added features without even considering the issue of TVs spying on them.

Television sets

Posted Feb 18, 2019 18:19 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (1 responses)

Why replace TV's firmware then? It's a dumb display.

Television sets

Posted Feb 21, 2019 22:47 UTC (Thu) by Wol (subscriber, #4433) [Link]

Because the firmware's broken, maybe?

Now binned because it broke, but I had a Logik / JVC TV that used to crash when you tried to record to USB. It did it somewhat at random but that's obviously very annoying.

My car stereo now seems to spend an inordinate amount of time "scanning USB" which impacts quite seriously on its usability - I think that's a bug ...

And trying to get this sort of stuff fixed is a nightmare, as it's almost impossible to contact the manufacturer, and the retailer's attitude is "well almost everything works". The fact that the bit that doesn't is very important to you, isn't important to them.

Cheers,
Wol

Television sets

Posted Feb 18, 2019 18:49 UTC (Mon) by excors (subscriber, #95769) [Link]

> My personal experience is that the "smart" TV is pretty useless, and I'm much more likely to use features through an add-on device than through the TV.

The same issues apply to the add-on device. I don't think telling customers of a Roku streaming stick "you can freely replace the firmware, as long as you don't want to stream anything from Netflix" would be useful. There's nothing particularly special about the hardware; if you just wanted a small programmable box with HDMI output, you could run your code on a Raspberry Pi instead. The interesting part is the device's original fully-functioning firmware; that's the thing you'd want to modify out of curiosity or for security.

> without even considering the issue of TVs spying on them

If you're concerned about that, the streaming sticks could spy on you just as easily as your TV could - there's often a microphone in the remote control (for voice search).

Television sets

Posted Feb 18, 2019 21:07 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

> I'm not sure what "continued functioning" legally means...

I'm not sure *anyone* knows what "continued functioning of the modified object code" legally means, including the people who wrote that clause. However, I would say that both the modified object code and the TPM are each functioning exactly as designed. I would consider this analogous to the case of a GPLv3 client for a private third-party web service: You can modify and execute the software as you please, but you'll have to make your own agreement with the third-party service to use their APIs. That third party might require you to use only approved software to access their APIs as part of their terms of service. You can either implement your own API-compatible service (use only DRM-free media) or negotiate to get your modified software approved.

Whether "the TV has not continued functioning" is beside the point. The GPLv3 doesn't talk about the functionality of the device as a whole, just the modified object code. Systems with modified code may not have access to the keys in the TPM which would be necessary to play DRM'd media, but the system isn't actually blocking the modified code or interfering with its execution.

> In the context of a smart TV, I don't think telling customers "you can replace the firmware, as long as you don't want to watch Netflix or any subscription channels" is much good.

What you're really objecting to here is that Netflix and subscription channels require DRM. I agree with you on this, but in practice they're never going to entrust their content to software they don't control (even though the empirical evidence says that whatever they're obsessing over can almost certainly already be found online without the DRM). The best you can reasonably hope for is that the parts which handle their content are sufficiently isolated from the front end that the front end software can be open-source and user-replaceable without getting involved with the "protected" media path. Since that requires more expensive hardware, I wouldn't recommend holding your breath for such a design in mass-produced consumer electronics.

Avoiding the coming IoT dystopia

Posted Feb 12, 2019 21:39 UTC (Tue) by excors (subscriber, #95769) [Link] (32 responses)

I think there is a fundamental security challenge here: If your IoT device allows the user to install new firmware, how do you tell that the person attempting to install the firmware is actually the user and not an attacker? (This isn't a rhetorical question, I'd like to know if there's a good answer!)

On a laptop or PC you can use UEFI Secure Boot and allow someone with physical access to enter the BIOS and type in their own keys, so that it will only run kernels and kernel modules signed by that person.

But on an IoT device, physical access is much less strongly related to trust: the devices are sometimes outdoors, and often spread all around your house, where it's fairly easy for an attacker to reach them without being noticed. And you're lucky if the device has even a single physical button on it; there's no physical way to enter a new key.

Their main UI is probably a smartphone app, connected over a local network or via the cloud, with some setup process to pair the device and phone. But I doubt the pairing process is trustworthy enough that you'd want to count it as permission to install custom firmware. It's good enough for regular use - if I'm visiting your house and I try to pair your IoT camera with my phone, you'll quickly notice that your phone can't access the camera any more (hopefully it'll send you a notification immediately), so you'll re-pair it and I'll lose access, and little harm is done. But if I can replace the firmware while I've temporarily got access, I can make it send me the video feed even after it's been paired back to your phone, and I can make it lie about what firmware it's currently got installed, so I have permanent undetectable access.

(Of course an attacker with physical access could, in principle, swap your device for an identical-looking one with custom hardware and custom firmware that spies on you, but that's orders of magnitude harder than simply modifying the public firmware source and reflashing it, and almost impossible to keep hidden if the user gets suspicious and starts investigating the device.)

Obviously lots of current IoT devices have terrible security, but some manufacturers do try to get it right - and that includes using some form of secure boot, probably with the keys in one-time-programmable memory (or at least in write-protected flash that's really hard to get physical access to), so you can guarantee that simply power-cycling the device will get it into a known-good state (according to the manufacturer's definition of "good"). The ones who are trying to do the right thing shouldn't be asked to compromise security for hackability. So is there any practical way to get both hackability and security?

Avoiding the coming IoT dystopia

Posted Feb 12, 2019 21:54 UTC (Tue) by ay (guest, #79347) [Link] (8 responses)

I've worked on reasonably secure IoT devices and similar products. Indeed the policy was secure boot and runtime, no GPLv3 software (and honestly nothing of value was lost), and no user-installed firmware. Could a "own your own devices" signing mechanism have been baked in? Sure but there was no business case for the cost and complexity of implementing and maintaining that.

Avoiding the coming IoT dystopia

Posted Feb 12, 2019 22:52 UTC (Tue) by excors (subscriber, #95769) [Link] (5 responses)

If there was a business case, how could that feature have been built in without significantly compromising security? (and without significantly affecting the BOM or the standard user experience). That's the part I don't really understand.

Maybe it needs some kind of remote attestation mechanism or something? Let an attacker replace the firmware signing keys if they want, but when you (the legitimate user) try to pair the device with your phone, the device sends a signed copy of those keys (plus nonce provided by the phone, to avoid replay attacks), computed by some small non-user-replaceable trusted code with a secret per-device private key, so your app can check whether it's still running clean firmware. And avoid MITM attacks with some out-of-band way to verify the device's identity, like an ID number printed on the device that the user has to scan into their phone, which is compared against the public key used for the signature. I suppose that doesn't sound too bad? But I don't know if that would actually work and be secure enough (or at all).

Avoiding the coming IoT dystopia

Posted Feb 13, 2019 6:50 UTC (Wed) by felixfix (subscriber, #242) [Link] (4 responses)

I've always wondered about this too. These things are built as cheaply as possible. Reprogrammable NVRAM is money. A button or USB port is lots more money.

I knew a components engineer whose entire job consisted of scouring hundreds of data books in different languages for equivalent components which were cheaper; taking even a full week to save a penny per unit paid his salary and more.

Any manufacturer who tried to do right by the GPL would go out of business from all the price shoppers.

I suspect all that would happen if buyers insisted on their GPL rights is that manufacturers would go out of business and evaporate, and everyone would appear in a brand new company doing the same thing, if GPL rights actually threatened their bottom line that way. The economics just don't add up.

Avoiding the coming IoT dystopia

Posted Feb 13, 2019 8:09 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Businesses will just ignore GPL, it's the new BSD anyway.

If people were to start really enforcing GPL, manufacturers would just switch to FreeBSD or in many cases to a smaller RTOS (FreeRTOS by Amazon is nice). In a few years they are going to use Fuchsia for that.

Avoiding the coming IoT dystopia

Posted Feb 13, 2019 20:33 UTC (Wed) by ay (guest, #79347) [Link]

The ones I've worked with certainly don't ignore it, in fact we spent a lot of time making sure we comply and provide a gpl drop.

However we absolutely ruled out GPLv3, in fact yocto makes that easy (and with buildroot you can write your own filters). Again nothing of value was lost, there's just nothing compelling licensed that way that we ever needed in a product.

I think that's the way it's going to continue to be and this whole battle is "lost", but I wouldn't blame insecure crappy IoT entirely, I can assure you the better engineered devices are doing secure boot for security reasons and you're not meant to subvert that without a lot of effort and indeed there's no business justification for even adding a jumper for you to own the thing.

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 15:33 UTC (Thu) by bfields (subscriber, #19510) [Link] (1 responses)

One moral to take from that is that per-unit costs really dominate when you're selling a massive number of units.

So if the cost of GPL compliance is a fixed cost (some up-front legal and developer review), and the risks are per-unit (per-unit penalties, or products taken off the market), then that might motivate higher GPL compliance in such cases?

Any manufacturer who tried to do right by the GPL would go out of business from all the price shoppers.

But, point taken that given that extreme price pressure, it could be hard to comply unless the risks of noncompliance are real.

Avoiding the coming IoT dystopia

Posted Feb 15, 2019 14:59 UTC (Fri) by NAR (subscriber, #1313) [Link]

"So if the cost of GPL compliance is a fixed cost "

The legal review, download link for the source, etc. is fixed cost. The extra USB port, button, connector, pin, etc. that would tell the device it's OK to download and use a new image from the owner (so the owner can actually install the modified GPL software) - that's a per-unit cost.

Avoiding the coming IoT dystopia

Posted Feb 13, 2019 2:52 UTC (Wed) by faramir (subscriber, #2327) [Link] (1 responses)

I seem to remember that in the old days, there was a jumper on the motherboard which you had to move in order to flash a new BIOS. No special security software or key management required. Of course, back then people never thought twice about opening up their computer before doing a BIOS update. That would be inconvenient in the modern world for most users. So make it software controlled instead. Either the new firmware has a valid signature OR the jumper is set to permissive mode. The most expensive part of doing this would be dedicating a pin on the SOC to test for the state of the jumper before allowing unsigned firmware updates. Given that all bets are off if someone has physical access to the device, it's not obvious to me what the downside of this would be other than vendors not being able to segment markets for their "hardware" products by arbitrarily limiting functionality based on how much you paid.

Avoiding the coming IoT dystopia

Posted Feb 13, 2019 11:22 UTC (Wed) by excors (subscriber, #95769) [Link]

I don't agree with:

> all bets are off if someone has physical access to the device

It's still important to consider the time, skill, money, equipment etc required by an attacker with physical access, and how easily the victim can discover the attack.

If you invite your neighbours around and their kid sneaks into your bedroom and reprograms your IoT camera with some undetectable off-the-shelf spyware after thirty seconds with a screwdriver and a phone, that's not acceptable security. If they have to desolder the flash chip, plug it into a reprogrammer, then solder it back on again (which requires specialised equipment since it's far too small to do by hand), that's a very different category of attack; maybe that's good enough for a consumer product, though it still doesn't seem great. And if the only way to make it undetectable is to steal the device's private key by spending days with the chip under an electron microscope, that's another category again and is probably good enough. The difficulty is in achieving one of those stronger forms of security while still allowing the legitimate user to replace the firmware.

Avoiding the coming IoT dystopia

Posted Feb 13, 2019 8:05 UTC (Wed) by eru (subscriber, #2753) [Link] (3 responses)

To hamper the physical access by an attacker on slightly larger devices, you could include a set of DIP switches (8 should be enough) that have to encode some number, specific to each device instance, before a firmware update is allowed. Not entirely unrealistic on things like baby monitors: I once owned one (not Internet-connected!) that had DIP switches in the transmitter and receiver for selecting the channel to use.

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 16:40 UTC (Thu) by felixfix (subscriber, #242) [Link] (2 responses)

And the extra cost just lost you half your Amazon buyers.

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 18:05 UTC (Thu) by smurf (subscriber, #17840) [Link] (1 responses)

You can't sell electric devices without an UL test and whatnot. Yes, that increases their price. So? These tests are not useless: they ensure (mostly) that you can't buy something that's more likely than not to catch fire (and take your house with it).

The cost of hooking random insecure IoT things into your WLAN isn't as high to you-the-homeowner (not yet anyway), but these insecurities enable DDoS attacks and whatnot, thus are costly to somebody else. In any other area of modern life, that would cause even more stringent regulations.

Avoiding the coming IoT dystopia

Posted Feb 15, 2019 18:51 UTC (Fri) by aaronmdjones (subscriber, #119973) [Link]

You most certainly can sell an electronic device without any UL testing. You usually need the UL logos on them to make them legal to import, but you can self-declare UL compliance, and that is hardly ever tested unless something actually happens.

What you *do* need to do UL testing for, is if you want to brand a product as UL *Listed*. Since it's a trademark, only the UL can do that, not you, or you'd be liable for trademark infringement.

Avoiding the coming IoT dystopia

Posted Feb 13, 2019 12:38 UTC (Wed) by cstanhop (subscriber, #4740) [Link] (18 responses)

I think your question can be reduced to "If your IoT device allows installing new firmware, how do you tell that the person attempting to install the firmware is actually not an attacker?" I think there are two questions there. Can we prevent attackers from installing new firmware? If they do install new firmware, can we detect it?

However this gets into threat modeling, and I don't think there is a one answer that will satisfy everybody. From some perspectives the owner is not authorized to update the firmware and would be considered an attacker. I don't find this an acceptable model for the devices I own and use in my home. In most of my personal scenarios, physical access would be a high enough bar to allow firmware updates. Having a way to remotely attest the firmware running is the firmware I installed would be a nice to have, but not strictly necessary.

Avoiding the coming IoT dystopia

Posted Feb 13, 2019 21:02 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (17 responses)

> From some perspectives the owner is not authorized to update the firmware

It's up to the owner to decide who is authorized and who is not. That's a key part of why they're called "the owner". If you are not authorized to update the firmware, or to decide who else is allowed to update the firmware, then as far as the device is concerned you don't own it.

For devices with Secure Boot or equivalent, it should be considered fundamental that the device has not been properly delivered to its new owner so long as the previous owner controls the keys needed to sign the lowest levels of firmware. Part of the process of legally transferring ownership for such a device should be causing the device to "imprint" on its new owner and recognize their absolute and exclusive authority over it, by reprogramming it with a new set of master keys. Failure to do so should be classified as fraud—you're claiming to turn over ownership but leaving the device in a state where it still recognizes you as its owner.

Avoiding the coming IoT dystopia

Posted Feb 13, 2019 22:10 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (16 responses)

Yeah, let's do it like this:
- You buy a device.
- You book an appointment at your nearest Department Of Internet Thingies.
- You come during the appointed time, stand in a short line (just 2-3 hours) and then file an ownership transfer form.
- In a couple of weeks you receive your QR code with the signed keys to transfer ownership.

I think everybody would LOVE this system!

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 0:54 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (15 responses)

Well obviously we wouldn't do it in the *worst possible way* as you're suggesting. More like:
- Buyer provides the seller with their public key.
- Seller imprints the device with the buyer's key.
- Seller delivers the device to the buyer.
- Buyer confirms that the device recognizes their key.

There's no need to involve anyone else unless the seller fails to properly update the key.

Alternatives would include delivering the device "blank" and letting the buyer load their own key, which might be a good option for brand-new devices, or including a factory reset switch which would allow anyone with sufficient physical access to clear the device and load their own key (if physical security is less of a concern).

However it's implemented, the one option which is *not* acceptable is for the seller to retain the master keys to a device they no longer own, with no option for the buyer to replace them. The device's idea of who its owner is should be aligned with the buyer's. If you want to sell someone *access* to a device while retaining control over it you're not selling them the device, you're only leasing it; and if that isn't made perfectly clear up front then the contract is invalid.

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 1:43 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> - Seller imprints the device with the buyer's key.
> - Seller delivers the device to the buyer.
Sorry, no. This two steps will add something like $100 per device. You'll have to either link individual shipments to consumers or establish local "customization centers". Both are not feasible. Then there's the issue of lost keys and repair/replacement. In short, this scheme is not going to work especially for various $20 IoT light bulbs or baby monitor cameras.

Realistically all you can hope for is the sale of blank devices without warranty of any kind.

For large IoT devices like TVs the best way forward is to move all the "smart" functionality into standardized modular components that can be replaced by the user.

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 2:36 UTC (Thu) by excors (subscriber, #95769) [Link] (3 responses)

Linking individual shipments to consumers is kind of feasible. See e.g. https://developer.amazon.com/docs/dash/pre-registration-o... - the Device Serial Number is scanned when shipping, so it can be linked to the buyer's Amazon account and other order data, in some database that can be queried when an app connects to the device and retrieves its DSN. And that's on a device that costs $5. (That's also why a lot of Amazon devices tell you it's important to select "this is a gift" when you want to avoid linking it to your own account.)

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 2:44 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

This is not a true price, Amazon is likely subsidizing it heavily. And you have to have a whole workflow to do it, you can't just ship crates across the ocean.

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 3:32 UTC (Thu) by excors (subscriber, #95769) [Link] (1 responses)

Sure, but there's no way they're being subsidised by $95 each. You do need a whole workflow, but that workflow already exists and is actively used; and (at least in the case of DRS) third-party device makers can integrate with that existing workflow, they don't need to build the whole thing themselves.

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 3:34 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Given the amount of sunken development costs and the Prime subscription requirement - it's very much possible.

Avoiding the coming IoT dystopia

Posted Feb 26, 2019 14:06 UTC (Tue) by omgold (guest, #109541) [Link] (9 responses)

Why so complicated?

They could just do the same as router vendors currently do with Wifi-Passwords.

- store a random (per-device) key/password in the device memory
- print the key/password on a sheet of paper which is delived to the customer together with the device.

Avoiding the coming IoT dystopia

Posted Feb 26, 2019 15:56 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (8 responses)

The problem with the WiFi router password model is that the per-device key doesn't change, so the original vender and all previous owners *also* have the key. The new owner needs their own unique secret.

If it's acceptable to reset the device back to a blank factory-default state prior to the sale (or after, assuming physical access is sufficient proof of ownership) then the new owner can program in their own secret when they receive the device. If not, the existing owner needs to transfer control to the new owner prior to the sale, and doing that without letting the existing owner know the new owner's secret requires a public-key authentication system. Reasons not to perform a factory reset include deterring theft or tampering while the device is in transit and/or wanting to preserve any data already on the device.

Avoiding the coming IoT dystopia

Posted Feb 27, 2019 7:28 UTC (Wed) by omgold (guest, #109541) [Link] (7 responses)

Why would it not suffice that in factory-default state there is a random per-device password preconfigured, but the owner is able to change that?

My reasoning about having the first is that it protects dumb users (who never change the password) from fun guys coming to visit, who want to reflash the firmware unnoticed. It is simply prevented by the owner storing the sheet with the preconfigured pw somewhere unknown to the attacker (which is likely).

About pubkey, it should be enough for the new owner to change the password, no? Not pubkey needed:

- previous owner provides current password, or just the vendor preconfigured-one (the latter would need a factory reset)
- new owner types in current password, which allows him to set his own one

Avoiding the coming IoT dystopia

Posted Feb 27, 2019 13:07 UTC (Wed) by excors (subscriber, #95769) [Link] (6 responses)

If there is a separate "sheet with the preconfigured pw", some fraction of customers will inevitably lose that sheet, then will phone customer support and (quite justifiably) demand to be allowed to use the product they bought.

I guess that's okay for ISP-provided routers - the customer has a contract with the ISP, so customer support has enough information to verify the identity of the caller then tell them the original password. And the ISP already provides customer support in the user's language, and is being paid like $50/month, so it's relatively cheap to deal with the occasional lost password.

But that solution doesn't scale to many IoT devices. Maybe you're buying the device for $10 from a small Chinese manufacturer. They can't afford to provide that level of individual customer support. And you're definitely going to lose track of all these password sheets if you have one per lightbulb. The manufacturer might still care about security, so they'd like a cleverer technical solution that provides a decent level of security without those support costs.

Avoiding the coming IoT dystopia

Posted Feb 27, 2019 18:19 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (4 responses)

It's not just a matter of support costs. The manufacturer (or ISP or whoever else provided the device) should not have the ability to impersonate the owner of an already-configured device without the owner's consent, as a matter of basic security. If the owner loses their credentials they *may* be able to reset the device to its factory-default state and start over—whether to provide that option depends on whether you're mainly trying to secure the data on the device or the device itself. If a physical factory reset option is provided then there is no need for default credentials beyond physical access, and the owner should be required to configure their own unique credentials before the device can be used. On the other hand, if the hardware is valuable in its own right and the goals include deterring theft then it may not make sense to allow the device to be reset at all without first authenticating the owner. In that case it must be accepted that if the owner's credentials are lost the device becomes nothing more than an expensive paperweight.

Avoiding the coming IoT dystopia

Posted Feb 28, 2019 7:24 UTC (Thu) by omgold (guest, #109541) [Link] (3 responses)

How would "should not have the ability to impersonate the owner of an already-configured device without the owner's consent" be implemented at all? Is that possible at all (with realistic effort)? Don't see how you could really protect yourself from someone having full control over the hardware and firmware before handing the device over to the "owner".

About printing the default key on separate paper, sure it has both advantages and drawbacks.

Advantage: visitors with temporary physical access cannot reflash the device unnoticed
Disadvantage: the paper may be lost

In case that default password is just used for flashing firmware, with a separate password for management of the device (the latter would be set to empty on factory reset), it seems it would be okay. The former use case is rare enough for not causing the vendor much extra work, or customers losing much for being unable to to that (Anyone wanting to mess with the firmware should make sure to obtain and not lose the password). The latter case would just be protected against by making the device lose the wifi pw on factory reset, so it won't go unnoticed.

Also I believe that obtaining a PK certificate from the vendor on request would not protect from the "visitor attack" scenario, as the visitor might just do that for his own pubkey. How would the vendor determine whether the request comes from the rightful owner, when the only proof is physical access?

Avoiding the coming IoT dystopia

Posted Feb 28, 2019 17:19 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (2 responses)

> Don't see how you could really protect yourself from someone having full control over the hardware and firmware before handing the device over to the "owner".

That isn't the goal. Before the device has been handed over it hasn't been configured yet, doesn't contain any of the new owner's information, and isn't trusted by other devices in the owner's network. By the time the new owner starts using the device, however, they should have control over it—and the prior owner should not. This is incompatible with per-device passwords which could be retained by the previous owner(s), or other parties, and not replaced by the actual owner of the device.

> In case that default password is just used for flashing firmware, with a separate password for management of the device (the latter would be set to empty on factory reset), it seems it would be okay.

Sure, but it's an unnecessary complication. If you're going to allow anyone who ever had access to the per-device password to reflash the firmware then you might as well just open it up to anyone with physical access and skip the password. Especially if the password is attached to the device, as others have suggested.

> (Anyone wanting to mess with the firmware should make sure to obtain and not lose the password).

The current owner might not care, but what about the next one? If devices are sold with a separate paper which is only needed to install non-vendor-approved firmware, the odds that paper will survive long enough to be included with any resale of the device are slim. The idea here is that a single key (most likely embodied in a smart card or other hardware token) which you use to identify yourself to all your devices, and which is required for setting up any new device, would be more likely to be retained than per-device default passwords.

> Also I believe that obtaining a PK certificate from the vendor on request...

I don't recall anyone suggesting that. If physical access is sufficient to reset the device then the vendor doesn't need to be involved; one would simply reset it and load new credentials. This doesn't prevent the "visitor attack" but such attacks can be made detectable. The most obvious approach would be to identify the device itself using a unique internal key which is destroyed and regenerated as part of the factory reset, making it appear as a new device. At that point the "visitor attack" becomes equivalent to a visitor simply removing the original device and replacing it with one of their own. They can mimic the original configuration but the absence of the original device will be immediately noticeable, and none of the other devices on the network will trust the new device.

Avoiding the coming IoT dystopia

Posted Mar 4, 2019 8:43 UTC (Mon) by omgold (guest, #109541) [Link] (1 responses)

> If you're going to allow anyone who ever had access to the per-device password to reflash the firmware then you might as well just open it up to anyone with physical access and skip the password.

"allow anyone who ever had access to the per-device password" < "anyone with physical access". I believe the most likely case will be devices which are never resold and the password will never be changed from the default, in which case it is a protection.

Okay, when assuming that a device is no longer a threat after wiping all personal information, the following mechanism should suffice:

- a factory reset wipes all personal information and reinstalls the original firmware
- before doing a firmware flashing operation the devices enforces wiping of all personal information

> Especially if the password is attached to the device, as others have suggested.

True, not a good idea to do that.

> The idea here is that a single key (most likely embodied in a smart card or other hardware token) which you use to identify yourself to all your devices, and which is required for setting up any new device, would be more likely to be retained than per-device default passwords.

Where would the hardware token come from?
- included with the device? -> expensive
- needs to be bought separately? -> impractical for unskilled users

What if it gets destroyed or lost, or if the previous owner does not include it or reset the association?

I'd say, if this is implemented, it would still be necessary that a factory reset clears the association and allows anyone with physical access to associate it to an arbitrary other token.

In that case the security would not be any better than allowing the user to set his own access password (which is also wiped on factory reset). That was my original argument/question. What kind of attack scenario, a PK authentication mechanism (with hardware token or not) would protect from?

Avoiding the coming IoT dystopia

Posted Mar 4, 2019 16:28 UTC (Mon) by smurf (subscriber, #17840) [Link]

> - before doing a firmware flashing operation the devices enforces wiping of all personal information

Why? if you can access the device's firmware flashing page then presumably you can also download the settings and re-upload them afterwards.

Avoiding the coming IoT dystopia

Posted Feb 27, 2019 22:33 UTC (Wed) by andresfreund (subscriber, #69562) [Link]

> If there is a separate "sheet with the preconfigured pw", some fraction of customers will inevitably lose that sheet, then will phone customer support and (quite justifiably) demand to be allowed to use the product they bought.

For a lot of devices having the default PW printed onto the device itself is viable...

Avoiding the coming IoT dystopia

Posted Feb 13, 2019 2:41 UTC (Wed) by lkundrak (subscriber, #43452) [Link]

> He pointed to some recent incidents, including IoT baby monitors that were compromised by attackers in order to verbally threaten the parents.

The story is pretty sickening.

On the other hand, there's at least one case, where an unauthorized access to something the article calls a "range-limited, walkie-talkie-esque" baby monitor uncovered an actual (and pretty bizzare) child abuse case: https://www.reddit.com/r/UnresolvedMysteries/comments/71e...

Avoiding the coming IoT dystopia

Posted Feb 13, 2019 7:53 UTC (Wed) by mfuzzey (subscriber, #57966) [Link] (10 responses)

Require by law users to be able to reprogram their own devices. Irrespective of GPL or otherwise licensing of the standard firmware.

Of course vendors would be under no obligation to provide source code of their proprietary firmware but even that should be replaceable by a clean room implementation.

As others have pointed out the absolute cost of providing a user firmware update mechanism is fairly low *but* in a highly competitive market it can make a prohibitive difference.

By making it a legal requirement (like EMC testing say) the playing field is levelled.

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 16:46 UTC (Thu) by felixfix (subscriber, #242) [Link] (9 responses)

"Require by law" -- so helpful, solves all the problems -- just pass a law! "So let it be written, so let it be done."

The first thing to go wrong will be the government adding all its own security theater so it can "share" co-ownership with you.

The second thing to go wrong will be the government specifying the exact allowed and required technology to make sure evil businesses don't find loopholes to comply with the letter of the law and not the spirit. The regulations will be so onerous and cumbersome that the government will have a thousand ways of showing non-compliance for any manufacturers it deems too uppity, ie, too concerned with what actual customers might want, as opposed to the customers' new co-owners.

The third thing to go wrong will be locking in technology which quickly becomes obsolete.

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 17:57 UTC (Thu) by nix (subscriber, #2304) [Link] (8 responses)

"Require by law" -- so helpful, solves all the problems -- just pass a law! "So let it be written, so let it be done."

Well, that actually is how one normally solves this problem. If e.g. safety features in cars are optional, a race to the bottom has historically resulted that leads to all best-selling models that don't sell explicitly on the basis of safety using none of them to save costs, or getting outsold by those that do so. Regulations requiring those safety features level the playing field, preventing outcompetition of safer models, and the resulting world is better for everyone.

It's not 'just pass a law', it's 'just pass a law and implement an enforcement mechanism' (for cars, regular legally-mandated checks that include routine verification that e.g. this car has seatbelts, etc). There's a reason the UK MOT test is named after the (historical) government ministry that mandated it (leaving actual checking up to third-party service providers that were periodically inspected).

This works. It is why we don't have cars that routinely burst into flames, cookers and heaters and in-house electrical networks that don't catch fire, buildings that aren't firetraps etc. Regulation makes requiring features economical where otherwise they would be competitively impossible to implement.

Avoiding the coming IoT dystopia

Posted Feb 15, 2019 0:08 UTC (Fri) by felixfix (subscriber, #242) [Link] (7 responses)

My apologies for being perceived as an anarchist rant, if I did.

What I meant is that far too many people pass ill-conceived laws in a rush with no thought to consequences, wanted or not, predicted or not. I then listed three ways any such law would go wrong.

I'd rather you answered those three predictions than the perceived-political preamble. But since you thought I went there, and then did go there yourself with a counter-example instead of responding to my three predictions, I will answer your counter-example.

Your last paragraph is as wrong as can be. Car advertising has always had manufacturers touting their safety, and if you look at graphs of vehicle safety per mile traveled, without seeing any years to make it easy, you will be hard-pressed to tell from the graph when government-mandated safety features came into play. Seat belts were available as options long before governments mandated them. Disc brakes, more efficient engines, many many such features were sold before governments mandated them.

Common sense and any reading of history shows that as people become more wealthy, as economies improve and as societies have more spare cash and more free time, they like products which don't blow up, burn them, fall apart, or endanger their children. Pick any product you wish; look at its history over time; and you will see that people demanded better products, always, continuously. When products were new and dangers unknown, people died and were injured; demand brought better products, and cheaper products; more customers meant more demand for safer and cheaper products.

Governments have *always* been late to the game. Maybe you should research saccharine, first declared carcinogenic in spite of all evidence, and finally declared non-carcinogenic 30 or 40 years later. Coffee is good -- bad -- good -- well heck who knows!

To have blind faith in government regs to be either timely or correct is not supported by history.

Now if you please, answer my three predictions with some substance. They may be partly flippant and sarcastic, but that should have made them easier to refute.

Avoiding the coming IoT dystopia

Posted Feb 15, 2019 0:47 UTC (Fri) by sfeam (subscriber, #2841) [Link] (3 responses)

You argue that government certification is not necessary to drive consumer demand for safety because the consumer will in any case choose a safe product in favor of an unsafe product. But this assumes that the consumer has some way of telling whether a product is safe or not. If you want historical examples, look at food safety before and after creation of the FDA. Consumers want, and always wanted, safe food and safe medicine. But "the market" demonstrably failed to provide any way for the consumer to know whether a particular packaged item was safe or not.

Determining the properties of a commodity IoT gizmo pulled from a bargain bin may be more feasible than determining the health benefit or harm of a box of fad diet supplement with no ingredient list, but only for someone with a lot more technical savvy and test gear than any normal shopper. The seat-belt example is not parallel because anyone can see whether they are in fact present, and favor a vehicle with seatbelts regardless of whether that feature was required or voluntarily offered. The recent VW diesel emission scandal is maybe a better parallel, since individuals purchasers had no way to detect that the manufacturer was lying about the behavior of an advertised feature. Yeah they choose the "safer" product, but failure of what was supposed to be a government certification of compliance vitiated that choice.

Avoiding the coming IoT dystopia

Posted Feb 24, 2019 20:27 UTC (Sun) by Wol (subscriber, #4433) [Link]

Seatbelts in cars may also be a false example. I'm not aware of all the details, but in the UK, rear seatbelts became a mandatory requirement in 1986. But how many people realise that all vehicles SINCE THE EARLY SIXTIES were capable of having rear seatbelts fitted? BECAUSE IT WAS A LEGAL REQUIREMENT. There was no requirement to fit them, but the mounting points had to be there, and they had to be a manufacturer's option.

I don't know what the dates are for front seatbelts, but obviously they're earlier. But those dates mean that, for almost my entire lifetime, rear seatbelts have been an option on new cars. However, until they became mandatory, many cars didn't have them. I know - in my 1985 car - I had them fitted by the dealer before delivery, so they weren't that common.

Cheers,
Wol

Avoiding the coming IoT dystopia

Posted Feb 25, 2019 2:52 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (1 responses)

> Consumers want, and always wanted, safe food and safe medicine.

Not true. *All else being equal*, safe food and medicine are obviously preferable to unsafe food and medicine. However, that condition almost never holds. Safe food and medicine cost more—and given the choice, quite a few people would choose slightly more risky products over safe ones with higher prices. The FDA makes people safer (by some metrics) by forcing them to either pay the higher price or go without, thus trading one highly visible form of harm for another, more subtle kind.

Avoiding the coming IoT dystopia

Posted Feb 25, 2019 7:28 UTC (Mon) by smurf (subscriber, #17840) [Link]

So what's the subtle harm in "forcing" people to not buy unsafe food or drugs?

I've got a more tangible harm of not doing that for you: the same people who are unlikely to buy safe food are also unlikely to voluntarily buy health insurance, therefore (when the unsafe food bites them or the unsafe drugs don't cure their disease) they end up as non-paying customers of the hospital's ER, thus forcing increased healthcare costs on the rest of us.

This is not hypothetical. In countries with mandatory insurance, going to a hospital costs an order of magnitude less than in the US.

Avoiding the coming IoT dystopia

Posted Feb 15, 2019 1:04 UTC (Fri) by karkhaz (subscriber, #99844) [Link]

I think the car example is a poor one.

> blow up, burn them, fall apart, or endanger their children

it's very unlikely that IoT devices will cause these dangers, and certainly not at the scale at which car fatalities would happen without safety features.

The real problem is that IoT devices are dangerous to populations _other than their users_ at massive scale---what in economics is termed a 'negative externality'. Comparable examples are environmental damage by companies, and this is exactly the situation where governmental regulation is required. Companies typically don't regulate themselves for harm caused to their non-customers, except to prevent damage that is so spectacular that it causes them to lose even customers who are not affected.

Consumers don't care that their IoToaster participated in a DDoS attack against a DNS server or whatever, in fact they don't know what that even means. They're not going to pay more money for a product that promises not to do that.

Avoiding the coming IoT dystopia

Posted Feb 15, 2019 15:42 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

Maybe you should research saccharine, first declared carcinogenic in spite of all evidence, and finally declared non-carcinogenic 30 or 40 years later.

What on earth does changing scientific understanding have to do with any of this?!

Avoiding the coming IoT dystopia

Posted Feb 15, 2019 16:47 UTC (Fri) by felixfix (subscriber, #242) [Link]

There was no changing scientific consensus, only a changing bureaucratic opinion.

Avoiding the coming IoT dystopia

Posted Feb 13, 2019 15:13 UTC (Wed) by PengZheng (subscriber, #108006) [Link] (7 responses)

Security is definitely the last reason for IOT reinstallability. They are much more physically accessible to attackers, unlike phones and laptops. Even for phones, iOS is much safer than android. Stop hoping that everybody has the necessary skills to protect themselves. That will never happen.

The Chinese camera joke is silly trolling. Home camera will send footage to the nearest sever, mostly a local one, otherwise it will be economically inefficient. Not to mention there is the Great firewall making the network quite jerky.

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 2:17 UTC (Thu) by ssmith32 (subscriber, #72404) [Link]

>Security is definitely the last reason for IOT reinstallability.

Depends on your threat model. If the seller is considered one of the primary malicious actors (see comments above about TVs selling data), then reinstallibility is a *key* part of IoT security.

Not taking a side here, just saying, in security, such absolute statements are often, but not always, unwise.

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 14:20 UTC (Thu) by mjthayer (guest, #39183) [Link] (5 responses)

> Security is definitely the last reason for IOT reinstallability. They are much more physically accessible to attackers, unlike phones and laptops. Even for phones, iOS is much safer than android. Stop hoping that everybody has the necessary skills to protect themselves. That will never happen.

There is an argument to be made (and I will not actually try to make it further, because there are lots of issues on both sides) that it should be possible for the owner to hire an independent professional to fix their device, that is, anyone with the necessary skills. That does not have to mean that any random person should be allowed to fix any device (radio transmitters?), just as anyone with the necessary skills is able to fix the electrical wiring in their house, but some parts are only allowed to be fixed by recognised professionals. Making it hard for someone without certain qualifications to fix (who decides who they are?) might be reasonable.

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 16:00 UTC (Thu) by smurf (subscriber, #17840) [Link] (4 responses)

Well, requiring some hoops that demonstrate rudimentary knowledge of public key voodoo and signing binaries and such should work as a first step.

A parallel might be drawn from electrical installation. It's easy enough to screw some wires into some terminals, but (a) you get inoculated from when you're three years old that this electrical shit is damn dangerous, (b) the wires have colors and the terminals have letters, if that, so it's quite obvious that things will go wrong when you don't know your stuff, (c) even when you start really learning about power installations they hit you with safety precautions left and right.

How to translate that to ioT is obvious. The first step is to legislate that manufacturers (or tinkerers) shall carry 100% liability for whatever happens when somebody manages to exploit their bugs. Second would be to raise awareness, which will be way easier as soon as there are choices other than "add some insecure crap to your network" and "don't buy that stuff in the first place" because there'll be way less cognitive dissonance.

Avoiding the coming IoT dystopia

Posted Feb 15, 2019 14:49 UTC (Fri) by NAR (subscriber, #1313) [Link] (1 responses)

"The first step is to legislate that manufacturers (or tinkerers) shall carry 100% liability for whatever happens when somebody manages to exploit their bugs."

That would surely solve the "GPL'd software on IoT devices" problem (GPL means no liability, but manufacturer has to provide liability, so it won't be able to use GPL'd software), but I'm not sure this is what the talker wants to achieve...

Avoiding the coming IoT dystopia

Posted Feb 15, 2019 16:54 UTC (Fri) by farnz (subscriber, #17727) [Link]

Not true - you can use GPL'd software, it's just that you have no-one upstream of you to handle the liability. It all falls on your shoulders as the IoT device maker; if upstream software has an exploitable bug, and you put that on your device, then you are liable for the results.

Same applies if you use Microsoft Windows Embedded, FWIW - the licence says that Microsoft aren't liable, but it's still possible to use it in places where you are liable, you just have to insure against the risk that there's a bug that results in liability for you.

Avoiding the coming IoT dystopia

Posted Feb 15, 2019 17:18 UTC (Fri) by mjthayer (guest, #39183) [Link] (1 responses)

"The first step is to legislate that manufacturers (or tinkerers) shall carry 100% liability for whatever happens when somebody manages to exploit their bugs."

Has there been any serious attempt anywhere to hold people to account for damage caused to other people (e.g. manufacturer taken to court when lots of their exploitable devices DDoS someone's important service) using existing legislation?

Avoiding the coming IoT dystopia

Posted Feb 25, 2019 16:23 UTC (Mon) by Wol (subscriber, #4433) [Link]

Which plays straight into the hands of the American "tick the checkboxes oh we must be safe" mentality, and which dodges blame by saying "oh look we carried the procedures mandated by law".

European legislation on the other hand, as someone else pointed out, is more interested in outcomes. So you should legislate that "businesses must be able to demonstrate robust, working procedures for dealing with the bugs in the code in their products". In other words, if your reaction to a bug report is to sweep it under the carpet, or if it's a serious bug to run around like a headless chicken, then you're in breach of the legislation and liable for the consequences.

If, on the other hand, you have a mechanism for creating, and rolling out, bugfixes to your products to deal with problems then it's much easier to show compliance with the legislation - you just point to your security team and say "watch them triage bugs, create fixes, and roll them out". The system is there, it can be watched in action, and while it may not (indeed, pretty definitely won't) fix all the problems it will result in far fewer of them.

Cheers,
Wol

Avoiding the coming IoT dystopia

Posted Feb 14, 2019 5:06 UTC (Thu) by pj (subscriber, #4506) [Link]

The best I've been able to do personally is prefer to purchase 'hackable' devices: Sonoff/ITEAD IoT gear (ESP8266 based), HomeAssistant-compatible IoT gear (preferably local-push, avoid cloud-*), Android phones that will run LineageOS, etc. I'd love a curated list of such things.

Avoiding the coming IoT dystopia

Posted Feb 19, 2019 8:55 UTC (Tue) by tdz (subscriber, #58733) [Link] (4 responses)

> The Linux upstream is too focused on big corporations and their needs, to the detriment of the small, hobbyist users

This is certainly true, but it's not like there's a conspiracy. Big corporations pay developers for what they need. I'd say that a neutral organization (e.g., the Linux Foundation) should hire a number of people for keeping the Linux ecosystem in good and hack-able shape.

Avoiding the coming IoT dystopia

Posted Feb 19, 2019 11:48 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

The Linux Foundation? You mean the body which has no community representation any more and is *entirely* funded by big corporations? ... perhaps another body retaining at least a little of the free software ethos would be more appropriate.

Avoiding the coming IoT dystopia

Posted Feb 19, 2019 16:59 UTC (Tue) by tdz (subscriber, #58733) [Link] (1 responses)

I see what you mean, but which other organization is vendor-neutral *and* has the necessary budget?

Avoiding the coming IoT dystopia

Posted Feb 20, 2019 8:26 UTC (Wed) by smurf (subscriber, #17840) [Link]

Maybe somebody like the Raspberry Pi foundation? They at least can be trusted to have the "needs of the small, hobbyist users" in mind. (They should get the rest of their patches upstreamed, dammit.)

The main problem is, however, that these needs are not a well-defined deliverable that'd be easy to organize some funding around, crowd- or otherwise.

Avoiding the coming IoT dystopia

Posted Feb 20, 2019 2:20 UTC (Wed) by pabs (subscriber, #43278) [Link]

Are there other organisations related to Free Software that would be able to fund such work? The only one I can think of that has enough funding would be Mozilla but it seems unlikely they would be interested.