要約

  • W3Cは8月14日、WebHID、Web NFC、WebUSB、Web Bluetooth、Web Serialを、まだ提案段階のDevices and Sensors新憲章から外すCfCを開始した。8月28日までに「あらゆる懸念」を知らせるよう求めた。
  • Intelは期限内に5 APIの削除への懸念を表明した。8月31日、W3Cの共同議長は懸念が提起された結果、削除について合意に至らなかったと記録した。Intelの一通だけを唯一の原因とはしていない。
  • WHATWGのSteering Groupは別の分岐を採用していた。W3C CfCに「異議」がなければ5仕様でworkstreamを始め、異議があればWeb Serialだけで始めるという条件である。
  • WHATWGは8月29日、Intelの懸念を認識しながら異議なしの条件が成立したとして5仕様をマージした。commitは登録変更を証明するが、W3CのFormal Objectionの解決や全リポジトリ・レビューの完成までは証明しない。
  • 組織横断のpredicate receiptには、両側の命題、回答語彙、分類規則、期限と時間帯、分類者、権限者、結果、不継承条項が必要である。

争点はAPIの採否そのものではなかった

確認時点のDevices and Sensors Working Group憲章案には、なお [PROPOSED] と表示されていた。Web Bluetooth、Web Serial、WebUSB、Web NFC、WebHIDはTentative Deliverablesで、いずれもDraft Community Group Reportである。憲章に入ればRecommendation Trackで扱う権限が生じ得るが、現行設計への賛同やRecommendation到達を意味しない。

W3Cは6月12日のレビュー要請で7月17日まで意見を募り、憲章調整中に合意できなかった実質的論点があると説明した。7月23日に公開されたFormal Objectionは、5 APIを削除するか、既知の攻撃類型、検証可能な規範的緩和策、横断レビュー、類型ごとの処理結果を条件にするよう求めた。

セキュリティ上の主張は異議申立人に帰属する。公開されたことは、W3Cが技術的事実として認定したことを意味しない。本稿はAPIの安全性を裁定せず、削除提案への反応が二つの制度でどう扱われたかだけを追う。

8月14日のW3C CfCの命題は限定されていた。Formal Objectionを解決するため、5 APIを憲章案のTentative Deliverablesから外すという案である。参加者には8月28日までに「any concerns」があれば返信するよう求め、沈黙は同意と扱うとした。入力欄に書かれていたのはformal objectionだけではなく、concern全般だった。

W3Cの返信は賛否二択ではない

Microsoftは5 APIを残して懸念に対応する方を望んだが、削除の合意を妨げないと明言した。WHATWGのworkstream案があるため、削除は作業終了ではなく主にvenueの変更になるとも述べた。さらに、Tentative Deliverableへの採用は現行設計の承認でもRecommendationの保証でもないと釘を刺した。

Will Morganはthreat model reviewを条件に残す案を支持し、いったん外してもWHATWGのworkstreamが6か月以内にできなければ戻せないかと問うた。François Daoustは、戻すには新しい憲章が必要だと説明した。編集継続とRecommendation Trackの権限は別である。

8月28日、Anssi Kostiainenは議長の立場ではないことを明記し、Intelの見解を投稿した。Intelは5 APIを削除することに懸念があり、多様なWeb利用者に向けた世界的採用には、W3Cのwide reviewとhorizontal reviewが有益だと考えていた。アーカイブの受信時刻は12:24 UTCで、指定日内である。

8月31日、KostiainenはDAS共同議長として結果を通知した。削除への懸念が提起されたため合意には至らず、W3C Teamが次の対応を検討するという内容だった。Intelの投稿だけを唯一の原因とはせず、憲章承認、Formal Objectionの解決、5 APIの恒久的維持も宣言していない。

したがってW3Cの状態は「削除に合意なし」であり、「維持を最終決定」ではない。

WHATWGは別の条件式を実行した

WHATWGのPull Request 264は4月から、ローカル周辺機器接続を扱うPeripheral APIs Workstreamを提案していた。対象は同じ5 APIで、議論にはWeb Serialだけで始める案、5仕様をまとめる案、W3Cとの関係、セキュリティ懸念の扱いが含まれていた。

8月25日のSteering Group議事録には、判断の分岐が明記されている。4人中3人がoption 2を選択した。金曜日までにW3C CfCへの objections がなければ既存PRの5仕様で開始し、異議があればWeb Serialだけで開始する。

W3Cが決めようとしていたのはW3C憲章からの削除である。WHATWGが決めたのはWHATWG workstreamの初期scopeである。命題は同じではない。しかし後者が前者の反応を条件に取り込んだため、W3CのconcernとWHATWGが検査するobjectionの対応関係が必要になった。

