Resumo

  • Em 14 de agosto, o W3C propôs retirar WebHID, Web NFC, WebUSB, Web Bluetooth e Web Serial dos entregáveis tentativos de uma carta ainda proposta. O Call for Consensus pedia resposta até 28 de agosto diante de qualquer preocupação.
  • Intel respondeu dentro do prazo que tinha preocupações com a retirada das cinco APIs. Em 31 de agosto, o copresidente do grupo declarou que preocupações haviam sido levantadas e que, por isso, não houve consenso sobre a remoção.
  • O Steering Group do WHATWG havia adotado outro teste: iniciar o Peripheral APIs Workstream com todas as cinco especificações se não houvesse objeções à CfC do W3C; com alguma objeção, começar somente por Web Serial.
  • O WHATWG incorporou a proposta completa em 29 de agosto. O comentário de merge registra ausência de objeções até seu corte e, na mesma passagem, reconhece as preocupações da Intel.
  • Um comprovante de predicado entre fóruns deve preservar pergunta, vocabulário de resposta, classificação, prazo e fuso, decisor, ação e limite de autoridade em cada lado.

A carta continuava sendo uma proposta

O rascunho da carta do Devices and Sensors Working Group ainda trazia [PROPOSED]. Web Bluetooth, Web Serial, WebUSB, Web NFC e WebHID apareciam como entregáveis tentativos, todos em estado Draft Community Group Report. Colocá-los na carta daria ao grupo um caminho de trabalho na Recommendation Track; não validaria o desenho existente nem garantiria publicação como Recommendation.

O aviso de 12 de junho abriu a revisão até 17 de julho e informou que algumas discussões substantivas não haviam sido resolvidas por consenso. Uma Formal Objection publicada em 23 de julho pediu a retirada das cinco APIs. Como alternativa, exigia uma condição explícita antes de adoção ou avanço: classes de exploração documentadas, mitigação normativa testável, revisões horizontais e disposição por classe.

Essas alegações técnicas pertencem ao autor da objeção. A publicação não as transforma em constatações do W3C, e este texto não decide se cada risco ou remédio é correto. O evento verificável é o tratamento dado às respostas sobre a retirada.

O Call for Consensus de 14 de agosto formulou uma proposta precisa: remover as cinco APIs da lista para resolver a Formal Objection. Pediu que participantes respondessem até 28 de agosto caso tivessem “any concerns” e considerou o silêncio consentimento. O canal não solicitava apenas uma objeção com rótulo formal; solicitava preocupações.

As respostas ocupavam mais de duas posições

Microsoft preferia manter as APIs e enfrentar os riscos, mas afirmou que não bloquearia o consenso para removê-las. Como havia uma proposta no WHATWG, a exclusão mudaria principalmente o local do trabalho, em vez de encerrá-lo. A mensagem também separou inclusão tentativa de endosso ao desenho e de garantia de Recommendation.

Will Morgan defendeu permanência condicionada a uma revisão de threat model e perguntou sobre a volta das APIs caso o workstream não surgisse em seis meses. François Daoust respondeu com o limite de competência: a readoção exigiria uma nova carta do W3C. Continuidade de edição não recria escopo normativo.

Em 28 de agosto, Anssi Kostiainen escreveu em nome da Intel e sem o chapéu de chair. Intel tinha preocupações com a retirada das cinco APIs porque via valor na revisão ampla e horizontal do W3C para uma adoção global diversa. A mensagem foi recebida às 12h24 UTC, dentro da data indicada.

No dia 31, Kostiainen falou como copresidente e publicou o resultado da consulta: preocupações haviam sido levantadas; como resultado, não houve consenso. O comunicado não atribuiu tudo exclusivamente à mensagem da Intel. Tampouco aprovou a carta, resolveu a Formal Objection ou decidiu manter as APIs de forma definitiva. A equipe do W3C consideraria o material nos próximos passos.

O estado exato é, portanto, falta de consenso para remover — não uma decisão final de conservar.

O WHATWG tinha uma bifurcação própria

A pull request 264 estava aberta desde abril para criar um Peripheral APIs Workstream. Seu escopo incluía as mesmas cinco famílias de conectividade local. A discussão já havia considerado um começo restrito a Web Serial, participação entre instituições e questões de segurança.

A ata do Steering Group de 25 de agosto registrou três opções e a decisão de três dos quatro representantes. A opção escolhida determinava: todas as cinco especificações na sexta-feira se não houvesse objections to the W3C CfC; apenas Web Serial se aparecesse alguma objeção.

