Should The Web Expose Hardware Capabilities? — Smashing Magazine

What “Adjacent Capability” Really Means for the Web

The debate between browser vendors over how far the web platform should reach into hardware territory is not just a technical squabble. It’s a fundamental disagreement about what the web is for. Chromium’s Project Fugu pushes APIs like WebUSB forward aggressively, while Apple and Mozilla hold back, citing security and privacy concerns. The Platform Adjacency Theory, written by Fugu lead Alex Russell, frames this as a choice between keeping the web relevant or “casting it in amber.”

There is something to that argument. Software is moving to the web because it is a better version of computing in many ways, and a meta-platform that cannot do what most computers do will lose ground. But the theory’s own examples — Java and Flash — suggest a more complicated picture. Both were widely distributed as browser plug-ins, making them alternative runtimes riding on top of the browser rather than true meta-platforms. Today, server-side Java and Node.js are better examples of what the theory describes: cross-platform runtimes with package ecosystems that keep adding capabilities previously reserved for the OS.

Client-side frameworks like Qt, Rust, Flutter, and Xamarin are different again — they don’t depend on pre-installed runtimes or abstract from the OS in the same way. The relevance-versus-capabilities curve in the theory applies reasonably well to those platforms, but the web has a key difference from all of them.

The WebUSB Controversy

The specific case that exposes the fault line is WebUSB. Chromium ships it; Safari and Firefox do not. The security objections are not abstract. A web page that can talk directly to a USB device raises questions about what the user actually consented to, and what a malicious site could do with unintended access to peripherals.

Russell’s response is to point out that native platforms already grant this kind of access, and that refusing to add adjacent capabilities to the web while tolerating the same issues in native apps is inconsistent. Declining to add such capabilities on security grounds alone, the theory argues, will make the web less relevant over time.

That position is sympathetic, especially to anyone who dislikes app stores and other walled gardens. But it doesn’t resolve the user-side concern: the dizziness of not knowing what a website is capable of doing with your hardware. Platform restrictions and auditing, however imperfect, provide some comfort that a web page isn’t silently reaching into your machine.

What the Vendor Split Actually Tells Us

• Google, with partners like Intel, Microsoft, and Samsung, keeps shipping new APIs in Chromium and treats the web as a continuous expansion surface.
• Apple responds with a conservative posture, often citing security and privacy concerns, and its App Store rules restrict browser choice on iOS.
• Mozilla is closer to Apple than to Google on these issues.
• This has led to accusations that Safari is the new IE, a blocker of progress rather than a participant in it.

All of this frames the argument as a simple binary: innovation versus stagnation. But the WebUSB case suggests a more useful way to think about it. The question is not whether the web should gain new capabilities, but which capabilities, under what conditions, and with what guarantees about user control, consent, and security. Those are engineering decisions as much as policy ones.

The Missing Third Dimension

Comparing the web to cross-platform frameworks like Qt, Flutter, or React Native misses a crucial axis: trust and distribution. Those frameworks don’t care how code is delivered — WebAssembly modules, app stores, Docker containers, or Ubuntu packages. Users rarely know or care what framework an app was built with, whether it’s Xamarin or node.js.

The web is different. Users know when they’re “browsing.” They understand that visiting a random website carries different risk than installing software from an administrator-vetted package. That distinction is fundamental to the web’s success. If browsers didn’t provide a clear sandbox separating arbitrary websites from local files, few would use them at all.

This is why full-screen prompts exist, and why browsers advertise their chrome. The line between “web” and “native” is not just technical — users hold different trust expectations for each. OS vendors and app stores come with their own review processes; the web does not.

Web technologies are also used for cross-platform development via Electron or Cordova, but that’s not “the web” in this sense. Those frameworks don’t require standards compliance or multi-browser support, so the conversation about Fugu APIs is largely tangential to them.

Native Apps and the App Store

Arguments that native platforms have security flaws don’t justify relaxing web security. Native vulnerabilities are a reason to fix native platforms, not to weaken web sandboxes because they lag in capabilities. The comparison only holds if you ignore the trust and distribution dimension entirely.

Apple’s App Store Review Guideline 2.5.6 — requiring browsers to use WebKit — is often cited as anti-competitive. But it must be read alongside other guidelines, like the one requiring apps to describe product changes in “What’s New” text. If an app could bundle its own engine that executes arbitrary code from any website, those review rules would become unenforceable. Websites don’t declare revisions; they change silently.

Experimental features like those in Project Fugu make this worse. If apps could ship any web framework, they could effectively run unaudited code or radically change their behavior between reviews. Until questions about sandboxing and trust for device APIs like Bluetooth and USB are resolved, allowing apps to freely render web content looks like a regression for users.

