> The Safari version is exposed and the Safari version is tied to the OS version for iOS.
User agents can be changed by users in Safari. I wouldn't recommend doing so, but it is possible to tell Safari to stop reporting the version number to websites. I'm unaware of any way to do the same for native apps.
> There is also a battery level API that is not supported by Safari.
Note that native iOS apps do have access to battery level, which is another fingerprinting vector that can be avoided by using websites through Safari or Firefox.
Yes, I’m sure all of the people who are going to download an extension to change the user agent version in iOS are really going to mess with analytics
And which way are you arguing that Apple should add more OS level APIs for web apps or should have less for native apps?
You can’t have it both ways. Either you want the wonderful world of PWAs where random websites have more access to your hardware and more parity with native apps and less privacy and security or you want it to remain more restrictive.
These and more are all APIs that Apple has refused to implement that HN users are clamoring for. Which side do you fall on?
> Yes, I’m sure all of the people who are going to download an extension to change the user agent version in iOS are really going to mess with analytics
Mechanisms to protect ourselves are not less valuable just because they're not universal. In any case, you shouldn't mess with your user agent primarily because a fake user agent on Safari is likely a bigger tracking vector than reporting the version -- but that's a separate conversation. The point being, you can do so if you have a need, unlike on native platforms.
Apple could also of course de-bundle Safari from OS updates, which would be a large security/privacy benefit, but that would get in the way of the all-too-convenient coupling of Safari to iOS's security model. It might force them to actually build security layers into their OS rather than relying on privileged applications.
And notably, this is likely to get better on the web, there is an ongoing conversation about how to handle user agent strings and how to reduce the information they leak without breaking capability tests. It's a complicated issue, but there are some interesting ideas that are being proposed for the web. As far as I know, I don't really see that conversation happening for native platforms, which seem to have an expectation that running an app should just privilege the app to know everything about the hardware.
----
> You can’t have it both ways. Either you want the wonderful world of PWAs where random websites have more access to your hardware and more parity with native apps and less privacy and security or you want it to remain more restrictive.
You can in fact have it both ways, you can implement native APIs via sensible changes that push those capabilities behind permissions. Notably, the battery life API does not currently require a permission in Chrome; it should.
Apple also had a good idea where PWA permissions were restricted to "installed" webapps. This shouldn't get rid of permission requirements, but it does significantly discourage webapps from requiring those permissions. The web is generally pretty good about this, but certain Google-proposed changes like the battery API are lagging. It would be good for the web and for users for Apple to be more involved in the standards process.
And as I've advocated for a while, you can take things even one step further than the web currently does and you can refuse to tell applications when permissions are denied, instead faking data. For the battery API, rather than reporting that a permission is disabled, browsers should instead report fake numbers.
But the idea that the web can't handle more advanced capabilities is false. Permissions are a complicated UX problem, but we have mechanisms to deal with them, and generally speaking the web has led the way on those mechanisms, with native platforms benefiting to a huge degree by imitating and building on web permission models and lessons.
People tend to forget how bad mobile permissions used to be. I would argue that the mainstream adoption of native platforms for runtime permissions, required optional permissions -- these are ideas that were popularized on the web and I would argue the web still often does a better job of handling that UX. Not that the web couldn't do better, but it is in comparison to other platforms doing a noticeably better job.
----
> These and more are all APIs that Apple has refused to implement that HN users are clamoring for. Which side do you fall on?
I agree with Apple that the majority of the APIs on this list (with a few exceptions) are unnecessary for web apps and should be approached with caution. In particular Web USB is extremely reckless, does not (as far as I can tell) have sufficient sandboxing to prevent device tampering or side-channel attacks through USB devices onto other parts of the OS, and at the very least it probably requires more safeguarding than just a permission prompt. Chrome is reckless in implementing those APIs, Apple is right to defer them.
That's not to say that they shouldn't be researched; NFC, Bluetooth, and MIDI input would be extremely important capabilities for the web if Google was proposing better privacy and security controls for them. Apple's policy around powerful web capabilities is often to stand to the side doing and saying nothing while Google develops bad specs, so that Apple has an excuse not to implement them. Needless to say, I don't give Apple credit for that. The world of notifications online would look very different if other stakeholders beyond Google had taken on bigger roles in shaping the API.
Of course, there are also plenty of APIs that Safari hasn't implemented that are not privacy risks. App badges are a good example, there's no privacy or security risk from being able to notify users that an app's state has changed. And of course it's been talked about to death, but the entire web notifications API as implemented by both Google and Apple actively encourages apps to be less private and to be looser with data. That didn't need to happen, Apple's negligence is part of the reason why web notifications are primarily only useful for advertisements and interaction reminders. Apple could easily lead the way on doing something better.
There is a lot of room for improvement here that doesn't require touching contentious or dangerous APIs. Typically when we talk about PWA capabilities on iOS, we're not talking about the ability to read device memory. What we're talking about is the ability to do much more innocuous things like schedule offline notifications without relying on a 3rd-party web server to trigger the notification -- something that would not only make PWAs more capable but would also make them more private and more secure.
