A Web deve expor os recursos de hardware?

Recentemente, fiquei interessado na diferença de opiniões entre os diferentes fornecedores de navegadores sobre o futuro da web — especificamente nos vários esforços para aproximar os recursos da plataforma web das plataformas nativas, como o Projeto Fugu do Chromium.

As principais posições podem ser resumidas como:

• O Google (junto com parceiros como Intel, Microsoft e Samsung) está avançando agressivamente e inovando com uma infinidade de novas APIs como as do Fugu, e as envia no Chromium;
• A Apple está recuando com uma abordagem mais conservadora, marcando muitas das novas APIs como levantando preocupações de segurança e privacidade;
• Isso (juntamente com as restrições da Apple na escolha do navegador no iOS) criou uma postura rotulando o Safari como o novo IE enquanto afirma que a Apple está diminuindo o progresso da web;
• A Mozilla parece mais próxima da Apple do que do Google nisso.

Minha intenção neste artigo é examinar as alegações identificadas com o Google, especificamente as da Platform Adjacency Theory do líder do Projeto Fugu, Alex Russell, examinar as evidências apresentadas nessas alegações e talvez chegar à minha própria conclusão.

Especificamente, pretendo mergulhar no WebUSB (uma API particularmente controversa do Projeto Fugu), verificar se as reivindicações de segurança contra ele têm mérito e tentar ver se surge uma alternativa.

A Teoria da Adjacência de Plataforma

A teoria acima mencionada faz as seguintes afirmações:

• O software está migrando para a web porque é uma versão melhor da computação;
• A web é uma meta-plataforma — uma plataforma abstraída de seu sistema operacional;
• O sucesso de uma metaplataforma se baseia em realizar as coisas que esperamos que a maioria dos computadores faça;
• Recusar a adição de recursos adjacentes à meta-plataforma da Web por motivos de segurança, ignorando os mesmos problemas de segurança em plataformas nativas, acabará tornando a Web cada vez menos relevante;
• A Apple e a Mozilla estão fazendo exatamente isso – recusando-se a adicionar recursos de computação adjacentes à web, assim “lançando a web em âmbar”.

Eu me relaciono com a paixão do autor por manter a web aberta relevante, e com a preocupação de que ir muito devagar com o aprimoramento da web com novos recursos a tornará irrelevante. Isso é aumentado pela minha antipatia por lojas de aplicativos e outros jardins murados. Mas, como usuário, posso me relacionar com a perspectiva oposta – às vezes fico tonto quando não sei quais sites que estou navegando são capazes ou não de fazer, e acho as restrições de plataforma e auditoria reconfortantes.

Metaplataformas

Para entender o termo “meta-plataforma”, analisei para que a teoria usa esse nome – Java e Flash, ambos produtos da virada do milênio.

Acho confuso comparar Java ou Flash com a web. Tanto o Java quanto o Flash, como mencionado na teoria, foram amplamente distribuídos na época por meio de plug-ins de navegador, tornando-os mais um tempo de execução alternativo montado em cima da plataforma do navegador. Hoje, o Java é usado principalmente no servidor e como parte da plataforma Android, e ambos não compartilham muito em comum, exceto a linguagem.

Hoje, o Java do lado do servidor talvez seja uma meta-plataforma, e o node.js também é um bom exemplo de meta-plataforma do lado do servidor. É um conjunto de APIs, um tempo de execução multiplataforma e um ecossistema de pacotes. De fato, o node.js está sempre adicionando mais recursos, anteriormente apenas possíveis como parte de uma plataforma.

No lado do cliente, Qt, um framework multiplataforma baseado em C++, não vem com um runtime separado, é meramente uma (boa!) biblioteca multiplataforma para desenvolvimento de UI.

O mesmo se aplica ao Rust — é uma linguagem e um gerenciador de pacotes, mas não depende de tempos de execução pré-instalados.