The definition of an “app” is admittedly arbitrary — it depends on whoever sets store policies. But the same is true for browsers. Who decides what counts as a browser? If the Facebook app with an embedded browser qualifies, the line gets very blurry. What makes apps meaningful is that some entity — ideally the hardware manufacturer — audits revisions of software with low-level access.

The Browser Line

Without drawing any line on “what is a browser,” every app could ship its own engine, lure users into an in-app browser, and track everything they do across foreign sites. That collapses the modern trust model entirely.

On iOS, an app exposes user actions to two parties: Apple and the app developer. Browsing in Safari exposes actions to one. An in-app browser with a custom engine adds a third — the engine’s vendor — creating avoidable same-origin violations and enabling click-tracking across domains.

The “only WebKit” rule may be too strict, but a workable alternative definition of browser needs to be proposed. Without one, every app becomes a tracking backdoor.

Apple’s Stance

Claims that Apple declines to implement features go beyond security concerns often cite caniuse.com data. That data does show many Chrome-only features. But it also lists a substantial number of features implemented in Safari and missing from Chrome. The two projects have different priorities; characterizing this as a categorical refusal to advance the web overstates the case.

Similarly, linking Apple’s statements that features would land if privacy and security concerns were met under the heading “it’s hard and we don’t want to try” misrepresents the position. A more balanced view is that Google is more aggressive about pushing the platform forward, not that Apple is frozen.

Permission Prompts and Trust Brokering

Google has innovated in the trust dimension, successfully with Trusted Web Activities. But most work on device-access trust revolves around permission prompts — making them harsher, time-boxing grants, or maintaining blocklists.

Intimidating prompts discourage users and shift liability onto them, with no recourse for developers. They may push developers toward safer APIs, but they don’t solve the underlying trust problem. Better prompts would encourage safe engagement, not scare users away.

Mozilla and Apple should innovate in this space rather than refuse to ship. Apple’s isLoggedIn proposal is one interesting direction: fingerprinting-prone device APIs could be exposed when the site already knows the user’s identity. That kind of contextual trust model deserves more attention.

WebUSB: When the API Is Too Powerful

WebUSB exposes the full USB protocol to web pages, minus a block-listed set of device classes. That opens genuinely useful doors: hooking up an Arduino board or debugging an Android phone from a browser tab. The appeal for educational and hobbyist hardware is real, and the cost barriers it removes matter.

The security picture is harder to swallow. USB already has a troubled reputation, and WebUSB hands that power to any website willing to show a permission prompt. Mozilla’s official standards position, articulated by David Baron, cuts to the core:

“Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they’re connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent.”

What a Permission Prompt Can’t Say

Chrome’s WebUSB prompt looks ordinary enough:

That prompt tells you a domain wants to connect to a device. It doesn’t tell you what the page intends to do with that connection. For a printer, camera, microphone, or GPS, the user’s mental model is clear: the browser mediates a specific, well-understood action. The prompt describes content or behavior, not just hardware.

USB is different. The WebUSB spec is deliberately generic, designed for device types that don’t exist yet, not for established classes like keyboards or storage. There is no prompt wording that can bridge that gap. Explaining what raw USB access to an arbitrary device enables requires understanding both the specific device’s firmware and the page’s code. That’s not something a dialog box can convey.

Lessons From the Yubikey Phishing Attack

The Yubikey incident shows how quickly that ambiguity becomes exploit. Attackers used WebUSB to phish data from a hardware authentication device. Chrome’s response, shipped in Chrome 67, was to block specific device IDs and specific device classes via a hardcoded blocklist.

That works as a stopgap but scales poorly. As WebUSB gains adoption, the blocklist will grow into a moving target that updates only with browser releases. Developers building legitimate WebUSB applications face an uncomfortable future: a device class they depend on could be blocked at any time, not because of anything they did, but because of someone else’s security failure or an OS-level decision to take over that class.

Shifting the Burden to Device Makers

There’s a deeper tension between capability and safety. The spec itself acknowledges that device manufacturers must “design their devices to only accept signed firmware” to defend against malicious WebUSB access. That raises firmware development costs and adds friction to the very prototyping workflow WebUSB was meant to simplify.

The security model also breaks down around synthetic versus physical interaction. Browsers carefully distinguish user-initiated actions from page-initiated ones—a script can’t click a link for you. But a physical USB device can. A compromised device could present multiple interfaces: one for debugging via ADB, one for pointer input via HID. Malicious code could exploit the debug interface to flash firmware, turning the device into a keylogger that operates with the user’s own physical authority. A blocklist added after the fact does nothing for devices whose firmware was already compromised through an allowed channel.

