Le Web devraitil présenter des capacités matérielles?

À propos de l'auteur

Noam Rosenthal est un consultant indépendant en plate-forme Web, un réviseur WebKit et un contributeur à Chromium et à plusieurs standards Web. Récemment, Noam a…
En savoir plus sur
Noam
…

Je me suis récemment intéressé à la différence d'opinions entre les différents fournisseurs de navigateurs sur l'avenir du Web – en particulier dans les divers efforts visant à rapprocher les capacités des plates-formes Web des plates-formes natives, telles que Chromium Projet Fugu .

Les principales positions peuvent être résumées comme suit:

• Google (avec des partenaires comme Intel, Microsoft et Samsung) fait activement avancer et innove avec une pléthore de nouvelles API comme celles de Fugu, et les expédie dans Chromium;
• Apple repousse avec une approche plus conservatrice, marquant de nombreuses nouvelles API comme soulevant des problèmes de sécurité et de confidentialité ;
• Ceci (avec les restrictions d'Apple sur le choix du navigateur dans iOS ) a créé une position étiquetant Safari comme le nouvel IE tout en affirmant qu'Apple ralentit la progression du Web;
• Mozilla semble plus proche d'Apple que de Google o

Mon intention dans cet article est d'examiner les revendications identifiées avec Google, en particulier celles de la Platform Adjacency Theory du chef du projet Fugu Alex Russell, d'examiner les preuves présentées dans ces affirmations, et peut-être arriver à ma propre conclusion.

Plus précisément, j'ai l'intention de me plonger dans WebUSB (une API controversée du projet Fugu), de vérifier si les revendications de sécurité à son encontre sont fondées et d'essayer de voir si une alternative

The Platform Adjacency Theory

La théorie susmentionnée fait les affirmations suivantes:

• Le logiciel se déplace vers le Web parce que c'est une meilleure version de l'informatique;
• Le Web est une méta-plateforme – une plateforme extraite de son système d'exploitation;
• Le succès d'une méta-plateforme repose sur l'accomplissement de ce que nous attendons de la plupart des ordinateurs;
• Refus d'ajouter des capacités adjacentes à la méta-Web. plate-forme sur la sécurité gro unds, tout en ignorant les mêmes problèmes de sécurité sur les plates-formes natives, finira par rendre le Web de moins en moins pertinent;
• Apple et Mozilla font exactement cela – refusant d'ajouter des capacités de calcul adjacentes au Web, «jetant ainsi le Web en orange ».

Je me rapporte à la passion de l'auteur pour garder le Web ouvert pertinent, et avec la crainte que le fait d'aller trop lentement pour améliorer le Web avec de nouvelles fonctionnalités le rendra inutile. Ceci est renforcé par mon aversion pour les app stores et autres jardins clos . Mais en tant qu'utilisateur, je peux me rapporter à la perspective opposée – j'ai parfois le vertige quand je ne sais pas ce que les sites Web que je navigue sont capables ou non de faire, et je trouve que les restrictions de plate-forme et l'audit sont réconfortants.

Méta-plates-formes

Pour comprendre le terme «méta-plate-forme», j'ai regardé à quoi la théorie utilise ce nom – Java et Flash, deux produits du début du millénaire.

Je trouve déroutant de comparer l'un ou l'autre. Java ou Flash sur le Web. Java et Flash, comme mentionné dans la théorie, étaient largement distribués à l'époque par le biais de plug-ins de navigateur, ce qui en fait davantage un environnement d'exécution alternatif au-dessus de la plate-forme du navigateur. Aujourd'hui, Java est principalement utilisé dans le serveur et dans le cadre de la plate-forme Android, et les deux ne partagent pas grand-chose en commun, sauf le langage.

Aujourd'hui, Java côté serveur est peut-être une méta-plate-forme, et node .js est également un bon exemple de méta-plateforme côté serveur. Il s'agit d'un ensemble d'API, d'un environnement d'exécution multiplateforme et d'un écosystème de packages. En effet, node.js ajoute toujours plus de fonctionnalités, auparavant uniquement possible dans le cadre d'une plate-forme.

Du côté client, Qt un framework multiplateforme basé sur C ++, n'est pas fourni avec un

Il en va de même pour Rust – c'est un langage et un gestionnaire de paquets, mais ne dépend pas des runtimes pré-installés.

Les autres moyens de développer des applications côté client sont principalement spécifiques à la plate-forme, mais incluent également certaines solutions mobiles multiplateformes comme Flutter et Xamarin .

Capabilities vs. Temps

Le graphique principal de la théorie montre la pertinence des méta-plates-formes sur un axe 2D des capacités en fonction du temps:

I can voyez comment le graphique ci-dessus a du sens lorsque vous parlez des cadres de développement multiplateformes mentionnés ci-dessus comme Qt, Xamarin, Flutter et Rust, ainsi que des plates-formes de serveur comme node.js et Java / Scala.

Mais tout ce qui précède a une différence essentielle avec le Web.

The 3rd Dimension

Les méta-plates-formes mentionnées plus tôt sont en effet en concurrence avec leurs OS hôtes dans la course aux capacités, mais contrairement au Web, ils ne sont pas d'avis sur la confiance et la distribution – la 3ème dimension, qui à mon avis fait défaut dans le graphique ci-dessus.

Qt et Rust sont de bons moyens de créer des applications qui sont distribuées via WebAssembly téléchargées et installées directement sur le système d'exploitation hôte, ou administrées via des gestionnaires de paquets comme Cargo ou des distributions Linux comme Ubuntu . React Native Flutter et Xamarin sont tous des moyens décents de créer des applications qui sont distribuées via les magasins d'applications. Les services node.js et Java sont généralement distribués via un conteneur docker une machine virtuelle ou un autre mécanisme de serveur.

Les utilisateurs ne savent généralement pas ce qui a été utilisé pour développer leur contenu, mais ils savent que un certain degré de distribution. Les utilisateurs ne savent pas ce que sont Xamarin et node.js, et si leur application Swift était un jour remplacée par une application Flutter, la plupart des utilisateurs ne s'en soucieraient pas et ne devraient idéalement pas s'en soucier.

Mais les utilisateurs le font. connaissent le Web – ils savent que lorsqu'ils «naviguent» dans Chrome ou Firefox, ils sont «en ligne» et peuvent accéder à des contenus auxquels ils ne font pas nécessairement confiance. Ils savent que le téléchargement de logiciels et leur installation constituent un risque potentiel et peuvent être bloqués par leur administrateur informatique. En fait, il est important pour la plate-forme Web que les utilisateurs sachent qu’ils «naviguent actuellement sur le Web». C'est pourquoi, par exemple, le passage en mode plein écran affiche une invite claire à l'utilisateur, avec des instructions pour y revenir.

Le Web a réussi parce que il n'est pas transparent – mais clairement séparé de son système d'exploitation hôte. Si je ne peux pas faire confiance à mon navigateur pour empêcher les sites Web aléatoires de lire des fichiers sur mon disque dur, je n'irai probablement sur aucun site Web.

Les utilisateurs savent également que leur logiciel informatique est «Windows» ou «Mac» , si leurs téléphones sont basés sur Android ou iOS, et s'ils utilisent actuellement une application (sous iOS ou Android, et sous Mac OS dans une certaine mesure). Le système d'exploitation et le modèle de distribution sont généralement connus de l'utilisateur – l'utilisateur fait confiance à son système d'exploitation et au Web pour faire des choses différentes et à différents degrés de confiance.

Ainsi, le web ne peut pas être comparé à des frameworks de développement multiplateformes, sans prendre en compte son modèle de distribution unique.

D'autre part, les technologies web sont également utilisées pour le développement multiplateforme, avec des frameworks comme Electron et Cordova . Mais ce ne sont pas exactement «le Web». Par rapport à Java ou node.js, le terme «Web» doit être remplacé par «Web Technologies». Et les "technologies Web" utilisées de cette manière ne doivent pas nécessairement être standard ou fonctionner sur plusieurs navigateurs. La conversation sur les API Fugu est quelque peu tangentielle à Electron et Cordova.

Native Apps

Lors de l'ajout de fonctionnalités à la plate-forme Web, la troisième dimension – le modèle de confiance et de distribution – ne peut être ignorée ni prise à la légère. Lorsque l'auteur prétend que «Apple et Mozilla postulant sur les risques liés aux nouvelles capacités sont démentis par les risques de plate-forme native existants acceptés» il met le Web et les plates-formes natives dans la même dimension en ce qui concerne la confiance. [19659005] Certes, les applications natives ont leurs propres problèmes de sécurité et défis. Mais je ne vois pas en quoi c'est un argument en faveur de davantage de capacités Web, comme ici . C'est une erreur – la conclusion devrait être de résoudre les problèmes de sécurité avec les applications natives, et non d'assouplir la sécurité des applications Web, car elles sont dans un jeu de rattrapage de pertinence avec des capacités du système d'exploitation.

Le natif et le Web ne peuvent pas être comparés en termes de capacités. , sans prendre en compte la 3ème dimension de la confiance et du modèle de distribution.

Limitations de l'App Store

L'une des critiques sur les applications natives dans la théorie concerne le manque de choix de moteur de navigateur sur iOS. C'est un fil conducteur des critiques contre Apple, mais il y a plus d'une perspective à cela.

La critique porte spécifiquement sur Item 2.5.6 des directives de révision de l'App Store d'Apple:

«Apps qui naviguent sur le Web doivent utiliser le framework WebKit et WebKit JavaScript appropriés. »

Cela peut sembler anticoncurrentiel, et j'ai ma propre réserve sur le caractère restrictif d'iOS. Mais l'élément 2.5.6 ne peut pas être lu sans le contexte du reste des directives d'examen de l'App Store, par exemple Item 2.3.12 :

«Les applications doivent décrire clairement les nouvelles fonctionnalités et les changements de produit dans leur Texte «Quoi de neuf». »

Si une application pouvait recevoir des autorisations d'accès aux appareils, puis inclure son propre cadre capable d'exécuter du code à partir de n'importe quel site Web, ces éléments des directives d'examen de l'App Store perdraient tout leur sens. Contrairement aux applications, les sites Web n'ont pas à décrire leurs fonctionnalités et les modifications apportées au produit à chaque révision.

Cela devient un problème encore plus grave lorsque les navigateurs proposent des fonctionnalités expérimentales, comme celles du projet Fugu, qui ne sont pas encore considérées comme une norme. Qui définit ce qu'est un navigateur? En autorisant les applications à expédier n'importe quel framework Web, l'App Store permettrait essentiellement à «l'application» d'exécuter tout code non audité, ou de modifier complètement le produit, contournant le processus d'examen de la boutique.

En tant qu'utilisateur de sites Web et d'applications, Je pense que les deux ont de la place dans le monde informatique, même si j'espère que le plus possible pourra passer au Web. Mais si l'on considère l'état actuel des normes Web et comment la dimension de confiance et de sandboxing autour de choses comme Bluetooth et USB est loin d'être résolue, je ne vois pas comment autoriser les applications à exécuter librement du contenu à partir du Web serait bénéfique pour les utilisateurs. .

The Pursuit Of Appiness

Dans un autre article de blog connexe le même auteur aborde certains de ces problèmes, en parlant d'applications natives:

«Être 'une application', c'est simplement rencontrer un ensemble de conventions de système d'exploitation arbitraires et modifiables. »

Je suis d'accord avec l'idée que la définition de« application »est arbitraire et que sa définition dépend de celui qui définit les politiques de l'App Store. Mais aujourd'hui, il en va de même pour les navigateurs. L'affirmation du post selon laquelle les applications Web sont sûres par défaut est également quelque peu arbitraire. Qui trace la ligne dans le sable de «qu'est-ce qu'un navigateur»? L'application Facebook avec un navigateur intégré est-elle «un navigateur»?

La définition d'une application est arbitraire, mais également importante. Le fait que chaque révision d'une application utilisant des capacités de bas niveau soit vérifiée par quelqu'un en qui je pourrais avoir confiance, même si cette personne est arbitraire, fait des applications ce qu'elles sont. Si ce quelqu'un est le fabricant du matériel pour lequel j'ai payé, cela rend les choses encore moins arbitraires – la société à laquelle j'ai acheté mon ordinateur est celle qui vérifie les logiciels avec des capacités moindres pour cet ordinateur.

Tout peut être un navigateur

Sans tracer une ligne de «qu'est-ce qu'un navigateur», ce que fait essentiellement l'App Store d'Apple, chaque application pourrait embarquer son propre moteur Web, inciter l'utilisateur à naviguer vers n'importe quel site Web en utilisant son navigateur intégré à l'application, et ajoutez le code de suivi de votre choix, réduisant ainsi la différence de 3ème dimension entre les applications et les sites Web.

Lorsque j'utilise une application sur iOS, je sais que mes actions sont actuellement exposées à deux joueurs: Apple et l'identité fabricant de l'application. Lorsque j'utilise un site Web sur Safari ou dans Safari WebView, mes actions sont exposées à Apple et au propriétaire du domaine de premier niveau du site Web que je consulte actuellement. Lorsque j'utilise un navigateur intégré à une application avec un moteur non identifié, je suis exposé à Apple, le fabricant de l'application, et au propriétaire du domaine de premier niveau. Cela peut créer des violations évitables de même origine, telles que le propriétaire de l'application qui suit tous mes clics sur des sites Web étrangers.

Je conviens que la ligne dans le sable de "Only WebKit" est peut-être trop sévère. Quelle serait une autre définition d’un navigateur qui ne créerait pas de porte dérobée pour suivre la navigation des utilisateurs?

Autre critique à propos d’Apple

La théorie prétend que le refus d’Apple d’implémenter des fonctionnalités ne se limite pas à des problèmes de confidentialité / sécurité. Il inclut un lien qui montre en effet de nombreuses fonctionnalités implémentées dans Chrome et non dans Safari. Cependant, en faisant défiler vers le bas, il répertorie également un nombre considérable d'autres fonctionnalités qui sont implémentées dans Safari et non dans Chrome.

Ces deux projets de navigateur ont des priorités différentes, mais c'est loin d'être la déclaration catégorique «Le jeu devient clair lors du zoom arrière » et de la critique sévère d'Apple essayant de lancer le Web en orange.

De plus, les liens intitulés c'est difficile et nous ne voulons pas essayer mènent à Apple déclare qu'ils implémenteraient des fonctionnalités si les problèmes de sécurité / confidentialité étaient satisfaits. J'estime que mettre ces liens avec ces titres est trompeur.

Je serais d'accord avec une déclaration plus équilibrée, à savoir que Google est beaucoup plus optimiste que Apple en ce qui concerne la mise en œuvre de fonctionnalités et l'avancement du Web.

Permission Prompt

Google va longtemps des voies innovantes dans la 3ème dimension, développant de nouvelles façons de négocier la confiance entre l'utilisateur, le développeur et la plate-forme, parfois avec beaucoup de succès, comme dans le cas de Trusted Web Activities .

Mais quand même , la plupart des travaux de la 3ème dimension en ce qui concerne les API de périphériques se concentrent sur les invites d'autorisation et les rendant plus effrayants ou des choses comme les autorisations de boîte de temps et les domaines bloqués.

Les invites «effrayantes», comme celles de cet exemple que nous voyons de temps en temps, semblent être destinées à décourager les gens d'accéder à des pages qui semblent potentiellement malveillantes. Parce qu'ils sont si flagrants, ces avertissements encouragent les développeurs à passer à des API plus sûres et à renouveler leurs certificats.

Je souhaite que, pour les capacités d'accès aux appareils, nous puissions proposer des invites qui encouragent l'engagement et garantissent la sécurité de l'engagement, plutôt que de le décourager et de transférer la responsabilité à l'utilisateur, sans remédiation disponible pour le développeur Web.

Je suis d'accord avec l'argument selon lequel Mozilla et Apple devraient au moins essayer d'innover dans cet espace plutôt que de «refuser de mettre en œuvre». Mais peut-être qu'ils le sont? Je pense que isLoggedIn d'Apple, par exemple, est une proposition intéressante et pertinente dans la 3ème dimension sur laquelle les futures API de périphérique pourraient s'appuyer – par exemple, les API de périphérique qui sont sujettes aux empreintes digitales peuvent être rendues disponibles lorsque le courant Le site Web connaît déjà l'identité de l'utilisateur.

WebUSB

Dans la section suivante, je vais plonger dans WebUSB, vérifier ce qu'il permet et comment il est géré dans la 3ème dimension – quel est le modèle de confiance et de distribution? Est-il suffisant? Quelles sont les alternatives?

The Premise

Le WebUSB API permet un accès complet au protocole USB pour les classes de périphériques qui ne sont pas block-listées .

It peut réaliser des choses puissantes comme la connexion à une carte Arduino ou le débogage et un téléphone Android .

C'est excitant de voir les vidéos de Suz Hinton sur la façon dont cette API peut vous aider réaliser des choses qui coûtaient très cher auparavant.

Je souhaite vraiment que les plates-formes trouvent des moyens d'être plus ouvertes et de permettre des itérations rapides sur des projets matériels / logiciels éducatifs, par exemple.

Funny Feeling

Mais quand même, je j'ai une drôle de sensation quand je regarde ce que WebUSB permet et les problèmes de sécurité existants avec l'USB en général.

L'USB me semble trop puissant en tant que protocole exposé au Web, même avec des invites d'autorisation.

] J'ai donc cherché plus loin.