As outras maneiras de desenvolver aplicativos do lado do cliente são principalmente específicas da plataforma, mas também incluem algumas soluções móveis multiplataforma, como Flutter e Xamarin.

Capacidades vs. Tempo

O gráfico principal da teoria mostra a relevância das meta-plataformas em um eixo 2D de capacidades versus tempo:

Eu posso ver como o gráfico acima faz sentido quando falamos sobre frameworks de desenvolvimento multiplataforma mencionados acima como Qt, Xamarin, Flutter e Rust, e também para plataformas de servidor como node.js e Java/Scala.

Mas todos os itens acima têm uma diferença fundamental em relação à web.

A 3ª Dimensão

As meta-plataformas mencionadas anteriormente estão de fato competindo contra seus sistemas operacionais host na corrida por recursos, mas, diferentemente da web, elas não opinam sobre confiança e distribuição - a 3ª dimensão, que na minha opinião está faltando no gráfico acima.

Qt e Rust são boas maneiras de criar aplicativos que são distribuídos via WebAssembly, baixados e instalados diretamente no sistema operacional host ou administrados por meio de gerenciadores de pacotes como Cargo ou distribuições Linux como Ubuntu. React Native, Flutter e Xamarin são maneiras decentes de criar aplicativos que são distribuídos por meio de lojas de aplicativos. O node.js e os serviços Java geralmente são distribuídos por meio de um contêiner docker, uma máquina virtual ou algum outro mecanismo de servidor.

Os usuários, em sua maioria, desconhecem o que foi usado para desenvolver seu conteúdo, mas estão cientes até certo ponto de como ele é distribuído. Os usuários não sabem o que são Xamarin e node.js, e se seu aplicativo Swift fosse substituído um dia por um aplicativo Flutter, a maioria dos usuários não se importaria e, idealmente, não deveria se importar com isso.

Mas os usuários conhecem a web – eles sabem que quando estão “navegando” no Chrome ou no Firefox, estão “online” e podem acessar conteúdo em que não necessariamente confiam. Eles sabem que baixar software e instalá-lo é um risco possível e pode ser bloqueado pelo administrador de TI. Na verdade, é importante para a plataforma web que os usuários saibam que estão atualmente “navegando na web”. É por isso que, por exemplo, alternar para o modo de tela cheia mostra um prompt claro para o usuário, com instruções de como voltar.

A web se tornou um sucesso porque não é transparente — mas claramente separada de seu sistema operacional host. Se eu não puder confiar no meu navegador para manter sites aleatórios longe da leitura de arquivos no meu disco rígido, provavelmente não irei a nenhum site.

Os usuários também sabem que o software de seu computador é “Windows” ou “Mac”, se seus telefones são baseados em Android ou iOS e se estão usando um aplicativo no momento (quando no iOS ou Android e no Mac OS até certo ponto) . O sistema operacional e o modelo de distribuição são geralmente conhecidos pelo usuário - o usuário confia em seu sistema operacional e na web para fazer coisas diferentes e em diferentes graus de confiança.

Portanto, a web não pode ser comparada a frameworks de desenvolvimento multiplataforma, sem levar em consideração seu modelo de distribuição exclusivo.

Por outro lado, as tecnologias web também são utilizadas para o desenvolvimento multiplataforma, com frameworks como Electron e Cordova. Mas esses não são exatamente “a web”. Quando comparado com Java ou node.js, o termo “The web” precisa ser substituído por “Web Technologies”. E as “tecnologias da web” usadas dessa maneira não precisam necessariamente ser baseadas em padrões ou funcionar em vários navegadores. A conversa sobre APIs Fugu é um pouco tangencial para Electron e Cordova.

Aplicativos nativos

Ao adicionar recursos à plataforma web, a 3ª dimensão – o modelo de confiança e distribuição – não pode ser ignorada ou tomada de ânimo leve. Quando o autor afirma que “a postura da Apple e da Mozilla sobre os riscos de novos recursos é desmentida pelos riscos aceitos da plataforma nativa existente” , ele está colocando a web e as plataformas nativas na mesma dimensão em relação à confiança.