8月29日、PRはマージされた。マージコメントは、金曜日の業務終了時刻（PDT）までにW3C CfCへの異議がなかったので、選択済みの5仕様案を実行したと説明する。そして同じ文でIntelの懸念を認識している。commit 7eb413bは db.json にPeripheral APIs workstreamとWebBluetooth、WebHID、WebNFC、WebSerial、WebUSBを追加した。

懸念を消した記録ではない。懸念を認めながら、WHATWGの分岐を止めるobjectionではないと扱った記録である。

マージコメントは、workstream repositoryが作られた際にIntelの懸念と別のセキュリティ事例をissue化すべきだとも述べた。この未来形は重要だ。commitが証明するのはregistryの変更であり、すべてのrepository、issue、レビュー、緩和策、仕様公開が完了したことではない。

二つの結果から違反は導けない

W3CとWHATWGは別組織で、各自の権限対象を持つ。WHATWG Workstream PolicyはWorkstream Participantの未解決の実質的objectionに独自の処理を定める。W3Cの公開リストに投稿されたconcernが、そのままWHATWG内部のformal objectionになるわけではない。

逆も同じである。WHATWGのworkstream発足はW3CのFormal Objectionを解決せず、W3C憲章も変更しない。W3Cで削除合意がなかったからといって、WHATWGのマージが承認されるわけでもない。証拠は参照されたが、決定権は移動していない。

言葉の意味を全世界で統一する必要もない。Microsoftは「懸念はあるがblockしない」という状態を明示した。Intelの懸念には同じ但し書きがない。W3Cのclose recordはconcernsを理由に合意なしとし、WHATWGはobjectionsの不在を理由に5仕様を選んだ。これは本件の各責任者による分類であって、未来の全手続を拘束する辞書ではない。

監査上の空白は接続部分にある。組織Bが「組織Aで異議がなければ実行する」と決めるなら、Aが出力したconcern、non-blocking concern、修正要求付きsupport、abstention、silenceをどうBのpredicateに写すのか公開すべきである。そうでなければ、決定自体が正当でも、第三者は分岐を再現できない。

Lu HengのThe Multi-Stakeholder Mirageは、ここで有効な抑制を示す。参加、助言、警告、異議は証拠だが、それだけで他者を拘束する権限にはならない。Intelはどちらの組織にも命令していない。だからこそ、各組織はその証拠をどう評価したかを自分の責任で示す必要がある。

Cross-venue predicate receiptの設計

最初の欄はupstream propositionである。対象憲章のversion、5項目、8月14日の開始メール、回答channel、期限、any concernsという入力語彙を固定する。期間中に提案本文が大きく変わったなら、clockを継続したか再開したかも残す。

次にresponse stateを保存する。Microsoftの希望とnon-blocking qualifier、Will Morganの条件案、Intelの明示的懸念を一つの賛否列に潰さない。公開Message-IDとtimestampがあれば、私信を出さずに同一性を確保できる。

三つ目はW3C resultである。誰が議長としてcloseしたか、時刻、consensus was not reached、公表理由、次に権限を持つ主体を記録する。後の正式憲章はsuccessorとして連結し、8月31日の結果を書き換えない。

四つ目はdownstream predicateである。5仕様かWeb Serialだけかという条件、PDTのcutoff、Steering Groupの決定、実際のclassifier、mapping ruleを示す。本稿の核心は、同じ語を強制することではない。認識済みのconcernがなぜこの条件でobjectionにならなかったかを公開することにある。

五つ目はactionとimmutable artifactである。PR 264、merge actor、commit 7eb413b、追加された5 recordsを結ぶ。その後のrepository creation、issue、scope変更、publicationは新しいeventとして追記する。

最後にnon-inheritance statementを置く。W3Cの判断はWHATWGの権限ではなく、WHATWGのcommitはW3Cの処分ではない。どちらも安全認証、ブラウザ実装の約束、利用者の同意を意味しない。

証拠の境界

調査時点でW3Cの公開グループページは「Chartered until 31 August 2026」と表示し、新憲章は提案状態だった。監視すべきstate gapではあるが、グループ停止、提案却下、非公開の最終決定を証明しない。

技術論争も未決である。Formal Objectionは具体的なsecurity gateを求め、継続を望む参加者はW3CまたはWHATWGで対応可能だと考えている。workstreamの存在は安全性の認定ではない。削除に合意がないことも5 APIの承認ではない。

確定できるのは手続上の連鎖である。W3Cはconcernsを求め、concernsが出たため合意なしとした。WHATWGはobjectionsの有無を条件にし、Intelのconcernを認めながら条件成立とした。両方が正当である可能性は残る。それでも、語彙変換は公開されるべき決定入力である。

出典