Le point de vue officiel de Mozilla

Je commence ed en lisant ce que David Baron avait à dire sur les raisons pour lesquelles Mozilla a fini par rejeter WebUSB, dans la position officielle de Mozilla sur les normes :

«Parce que de nombreux périphériques USB ne sont pas conçus pour gérer potentiellement – les interactions malveillantes via les protocoles USB et parce que ces périphériques peuvent avoir des effets significatifs sur l'ordinateur auquel ils sont connectés, nous pensons que les risques de sécurité liés à l'exposition de périphériques USB au Web sont trop importants pour risquer d'y exposer les utilisateurs ou de les expliquer correctement. les utilisateurs finaux pour obtenir un consentement éclairé significatif. »

L'invite d'autorisation actuelle

Voici à quoi ressemble l'invite d'autorisation WebUSB de Chrome au moment de la publication de ce message:

Domaine particulier Foo veut se connecter à une barre de périphérique particulière. Pour faire quoi? et comment puis-je en être sûr?

Lors de l'octroi de l'accès à l'imprimante, à l'appareil photo, au microphone, GPS ou même à quelques-uns des profils plus contenus WebBluetooth GATT comme surveillance de la fréquence cardiaque cette question est relativement claire et se concentre sur le contenu ou l'action plutôt que sur le dispositif . Il y a une compréhension claire des informations que je veux du périphérique ou de l'action que je veux effectuer avec lui, et l'agent utilisateur intervient et s'assure que cette action particulière est gérée.

