Why Safari Blocks Web APIs Over Privacy and Security Risks

Apple’s WebKit team, the engineers behind the Safari web browser, has refused to implement several proposed modern Web APIs, most notably Web Bluetooth and Web USB. This article provides an overview of why Apple blocks these features, detailing how they expose users to unavoidable browser fingerprinting, break the foundational security sandbox of the web, and introduce severe hardware-level vulnerabilities that users cannot reasonably defend against.

The Threat of Advanced Browser Fingerprinting

Browser fingerprinting is a tracking technique used to identify individual users based on their specific device and browser configurations, completely bypassing the need for traditional cookies. When a website can query a device for its specific characteristics—such as screen resolution, installed fonts, and operating system—it can stitch those data points together to create a unique profile.

APIs like Web Bluetooth, Web USB, and the Network Information API drastically increase the "surface area" for fingerprinting. If a website can detect what kinds of USB devices, Bluetooth accessories, or specific hardware configurations are attached to your computer, your device becomes instantly identifiable. Even if you clear your cookies, use a VPN, or browse in Private Mode, the unique combination of your connected hardware allows trackers to permanently identify you across the web. Apple refuses to implement APIs that hand over this level of identifiable hardware data to websites.

Breaking the Browser Sandbox

The fundamental security model of the web relies on "sandboxing." When you visit a website, the code on that site runs in a restricted environment, isolated from your computer's underlying operating system and hardware. This ensures that simply clicking a malicious link cannot compromise your entire machine.

Web USB and Web Bluetooth intentionally pierce this sandbox by allowing websites to communicate directly with peripheral hardware. This creates massive security risks:

  • Firmware Exploitation: Many USB and Bluetooth devices were never designed to defend against attacks coming directly from the open web. A malicious website using Web USB could rewrite the firmware of a connected device, permanently damaging it or infecting it with malware that spreads to other computers.
  • Data Theft: Direct access to peripherals means a compromised or malicious site could potentially read data directly from connected storage, cameras, medical devices, or even hardware security keys, bypassing the operating system's built-in protections.
  • Keystroke Injection: If a website gains access to a connected keyboard or mouse receiver via these APIs, it could theoretically log keystrokes or inject commands directly into the host computer.

Proponents of these APIs, such as Google (which implements them in Chrome), argue that the features are safe because the browser asks the user for permission via a pop-up prompt before granting hardware access.

Apple’s security team rejects this argument, stating that permission prompts are not a valid substitute for inherent security. Most everyday users do not understand the deep technical implications of granting a website access to a USB port or a Bluetooth controller. A user might click "Allow" simply to make a web page function, unknowingly giving that site full read-and-write control over a connected device's firmware. WebKit engineers argue that a browser should not offer users a single button that, if clicked by mistake, completely compromises their hardware security.

The Native App Alternative

By declining to implement these APIs, Safari draws a strict boundary between what a website should be able to do and what a native application should do. For developers who genuinely need deep access to Bluetooth or USB hardware, Apple requires the use of native iOS or macOS applications. Native apps must go through a vetting process, are cryptographically signed by identified developers, and can be revoked by Apple if found to be malicious—safeguards that simply do not exist on the open, decentralized web where a user is only one accidental click away from a malicious URL.