As perguntas eram diferentes. O W3C decidia se retirava itens de uma carta do W3C. O WHATWG decidia o escopo inicial de um órgão do WHATWG. Ainda assim, a segunda decisão importou um estado da primeira. Para ser reproduzível, ela precisava dizer como concern no processo de origem se relacionava com objection no teste de destino.

Em 29 de agosto, a proposta foi incorporada. O registro de merge disse que não havia objeções à CfC até o fim do expediente de sexta-feira no fuso PDT, ao mesmo tempo em que reconheceu as preocupações da Intel. O commit imutável 7eb413b acrescentou ao db.json o workstream Peripheral APIs e os registros WebBluetooth, WebHID, WebNFC, WebSerial e WebUSB.

O WHATWG não apagou a preocupação. Classificou-a como algo que não acionava a ramificação “há objeção” de sua própria decisão.

O comentário acrescentou uma obrigação futura: registrar essas preocupações e outro cenário de segurança como issues quando o repositório do workstream fosse criado. Logo, o commit prova a entrada e o escopo. Não prova que todo repositório, issue, review, mitigação ou publicação já existia.

Procedimentos diferentes não equivalem a violação

O W3C controla suas cartas e suas decisões. O Steering Group do WHATWG controla a criação dos próprios workstreams. A Workstream Policy atribui um procedimento específico a objeções substantivas de Workstream Participants; uma preocupação numa lista do W3C não se converte automaticamente nesse objeto.

Também não há herança no sentido contrário. O merge do WHATWG não resolve a Formal Objection nem altera a carta do W3C. A ausência de consenso no W3C não aprova, invalida ou reverte o workstream do WHATWG. Um elo de informação não é um elo de comando.

As palavras não precisam ter significado universal. Microsoft demonstrou a categoria “preocupação sem bloqueio”. Intel declarou preocupação sem a mesma ressalva. O W3C tratou a existência de preocupações como incompatível com consenso sobre a remoção; o WHATWG tratou seu teste de objeções como satisfeito. Essas são classificações públicas neste caso, não definições obrigatórias para qualquer processo futuro.

O risco está na junção invisível. Se o fórum B age quando não há objeção no fórum A, deve publicar como os estados que A realmente produz entram no predicado de B. Preocupação, preocupação não bloqueante, apoio com mudanças, abstenção e silêncio não são necessariamente a mesma coisa. Sem um mapa, um leitor precisa adivinhar por que uma condição foi satisfeita.

O argumento de Lu Heng em The Multi-Stakeholder Mirage fornece uma contenção útil: participação, advertência e objeção são evidência, não autoridade herdada. A Intel não comandava nenhuma das instituições. Cabe a cada uma mostrar como usou a evidência dentro da competência que já possuía.

Como seria o comprovante de predicado

O primeiro bloco fixa a proposição de origem: versão da carta, cinco nomes, mensagem de abertura, canal, prazo e a expressão any concerns. Uma alteração material durante a consulta teria de indicar se o relógio continuou ou reiniciou.

O segundo preserva os estados reais das respostas. A preferência e a ressalva não bloqueante da Microsoft, a proposta condicional de Will Morgan e a preocupação da Intel não cabem numa coluna única. Message-ID, horário e URL pública tornam o registro suficiente sem expor conversa privada.

O terceiro registra o resultado do W3C: chair responsável, horário, frase consensus was not reached, motivo publicado e próximo ator competente. Uma carta futura entra como sucessora e não reescreve o fechamento de 31 de agosto.

O quarto descreve o predicado do WHATWG: cinco contra uma especificação, corte em PDT, Steering Group, classificador e regra de mapeamento. A pergunta central é simples: por que uma preocupação reconhecida não contou como objeção para essa ramificação?

O quinto aponta ação e artefato: PR, merge, commit e registros adicionados. Repositórios, issues e publicações posteriores recebem seus próprios estados. Uma cláusula final declara a não herança de autoridade entre W3C e WHATWG.

Limite probatório

No corte, a página pública do grupo ainda mostrava “Chartered until 31 August 2026”, enquanto a carta sucessora continuava proposta. É um descompasso a acompanhar, não prova de encerramento, rejeição ou decisão final oculta.

A controvérsia técnica segue aberta. A Formal Objection pede controles específicos; outras respostas entendem que o trabalho pode tratar os riscos em um dos dois locais. Criar um workstream não certifica segurança. Não formar consenso para retirar também não aprova as APIs.

O registro permite uma conclusão limitada. O W3C pediu preocupações e citou preocupações ao fechar sem consenso. O WHATWG testou objeções, reconheceu uma preocupação da Intel e declarou cumprida sua condição. Os dois resultados podem ser regulares. O mapeamento que os conecta precisa ser público.

Fontes