The battle really parallels the larger right to repair debate. (Especially if we realize the latter is probably is better called the right to exercise control over purchased goods.)
It's become an issue of defining "purchasing". But companies don't want us to purchase appliances, they would be much happier if we could rent them.
The rental/do not own anything model is just awful, in my opinion.
I tend to use things until they completely wear out, and I get really good life out of them. This makes them very cheap compared to the usage pattern of upgrading all of the time. Renting would be very expensive lifestyle; and my usage pattern is more environmentally friendly to boot.
It's not that I want to own or lease most random stuff I use. I want the use of a particular item. Since owning is cheaper I own a lot of stuff.
If my local library or maker space had better tool and book availability I would own fewer tools sitting in the shed used for one project and not with the effort to resell
No general computing company should be the single ingress point to running on their platform. For platforms with significant penetration, this is a market monopoly. [1]
For Apple, it's iOS and, increasingly, MacOS.
For Google, it's Android, and as has become glaringly obvious, Chrome. They shouldn't be allowed to run a browser.
The DOJ needs to stamp out this anti-competitive, anti-consumer behavior.
You can "protect" consumers with a permissions model and malware signature warnlist regardless of whether you enforce a store. Microsoft does it. Microsoft is the only company playing fairly.
([1] And no, this doesn't apply to game consoles. They're toys with lots of alternatives. You don't do business, banking, dating, note taking, drawing, stock trading, etc. on them.)
Because it's artificially made impossible. No computer should be artificially restricted – let's not keep any loopholes open for no reason.
I’ll believe it when I see an alternative to iOS devices that my dad can’t get malware on and only need a few seconds to fix by uninstalling an app or power cycling the device.
WebAssembly will be the ticket there—once it’s developed a bit more.
That being said, nothing compares to native. You could have shitty hardware by today’s standard with amazingly performant software if there weren’t so many damn layers in-between.
People are fickle with hardware though and we devs need things to slow down a bit to appreciate the nuances of each device!
With scale comes scaling issues; general purpose computing and repairability need a different commercial model that doesn't match with the currently used models.
This leaves two avenues:
- Make it worse for everyone but keep it going
- Make it worse for everyone in a different way and keep it going
I don't know of a good solution here, but I do know that it's a sucky situation and the many "good ideas" to fix it aren't actually making it that much better.
Current scenario:
- Manufacturer on the hook for most things but also controls most things
- End-users that fall within the 90% bell-curve are fine
- End-users that fall outside of that are royally screwed and they don't even know it
- Users that are not end-users are screwed, but they know they are
So far all I have seen is:
- Manufacturers still on the hook for everything but they get to control less
- Everyone gets a little better but also a little screwed now
- The 10% outside of the curve don't get as screwed as they did but they still don't really know that they are screwed
- The non-users don't get screwed the way they used to but still get screwed
To clarify:
If I were to manufacture something, express what user experience comes with my 'thing' and warrant that experience to a certain degree, I don't want to be on the hook for any service or cost outside of that. The more I get to control, the smaller I can make the risk. That means I can also plan ahead better and reserve resources, but not so much that I don't have resources for something else left over.
This also means that if someone wants a different experience (i.e. they are not my targeted audience) or if someone wants to do something I cannot verify, I really do not want to be on the hook for that.
In total that means:
- If what I want and what my customer wants is similar enough, we're both happy
- If a small percentage wants something else, I cut my losses and simply don't serve their needs as soon as the cost of maintaining that deviation is bigger than what I would make off of it (short term and long term)
- If someone does something I don't have control over, but they do come to me to fix their problem, I don't want to be responsible for that, and I don't want to do any research on the possibility that something I made happened to break at the same time the customer broke something else; I just want a blanket "I am the captain of my UX" rule and be done with it
Now, I'm not saying this is ideal, or that I am an actual manufacturer, or that this is specifically what Google is doing (or Apple is doing for that matter), but I am saying that you can't have it both ways. Want something cheap and abundant? Gotta have scale. Can't have scale if you make a bunch of risk, add a lot of differences and support more than your middle-of-the-bell-curve. This sucks, but it's also not easy as saying "let me do what I want", because what happens to you and your device has side-effects, and I really don't want to get affected by something someone on the mobile network (or wifi network) I'm on did to their 'personal' and 'owned' and 'freedom' and 'muh righz' device.
Or in a high contrast (black-and-white/good-or-evil) line: If you want to be on a shared service, play by the rules or get out. (reality isn't that high of a contrast obviously, but it drives the point of externalities home a lot quicker)
1 - I'm not sure I've encountered anybody that universally falls within the 90% 'ideal' coverage. The more hostile things are to outliers, the more difficult everyone's life becomes.
2 - As far as I can tell, the slack that allows the bottom and top vigesimile (? 1/20th) to survive is also what allows the flexibility to foster the discovery of novel technical and societal configurations that are materially better than the status quo. That's how a kid from a family of coal miners has a path to making significant contributions to NASA.
As for point 2: that should indeed be how it works, but the circumstances have changed, especially for large scale general purpose computing, and for various reasons and stakeholders as well. This is also the (wrong) fuel on the (wrong) fires in the current discussions on ownership, repairability and shared systems; it often tries to compare the "now" with a chosen "back then", and leaves out externalities causing the whole comparison to be useless.
For example: it used to be that you could run whatever code you wanted and you didn't need anyones permissions and nobody could stop you. Now, at scale, that means everyone from teenagers at schools circumventing the implementation of a usage policy to state-level actors extracting information would run whatever they want. They are of course already doing that to some degree, but this would be so much bigger and so much easier when you just 'run whatever code appears at the JMP', we might as well not have an internet.
This, in turn, means that you have to have some form of control, and some form of distribution or supply of such control as neither the will, nor the skill exists at the required scale to have everyone do this individually. How does one assert such control? Cryptographically. And now you're in PKI hell, or you're in DRM hell with DRM servers that go offline and render systems unusable. Oh, and you get DMCA and Legal requirements for free too.
It would be amazing if we could figure out a way to operate shared systems, and have some form of delegated control without having a PKI-like authority as the only way to ensure it. But I haven't seen it yet :-(
And this is just one of the many issues.
Take hardware for example; you can do plenty of nefarious things with hardware, and the user would never know about it. Want to backdoor an audio module so it constantly streams what the microphone picks up to an actor of choice (a social media company, advertising company, your abusive spouse, the government of a state that will hurt you on detection of dissent), you can do that and no normal user would ever notice. How would you then prevent such modification? Well, you could make hardware hard to access or hard to modify without visible marks. That's one area (slightly) covered, but then there is the software, imagine hacking that remotely. So how would you do something about that? Perhaps signing the software and checking the signature. Bam, back in PKI hell.
And if you were to make hardware hard to access, now you have a bad UX when someone comes to your service department and gets presented with a huge bill because your device had to be rebuilt because your kid put puke in the microphone hole. But if you make it unsafe you have the other problems again. No winning deal there. Or what if you use seals, now you have no idea why the seals are broken. Did someone tamper with it? Was it just a service call that's not registered in your system because it was done elsewhere? Who can you trust? What if you fix the reported issue but now something else breaks and you don't know if you did it or the previous tech did it? Guesses everywhere, everyone is sad, nothing works. yay.
Again, no real solution here. Say you do the (not very often implemented) secure boot method where you insert your own CA; that's great for yourself, not great for a shared system, because now everything else that requires you to be securely booted needs to trust that CA too. This, hoever, is an area where you can do a partial fix: if you just want local verification and you have the CA and CT you can at least know for yourself. But that doesn't work at scale. We can't expect billions of people to be PKI experts. And we can't expect them to understand the ramifications of the lack of verification either. (which includes effects on them, but also effects on everyone else they are in contact with by proxy) So now you still need that 'magic' central authority making a policy and a verification for that policy and enforcement. PKI hell all over again!
(keep in mind, I don't name PKI hell a hell because PKI is bad, I think it's great and I love me some hashing, public-key cryptography and root-of-trust chains -- it's just that there is no solution right now where you don't end up having an authority that can use it for good and bad at the same time)
There are a lot of scenarios where we could mitigate 'some' of it:
- Authenticated core but leave peripherals alone (your mainboard and CPU and AV chain would be on its own, but your keyboard can be key logging you as much as you want)
- Unauthenticated mode but no interaction with shared systems (would work great for things like farming equipment)
- Offline or do-it-yourself mode (again, no interaction, but you'd be offline anyway)
But then you're still in the realm of real-world abuse (want to know your ex'es password? backdoor the keyboard! steal your boss's documents? backdoor the printer!).
I don't know how to fix all of this, but removing all forms of authentication and still having shared systems isn't the way.
I'm old enough to have used the internet with a computer running Windows 98SE. As far as I can tell, besides data throughput, only webmail, maps, and media streaming have gotten materially better since that time, and even those peaked in an era when people were still running Windows XP SP3.
Despite all this froth about how we need to lock stuff down within an inch of its life with manufacturer-specified code verification, (North American) banks still seem to mostly be using the same terrible authentication policies they were 10, even 20 years ago.
The hardware problem isn't new; phone taps have been easy to install for decades. The world didn't end, nor did we shut down the telephone network.
In re software, we could easily strengthen owner trust in systems without having manufacturers ensnare us in straitjackets. Trust on first use could allow an infrequently-updated chain loader to verify subsequent components without depriving the owner of using the system as they desire. Hardware tokens, or physical buttons with dedicated circuitry could prevent certain system functions from being configured / updated without direct user intervention. 'Trusted' execution environments could be used to run software of particular significance to the device owner. We have an enormous quantity of tools in our tool box to improve the security of systems without relinquishing ultimate control.
Ultimately, though, liberty will always have some irreducible risk. It's not obvious to me why we should be valuing status-quo business plans to its detriment.
Even technically skilled users won't benefit from a construction of 'trust on first use', when was the last time you verified the host key of a system you SSH'ed into for the first time? How do you trust a system purely on something like that? And even then, when you got an error that the host key no longer matched, did you go on a research run to figure out how this might have happened, or did you just replace the key in your local known hosts cache and went on with your day?
What about websites, do you disable all CA's and just use local key pinning on all the websites that you visit? This is something you could do right now. But you won't, and neither will anyone else because it is far too inconvenient. It makes the entire thing useless. And every time you send an email, are you going to verify the fingerprint of the supplied certificate as well?
While it might not obvious to you, the feasibility of this at scale is something you can figure out by simply talking to users, looking at A/B test, comparative research, and looking at the security configuration of various user's systems and asking why they might have chosen the configuration as it is, and what the impact to them, the people they interface with and the internet as a whole might be.
wrt phone taps: it's possible and not the point (and not useful; the Americans did plenty of local and global taps and almost none of the broad taps yielded anything useful over 10 years, it was only the highly targeted taps that yielded real results). It's also not froth, "locking up stuff" and "straight jackets". It's about a hard problem, with everybody having an opinion but nobody having a solution. And the only thing people seem to want to do in such a scenario is apply a scorched earth policy which besides the obvious destruction doesn't yield a solution either. With the current devices and services there is so much personal data, proximity and interaction that the value and impact is much higher than your landline at home. The point isn't to make it perfect or perfectly secure, but to make it hard enough that it isn't an attractive broad-spectrum target anymore. Making it cryptographically hard to hack into a baseband, a bootrom or kernel is a very effective method to make this protection a reality, and so far there has not been a successful alternative presented by anyone, anywhere.
Ultimate absolute liberty is a fallacy, externalities exist, and society doesn't work in anarchy (but doesn't flourish in strict hierarchy either). Until you can manipulate time and space, and modify matter at a subatomic level, you are and will always be dependant on externalities, and as such you have to work with those. How hard you make it for yourself or others depends on the degree of society and civilisation you can live with. You don't control the BGP tables on your ISP's routers, but that seems to be fine for all the millions of users. But all of this is straying away from the topic at hand quite significantly.
(Edit;) As to the 'value status-quo business plans': that is not something we value, but something the producers of some large-scale hardware and software manufacturers value. They aren't society's friend, but they do need it to buy its products. And if the USP of the product is something you want to remove, then the manufacturer is probably going to try to prevent that. This would be 'fixed' by you getting what you want and they getting what they want, but that is not technically feasible (or: has not been shown to be technically feasible yet), hence the long blocks of text describing that problem.
The Internet is a good example. The threat model has been far too trusting, historically. We're paying for that in a variety of different ways. Burning it all down and starting over is impossible, so we're stuck in a mess. Maybe we can do better in the future.
This is also something that feeds the 'it used to be better back in the day' feeling, because some aspects might actually have been better because too many possible threat actors back then wouldn't take internet seriously and as such weren't an actual threat. So it wasn't safer, it was just less-attacked. As a result where was less pressure to make hardened clients and servers, and as a result of that, it meant that things like digital signatures were extremely optional (and computationally too expensive to include for the sake of it).
On the other hand, it's also the openness that brought its success, and may very well cause its downfall. (that said, nobody has been able to come up with a worthy replace ment so far) Having no single owner makes it better in that regard, but also worse.