USB Is Generic

Contrairement au appareils mentionnés ci-dessus qui sont exposés via des API spéciales, l'USB n'est pas spécifique au contenu. Comme mentionné dans l'introduction de la spécification WebUSB va plus loin et est intentionnellement conçu pour des types d'appareils inconnus ou pas encore inventés, pas pour des classes d'appareils bien connues comme les claviers ou les disques externes.

Ainsi, contrairement aux cas de l'imprimante, du GPS et de l'appareil photo, je ne peux pas penser à une invite qui informerait l'utilisateur de ce que l'octroi d'une autorisation de page à se connecter à un appareil avec WebUSB permettrait dans le domaine du contenu, sans une compréhension approfondie du

L'incident et l'atténuation de Yubikey

Un bon exemple d'il n'y a pas si longtemps est l'incident Yubikey où le WebUSB de Chrome a été utilisé pour hameçonner les données d'un Dispositif d'authentification alimenté par USB.

Puisqu'il s'agit d'un problème de sécurité qui est censé être résolu, j'étais curieux de plonger dans les efforts d'atténuation de Chrome dans Chrome 67, qui incluent le blocage d'un ensemble spécifique des dispositifs et un ensemble spécifique de classes .

Class / Device Block-List

Donc, la défense réelle de Chrome contre les exploits WebUSB qui se sont produits dans la nature, en plus de l'invite d'autorisation actuellement très générale, était de bloquer des

