Apple claims that the 16 Web APIs above would allow online advertisers and data analytics firms to create scripts that fingerprint users and their devices.
User fingerprints are small scripts that an advertiser loads and runs inside each user’s browser. The scripts execute a set of standard operations, usually against a common Web API or common web browser feature, and measure the response.
Since each user has a different browser and operating system configuration, responses are unique per user device. Advertisers use this unique response (fingerprint), coupled with other fingerprints and data points, to create unique identifiers for each user.
Catalin Cimpanu
Most of the APIs mentioned in the list are widely available to native iOS apps (things like Bluetooth and NFC access, battery status, ambient light sensor, and background geolocation), so Apple’s argument feels disingenuous. It is certainly possible that the WebKit team does not have the resources to work on implementation – after all, it happened at Microsoft before – or to build privacy controls around those new APIs.
Indeed.
— Alex Russell (@slightlylate) June 29, 2020
It gives up the game, and the game is to keep the web second class.
If homescreen webapps were competitive, Apple's power to compel iOS native development -- & the power that comes with it via app store bottleneck -- evaporates.
Or, more likely, Apple is using this pretext to prevent webapps from competing on a level ground with its revenue source, the App Store. iOS devices are tightly controlled by Apple, to the point that you cannot run a different browser rendering engine – and you cannot install apps from outside the App Store. The only platform that can freely deliver apps on an iOS device is the web, so to maintain control Apple needs to keep the web in check, lest users start discovering there is life outside Apple’s walls. Previous ‘privacy initiatives’ at Apple have also targeted web content, while native apps can run around snooping people’s clipboards without suffering consequences. Preventing WebKit from implementing features that would improve webapp experience looks like another tactic to keep competition at bay.
Update: An older instance of the same tactic, from November 2019 when the Mac App Store has quietly started rejecting apps built with Electron:
Apple’s subtle, anti-competitive practices don’t look terrible in isolation, but together they form a clear strategy: Make it so painful to build with web-based technology on Apple platforms that developers won’t bother. Now that the App Store is not accepting apps built using Electron, developers will likely find creative ways to work around it, but Apple is setting up for a continual cat-and-mouse game as it plans to exert more control over which apps can run on the platform in the future.
These types of changes may be made in the name of privacy or security, but the reality is that the argument looks weak when both users and developers simply don’t have a choice because Apple controls the platform, browser engine, and the distribution method. Regardless of your opinion of Electron app quality, choice is important.
Owen Williams
Post a Comment