1x65: Soft Bricking


Probably closer to the cable / satellite provider model. Although maybe taking a lesson from the cel phone space, we’ll find the government regulating eventually with requirements for device “unlocking” and portability between service providers.


With respect to the next generation of enthusiasts, I think there’s one other factor to take into account. Namely that in the late 90’s, most people wanting to work on open source had to do it in their spare time, These days open source has become big business and a track record contributing to open source projects (however small the contribution) is likely to result in interest from recruitment firms if not employment working on open source. Many open source enthusiasts also happen to now get paid for doing what they enjoy.


@sil was wondering how to make a “works-offline” consortium a viable business - well how about selling insurance policies to the orange/red companies (those that the death of, would brick their device(s)) which could either be enough to keep the servers running for a few years (with varying levels of staff support paid for to keep security updates/bugs fixed depending on the level paid for)? Then orange/red companies could claim to be less red and put a more-green kite mark logo on their box. Of course the cost of that green mark (and how much customers care/will pay extra for it) has to be worth the expense…

Of course companies could avoid the insurance cost by instead agreeing to open source their code (or at least provide a free download of the binaries + dependencies and spec for the system to run it on). What about dependent services too for the cloud service?

The insurance premium would be based on how often your company or industry or product type gets shut down and how much your products rely on the cloud, which could be a good push in the safer direction


One reason for companies not to open source their code on “death” is that if they end up with a lot of debt, one way to clear that debt may be to sell the product and code to another company (who might not plan to run the same service but a competing one with a different API or just using one part of it, which means the original products would still be bricked - or even if its the same service, likely at a different IP address and if your original product configuration for IP/port is unavailable or locked down, that still really annoyingly leaves you bricked even though it might work if it could be changed and you signed up with the new co.).


Well the current state of affairs is already (5) and (6) as there are already organizations, for-profit and non-profit, that give ratings and rankings to products and services. There’s Consumer Reports, JD Power, US News, CNET, and even the Federal Trade Commission (FTC) and Better Business Bureau in the U.S.

If a device is tied wholly or considerably to a service, consumers today already weigh the pros and cons of agreeing to a service and accept the possibility of the service disappearing overnight. For things like the Mycroft, it’s basically a given you are taking on that risk since the product isn’t even released yet (and may never be). And for cable set-top boxes and the Amazon Echo everyone can agree that the entire point of the device is tied to a service which could go poof in the future.

Options (1) to (4) would imply some kind of government intervention, but I’m not sure if that’s entirely warranted. Is it reasonable to impose those costs on businesses? Would there be any repercussions in doing so? Like I said, there are already third-party ratings agencies whose reviews can be considered by consumers who care about these things. It would be an interesting public policy discussion though :wink:


In this situation even somewhat open companies have reverted to closed in their final days. Anyone ever use the Zeo Sleep Tracker? They dipped their toes in the water of “openness” by releasing source code for interacting with their devices on SourceForge. When it was time to shutdown they yanked all the code off their sites and SourceForge.


There’s nothing new here. It’s been happening for a long time with certain games, Ubisoft and EA in particular would EOL games last decade and there would be no more option for multiplayer, as they controlled the servers.

Also, some tech should be obsolete but it’s not. There is something on the order of a billion Android phones that are completely vulnerable to awful security issues but are never going to get an update. That’s a billion or so people walking around with a device in their pocket with a camera, microphone, GPS and most if not all of their important account details that have no defence against known, proven attacks. Sure it still makes a phone call, but at what cost? What about all those computers still running XP, not your problem, until they’re used as zombies in a DDoS against your business or a service you use. Or they’re running in your hospital and some enterprising person on the other side of the planet decides to install ransomware on them.

Another issue, and one I think everyone might have had in mind when debating Bryan, is that some devices are going to rely on server-side processing to do their magic. For example, Amazon Echo. Though, if you willingly put a microphone in your house so that Amazon can record everything that happens in order to sell you more crap, I’m sorry but we can’t be friends.

The only answer in the long run is consumer awareness, that your device and/or software is reliant on the manufacturer/maintainer and thus YMMV. Openness or guarantees from the company might be a feature or requirement, though right now this usually gets sunk by Moore’s Law and the quest for newer and shinier.

Edit: I was way off, it’s 400 million according to The Register. Still a ridiculous amount.


Certainly there are, but they’re giving an overall rating. I think we were talking about some sort of thing assessed purely on the device/company’s process around longevity. That is, a given device gets a red/amber/green rating around how well they’ve promised to handle the company going bust or getting bored with the product, their discontinuation and deprecation policy for APIs, etc. I’m sure that Which or Consumer Reports or any of the others would then take that rating into account in their own reviews!

