Apple Blocks W3C Standards

Is it right for a browser maker to decide which standards to implement?

Standards are there so that we can write web pages and web apps that we can expect to work on all browsers. This isn’t going to be the case for Safari/webkit as Apple just announced that it will not support:

• Web Bluetooth
• Web MIDI API
• Magnetometer API
• Web NFC API
• Device Memory API
• Network Information API
• Battery Status API
• Ambient Light Sensor
• HDCP Policy Check extension for EME
• Proximity Sensor
• WebHID
• Serial API
• Web USB
• Geolocation Sensor (background geolocation)
• User Idle Detection

Apple is firmly of the opinion that it can pick and choose. On this subject it is possible to be on either side of the fence; Apple is just using excuses for not implementing some standards that work against its profit margins or Apple is deeply caring about its users and is not implementing some standards to protect them.

All perfectly legitimate standards. You may have your concerns about some of them – frankly I’m spooked by Web Bluetooth and Web USB, but its up to the browser makes to make them safe for us to use.

My opinion counts for nothing in this and, of the others I’ve used, the Magnetometer API, Battery Status API and User Idle Detection and am disappointed and concerned that Apple has decided to make my one-page apps not run under Webkit.

The point is that ??however I feel about each of the APIs, it really isn’t up to me or Apple to decide which standards are “safe” enough and important enough to be ???implementable. Keep in mind that Webkit is the only rendering engine allowed on Apple devices.

Standards are standards.

The argument that Apple is making is that these particular APIs make fingerprinting easier and hence they are not implementing them to make their users safer.

Of course, each of these APIs can be used to identify a browser in a particular context, but there are lots of others. You could make the case that if you don’t want to be fingerprinted don’t use a browser of any description because it is nearly always possible to find some identifying characteristic born out of the effects of system configuration and past history.

Apple is also removing existing features – custom fonts, minor version numbers and, ironically, the “do not track” flag.

More suprisingly:

Trackers executing script in the first-party context often make use of first-party storage to save and recall cross-site tracking information. Therefore, ITP caps the expiry of all cookies created in JavaScript to 7 days and deletes all other script-writeable storage after 7 days of no user interaction with the website. The latter storage forms are:

• IndexedDB
• LocalStorage
• Media keys
• SessionStorage
• Service Worker registrations and cache

A more cynical viewpoint is that the more of this sort of API Webkit refuses to support, the more web apps have to become native apps to do their job and the more native apps there are the more money Apple makes.

Making the Webkit browser standards non-compliant is a good way of protecting the App Store and stopping the advance of the web app. Interestingly, Apple does address the issue of the 7-day storage restriction on PWAs. If you add a PWA (progressive web app) to the home screen, then the storage it uses it exempt from the 7-day limit.

However, even if Apple is trying to be protective of its users, this is not the way to do the job. It should have been proactive before the standards were established.

Once standards are established Apple as well as other browser builders, should seek to find ways to implement the APIs in ways that are protective, but still operate within the standard. What a browser maker should not do, for any reason, is pick and choose which standards to implement; particularly when it has the monopoly on a particular platform.

More Information

• Tracking Prevention in WebKit

Last updated on April 1st, 2023