Apple: We're defending your privacy by nixing 16 browser APIs. Rivals: You mean defending your bottom line
(2020/06/29)
- Reference: 1593465633
- News link: https://www.theregister.co.uk/2020/06/29/apple_web_developers/
- Source link:
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 [1]post on tracking prevention.
The nixed APIs include:
Web Bluetooth
Web MIDI API
Magnetometer API
Web NFC API
Device Memory API
Network Information API
Battery Status API
Web Bluetooth Scanning
Ambient Light Sensor
HDCP Policy Check extension for EME
Proximity Sensor
WebHID
Serial API
Web USB
Geolocation Sensor (background geolocation)
User Idle Detection
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 [2]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 [3]Battery Status API in [4]Chrome 45 , which debuted on July 10, 2015. Rather than removing it, the web giant in May committed to modifying it by [5]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.
Apple says if developers are unhappy with its App Store decisions, it will entertain appeals against its rulings – and even its own rules [6]READ MORE
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 [7]are now the subject of an EU antitrust inquiry.
"Never forget that Apple prevents browser engine choice *primarily* to prevent the web from being an attractive development target for non-legacy content," wrote Alex Russell, senior staff software engineer at Google, who works on Chrome, Blink, and web standards, [8]via Twitter on Monday.
Apple's goal, argues Russell, is to ensure that the web platform remains [9]less capable than native apps .
Russell points out that Apple supports other APIs that can be abused, such as those related to orientation/acceleration, geolocation, camera access, GPU accelerated graphics, gamepad API, and file and directory upload.
Or as Ben Thompson, tech analyst for Stratechery, put it in a [10]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 [11]have been falling . ®
Sponsored: [12]The Forrester New Wave™: Public Cloud Enterprise Container Platforms, Q3 2019
[1] https://webkit.org/tracking-prevention/
[2] https://blog.lukaszolejnik.com/battery-status-not-included-assessing-privacy-in-w3c-web-standards/
[3] https://www.w3.org/TR/battery-status/
[4] https://www.chromestatus.com/feature/4537134732017664
[5] https://www.chromestatus.com/features/5087503189016576
[6] https://www.theregister.com/2020/06/23/apple_developer_relations/
[7] https://www.theregister.com/2020/06/16/eu_apple_competition_investigations/
[8] https://twitter.com/slightlylate/status/1277656291616280577?s=20
[9] https://twitter.com/slightlylate/status/1277655880654131203
[10] https://stratechery.com/2020/apple-and-facebook/
[11] https://love2dev.com/pwa/ios/
[12] https://go.theregister.com/tl/1956/-8475/the-forrester-new-wave-public-cloud-enterprise-container-platforms-q3-2019?td=wptl1956
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 [1]post on tracking prevention.
The nixed APIs include:
Web Bluetooth
Web MIDI API
Magnetometer API
Web NFC API
Device Memory API
Network Information API
Battery Status API
Web Bluetooth Scanning
Ambient Light Sensor
HDCP Policy Check extension for EME
Proximity Sensor
WebHID
Serial API
Web USB
Geolocation Sensor (background geolocation)
User Idle Detection
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 [2]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 [3]Battery Status API in [4]Chrome 45 , which debuted on July 10, 2015. Rather than removing it, the web giant in May committed to modifying it by [5]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.
Apple says if developers are unhappy with its App Store decisions, it will entertain appeals against its rulings – and even its own rules [6]READ MORE
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 [7]are now the subject of an EU antitrust inquiry.
"Never forget that Apple prevents browser engine choice *primarily* to prevent the web from being an attractive development target for non-legacy content," wrote Alex Russell, senior staff software engineer at Google, who works on Chrome, Blink, and web standards, [8]via Twitter on Monday.
Apple's goal, argues Russell, is to ensure that the web platform remains [9]less capable than native apps .
Russell points out that Apple supports other APIs that can be abused, such as those related to orientation/acceleration, geolocation, camera access, GPU accelerated graphics, gamepad API, and file and directory upload.
Or as Ben Thompson, tech analyst for Stratechery, put it in a [10]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 [11]have been falling . ®
Sponsored: [12]The Forrester New Wave™: Public Cloud Enterprise Container Platforms, Q3 2019
[1] https://webkit.org/tracking-prevention/
[2] https://blog.lukaszolejnik.com/battery-status-not-included-assessing-privacy-in-w3c-web-standards/
[3] https://www.w3.org/TR/battery-status/
[4] https://www.chromestatus.com/feature/4537134732017664
[5] https://www.chromestatus.com/features/5087503189016576
[6] https://www.theregister.com/2020/06/23/apple_developer_relations/
[7] https://www.theregister.com/2020/06/16/eu_apple_competition_investigations/
[8] https://twitter.com/slightlylate/status/1277656291616280577?s=20
[9] https://twitter.com/slightlylate/status/1277655880654131203
[10] https://stratechery.com/2020/apple-and-facebook/
[11] https://love2dev.com/pwa/ios/
[12] https://go.theregister.com/tl/1956/-8475/the-forrester-new-wave-public-cloud-enterprise-container-platforms-q3-2019?td=wptl1956
Re: Gotta agree with Apple for a change
Aitor 1
While you are probably correct about google, this does not substract from the main point: the objective of Apple is to prevent websites that compete with their lucrative walled garden.
Possibly, but..
Anonymous Coward
Apple do seem to be one of the only major tech players out there that are also genuinely concerned about user and device security. Sure, they don't get it right all of the time (and have made some glaring errors other the years), but they do try, do learn and are will to stand up to "big brother" state intervention.
So Google is upset
idiottaxpayerhere previously ishtiaq/theghostdeejay
because Apple have decided not to implement a few potentially privacy busting A.P.I.s"?
Well boo fucking hoo.
Funny how people from Google never comment about how it always seems to be an iPhone the F.B.I. or whoever, seem to have difficulty with decrypting. It never seems to be an Android phone. Funny that.
And Google, you never seem to mention the fact that you also take a 30 percent cut of the price of apps that you sell in your shitshow of a store. Would that include the apps that turn out to be malware?
Just saying.
Cheers… Ishy
Gotta agree with Apple for a change
By the size of Google's temper tantrum, you can absolutely bet they're using this for fingerprinting.
None of those APIs are necessary in a browser.