É verdade que os aplicativos nativos têm seus próprios problemas e desafios de segurança. Mas não vejo como isso seja um argumento a favor de mais recursos da web, como aqui. Isso é uma falácia - a conclusão deve ser corrigir problemas de segurança com aplicativos nativos, não relaxar a segurança para aplicativos da Web porque eles estão em um jogo de recuperação de relevância com os recursos do sistema operacional.

Nativo e web não podem ser comparados em termos de capacidades, sem levar em conta a 3ª dimensão do modelo de confiança e distribuição.

Limitações da App Store

Uma das críticas sobre aplicativos nativos na teoria é sobre a falta de escolha do mecanismo do navegador no iOS. Este é um fio comum de críticas contra a Apple, mas há mais de uma perspectiva para isso.

A crítica é especificamente sobre o item 2.5.6 das diretrizes de revisão da loja de aplicativos da Apple:

“Os aplicativos que navegam na Web devem usar a estrutura WebKit apropriada e o WebKit JavaScript.”

Isso pode parecer anticompetitivo, e tenho minhas próprias reservas sobre o quão restritivo é o iOS. Mas o item 2.5.6 não pode ser lido sem o contexto do restante das diretrizes de revisão da loja de aplicativos, por exemplo, o item 2.3.12:

“Os aplicativos devem descrever claramente novos recursos e alterações de produtos em seu texto 'O que há de novo'.”

Se um aplicativo pudesse receber permissões de acesso ao dispositivo e incluísse sua própria estrutura que pudesse executar código de qualquer site, esses itens nas diretrizes de revisão da loja de aplicativos se tornariam sem sentido. Ao contrário dos aplicativos, os sites não precisam descrever seus recursos e alterações de produtos a cada revisão.

Isso se torna um problema ainda maior quando os navegadores lançam recursos experimentais, como os do projeto Fugu, que ainda não são considerados um padrão. Quem define o que é um navegador? Ao permitir que os aplicativos enviem qualquer estrutura da Web, a loja de aplicativos essencialmente permitiria que o “aplicativo” executasse qualquer código não auditado ou alterasse o produto completamente, contornando o processo de revisão da loja.

Como usuário de sites e aplicativos, acho que ambos têm espaço no mundo da computação, embora espere que o máximo possível possa migrar para a web. Mas ao considerar o estado atual dos padrões da Web e como a dimensão da confiança e do sandboxing em torno de coisas como Bluetooth e USB está longe de ser resolvida, não vejo como permitir que aplicativos executem conteúdo livremente da Web seria benéfico para os usuários .

A Busca da Aptidão

Em outra postagem de blog relacionada, o mesmo autor aborda um pouco disso, ao falar sobre aplicativos nativos:

“Ser 'um aplicativo' é apenas atender a um conjunto de convenções de sistema operacional arbitrárias e mutáveis.”

Concordo com a noção de que a definição de “app” é arbitrária e que sua definição depende de quem define as políticas da loja de aplicativos. Mas hoje, o mesmo vale para os navegadores. A afirmação da postagem de que os aplicativos da Web são seguros por padrão também é um pouco arbitrária. Quem desenha a linha na areia de “o que é um navegador”? O aplicativo do Facebook com navegador embutido é “um navegador”?

A definição de um aplicativo é arbitrária, mas também importante. O fato de que cada revisão de um aplicativo que usa recursos de baixo nível é auditada por alguém em quem eu possa confiar, mesmo que esse alguém seja arbitrário, torna os aplicativos o que são. Se esse alguém for o fabricante do hardware pelo qual paguei, isso o torna ainda menos arbitrário – a empresa de quem comprei meu computador é o único software de auditoria com recursos mais baixos para esse computador.

Tudo pode ser um navegador

