Summary

  • W3C's 14 August call for consensus proposed removing WebHID, Web NFC, WebUSB, Web Bluetooth and Web Serial from a draft Devices and Sensors charter. It asked for any concerns by 28 August and treated silence as consent.
  • Intel replied before the deadline that it had concerns about removing all five. On 31 August, the W3C co-chair said concerns had been raised and, as a result, consensus was not reached. The result did not identify one message as the sole cause.
  • WHATWG's Steering Group had separately chosen to start a Peripheral APIs Workstream with all five specifications if there were no objections to the W3C CfC; otherwise it would start with Web Serial alone.
  • WHATWG merged the five-specification workstream on 29 August, saying the no-objection condition was met while expressly acknowledging Intel's concerns. The commit proves the workstream registry change, not resolution of W3C's Formal Objection or completion of every repository and review.
  • A cross-venue predicate receipt should state each proposition, invited response vocabulary, response classification, deadline, classifier, decision owner and result. It would make the semantic join visible without requiring W3C and WHATWG to share terminology or authority.

One archive carried two propositions

The dispute began with a proposed W3C charter, not with a final technical standard. The draft placed Web Bluetooth, Web Serial, WebUSB, Web NFC and WebHID among the Devices and Sensors Working Group's tentative deliverables. Each was still identified as a Draft Community Group Report. Tentative status opened a route into Recommendation-track work; it did not endorse the current design or guarantee advancement.

W3C's 12 June review notice invited comments through 17 July and said some substantive issues had not been resolved by consensus during charter refinement. A Formal Objection published on 23 July argued that the five APIs posed serious security and privacy risks. Its requested resolution had two branches: remove the five tentative deliverables, or add a gate requiring documented exploit classes, testable normative mitigations, horizontal reviews and a disposition for each class.

Those technical assertions belong to the objector. The checked record does not turn them into W3C findings, and this Article does not decide whether the proposed mitigations are sufficient. The governance event is narrower: two institutions attached different downstream actions to responses about the removal proposal.

On 14 August, Reilly Grant opened the W3C call for consensus. Its proposition was exact: resolve the Formal Objection by removing all five APIs from the tentative-deliverables list. Its response instruction was also exact: reply by 28 August if participants had “any concerns”. Silence would be considered consent.

That vocabulary matters. The call did not ask only for a formally labelled objection. It asked for concerns about the removal proposition.

The W3C thread preserved more than yes or no

The responses did not fit a binary tally. Microsoft preferred to keep the five APIs in scope and wanted the security concerns addressed, but expressly said it would not block consensus to remove them. Because a WHATWG Peripheral APIs Workstream was proposed, Microsoft said removal would primarily change the venue rather than end the work. It also cautioned that tentative adoption would not endorse the current designs or guarantee Recommendation status.

Will Morgan preferred retention subject to a threat-model review and asked whether the work would move to WHATWG. He suggested removing the items and re-adopting them if the new workstream did not appear within six months. François Daoust then supplied an important authority boundary: re-adoption would require a new W3C charter. An editor or chair could not simply restore Recommendation-track scope by changing a list.

The clearest response for the later semantic seam arrived on 28 August. In a message with his chair hat explicitly off, Anssi Kostiainen wrote for Intel that Intel had concerns about removing all five APIs. Intel's reason was institutional: it considered W3C's wide and horizontal review valuable for preparing the APIs for global adoption. The archive received the message at 12:24 UTC, before the named date ended.

On 31 August, Kostiainen wrote again, this time as DAS co-chair, to close the call. He said concerns had been raised about the proposed removal and, as a result, consensus was not reached. He did not say that Intel's message alone controlled the result. He did not approve the proposed charter, resolve the Formal Objection or declare the APIs safe. The W3C Team would take the feedback into account when planning next steps.

The resulting W3C state is therefore no consensus on removal, not final decision to retain.

WHATWG depended on a different word

WHATWG was deciding a separate institutional object: whether to establish its own Peripheral APIs Workstream and with what initial scope. The workstream proposal covered local peripheral connectivity and named the same five APIs. It had been open since April. Discussion included support, requests for broader participation, a July preference to begin with Web Serial alone, and a late security concern.

The decisive dependency appears in the WHATWG Steering Group minutes for 25 August. The Steering Group considered starting with Web Serial alone or starting with all five. Three of four representatives selected option 2: start with all five on Friday if there were no objections to the W3C CfC; if any objections appeared, start with Web Serial only.

This was not the proposition in the W3C call. W3C was asking whether to remove five tentative deliverables from a proposed W3C charter. WHATWG was choosing the opening scope of a WHATWG workstream. But WHATWG made its scope branch depend on a classification of responses in the W3C process.

