A Web deve expor os recursos de hardware?

Recentemente, estive 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 levar os recursos da plataforma da web para mais perto das plataformas nativas, como o Projeto Fugu .

As posições principais 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 distribui no Chromium;
• A Apple está reagindo com uma abordagem mais conservadora, marcando muitas das novas APIs como levantando questões de segurança e privacidade ;
• Isso (junto com as restrições à escolha do navegador no iOS da Apple) criou uma postura rotulando o Safari como o novo IE , enquanto afirma que a Apple está retardando o progresso da web ;
• Mozilla parece mais próximo da Apple do que do Google nisso.

Minha intenção neste artigo é examinar as alegações identificadas com o Google, especificamente aquelas na Teoria da Adjacência da Plataforma pelo líder do Projeto Fugu Alex Russell, olhe para as evidências apresentadas nessas alegações e talvez chegue à minha própria conclusão.

Especificamente, pretendo mergulhar em WebUSB (uma API polêmica específica do Projeto Fugu), verificar se as reivindicações de segurança contra tenha mérito e tente ver se surge uma alternativa.

A Teoria da Adjacência da Plataforma

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

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

Eu me identifico com a paixão do autor em manter a web aberta relevante e com a preocupação de que ir devagar demais para aprimorar a 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 identificar com a perspectiva oposta-às vezes fico tonto quando não sei quais sites em que estou navegando são capazes ou não de fazer, e acho que as restrições de plataforma e a auditoria são reconfortantes.

Meta-plataformas

Para entender o termo “meta-plataforma”, olhei 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, eram amplamente distribuídos na época por meio de plug-ins de navegador, tornando-os mais um tempo de execução alternativo montado na plataforma do navegador. Hoje, 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 uma meta-plataforma e node.js também é um bom exemplo de um meta-plataforma. É um conjunto de APIs, um tempo de execução multiplataforma e um ecossistema de pacotes. Na verdade, node.js está sempre adicionando mais recursos, anteriormente possíveis apenas como parte de uma plataforma.

No lado do cliente, Qt , uma estrutura multiplataforma baseada em C ++, não vem com um tempo de execução separado, é apenas uma (boa!) biblioteca de plataforma cruzada para desenvolvimento de IU.

O mesmo se aplica a 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 de plataforma cruzada como Flutter e Xamarin .

Capacidades vs. Tempo

O gráfico principal na teoria mostra a relevância das meta-plataformas em um eixo 2D de recursos vs. tempo:

Eu posso ver como o gráfico acima faz sentido quando falamos sobre frameworks de desenvolvimento de plataforma cruzada 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 com seus sistemas operacionais host na corrida por recursos, mas, ao contrário da web, elas não têm opiniões 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 pacote gerentes 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. Os serviços node.js e Java geralmente são distribuídos por meio de um contêiner docker , uma máquina virtual ou algum outro mecanismo de servidor.

A maioria dos usuários não tem conhecimento do que foi usado para desenvolver seu conteúdo, mas está ciente 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 saberia e, idealmente, não deveria se preocupar com isso.

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

A web se tornou um sucesso porque não é transparente-mas claramente separada de seu sistema operacional host. Se eu não pudesse confiar em meu navegador para impedir que sites aleatórios leiam arquivos em meu disco rígido, provavelmente não acessaria nenhum site.

Os usuários também sabem que o software de seu computador é “Windows” ou “Mac”, sejam seus telefones baseados em Android ou iOS e se eles estão usando um aplicativo (quando no iOS ou Android e no Mac OS até certo ponto). O SO e o modelo de distribuição são geralmente conhecidos do usuário-o usuário confia em seu SO 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 de plataforma cruzada, sem levar em consideração seu modelo de distribuição exclusivo.

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

Aplicativos nativos

Ao adicionar recursos à plataforma da 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 de segurança e desafios. 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 os problemas de segurança com aplicativos nativos, não relaxar a segurança dos aplicativos da Web porque eles estão em um jogo de atualização relevante com os recursos do sistema operacional.

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

Limitações da App Store

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

A crítica é especificamente sobre o Item 2.5.6 da análise da loja de aplicativos da Apple diretrizes:

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