Sem traçar uma linha de “o que é um navegador”, que é essencialmente o que a loja de aplicativos da Apple faz, cada aplicativo pode enviar seu próprio mecanismo da web, atrair o usuário a navegar para qualquer site usando seu navegador no aplicativo e adicionar qualquer código de rastreamento quer, recolhendo a diferença de 3ª dimensão entre aplicativos e sites.

Quando uso um aplicativo no iOS, sei que minhas ações estão atualmente expostas a dois jogadores: a Apple e o fabricante do aplicativo identificado. Quando uso um site no Safari ou em um Safari WebView, minhas ações são expostas à Apple e ao proprietário do domínio de nível superior do site que estou visualizando no momento. Quando uso um navegador no aplicativo com um mecanismo não identificado, sou exposto à Apple, fabricante do aplicativo, e ao proprietário do domínio de nível superior. Isso pode criar violações de mesma origem evitáveis, como o proprietário do aplicativo rastrear todos os meus cliques em sites estrangeiros.

Concordo que talvez a linha na areia de “Only WebKit” seja muito dura. Qual seria uma definição alternativa de um navegador que não criaria um backdoor para rastrear a navegação do usuário?

Outras críticas sobre a Apple

A teoria afirma que o declínio da Apple em implementar recursos não se limita a questões de privacidade/segurança. Inclui um link, que de fato mostra muitos recursos implementados no Chrome e não no Safari. No entanto, ao rolar para baixo, ele também lista uma quantidade considerável de outros recursos implementados no Safari e não no Chrome.

Esses dois projetos de navegadores têm prioridades diferentes, mas está longe da afirmação categórica “O jogo fica claro ao diminuir o zoom” e das duras críticas sobre a Apple tentar lançar a web em âmbar.

Além disso, os links intitulados são difíceis e não queremos tentar levar a declarações da Apple de que eles implementariam recursos se as preocupações de segurança/privacidade fossem atendidas. Eu sinto que colocar esses links com esses títulos é enganoso.

Eu concordaria com uma afirmação mais equilibrada, que o Google é muito mais otimista do que a Apple sobre a implementação de recursos e o avanço da web.

Solicitação de permissão

O Google percorre caminhos inovadores na 3ª dimensão, desenvolvendo novas formas de intermediar a confiança entre o usuário, o desenvolvedor e a plataforma, às vezes com grande sucesso, como no caso de Trusted Web Activities.

Mas ainda assim, a maior parte do trabalho na 3ª dimensão no que se refere às APIs do dispositivo é focada em prompts de permissão e tornando-os mais assustadores, ou coisas como concessões de permissão de caixa de tempo e domínios bloqueados.

Os prompts “assustadores”, como os deste exemplo que vemos de tempos em tempos, parecem ter o objetivo de desencorajar as pessoas de acessar páginas que parecem potencialmente maliciosas. Por serem tão evidentes, esses avisos incentivam os desenvolvedores a migrar para APIs mais seguras e a renovar seus certificados.

Eu gostaria que, para recursos de acesso a dispositivos, pudéssemos apresentar avisos que incentivem o envolvimento e garantam que o envolvimento seja seguro, em vez de desencorajá-lo e transferir a responsabilidade para o usuário, sem remediação disponível para o desenvolvedor da web. Mais sobre isso mais tarde.

Concordo com o argumento de que a Mozilla e a Apple deveriam pelo menos tentar inovar nesse espaço em vez de “recusar a implementação”. Mas talvez sejam? Acho que o isLoggedIn da Apple, por exemplo, é uma proposta interessante e relevante na 3ª dimensão que as futuras APIs de dispositivos podem construir - por exemplo, APIs de dispositivos que são propensas a impressões digitais podem ser disponibilizadas quando o site atual já conhece a identidade do o usuário.

WebUSB

Na próxima seção vou mergulhar no WebUSB, verificar o que ele permite e como é tratado na 3ª dimensão – qual é o modelo de confiança e distribuição? É suficiente? Quais são as alternativas?

A premissa

A API WebUSB permite acesso total ao protocolo USB para classes de dispositivos que não estão na lista de bloqueio.