On 29 August, pull request 264 was merged. The merge explanation said the Steering Group's chosen condition had been satisfied: there were no objections to the W3C CfC by end of business PDT on Friday. In the same sentence, it acknowledged Intel's concerns. The immutable commit 7eb413b added a Peripheral APIs workstream and records for WebBluetooth, WebHID, WebNFC, WebSerial and WebUSB to WHATWG's registry data.

The record is unusually candid. It does not erase the concern. It exposes the classification: concern acknowledged, objection condition treated as absent.

The merge comment also kept one future state open. It said Intel's concerns and another security scenario should be captured as issues when the workstream repository was created. The commit therefore proves the registry mutation. It does not prove that every promised issue, repository, publication, review or mitigation already existed at the evidence cutoff.

Different results do not prove a contradiction

It would be easy to turn the sequence into a charge that one institution ignored the other. The evidence does not support that conclusion. W3C and WHATWG controlled different objects under different rules. A W3C concern did not automatically become a WHATWG Workstream Participant's formal unresolved substantive objection under the WHATWG Workstream Policy. A WHATWG launch did not decide the W3C charter or dispose of a W3C Formal Objection.

Nor does the vocabulary have to be universal. In the W3C thread, Microsoft demonstrated a concern but will not block state. Intel's message declared concerns without the same non-blocking qualifier. W3C's close record treated concerns as enough to prevent consensus on removal. WHATWG's launch condition used objections, and its merger treated that condition as unmet by the acknowledged Intel concern. Those are public classifications by the relevant actors, not dictionary definitions binding every future process.

The governance risk lies in the join. A downstream condition that says “if no objections to process X” needs a public rule for mapping the actual states emitted by process X. Otherwise, a reader must infer whether concern, non-blocking concern, support with requested changes, silence and Formal Objection all count the same way. The decision may remain valid, yet its dependency is not reproducible.

Lu Heng's multi-stakeholder critique supplies a useful discipline without deciding this case: participation, warning, advice and objection are forms of evidence; none should be inflated into authority it does not carry. Here, the discipline runs in both directions. Intel's message did not command either institution. W3C and WHATWG each had authority over its own decision. The archive should show how each institution used the evidence.

A cross-venue predicate receipt

The first field should pin the upstream proposition. For this event, it is not “Are the APIs good?” It is the 14 August proposal to remove five named tentative deliverables from a specific proposed W3C charter. The receipt should include the charter version, opening message, eligible channel, deadline and the language any concerns.

The second field should preserve response state rather than compressing every message into for or against. Microsoft's preference, its non-blocking qualifier, Will Morgan's conditional position and Intel's unqualified concern are different evidence. Each message already has a timestamp and stable Message-ID. A compact record can retain those facts without publishing private deliberation.

The third field is the upstream result: the co-chair, close time, consensus was not reached, stated reason and next competent actor. The no-consensus result should point to the later W3C Team action when one appears. It should not be overwritten by a final charter.

The fourth field is the downstream predicate. It should quote WHATWG's all-five/Serial-only branch, identify the Steering Group as decision owner, state the end-of-business PDT cutoff and publish the mapping rule. Did a W3C concern count as a WHATWG objection? If not, who classified it and under which stated test? The merge record gives the answer in this case, but not a reusable rule.

The fifth field is the downstream action and immutable artifact: pull request 264, the merger, commit 7eb413b and the five records added. Later repository creation, issue filing, scope changes and publications belong as successor events.

Finally, the receipt needs a non-inheritance line. W3C's failed removal consensus does not approve a WHATWG workstream. WHATWG's workstream does not settle W3C's Formal Objection. Neither event is a safety certification or a browser-deployment mandate. The two records can be linked without pretending that authority crossed with the link.

Evidence boundary

At the evidence cutoff, W3C's public group page still displayed Chartered until 31 August 2026, while the proposed successor charter remained labelled [PROPOSED]. Those surfaces justify monitoring. They do not prove that the group stopped operating, that the successor was rejected or that a final decision occurred off the checked public record.

The technical controversy also remains open. The Formal Objection asked for specific mitigation and review gates; supporters argued that W3C or WHATWG could provide a venue for that work. This Article neither validates the alleged exploit classes nor dismisses them. A workstream can exist while safety questions remain unresolved. A failed removal CfC can leave charter scope undecided.

The provable event is semantic and institutional. W3C invited concerns and later cited concerns when recording no consensus. WHATWG conditioned its launch on the absence of objections, acknowledged Intel's concern and recorded the condition as satisfied. The decisions may both be proper. Their shared dependency deserves a receipt precise enough that no later summary has to turn one word into another in secret.

Sources