Informed Consent for a Cable

Most users understand what a printer does or why a camera needs permission. “USB” reads as a cable or a socket. The protocol underneath is invisible. A page asking to “connect” sounds harmless, which is precisely the problem.

Scarier prompts are a proposed fix, but they can’t enumerate what raw USB access makes possible. A genuinely accurate warning—something like “this page may take over your computer”—would be truthful but counterproductive. Users who understand the risk won’t click through, and constant rewording of the dialog only deepens the confusion.

Prototyping Needs Different Rules

There’s a viable path forward if WebUSB and similar Project Fugu APIs are positioned as prototyping tools rather than product infrastructure. That framing would justify stricter guardrails:

• Specifications should explicitly state that the API targets prototyping, not production deployments.
• Availability should require an explicit opt-in, such as toggling the API on manually in browser settings.
• Permission prompts should carry the same weight as invalid SSL certificate warnings.

Without these constraints, the APIs read as intended for real products. And for real products, the current consent model—and the reliance on reactive blocklists—doesn’t hold up.

Rethinking Device Access: An Action-Based Trust Model

Rebuffing harmful APIs outright isn't sufficient. Those who decline such capabilities should also propose alternative ways to safely expose the features users and developers genuinely need. Here's a practical alternative built around the concept of informed consent based on content and action, rather than broad device control.

The Prompt Should Describe the Action, Not the Peripheral

Current permission prompts ask users to allow a site to "connect to" or "take over" a device. This is far too generic. Instead, the prompt should focus on a specific action with verified parameters. Taking the WebUSB example of a 3D printer, the ideal prompt would read: Allow AutoDesk 3ds-mask to print a model to your CreatBot 3D printer?

Such a dialog would display the full print parameters—refinement, thickness, dimensions—along with a verified preview of the object to be printed. These details must be validated by a trusted user agent, not just presented by a web page.

Unfortunately, today's browsers can only verify a few facts:

• The requesting domain has a certificate registered to AutoDesk.
• The targeted peripheral identifies itself as a "CreatBot 3d printer."
• The device and domain are not on a block-list.
• The user clicked "Yes" on a general consent question.

To show a truthful, action-oriented dialog, the browser would also need to confirm:

• The granted action is printing a 3D model, and nothing else.
• The specified parameters will be honored.
• The preview shown to the user is a true representation of the print job.
• In sensitive cases, an additional short-lived token verifies the identity of AutoDesk.

Without such verification, a site granted broad "connect" access could, due to a bug or malicious dependency, start printing large models without meaningful consent.

Moreover, a full-featured web 3D printing capability would extend far beyond raw USB access—it would need print spooling and queue management that persists even when the browser window is closed. WebUSB is not designed for this. It's likely a hacky, short-lived solution. If OS vendors natively support 3D printers, sites relying on WebUSB would break.

A Driver Auditing Authority

Overarching permissions like "take over the peripheral" are problematic. Still, users shouldn't have to download random executables. A middle path exists: audited driver code that uses the WebUSB API internally to:

• Implement the "print" command.
• Display an out-of-page print dialog.
• Connect to a specific set of USB devices.
• Continue some actions in the background via a service worker or even when the browser is closed.

Auditing would verify that this driver's behavior truly amounts to "printing," that it respects the parameters, and that it shows an accurate preview. This model parallels certificate authorities—an essential web trust component that operates independently of browser vendors.

Driver Syndication and Its Caveats

These drivers need not be audited by Apple or Google, though vendors could choose to do so. Instead, a trusted issuer—like the peripheral manufacturer or a platform such as Arduino—could certify drivers, similar to how Let's Encrypt certificates work. Users could see a prompt like: "Arduino trusts that this code will flash your Uno with this firmware," complete with a preview.

This approach has its risks:

• The driver could still be buggy or malicious, though auditing reduces that risk.
• It adds development overhead and is less native to the web platform.
• It doesn't exist today and can't materialize purely from internal browser innovation.

Another possibility is to standardize and improve the Web Extensions API so add-on stores like the Chrome Web Store act as mediating auditors between user requests and peripheral access.

A Balanced View on Web Capabilities

The ambitious efforts of Google and partners to expand web capabilities are valuable. Yet upon closer inspection, Apple and Mozilla's cautious stance carries real technical weight. The informed-consent problem for open-ended hardware access is unresolved.

Apple could engage more openly in proposing new ways to enable device features, but its position likely stems from a long-standing philosophy about computing—not from anti-competitive intent. Supporting broad capabilities like WebUSB requires a trust model that goes beyond permission prompts and block-lists, borrowing from ecosystems like certificate authorities and package registries. Such a model is necessary for the web to safely evolve its hardware reach.