Cela peut être une solution simple pour une nouvelle technologie ou une nouvelle expérience, mais cela deviendra de plus en plus difficile à réaliser lorsque (et si) WebUSB devient plus populaire.

J'ai peur que les gens innovent sur les appareils éducatifs via WebUSB pourrait atteindre une situation difficile. Au moment où ils auront terminé le prototypage, ils pourraient être confrontés à un ensemble de listes de blocage non standard en constante évolution, qui ne se mettent à jour qu'avec les versions de navigateur, basées sur des problèmes de sécurité qui n'ont rien à voir avec elles.

Je pense que la standardisation de cette API sans aborder cela finira par être contre-productive pour les développeurs qui s'y fondent. Par exemple, quelqu'un pourrait passer des cycles à développer une application WebUSB pour les détecteurs de mouvement, pour découvrir plus tard que les détecteurs de mouvement deviennent une classe bloquée, soit pour des raisons de sécurité, soit parce que le système d'exploitation décide de les gérer, provoquant ainsi tout l'effort WebUSB.

Sécurité contre fonctionnalités

La théorie de la contiguïté des plates-formes, à certains égards, considère que les capacités et la sécurité sont un jeu à somme nulle, et qu'être trop prudent en matière de sécurité et de confidentialité ferait perdre aux plates-formes leur pertinence