Ele pode alcançar coisas poderosas, como conectar-se a uma placa Arduino ou depurar um telefone Android.

É emocionante ver os vídeos de Suz Hinton sobre como essa API pode ajudar a alcançar coisas que antes eram muito caras.

Eu realmente desejo que as plataformas encontrem maneiras de serem mais abertas e permitir iterações rápidas em projetos de hardware/software educacionais, por exemplo.

Sentimento engraçado

Mas ainda assim, tenho uma sensação engraçada quando vejo o que o WebUSB permite e os problemas de segurança existentes com o USB em geral.

O USB parece muito poderoso como um protocolo exposto à web, mesmo com solicitações de permissão.

Então eu pesquisei mais.

Visão oficial da Mozilla

Comecei lendo o que David Baron tinha a dizer sobre por que a Mozilla acabou rejeitando o WebUSB, na posição oficial de padrões da Mozilla:

“Como muitos dispositivos USB não são projetados para lidar com interações potencialmente maliciosas nos protocolos USB e como esses dispositivos podem ter efeitos significativos no computador ao qual estão conectados, acreditamos que os riscos de segurança de expor dispositivos USB à Web são muito amplo para arriscar expor os usuários a eles ou explicar adequadamente aos usuários finais para obter um consentimento informado significativo”.

O prompt de permissão atual

É assim que o prompt de permissão WebUSB do Chrome se parece no momento da publicação desta postagem:

O domínio específico Foo deseja se conectar a um determinado dispositivo Bar. Para fazer o que? e como posso saber com certeza?

Ao conceder acesso à impressora, câmera, microfone, GPS ou mesmo a alguns dos perfis mais contidos do WebBluetooth GATT, como monitoramento de frequência cardíaca, essa pergunta é relativamente clara e foca no conteúdo ou ação e não no dispositivo . Há uma compreensão clara de quais informações eu quero do periférico ou qual ação eu quero realizar com ele, e o agente do usuário faz a mediação e garante que essa ação específica seja tratada.

USB é genérico

Ao contrário dos dispositivos mencionados acima que são expostos por meio de APIs especiais, o USB não é específico de conteúdo. Conforme mencionado na introdução da especificação, o WebUSB vai além e é projetado intencionalmente para tipos de dispositivos desconhecidos ou ainda não inventados, não para classes de dispositivos conhecidos, como teclados ou unidades externas.

Assim, diferentemente dos casos da impressora, GPS e câmera, não consigo pensar em um prompt que informasse ao usuário o que permitiria uma permissão de página para se conectar a um dispositivo com WebUSB no domínio do conteúdo, sem um profundo conhecimento do determinado dispositivo e auditar o código que o está acessando.

O Incidente e Mitigação de Yubikey

Um bom exemplo de não muito tempo atrás é o incidente Yubikey, onde o WebUSB do Chrome foi usado para phishing de dados de um dispositivo de autenticação alimentado por USB.

Como esse é um problema de segurança que está resolvido, fiquei curioso para mergulhar nos esforços de mitigação do Chrome no Chrome 67, que incluem o bloqueio de um conjunto específico de dispositivos e um conjunto específico de classes.

Lista de bloqueio de classe/dispositivo

Portanto, a defesa real do Chrome contra explorações WebUSB que aconteciam à solta, além do prompt de permissão muito geral atualmente, era bloquear dispositivos e classes de dispositivos específicos.

Esta pode ser uma solução simples para uma nova tecnologia ou experimento, mas se tornará cada vez mais difícil de realizar quando (e se) o WebUSB se tornar mais popular.

Receio que as pessoas inovando em dispositivos educacionais via WebUSB possam chegar a uma situação difícil. No momento em que terminam de prototipar, eles podem estar enfrentando um conjunto de listas de bloqueio não padrão em constante mudança, que só são atualizadas junto com as versões do navegador, com base em problemas de segurança que não têm nada a ver com eles.

