Apple Blocks 15 W3C Standards In Safari
Written by Mike James   
Wednesday, 08 July 2020

When is a web browser not standards-based? When it's made by Apple. Is it right for a browser maker to decide which standards to implement? Apple is firmly of the opinion that it can pick and choose.

 applesq

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. However standards are their 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

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.

W3Clogo

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.

safariicon

More Information

Tracking Prevention in WebKit

Related Articles

Apple And Google Break W3C Standards

Google's Blink Not Implementing W3C Pointer Events       

WebKit Is Breaking The Web

Who Is Building WebKit?

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on, Twitter, Facebook or Linkedin.

 

Banner


Chrome 84 Adds Web OTP API
23/07/2020

Google has launched Chrome 84 with improvements including the Web OTP API, Web Animations API, and changes to SameSite cookies, along with the removal of older versions of Transport Layer Security (TL [ ... ]



RavenDB Adds Time Series Query Support
16/07/2020

The latest release of RavenDB adds the ability to query and index time series data, along with other improvements including the ability to schedule periodic document refreshes, customize database comp [ ... ]


More News

graphics

 



 

Comments




or email your comment to: comments@i-programmer.info

 

Last Updated ( Wednesday, 08 July 2020 )