The right to repair is mostly about hardware. But it's hard to ignore the software part of hardware. And that means having the right to keep and run old versions of software. Old software that work perfectly fine and do their job.
Forced auto-upgrades are fundamentally hostile to the user's freedoms. Ever since the browsers introduced forced auto-upgrades, we've been moving away from an open web to an internet of closed silos.
Forced auto-upgrades is often justified in the name of security. It's not worth it. The "good intention" of improving security through forced auto-upgrades is pushing us down the road to hell.
In a way, we developers are responsible for all of this. We all jumped on the Chrome bandwagon, we all told our friends & families to use Chrome, we all enjoyed the reduced browser market fragmentation after the forced auto-upgrades were introduced. We loved not having to support old browsers anymore. We loved being able to use the latest and greatest browser features. We get angry because Safari is "holding us back".
But at what cost?
Developing for work & for money might've become easier, but what about developing for yourself? As a power user, in control over your own computer? The internet has been getting more and more hostile to alternative ways of interaction, especially as browser market share turns into a monoculture.
We need to encourage more market fragmentation across software - including browser versions and OS versions. We also need to beware of the "winner take all" distribution. There's a strong tendency for everyone to pile onto the most popular programming languages, frameworks, tools. This has an extremely strong centralizing effect, it leads to a very thin long tail for alternative choices. And usually the alternate choices are very limited because there's not enough demand to improve those choices. Clustering around popular choices ironically hurts the market fragmentation collectively.
We need to make it easier to use old software. This pressure to constantly upgrade all software is also leaving many good software behind. Old software that worked great in their particular milieu.
One of the dreams of VMs was to be able run all sorts of old software any time, safely, securely, in their own perfect environment & dependencies. When is that going to become a common & easy thing to do?
Yep, agreed. I think the steps for consumer-operable, secure personal devices and software are relatively straightforward.
- Code should be open source and available from widely-mirrored common publishers
- Builds should be reproducible (partially addressing your concerns)
- Auto-updates should be turned on by default, but can always be disabled (also addressing your concerns)
Proprietary software and auto-updates run the risk that user-harmful changes may be introduced with close to zero ability for the developer community to inspect, reason about, report and fix them.
Most of those harmful changes are small errors and accidental mistakes, but they go easily unnoticed in a world where developed code is unlikely to be seen, and where the customer has little ability to see (at install-time or retrospectively) the contents of updates.
If you have a safety-critical and/or widely-used system, then before applying a change, you'd ideally like to know exactly what the contents of that change are, be able to read and figure out what impact it will have, and then choose if and when to update.
If that works well for service infrastructure -- and I think it does -- there's little reason to expect it should be any different for personal devices and software.
This kind of visibility can be opt-in for everyday consumers, but the transparency should exist so that developers (a large and growing community, with incentives to assist) can help to make the ecosystem safe and healthy.
Most of the challenges introducing this are social rather than technical I think. Some developers aren't used to (and may legitimately feel uncomfortable with) writing code and making mistakes in public, app stores have ossified and are cash cows, and channeling worldwide code review and feedback to developers can be a challenge (albeit a fairly well-understood one at this point).