Acho que padronizar essa API sem resolver isso acabará sendo contraproducente para os desenvolvedores que confiam nela. Por exemplo, alguém pode passar ciclos desenvolvendo um aplicativo WebUSB para detectores de movimento, apenas para descobrir mais tarde que os detectores de movimento se tornam uma classe bloqueada, seja por motivos de segurança ou porque o sistema operacional decide lidar com eles, fazendo com que todo o seu esforço WebUSB vá para desperdício.

Segurança versus recursos

A teoria da adjacência de plataforma, de certa forma, considera recursos e segurança como um jogo de soma zero, e que ser muito conservador em questões de segurança e privacidade faria com que as plataformas perdessem sua relevância.

Tomemos o Arduino como exemplo. A comunicação do Arduino é possível com o WebUSB e é um caso de uso importante. Alguém desenvolvendo um dispositivo Arduino agora terá que considerar um novo cenário de ameaça, onde um site tenta acessar seu dispositivo usando WebUSB (com alguma permissão do usuário). De acordo com a especificação, este fabricante de dispositivos agora precisa “projetar seus dispositivos para aceitar apenas firmware assinado”. Isso pode sobrecarregar os desenvolvedores de firmware e aumentar os custos de desenvolvimento, enquanto todo o objetivo da especificação é fazer o oposto.

O que torna o WebUSB diferente de outros periféricos

Nos navegadores, há uma clara distinção entre interações do usuário e interações sintéticas (interações instanciadas pela página da web).

Por exemplo, uma página da web não pode decidir por conta própria clicar em um link ou ativar a CPU/tela. Mas dispositivos externos podem – por exemplo, um dispositivo de mouse pode clicar em um link em nome do usuário e quase qualquer dispositivo USB pode ativar a CPU, dependendo do sistema operacional.

Assim, mesmo com a atual especificação WebUSB, os dispositivos podem optar por implementar várias interfaces, por exemplo, depurar para adb e HID para entrada de ponteiro, e usando código malicioso que tira proveito do ADB, tornar-se um keylogger e navegar em sites em nome do usuário, dada a mecanismo de flash de firmware explorável certo.

Adicionar esse dispositivo a uma lista de bloqueio seria tarde demais para dispositivos com firmware comprometido usando ADB ou outras formas permitidas de flash, e tornaria os fabricantes de dispositivos ainda mais dependentes das versões do navegador para correções de segurança associadas a seus dispositivos.

Consentimento Informado e Conteúdo

O problema com o consentimento informado e o USB, como mencionado anteriormente, é que o USB (especificamente nos casos de uso extra-genéricos do WebUSB) não é específico de conteúdo. Os usuários sabem o que é uma impressora, o que é uma câmera, mas “USB” para a maioria dos usuários é apenas um cabo (ou um soquete) – um meio para um fim – muito poucos usuários sabem que USB é um protocolo e o que o habilita entre sites e dispositivos meios.

Uma sugestão era ter um prompt “assustador”, algo como “Permitir que esta página da Web assuma o controle do dispositivo” (que é uma melhoria em relação ao aparentemente inofensivo “quer se conectar”).

Mas, por mais assustadores que sejam os prompts, eles não podem explicar a amplitude de coisas possíveis que podem ser feitas com acesso bruto a um periférico USB que o navegador não conhece intimamente e, se o conhecessem, nenhum usuário em sã consciência clicaria em "Sim ”, a menos que seja um dispositivo em que eles confiam totalmente para ser livre de bugs e um site que eles realmente confiam para ser atualizado e não malicioso.

Um possível prompt como esse seria “Permitir que esta página da Web potencialmente domine seu computador”. Eu não acho que um prompt assustador como este seria benéfico para a comunidade WebUSB, e mudanças constantes nesses diálogos deixarão a comunidade confusa.

Prototipagem vs. Produto

Eu posso ver uma possível exceção a isso. Se a premissa do WebUSB e de outras APIs Fugu do projeto fosse oferecer suporte à prototipagem em vez de dispositivos de nível de produto, prompts genéricos abrangentes poderiam fazer sentido.