Isso pode parecer anticoncorrencial, e eu 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 app-store, por exemplo Item 2.3.12 :

“Os aplicativos devem descrever claramente os novos recursos e as mudanças no produto em seu texto‘ O que há de novo ’.”

Se um aplicativo pudesse receber permissões de acesso ao dispositivo e, em seguida, incluir sua própria estrutura que pudesse executar o código de qualquer site da web, esses itens nas diretrizes de revisão da app store perderiam o sentido. Ao contrário dos aplicativos, os sites não precisam descrever seus recursos e mudanças no produto a cada revisão.

Isso se torna um problema ainda maior quando os navegadores fornecem 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, evitando o processo de revisão da loja.

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

A busca pela elegância

Em outra postagem do blog relacionada, o mesmo autor aborda algumas dessas questões, ao falar sobre aplicativos nativos:

“Ser‘ um aplicativo ’é meramente 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 app store. Mas hoje, o mesmo é verdade para navegadores. A afirmação da postagem de que aplicativos da web são seguros por padrão também é um tanto arbitrária. Quem traça o limite na areia de “o que é um navegador”? O aplicativo do Facebook com navegador integrado é “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 posso confiar, mesmo que 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 da qual comprei meu computador é o software de auditoria com menos recursos para aquele computador.

Tudo pode ser um navegador

Sem traçar uma linha de “o que é um navegador”, que é o que a loja de aplicativos da Apple basicamente faz, cada aplicativo poderia lançar seu próprio mecanismo da web, atrair o usuário a navegar em qualquer site usando seu navegador no aplicativo e adicionar qualquer código de rastreamento que desejar, reduzindo a diferença de terceira dimensão entre aplicativos e sites.

Quando uso um aplicativo no iOS, sei que minhas ações estão atualmente expostas a dois jogadores: Apple e o fabricante do aplicativo identificado. Quando eu 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 eu uso um navegador no aplicativo com um mecanismo não identificado, sou exposto à Apple, o 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 rastreando todos os meus cliques em sites estrangeiros.

Eu 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 a recusa 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 que são implementado no Chrome e não no Safari. No entanto, ao rolar para baixo, ele também lista uma quantidade considerável de outros recursos que são implementados no Safari e não no Chrome.

Esses dois projetos de navegador têm prioridades diferentes, mas estão longe da declaração categórica “ O jogo fica claro quando se afasta o zoom ” e com as duras críticas sobre a Apple tentar lançar a web em âmbar.

Além disso, os links com o título é difícil e não queremos tentar levam ao declarações de que implementariam recursos se as questões de segurança/privacidade fossem atendidas. Acho que colocar esses links com esses títulos é enganoso.

Eu concordaria com uma declaração mais equilibrada, que o Google é muito mais otimista do que a Apple em relação à implementação de recursos e ao avanço da web.

Aviso 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 Atividades confiáveis ​​da Web .

Mas ainda assim, a maior parte do trabalho na 3ª dimensão no que se refere às APIs de dispositivos concentra-se em solicitações de permissão e tornando-as mais assustadoras ou coisas como concessões de permissão de limite de tempo e domínios listados para bloqueio.

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

Desejo que, para os recursos de acesso do dispositivo, possamos apresentar prompts 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 nessa área, em vez de “recusar a implementação”. Mas talvez eles sejam? Acho que isLoggedIn da Apple, por exemplo, é uma proposta interessante e relevante na 3ª dimensão que futuras APIs de dispositivo poderiam baseadas-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 usuário.

WebUSB

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

A premissa

A API WebUSB permite acesso total ao protocolo USB para classes de dispositivos que não são block-listed .

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

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

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

Sensação engraçada

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

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

Então, eu pesquisei mais.

Visualização oficial da Mozilla

Comecei lendo o que David Baron tinha a dizer sobre por que a Mozilla acabou rejeitando o WebUSB, no posicionamento oficial dos padrões :

“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 ao A web é muito ampla para expor os usuários a eles ou para explicar adequadamente aos usuários finais para obter consentimento informado significativo. ”

O prompt de permissão atual

Esta é a aparência do prompt de permissão WebUSB do Chrome no momento da publicação desta postagem:

Domínio específico Foo deseja se conectar à barra de dispositivo específico. Para fazer o que? e como posso saber com certeza?

Ao conceder acesso à impressora, câmera, microfone, GPS ou mesmo a alguns dos mais contidos WebBluetooth perfis GATT como monitoramento de frequência cardíaca , esta questão é relativamente clara e se concentra no conteúdo ou ação , e não no dispositivo . Há uma compreensão clara de quais informações eu desejo do periférico ou que ação desejo executar com ele, e o agente do usuário medeia 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 para o conteúdo. Conforme mencionado na introdução das especificações , WebUSB vai além e é intencionalmente projetado para tipos desconhecidos ou ainda não inventados de dispositivos, não para classes de dispositivos conhecidas como teclados ou unidades externas.

Portanto, ao contrário dos casos da impressora, GPS e câmera, não consigo pensar em um prompt que informe o usuário sobre o que permitir a uma página de permissão para se conectar a um dispositivo com WebUSB no domínio do conteúdo, sem um profundo compreensão do dispositivo específico e auditoria do código que o está acessando.

Incidente e mitigação de Yubikey

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

Uma vez que este é um problema de segurança que já foi resolvido, eu estava curioso para mergulhar no esforços de mitigação no Chrome 67, que incluem o bloqueio de a conjunto específico de dispositivos e um conjunto específico das aulas .

Lista de Bloqueio de Classe/Dispositivo

Portanto, a defesa real do Chrome contra exploits WebUSB que aconteciam em liberdade, além do prompt de permissão muito geral no momento, era bloquear dispositivos e classes de dispositivos específicos.

Esta pode ser uma solução direta 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.

Temo que as pessoas que inovam em dispositivos educacionais via WebUSB possam chegar a uma situação difícil. No momento em que terminam a prototipagem, 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 dependem dela. 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 razões de segurança ou porque o sistema operacional decide lidar com eles, fazendo com que todo o esforço WebUSB vá para resíduos.

Segurança vs. Recursos

A teoria da adjacência da plataforma, de certa forma, considera os recursos e a segurança 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.

Vejamos o Arduino como exemplo. A comunicação do Arduino é possível com WebUSB e é um principal caso de uso . 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 de usuário). De acordo com as especificações , este fabricante de dispositivo agora tem que “projetar seus dispositivos para aceitar apenas firmware assinado”. Isso pode sobrecarregar os desenvolvedores de firmware e aumentar os custos de desenvolvimento, enquanto todo o propósito da especificação é fazer o oposto.

O que torna o WebUSB diferente de outros periféricos

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

Por exemplo, uma página da web não pode decidir por si mesma 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.

Portanto, mesmo com a especificação WebUSB atual, os dispositivos podem escolher 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, torna-se um keylogger e navega em sites em nome do usuário, com o mecanismo correto de flashing de firmware explorável.

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 do que antes nas versões de 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, conforme mencionado antes, é que o USB (especificamente nos casos de uso WebUSB extra-genéricos) 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 significa.

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

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

Um possível prompt como este seria “Permitir que esta página da web assuma o controle do seu computador”. Não acho que um prompt assustador como este seja benéfico para a comunidade WebUSB, e as mudanças constantes nesses diálogos vão deixar a comunidade confusa.

Prototipagem vs. Produto

Posso ver uma possível exceção para isso. Se a premissa do WebUSB e das outras APIs do Fugu do projeto era 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 ser para prototipagem;
2. Disponibilizar essas APIs somente após algum gesto de aceitação, como permitir que o usuário as habilite manualmente nas configurações do navegador;
3. Tenha avisos de permissão “assustadores”, como os de certificados SSL inválidos.

Não ter os itens 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 participantes do mundo da web que recusam certas APIs por serem prejudiciais também devem ofender e propor maneiras pelas quais elas recursos que são importantes para usuários e desenvolvedores podem ser expostos com segurança. Não represento nenhum jogador importante, mas vou dar uma chance humilde.

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

Solicitação direta e verificada

O caso principal que farei é 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 e específica com um conjunto específico de parâmetros verificados, não para uma ação geral como “assumir” ou “conectar-se a” um dispositivo.

