Hacker News new | ask | show | jobs
by Dragory 2244 days ago
> I would still prefer to have to trust just one authority for my platform than a multitude of random developers.

These are not the only two options. What about multiple authorities, but not random individual developers? That's basically how it works with e.g. game stores on PC (though Steam is certainly the largest), or package repositories on Linux.

Like you, I like being able to trust an authority to vet the software I install rather than having to judge the trustworthiness of each individual developer, but I'm not a fan of there only being one authority by design (as it is on e.g. iOS). It introduces a single point of failure and gives that authority full control over all software on that platform - for better or worse. Many package managers specifically deal with the issue of consolidating updates to a single system while not relying on a single authority.

2 comments

> What about multiple authorities, but not random individual developers? That's basically how it works with e.g. game stores on PC (though Steam is certainly the largest), or package repositories on Linux.

> Like you, I like being able to trust an authority to vet the software I install rather than having to judge the trustworthiness of each individual developer, but I'm not a fan of there only being one authority by design (as it is on e.g. iOS).

You can already do this on Android though. Samsung offers an individual app store for it's phones, and FDroid works on all phones.

When it comes to the system's core sandboxing mechanism, only one authority can sign the certificates and provision capabilities etc.

If multiple authorities can sign apps, it sort of defeats the point and makes the sandboxing less trustworthy.

Right now, I can either: Rest assured that an app is sandboxed (via the App Store or macOS Notarization) or choose to let it run anyway (on macOS.) A dev could notarize their game (or not) and distribute it through Steam or the App Store, or both.

If Steam and GoG etc. could sign apps, then you're back to having multiple authorities of varying trustworthiness.

HTTPS has multiple authorities. do you use HTTPS?
That's not a good analogy for OS sandboxing:

• Will third-parties have the same standards for checking if an app uses only the authorized APIs and gating privacy/resource access?

• What happens when Apple/Google introduce new OS APIs, will those third-party signing authorities update their standards at the same time?

• What if a third-party goes rogue and starts signing malicious apps? How and how soon will we know?

> Will third-parties have the same standards for checking if an app uses only the authorized APIs and gating privacy/resource access?

You get to choose who the third parties are, so choose ones who do. Some of them may even have higher standards than the platforms do.

> What happens when Apple/Google introduce new OS APIs, will those third-party signing authorities update their standards at the same time?

This was solved decades ago. You introduce new APIs with new operating system versions and provide development releases to developers ahead of time so they're ready by the time the new system is released to the general public.

> What if a third-party goes rogue and starts signing malicious apps? How and how soon will we know?

Presumably the same way you know when Google or Apple does it.

> You introduce new APIs with new operating system versions and provide development releases to developers ahead of time so they're ready by the time the new system is released to the general public.

Even major companies still haven't implemented something as trivial as Dark Mode in all of their apps by now, I wouldn't count on them to keep up with more complex changes.

Google still hasn't implemented Picture-in-Picture on iPads. Others still don't support split-view multitasking. Both these features have been out for years.

My impression was that you were talking about API changes that actually require the developer to use them, e.g. because the old thing doesn't work with the new system anymore. Then you give them some notice and they're ready with the new thing because they want their app to keep working.

The things you're listing are optional features. That doesn't require some kind of coordinated effort. If one distributor requires support for Dark Mode on day one and another gives developers a year and another never requires it at all, so what? If you really love Dark Mode you can decline to install apps from distributors who don't require it. Or just decline to install apps that don't have it, which you could do regardless of what any distributors allow.