Para tornar isso viável, porém, acho que o seguinte deve acontecer:

1. Use a linguagem nas especificações que definem as expectativas sobre isso para prototipagem;
2. Ter essas APIs disponíveis somente após algum gesto de aceitação, como fazer com que o usuário as habilite manualmente nas configurações do navegador;
3. Tenha prompts de permissão “assustadores”, como os de certificados SSL inválidos.

Não ter o acima me faz pensar que essas APIs são para produtos reais e não para protótipos e, como tal, o feedback é válido.

Uma Proposta Alternativa

Uma das partes da postagem original do blog com a qual concordo é que não basta dizer “não” – os principais players do mundo da web que recusam certas APIs por serem prejudiciais também devem ofender e propor maneiras pelas quais esses recursos que importam para usuários e desenvolvedores podem ser expostos com segurança. Não represento nenhum jogador importante, mas vou tentar humildemente.

Eu acredito que a resposta para isso está na 3ª dimensão de confiança e relacionamento, e que está fora da caixa de prompts de permissão e listas de bloqueio.

Solicitação direta e verificada

O caso principal que vou fazer é que o prompt deve ser sobre o conteúdo ou ação, e não sobre o periférico, e que o consentimento informado pode ser concedido para uma ação direta específica com um conjunto específico de parâmetros verificados, não para um ação geral como “assumir” ou “conectar-se a” um dispositivo.

O exemplo da impressora 3D

Na especificação WebUSB, as impressoras 3D são trazidas como exemplo, então vou usar aqui.

Ao desenvolver um aplicativo WebUSB para uma impressora 3D, quero que o prompt do navegador/SO me pergunte algo como Permitir que o AutoDesk 3ds-mask imprima um modelo em sua impressora 3D CreatBot? , será mostrada uma caixa de diálogo do navegador/SO com alguns parâmetros de impressão, como refinamento, espessura e dimensões de saída, e com uma visualização do que será impresso. Todos esses parâmetros devem ser verificados por um agente de usuário confiável, não por uma página da Web drive-by.

Atualmente, o navegador não conhece a impressora e pode verificar apenas algumas das declarações no prompt:

• O domínio solicitante possui um certificado registrado na AutoDesk, portanto, há alguma certeza de que se trata da AutoDesk Inc;
• O periférico solicitado chama-se “impressora 3d CreatBot”;
• Este dispositivo, classe de dispositivo e domínio não são encontrados nas listas de bloqueio do navegador;
• O usuário respondeu “Sim” ou “Não” a uma pergunta geral que lhe foi feita.

Mas, para mostrar um prompt e um diálogo verdadeiros com os detalhes acima, o navegador também precisa verificar o seguinte:

• Quando a permissão for concedida, a ação executada será a impressão de um modelo 3D, e nada mais que isso;
• Os parâmetros selecionados (refinamento/espessura/dimensões etc.) serão respeitados;
• Uma prévia verificada do que vai ser impresso foi mostrada ao usuário;
• Em certos casos sensíveis, uma verificação adicional de que isso é de fato o AutoDesk, talvez com algo como um token de curta duração revogável.

Sem verificar o acima, um site que recebeu permissão para “conectar-se” ou “assumir” uma impressora 3D pode começar a imprimir grandes modelos 3D devido a um bug (ou código malicioso em uma de suas dependências).

Além disso, uma capacidade de impressão 3D da Web totalmente desenvolvida faria muito mais do que o WebUSB pode fornecer - por exemplo, spool e enfileiramento de diferentes solicitações de impressão. Como isso seria tratado se a janela do navegador estivesse fechada? Não pesquisei todos os possíveis casos de uso de periféricos WebUSB, mas suponho que, ao analisá-los de uma perspectiva de conteúdo/ação, a maioria precisará de mais do que acesso USB.

