Why? Fingerprinting. Rather than these APIs being used for what they are meant for, they end up being used for gross ad tech. As in, “hey, we don’t know exactly who you are, but wait, through a script we can tell your phone stopped being idle from 8:00 am to 8:13 am and were near the Bluetooth device JBL BATHROOM, so it’s probably dad taking his morning poop! Let’s show him some ads for nicer speakers and flannel shirts ASAP.”
I’ll pull the complete list here from Catalin Cimpanu’s article:
- Web Bluetooth – Allows websites to connect to nearby Bluetooth LE devices.
- Web MIDI API – Allows websites to enumerate, manipulate and access MIDI devices.
- Magnetometer API – Allows websites to access data about the local magnetic field around a user, as detected by the device’s primary magnetometer sensor.
- Web NFC API – Allows websites to communicate with NFC tags through a device’s NFC reader.
- Device Memory API – Allows websites to receive the approximate amount of device memory in gigabytes.
- Network Information API – Provides information about the connection a device is using to communicate with the network and provides a means for scripts to be notified if the connection type changes
- Battery Status API – Allows websites to receive information about the battery status of the hosting device.
- Web Bluetooth Scanning – Allows websites to scan for nearby Bluetooth LE devices.
- Ambient Light Sensor – Lets websites get the current light level or illuminance of the ambient light around the hosting device via the device’s native sensors.
- HDCP Policy Check extension for EME – Allows websites to check for HDCP policies, used in media streaming/playback.
- Proximity Sensor – Allows websites to retrieve data about the distance between a device and an object, as measured by a proximity sensor.
- WebHID – Allows websites to retrieve information about locally connected Human Interface Device (HID) devices.
- Serial API – Allows websites to write and read data from serial interfaces, used by devices such as microcontrollers, 3D printers, and othes.
- Web USB – Lets websites communicate with devices via USB (Universal Serial Bus).
- Geolocation Sensor (background geolocation) – A more modern version of the older Geolocation API that lets websites access geolocation data.
- User Idle Detection – Lets website know when a user is idle.
I’m of mixing feelings. I do like the idea of the web being a competitive platform for building any sort of app and sometimes fancy APIs like this open those doors.
Not to mention that some of these APIs are designed to do responsible things, like knowing connections speeds through the Network Information API and sending less data if you can, and the same for the Battery Status API.
This is all a similar situation to
It’s a load of horseshit to protect their App Store business, hurting the open web.
A also have mixed feelings about these, but I think the Network API should be standard as long as there is no chance of revealing the actual network endpoints (cell towers, wifi name, etc). If it is only used to gauge network speed/preferences then it could be extremely useful. You could load higher quality assets, preload items, etc all based on network speed or “data saver” preferences.
They’ve already implemented permission prompts for various APIs so that could apply to many of these. These won’t be implemented for homescreen added sites either. This, along with the 44px dead zone at the bottom of sites when in minimal UI mode all seem to be there to drive developers into producing apps. Not implementing useful APIs (like many of these are) and killing the best screen area within thumb-reach, all seem to be a good foundation for an anti-competitive complaint.
Sure thing that this has nothing to do with the fact that if we could use those APIs on Safari we would not place our apps on the AppStore and pay a big slice to Apple.
It seems to me that this is a great opportunity for apple to show leadership in the space. If they decided not to ignore progress in web api’s but rather to implement an elegant OPT-IN workflow for the user, then they could set the standard for other browsers when implementing functionalities with privacy implications.
will this hurt the iTunes subscribers who are using the same??
Several angry commentors have declared that this is because Apple don’t want to lose App Store revenue, and miss the fact that Mozilla is currently refusing to implement several of these as well.
In particular, the Bluetooth, MIDI, Serial and USB APIs have been flagged by Mozilla as being critical security vulnerabilities. They argue that there is no permission prompt that can explain to a non-tech savy user exactly how dangerous these APIs can be. There’s already been an exploit in WebUSB that allowed researchers to hack Yubikey’s security tokens (https://www.wired.com/story/chrome-yubikey-phishing-webusb/), and there’s a so-far theoretical attack against most of these APIs that lets you reprogram a remote device into a keyboard and then the attacker can execute arbitrary commands as the user (https://github.com/WebBluetoothCG/web-bluetooth/issues/46).
Before yelling abuse at Apple, please take note that most if not all of these APIs are currently Chromium-only.
I line up with Chris on this. I’m 100% for the open web and being able to build apps that compete with native technologies, but our culture of tracking (sorry, um, “personalization”) has made that impossible. Trackers don’t even respect the do-not-track setting. If there’s a privacy problem, or especially a security one, then it’s a non-starter. If and when those problems get resolved we can start dreaming up App Store conspiracies.