[wg/das] Formal Objection (charter review)

Quoted from
   https://www.w3.org/wbs/33280/das-wg-charter-2026/results/

[[
We object to this charter on the grounds that the tentative deliverables 
are detrimental to the security and privacy of users. W3C shouldn’t 
recommend solutions that can knowingly be exploited to compromise users’ 
devices.

There are severe risks to standardizing the listed tentative 
deliverables. For instance, consider the (peer-reviewed) paper 
"Peripheral Instinct: How External Devices Breach Browser Sandboxes" 
https://misc0110.net/web/files/peripheralinstinct_www25.pdf (Trampert et 
al., WWW '25, ACM), which outlines how WebHID, WebUSB, Web Serial, and 
Web MIDI can be combined to create full exploit chains on user's 
devices. The paper's authors built "several full-chain exploits, leading 
to arbitrary code execution on the victim system, circumventing the 
browser sandbox." Concrete exploits demonstrated by Trampert et al.:

* Custom firmware flashed onto a Logitech Unifying Receiver via WebHID, 
an attack that "only requires granting the WebHID permission" and "no 
user interaction by the ultimate target user" (§4.1, §6.1);
* Modem AT-command attacks over Web Serial (SMS and two-factor-code 
interception, GPS tracking, permanent SIM lockout) (§7);
* And a permission model where, "Once permitted, the site can interact 
with the device without further consent on future visits," and a grant 
can be inherited "via a Cross-Site Scripting (XSS), website compromise, 
or domain re-registration" (§3.3).

Although the specifications include some normative policy enforcement 
points, such as relying on secure contexts, a permission prompt, 
Permissions Policy, device blocklists, etc., they put little constrains 
what a permitted origin does once access is granted, which is where the 
documented threats live.

# Limited Security Mitigations by Design

What is most concerning about the tentative deliverables’ response to 
these concerns is the claim that the attacks cannot be mitigated because 
the data passed through is an opaque sequence of bytes. While true, it’s 
beside the point: the documented attacks are mitigated not by inspecting 
bytes but by constraining the grant, which a specification can and 
should control. The specs leave dealing with these issues to 
non-normative prose:

* WebUSB https://wicg.github.io/webusb/#security-and-privacy — firmware 
protection is a non-normative recommendation to device makers, and the 
spec concedes "there is nothing that can be done by the UA to prevent 
further damage." While WebUSB normatively blocks a set of protected 
interface classes (HID, Mass Storage, Audio) because "high level APIs 
exist [for each of them] and provide greater protection for user privacy 
and security," that is a surface-level mitigation.
* Web Serial https://wicg.github.io/serial/#x7-security-considerations — 
The spec says that "there is no mechanism that will completely prevent 
this type of attack." And furthermore, it says that exploitable 
microcontroller boards "should not be blocked." The modem/AT-command 
class issue is left unaddressed.
* WebHID https://wicg.github.io/webhid/#security-and-privacy — the 
macro-reprogramming mitigation is shifted to device makers; Trampert et 
al. find the issues "remain unaddressed."
* Web Bluetooth 
https://webbluetoothcg.github.io/web-bluetooth/#security-and-privacy — 
byte-payload validation is “addressed” by the hand-wavy, unenforceable 
text "UAs are encouraged to validate these values when they can."
* Web NFC https://w3c-cg.github.io/web-nfc/#security — integrity and 
authenticity are deferred to applications and to non-normative "security 
hardening."

In all of these cases, the danger is in the permission grant, not the 
byte stream, and the permission grant isn’t usefully constrained by the 
specifications:

* **Too broad:** a single grant reaches more of the device than the 
site/function needs.
* **Too persistent and transferable**: reusable on later visits, 
inheritable via XSS or domain re-registration; a standing handle to a 
uniquely identifiable device is itself a cross-context tracking surface.
* **Too silent**: nothing requires the user agent to surface that a 
device is being driven.

Trampert et al. (§1): "while the API specifications list security 
considerations, they merely shift the responsibility of maintaining 
security to device vendors, many of which have not prepared their 
devices accordingly."

# Response to Disposition of Comments

When Apple raised these concerns in w3c/charter-drafts#798 
https://github.com/w3c/charter-drafts/issues/798 the Disposition of 
Comments 
https://w3c.github.io/charter-drafts/2026/das-wg-charter-doc.html#potential-security-risk-on-sandbox-escape-via-device-apis---noted 
answered the documented evidence not with mitigation but with 
acknowledgment: "These attack scenarios are largely acknowledged by the 
'Security Considerations' sections of these specifications. Wide review 
on these specifications may also help detect and address more security 
risks."

That they are "largely acknowledged" does not even remotely suffice, and 
falls far short of the normative security mitigation the charter 
promises (below). The W3C should not advance a charter that intends to 
recommend APIs that can be exploited to achieve arbitrary code execution 
or potentially destroy users' devices. These are not nascent proposals 
in need of incubation time. The specifications ship in Chromium and the 
peer-reviewed work above studied them in that deployed form; the 
weaknesses are in the current drafts, not a hypothetical future. The 
commitment to "define normative mitigations" cannot be read as a request 
for time to do the work when that work was not done over the many years 
these features have been deployed in the wild.

# The charter's own commitments

The charter https://www.w3.org/2026/06/das-wg-charter.html#scope 
promised to prevent exactly this: it commits to incorporating 
mitigations "normatively into the respective specifications," for every 
API "in scope" that exposes sensitive data. The charter also commits to 
"limit their functionality and data exposure to the minimum required to 
implement real-world use cases adhering to the principles of data 
minimization." That bears on the shape of the permission grant, which is 
broader than the minimum these use cases require. Where a narrower, 
capability-shaped grant would serve, minimization points to it; where 
raw transport is genuinely necessary, the commitment still obliges the 
group to justify that and to mitigate as best they can. The charter 
committed to minimize the grant and has not shown how it will.

# Requested resolution

We request that Web Bluetooth, Web Serial, WebUSB, Web NFC, and WebHID 
be removed from the charter’s list of tentative deliverables.

Alternatively, the charter must include an explicit gating condition: 
the Working Group must not adopt, publish as FPWD, advance, or request 
Recommendation status for any of these specifications unless and until 
the Working Group has:

1. Documented the known exploit classes, including firmware 
reprogramming, firmware rollback, macro/keyboard injection, 
modem/AT-command abuse, persistent grants, inherited grants after site 
compromise or domain transfer, and device-fingerprinting risks;
2. Defined testable normative mitigations in the relevant specification, 
not merely non-normative Security Considerations;
3. Obtained and addressed Security, Privacy, and TAG reviews of those 
mitigations before the specification becomes a Working Group deliverable 
or advances on the Recommendation track; and
4. Published a disposition explaining, for each known exploit class, 
whether the exploit is mitigated by the specification, left to 
user-agent policy, left to device vendors, or impossible for the user 
agent to mitigate.

If the answer for a class of documented attacks is that the user agent 
cannot mitigate it, the charter should not pursue Recommendation-track 
standardization of the affected low-level device API.
]]

Received on Thursday, 23 July 2026 14:24:50 UTC