Por causa do exposto, o uso do WebUSB para impressão 3D provavelmente será complicado e de curta duração, e os desenvolvedores que confiam nele terão que fornecer um driver “real” para sua impressora em algum momento. Por exemplo, se os fornecedores do sistema operacional decidirem adicionar suporte integrado para impressoras 3D, todos os sites que usam essa impressora com WebUSB deixarão de funcionar.

Proposta: Autoridade de Auditoria de Motoristas

Portanto, permissões abrangentes como "assumir o periférico" são problemáticas, não temos informações suficientes para mostrar um diálogo de parâmetro completo e verificar se seus resultados serão respeitados e não queremos enviar o usuário em uma viagem insegura para baixar um executável aleatório da web.

Mas e se houvesse um trecho de código auditado , um driver, que usasse a API WebUSB internamente e fizesse o seguinte:

• Implementado o comando “imprimir”;
• Exibido um diálogo de impressão fora da página;
• Conectado a um determinado conjunto de dispositivos USB;
• Executou algumas de suas ações quando a página está em segundo plano (por exemplo, em um service worker), ou mesmo quando o navegador está fechado.

Uma auditoria de um driver como esse pode garantir que o que ele faz equivale a “imprimir”, que respeita os parâmetros e que mostra a visualização da impressão.

Eu vejo isso como sendo semelhante às autoridades de certificação, uma peça importante no ecossistema da web que está um pouco desconectada dos fornecedores de navegadores.

Distribuição de motoristas

Os drivers não precisam ser auditados pelo Google/Apple, embora o fornecedor do navegador/SO possa optar por auditar os drivers por conta própria. Pode funcionar como autoridades de certificação SSL — o emissor é uma organização altamente confiável; por exemplo, o fabricante do periférico específico ou uma organização que certifica muitos drivers, ou uma plataforma como o Arduino. (Imagino organizações surgindo semelhantes ao Let's Encrypt.)

Pode ser suficiente dizer aos usuários: “Arduino confia que este código irá piscar seu Uno com este firmware” (com uma prévia do firmware).

Ressalvas

Obviamente, isso não está livre de possíveis problemas:

• O próprio driver pode ser bugado ou malicioso. Mas pelo menos é auditado;
• É menos “web” e gera uma carga adicional de desenvolvimento;
• Isso não existe hoje e não pode ser resolvido por inovação interna nos mecanismos do navegador.

Outras alternativas

Outras alternativas podem ser padronizar e melhorar de alguma forma a API de extensões da Web entre navegadores e tornar as lojas de complementos de navegador existentes, como a Chrome Web Store, em uma espécie de autoridade de auditoria de driver, mediando entre solicitações de usuários e acesso periférico.

Resumo da opinião

Os esforços ousados ​​do autor, do Google e de seus parceiros para manter a web aberta relevante, aprimorando seus recursos, são inspiradores.

Quando chego aos detalhes, vejo a visão mais conservadora da Apple e da Mozilla sobre a web e sua abordagem defensiva aos novos recursos do dispositivo, como tendo mérito técnico. Os principais problemas com consentimento informado sobre recursos de hardware abertos estão longe de serem resolvidos.

A Apple poderia ser mais aberta na discussão para encontrar novas maneiras de habilitar os recursos do dispositivo, mas acredito que isso vem de uma perspectiva diferente sobre computação, um ponto de vista que fez parte da identidade da Apple por décadas, não de um ponto de vista anticompetitivo.

A fim de suportar coisas como os recursos de hardware um tanto abertos no projeto Fugu, e especificamente WebUSB, o modelo de confiança da web precisa evoluir além de prompts de permissão e listas de bloqueio de domínio/dispositivo, inspirando-se em ecossistemas de confiança como autoridades de certificação e distribuições de pacotes.

Leitura adicional no SmashingMag:

• Como melhorar o desempenho do site pode ajudar a salvar o planeta
• Rumo a uma Web sem anúncios: diversificando a economia online
• Existe um futuro além de escrever um ótimo código?
• Usando a Ética no Web Design