Prenons Arduino comme exemple. La communication Arduino est possible avec WebUSB et constitue un cas d'utilisation majeur . Quelqu'un qui développe un appareil Arduino devra désormais envisager un nouveau scénario de menace, dans lequel un site tente d'accéder à son appareil en utilisant WebUSB (avec une autorisation de l'utilisateur). Conformément à la spécification ce fabricant de périphériques doit désormais «concevoir ses périphériques pour n'accepter que les micrologiciels signés». Cela peut alourdir les développeurs de microprogrammes et augmenter les coûts de développement, alors que le but même de la spécification est de faire le contraire.

Qu'est-ce qui différencie WebUSB des autres périphériques

Dans les navigateurs, il existe une distinction claire entre les interactions des utilisateurs. et les interactions synthétiques (interactions instanciées par la page Web).

Par exemple, une page Web ne peut pas décider seule de cliquer sur un lien ou de réactiver le processeur / l'affichage. Mais les périphériques externes peuvent – par exemple, une souris peut cliquer sur un lien au nom de l'utilisateur et presque tous les périphériques USB peuvent réveiller le processeur, selon le système d'exploitation.

Ainsi, même avec la spécification WebUSB actuelle, les périphériques peuvent choisir pour implémenter plusieurs interfaces, par ex. debug pour adb et HID pour l'entrée de pointeur, et en utilisant un code malveillant qui tire parti d'ADB, devenez un keylogger et parcourez des sites Web au nom de l'utilisateur, étant donné le bon mécanisme de clignotement du micrologiciel exploitable .