I utterly, utterly disagree. If that were the case then there wouldn’t have been any discussion about Revolv at all, because everyone would have already accepted the policy. The idea that a device you’ve already bought and which already works may suddenly stop working because the company you bought it from are bored with it is a new and surprising one to basically everyone, and it would be nice to build a world where everyone learns that this is a possibility through being as educated as you suggest, rather than from having been burned by it and so swearing off technology. There’s a massive externality here; every time a company screws customers like this unexpectedly, they count the benefits to their cashflow and the deficits to their reputation from doing so, but they don’t count the marginal amount that doing this damages the credibility of internet-connected devices in general. If too many companies do it, then everyone basically stops trusting or feels wary about all such devices and the market is seriously hampered.


Yes. Can’t believe that no-one mentioned this (at least from my quick skim-read). Why is no-one reading between the lines of this story?

Shutting down an API is one thing, but telling users that you’re intentionally going to brick their device is a completely stupid thing unless you have a particular motive for doing so. In this case, a motive sufficiently powerful that Nest would rather refund all the users than not do it.

Reasons I can think of would be:

  1. The way the tool works relies on either software or a protocol that is obsolete (and/or insecure), and thus is likely to stop working in the future anyway.
  2. The tool has an existing security vulnerability that it isn’t worth patching.
  3. The tool has weak security that could be broken and represent a vulnerability for the end user and/or the company/internet at large (ie easily zombied)
  4. The device is sufficiently badly designed that it just plain won’t work without the server end (most likely in combination with either 1 or 2)


Fair enough. After thinking on this for a bit, isn’t this just a classic case of where we should be advocating for open standards and open formats? If the API is open, I could care less if the company fail or withdraw their service from the market. Even if they don’t open source their code, just publishing their API would be a huge step in the right direction of being able to use devices you’ve payed for. Sure, it would be inconvenient as you then have to find another company or pay to host your own, but at least you have still have access to the device you paid for. That seems to me to be the ideal rather than trying to implement a potentially complicated ratings systems given that there are already lots of organizations that provide reviews. It’s all well and good to say there should be a common rating, but the devil is in the details–Who will do the rating? How would you ensure compliance and how much would it cost? Would every company that make a product be liable? I’m not saying these things can’t be worked out, just that there would need to be plenty of attention to detail when implementing it.

Every company that starts out making a product feels the need to withhold information since they believe doing so gives them a competitive advantage in the market. The trick then is how do we convince them that open standards are better for everyone? Companies aren’t going to respond unless they see their customers asking for it. Of course, that’s leading into the whole “advocacy effectiveness” thing you guys hinted would be in the next show :wink:

Maybe companies do have to be guilted into it with a mandatory red/amber/green rating, but I do wonder if there is another way we can convince get companies to do the right thing.


I agree entirely, and such evangelism for opening and documenting the API that the device uses is a good idea. It’s had little to no success, historically, but it’s still the right thing. Asking for this can continue in parallel with other approaches to help inform customers about whether a device is good or not, and of course a device which talks to its server via an open and documented API has gone a long way towards getting a “green” rather than “red” rating.

(Note that having a documented API doesn’t actually help very much, because the device will be hardcoded to talk to api.company.com. If you’re a techie, you can probably poke your router to lie about where that is and have it talk to your own server, but that’s not sensibly available to normal customers; the company could also provide a way to configure the endpoint on the device, but that’s extra work for them and it makes it easier to buy the device and not use their service, which disinclines them to make it possible. But it could still be doable.)


I think you’ve hit on a subject that’s much more important than people realise. Until recently I had a Saab 9-5, originally built in 2002. It was a wonderful car, but when it’s electronics started to fail, diagnosing the problems started to get harder and harder because the marque had gone bust, and therefore support for older models fizzled out a lot faster than would normally be the case. I wouldn’t be surprised if this sort of thing gets more serious with the advent of Electric vehicles and autonomous cars.

Good work chaps, a subject well worth airing.


For what it’s worth, Adafruit adheres to what it calls the IoT bill of rights, which they apply to their own adafruit.io IoT service. It’s discussed in their weekly Ask an Engineer segment on YouTube this very week: https://youtu.be/aOzGigXecxk?t=5m31s


they just got a commitee.

ToDo sure beats TaskUs - InMyHumbleOpin.

Listened to 1x65: Soft Bricking for the first time today … and as far as : -

… there’s always OpenSourceFriday :rocket:

Please respect our code of conduct which is simple: don't be a dick.