Apple has said it has decided not to implement 16 web APIs in its Safari browser’s WebKit engine in part because they pose a privacy threat. Critics of the iGiant, including competitors like Google, see Apple’s stance as a defense against a competitive threat.
These APIs, developed in recent years to allow web developers to have access to capabilities available to native mobile platform coders, have the potential to be abused for device fingerprinting, a privacy-violating technique for constructing a unique identifier out of readable device characteristics that can be used for tracking individuals across websites and can be correlated to follow people across devices.
“WebKit’s first line of defense against fingerprinting is to not implement web features which increase fingerprintability and offer no safe way to protect the user,” explains the WebKit team’s recently updated post on tracking prevention.
[…]
In a message to The Register, Lukasz Olejnik, an independent researcher and consultant, characterized the decision as a win for privacy, noting that research he co-authored in 2015 and subsequently on the privacy risks of the Battery Status API and other browser fingerprinting threats helped shape Apple’s policy.
Concern about abuse of the Battery Status API, which websites and browser-based apps can use to check the battery level of a visitor’s/user’s mobile device, prompted Mozilla to remove support in October 2016. Around the same time, Apple, which had implemented the API in code but never activated it, decided not ship it.
Google meanwhile shipped the Battery Status API in Chrome 45, which debuted on July 10, 2015. Rather than removing it, the web giant in May committed to modifying it by allowing developers to disable the API with their apps and in third-party components.
Apple, trying to control its market? No!
Google engineers coincidentally are among those expressing frustration with Apple for holding the web platform back.
Apple requires that all web browsers on iOS devices use Safari’s WebKit rendering engine, which has made mobile browsers on iOS something of a monoculture: Though users may choose to run Chrome on iOS, it’s essentially Safari under the hood.
Over the past few years, Apple’s leisurely (or cautious) pace of API deployment in Safari has meant that Progressive Web Apps (PWAs) – installable web apps that run offline – haven’t worked properly on iOS devices.
As a result, web developers, particularly those interested in PWA adoption, have accused Apple of trying to hamstring web apps to protect its financial stake in native iOS apps, for which it gets a 30 per cent share of revenue through its App Store rules. Those same rules are now the subject of an EU antitrust inquiry.
[…]
Or as Ben Thompson, tech analyst for Stratechery, put it in a blog post on Monday, “Making the web less useful makes apps more useful, from which Apple can take its share; similarly, it is notable that Apple is expanding its own app install product even as it is kneecapping the industry’s.”
Asked about whether these competitive concerns have substance, Olejnik acknowledged that some people see Apple’s technical decisions in that light.
“That said, some privacy concerns are legitimate,” he said.
And for what it’s worth, the technical barriers to PWAs have been falling.
Robin Edgar
Organisational Structures | Technology and Science | Military, IT and Lifestyle consultancy | Social, Broadcast & Cross Media | Flying aircraft