O exemplo de 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 navegador/sistema operacional me pergunte algo semelhante a Permitir que a máscara 3ds do AutoDesk imprima um modelo em sua impressora 3D CreatBot? , será exibida uma caixa de diálogo do navegador/sistema operacional com alguns parâmetros de impressão, como refinamento, espessura e dimensões de saída, e com uma prévia 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 de passagem.

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

• O domínio solicitante tem um certificado registrado para AutoDesk, então há alguma certeza de que este é AutoDesk Inc;
• O periférico solicitado chama a si mesmo de “impressora CreatBot 3d”;
• 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 foi feita.

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

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

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

Além disso, uma capacidade imaginária de impressão 3D totalmente desenvolvida na web faria muito mais do que a WebUSB pode fornecer-por exemplo, colocar em spool e enfileirar diferentes solicitações de impressão. Como isso seria tratado se a janela do navegador fosse fechada? Eu não pesquisei todos os casos de uso de periféricos WebUSB possíveis, mas acho que, ao olhar para eles de uma perspectiva de conteúdo/ação, a maioria precisará de mais do que acesso USB.

Por causa do acima exposto, usar WebUSB para impressão 3D provavelmente será difícil e de curta duração, e os desenvolvedores que dependem dele terão que fornecer um driver “real” para sua impressora em algum momento. For example, if OS vendors decide to add built-in support for 3D printers, all sites using that printer with WebUSB would stop working.

Proposal: Driver Auditing Authority

So, overarching permissions like “take over the peripheral” are problematic, we don’t have enough information in order to show a full-fledged parameter dialog and verify that its results are going to be respected, and we don’t want to send the user on an unsafe trip to download a random executable from the web.

But what if there was an audited piece of code, a driver, that used the WebUSB API internally and did the following:

• Implemented the “print” command;
• Displayed an out-of-page print dialog;
• Connected to a particular set of USB devices;
• Performed some of its actions when the page is in the background (e.g. in a service worker), or even when the browser is closed.

An auditing of a driver like this can make sure that what it does amounts to “printing”, that it respects the parameters, and that it shows the print preview.

I see this as being similar to certificate authorities, an important piece in the web ecosystem that is somewhat disconnected from the browser vendors.

Driver Syndication

The drivers don’t have to be audited by Google/Apple, though the browser/OS vendor can choose to audit drivers on its own. It can work like SSL certificate authorities — the issuer is a highly trusted organization; for example, the manufacturer of the particular peripheral or an organization that certifies many drivers, or a platform like Arduino. (I imagine organizations popping up similar to Let’s Encrypt.)

It might be enough to say to users: “Arduino trusts that this code is going to flash your Uno with this firmware” (with a preview of the firmware).

Caveats

This is of course not free of potential problems:

• The driver itself can be buggy or malicious. But at least it’s audited;
• It’s less “webby” and generates an additional development burden;
• It doesn’t exist today, and cannot be solved by internal innovation in browser engines.

Other Alternatives

Other alternatives could be to somehow standardize and improve the cross-browser Web Extensions API, and make the existing browser add-on stores like Chrome Web Store into somewhat of a driver auditing authority, mediating between user requests and peripheral access.

Summary Of Opinion

The author, Google and partners’ bold efforts to keep the open web relevant by enhancing its capabilities are inspirational.

When I get down to the details, I see Apple and Mozilla’s more conservative view of the web, and their defensive approach to new device capabilities, as carrying technical merit. Core issues with informed consent around open-ended hardware capabilities are far from being solved.

Apple could be more forthcoming in the discussion to find new ways to enable device capabilities, but I believe this comes from a different perspective about computing, a standpoint that was part of Apple’s identity for decades, not from an anti-competitive standpoint.

In order to support things like the somewhat open-ended hardware capabilities in project Fugu, and specifically WebUSB, the trust model of the web needs to evolve beyond permission prompts and domain/device block-lists, drawing inspiration from trust ecosystems like certificate authorities and package distributions.

Further Reading on SmashingMag:

• How Improving Website Performance Can Help Save The Planet
• Towards An Ad-Free Web: Diversifying The Online Economy
• Is There A Future Beyond Writing Great Code?
• Using Ethics In Web Design