What was once a promise of technology to allow us to automate and analyze the environments in our physical spaces is now a heap of broken ideas and broken products. Technology products have been deployed en masse, our personal data collected and sold without our consent, and then abandoned as soon as companies strip mined all the profit they thought they could wring out. And why not? They already have our money.
The Philips Hue, poster child of the smart home, used to work entirely on your local network. After all, do you really need to connect to the Internet to control the lights in your own house? Well you do now! Philips has announced it will require cloud accounts for all users—including users who had already purchased the hardware thinking they wouldn’t need an account (and the inevitable security breaches that come with it) to use their lights.
Will you really trust any promises from a company that unilaterally forces a change like this on you? Does the user actually benefit from any of this?
Matter in its current version … doesn’t really help resolve the key issue of the smart home, namely that most companies view smart homes as a way to sell more individual devices and generate recurring revenue.
—Stacey Higginbotham
It keeps happening. Stuff you bought isn’t yours because the company you bought it from can take away features and force you to do things you don’t want or need to do—ultimately because they want to make more money off of you. It’s frustrating, it’s exhausting, and it’s discouraging.
And it has stopped IoT for the rest of us in its tracks. Industrial IoT is doing great—data collection is the point for the customer. But the consumer electronics business model does not mesh with the expected lifespan of home products, and so enshittification began as soon as those first warranties ran out.
How can we reset the expectations we have of connected devices, so that they are again worthy of our trust and money? Before we can bring the promise back, we must deweaponize the technology.
Guidelines for the hardware producer
What we can do as engineers and business owners is make sure the stuff we’re building can’t be wielded as a lever against our own customers, and to show consumers how things could be. These are things we want consumers to expect and demand of manufacturers.
1) Control over firmware updates.
You scream, “What about security updates!” But a company taking away a feature you use or requiring personal data for no reason is arguably a security flaw.
We were once outraged when intangible software products went from something that remained unchanging on your computer, to a cloud service, with all the ephemerality that term promises. Now they’re coming for our tangible possessions.
No one should be able to do this with hardware that you own. Breaking functionality is entirely what security updates are supposed to prevent! A better checklist for firmware updates:
- Allow users to control when and what updates they want to apply.
- Be thorough and clear as to what the update does and provide the ability to downgrade if needed.
- Separate security updates from feature additions or changes.
- Never force an update unless you are sure you want to accept (financial) responsibility for whatever you inadvertently break.
- Consider that you are sending software updates to other people’s hardware. Ask them for permission (which includes respecting “no”) before touching their stuff!
2) Do less on the Internet.
A large part of the security issues with IoT products stem from the Internet connectivity itself. Any server in the cloud has an attack surface, and now that means your physical devices do.
The solution here is “do less”. All functionality should be local-only unless it has a really good reason to use the Internet. Remotely controlling your lights while in your own house does not require the cloud and certainly does not require an account with your personal information attached to it. Limit the use of the cloud to only the functions that cannot work without it.
As a bonus, less networked functionality means fewer maintenance costs for you.
3) Decouple products and services.
It’s fine to need a cloud service. But making a product that requires a specific cloud service is a guarantee that it can be enshittified at any point later on, with no alternative for the user owner.
Design products to be able to interact with other servers. You have sold someone hardware and now they own it, not you. They have a right to keep using it even if you shut down or break your servers. Allow them the ability to point their devices to another service. If you want them to use your service, make it worthwhile enough for them to choose you.
Finally, if your product has a heavy reliance on the cloud to work, consider enabling your users to self-host their own cloud tooling if they so desire. A lot of people are perfectly capable of doing this on their own and can help others do the same.
4) Use open and standard protocols and interfaces.
Most networked devices have no reason to use proprietary protocols, interfaces, and data formats. There are open standards with communities and software available for almost anything you could want to do. Re-inventing the wheel just wastes resources and makes it harder for users to keep using their stuff after you’re long gone. We admittedly did this with Twine, creating an encrypted protocol that minimized chatter, because we needed to squeeze battery life out of WiFi back when there weren’t good options.
If you do have a need for a proprietary protocol (and there are valid reasons to do so):
- Document it.
- If possible, have a fallback option that uses an open standard.
- Provide tooling and software to interact with your custom protocols, at the very least enough for open source developers to be able to work with it. This goes for physical interfaces as much as it does for cloud protocols.
- If the interface requires a custom-made, expensive, and/or hard-to-find tool to use, then consider using something else that is commonly available and off the shelf instead.
5) Be a good citizen.
Breaking paid-for functionality on other people’s stuff is inherently unethical. Consider not doing this! Enshittification is not a technical problem, it is a behavioral one. Offer better products that are designed to resist enshittification, and resist it yourself in everything you do.
Nothing forced Philips to do what they are doing: a human made a decision to do it. They could have just as easily chosen not to. With Twine’s server lock-in, at least we chose to keep it running, for 12 years now. Consider that you can still make a decent living by being honest and ethical towards the people who are, by purchasing your products, paying for your lifestyle.
We didn’t get here by accident. Humans made choices that brought us to this point, and we can’t blame anyone for being turned off by it. But we can choose to do better. We can design better stuff. And we can choose not to mess things up after the fact.
We’re putting this into practice with Pickup. (We also think that part of an IoT reset is giving users the creative freedom of a general-purpose device.) If you’re looking for something better and our product can fill a need you have, consider backing us. We cannot claim to be perfect or have all of the answers, but we are absolutely going to try. The status quo sucks. Let’s do something about it.