[Razengan]

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.

[gowld]

HTTPS has multiple authorities. do you use HTTPS?

[Razengan]

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?

[AnthonyMouse]

> 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.

[Razengan]

> 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.

[AnthonyMouse]

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.