L'ajout de cet appareil à une liste de blocage serait trop tardif pour les appareils dont le micrologiciel a été compromis à l'aide d'ADB ou d'autres formes autorisées de clignotement, et rendrait les fabricants d'appareils encore plus dépendants des versions de navigateur pour les correctifs de sécurité associés à leurs appareils

Consentement éclairé et contenu

Le problème avec le consentement éclairé et l'USB, comme mentionné précédemment, est que l'USB (en particulier dans les cas d'utilisation WebUSB extra-génériques) n'est pas spécifique au contenu. Les utilisateurs savent ce qu'est une imprimante, ce qu'est un appareil photo, mais «USB» pour la plupart des utilisateurs est simplement un câble (ou une prise) – un moyen pour atteindre une fin – très peu d'utilisateurs savent que l'USB est un protocole et ce qui le permet entre les sites Web

Une suggestion était d'avoir une invite «effrayante», quelque chose du genre «Autoriser cette page Web à prendre le contrôle de l'appareil» (ce qui est une amélioration par rapport aux «veut se connecter» apparemment inoffensifs).

Mais aussi effrayantes que soient les invites, elles ne peuvent pas expliquer l'ampleur des choses possibles qui peuvent être faites avec un accès brut à un périphérique USB que le navigateur ne connaît pas intimement, et si elles le faisaient, aucun utilisateur sain d'esprit ne le ferait cliquez sur "Oui", à moins qu'il ne s'agisse d'un appareil dont ils ont pleinement confiance pour être exempt de bogues et d'un site Web en qui ils ont vraiment confiance pour être à jour et non malveillant.

Une invite possible comme celle-ci indiquerait "Autoriser cette page Web pour potentiellement prendre le contrôle de votre ordinateur ». Je ne pense pas qu'une invite effrayante comme celle-ci serait bénéfique pour la communauté WebUSB, et des changements constants dans ces dialogues la laisseront perplexe.

Prototyping vs. Product

Je peux voir une exception possible à cela . Si le principe de WebUSB et des autres API du projet Fugu était de prendre en charge le prototypage plutôt que les périphériques de qualité produit, des invites génériques globales pourraient avoir un sens.

Pour rendre cela viable, cependant, je pense que ce qui suit doit se produire:

1. Utilisez un langage dans les spécifications qui définissent les attentes à ce sujet pour le prototypage;
2. N'ayez ces API disponibles qu'après un geste d'activation, comme si l'utilisateur les activait manuellement dans les paramètres du navigateur;
3. Have "effrayant », Comme celles pour les certificats SSL invalides.

Ne pas avoir ce qui précède me fait penser que ces API sont pour de vrais produits plutôt que pour des prototypes, et en tant que tels, les commentaires sont valables.

An Alternative Proposal [19659003] L’une des parties du billet de blog original avec laquelle je suis d’accord est qu’il ne suffit pas de dire «non» – les principaux acteurs du Web qui refusent certaines API parce qu’elles sont nuisibles devraient également être offensés et proposer des moyens par lesquels ces capacités tapis ter aux utilisateurs et aux développeurs peuvent être exposés en toute sécurité. Je ne représente aucun acteur majeur, mais je vais essayer humblement.

Je crois que la réponse à cela réside dans la 3ème dimension de la confiance et de la relation, et que cela sort du cadre des invites d'autorisation et des listes de blocage.

Invite simple et vérifiée

Le principal argument que je vais faire valoir est que l'invite doit concerner le contenu ou l'action, et non le périphérique, et que le consentement éclairé peut être accordé pour une action simple et spécifique avec un ensemble spécifique de paramètres vérifiés, pas pour une action générale comme «prendre le contrôle» ou «se connecter à» un appareil.

L'exemple d'imprimante 3D

Dans la spécification WebUSB , Les imprimantes 3D sont présentées à titre d'exemple, je vais donc les utiliser ici.

Lors du développement d'une application WebUSB pour une imprimante 3D, je veux que l'invite du navigateur / du système d'exploitation me demande quelque chose du genre Autoriser AutoDesk 3ds-mask à imprimer un modèle sur votre imprimante 3D CreatBot? afficher un navigateur / Boîte de dialogue du système d'exploitation avec certains paramètres d'impression, tels que le raffinement, l'épaisseur et les dimensions de sortie, et avec un aperçu de ce qui va être imprimé. Tous ces paramètres doivent être vérifiés par un agent utilisateur de confiance, et non par une page Web au volant.

Actuellement, le navigateur ne connaît pas l'imprimante et il ne peut vérifier que certaines des revendications de l'invite: [19659006] Le domaine demandeur a un certificat enregistré dans AutoDesk, il y a donc une certaine certitude qu'il s'agit d'AutoDesk Inc;

Mais pour afficher une invite véridique et dialoguer avec les détails ci-dessus, le navigateur aurait également doivent vérifier ce qui suit:

• Lorsque l'autorisation est accordée, l'action effectuée sera l'impression d'un modèle 3D, et rien d'autre que cela;
• Les paramètres sélectionnés (raffinement / épaisseur / dimensions etc.) vont être respectés;
• Un aperçu vérifié de ce qui va être imprimé a été montré à u ser;
• Dans certains cas sensibles, une vérification supplémentaire qu'il s'agit bien d'AutoDesk, peut-être avec quelque chose comme un jeton révocable de courte durée.

Sans vérifier ce qui précède, un site Web qui a reçu l'autorisation de se «connecter» ou «prendre le contrôle» d'une imprimante 3D peut commencer à imprimer d'énormes modèles 3D en raison d'un bogue (ou d'un code malveillant dans l'une de ses dépendances).

En outre, une capacité d'impression 3D Web imaginée à part entière ferait beaucoup plus que ce que WebUSB peut fournir, par exemple, la mise en file d'attente et la mise en file d'attente de différentes demandes d'impression. Comment cela serait-il géré si la fenêtre du navigateur était fermée? Je n'ai pas recherché tous les cas d'utilisation possibles des périphériques WebUSB, mais je suppose que lorsque je les regarde du point de vue du contenu / action, la plupart auront besoin de plus qu'un accès USB.

En raison de ce qui précède, utiliser WebUSB pour L'impression 3D sera probablement piratée et de courte durée, et les développeurs qui s'y fondent devront fournir un «vrai» pilote pour leur imprimante à un moment donné. Par exemple, si les fournisseurs de systèmes d'exploitation décident d'ajouter la prise en charge intégrée des imprimantes 3D, tous les sites utilisant cette imprimante avec WebUSB cesseraient de fonctionner.

Proposition: Driver Auditing Authority

Donc, des autorisations globales telles que «prendre le contrôle du périphérique» sont problématiques, nous n'avons pas suffisamment d'informations pour afficher une boîte de dialogue de paramètres à part entière et vérifier que ses résultats vont être respectés, et nous ne voulons pas envoyer l'utilisateur dans un voyage dangereux pour télécharger un exécutable aléatoire

Mais que se passerait-il s'il y avait un morceau de code audité un pilote, qui utilisait l'API WebUSB en interne et faisait ce qui suit:

• Implémentation de la commande «print»; [19659007] Affiche une boîte de dialogue d'impression hors page;
• Connecté à un ensemble particulier de périphériques USB;
• A effectué certaines de ses actions lorsque la page est en arrière-plan (par exemple dans un technicien de maintenance), ou même lorsque le le navigateur est fermé.

Un audit d'un pilote comme celui-ci peut garantir que ce que je t revient à «imprimer», à respecter les paramètres et à afficher l'aperçu avant impression.

Je vois cela comme étant similaire aux autorités de certification un élément important de l'écosystème web qui est quelque peu déconnecté des fournisseurs de navigateurs.

Syndication des pilotes

Les pilotes n'ont pas besoin d'être audités par Google / Apple, bien que le fournisseur du navigateur / système d'exploitation puisse choisir d'auditer les pilotes par lui-même. Cela peut fonctionner comme les autorités de certification SSL – l'émetteur est une organisation hautement fiable; par exemple, le fabricant du périphérique particulier ou une organisation qui certifie de nombreux pilotes, ou une plate-forme comme Arduino. (J'imagine que des organisations apparaissent comme Let's Encrypt .)

Il suffira peut-être de dire aux utilisateurs: «Arduino est convaincu que ce code va flasher votre Uno avec ceci 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:

(ra, yk, il)