Catégories
Plugin et site web

Le Web devrait-il présenter des capacités matérielles? – Magazine Smashing

A propos de l'auteur

Noam Rosenthal est un consultant indépendant en plateforme Web, un réviseur WebKit et un contributeur à Chromium et à plusieurs standards Web. Récemment, Noam a…
Plus à propos
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 différents efforts visant à rapprocher les capacités de la plate-forme Web des plates-formes natives, comme le projet Fugu de Chromium.

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

  • Google (en collaboration avec des partenaires comme Intel, Microsoft et Samsung) fait activement progresser et innove avec une pléthore de nouvelles API comme celles de Fugu, et les livre 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 à ce sujet.

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

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

La théorie de l'adjacence de la plateforme

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

  • Les logiciels migrent 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 le fait qu'elle accomplit les choses que nous attendons de la plupart des ordinateurs;
  • Refuser d'ajouter des capacités adjacentes à la méta-plate-forme Web pour des raisons de sécurité, tout en ignorant les mêmes problèmes de sécurité dans les plates-formes natives, finira par rendre le Web de moins en moins pertinent;
  • C'est exactement ce que font Apple et Mozilla – refusant d'ajouter des capacités de calcul adjacentes au Web, «jetant ainsi le Web en orange».

Je suis en relation avec la passion de l’auteur pour la pertinence du Web ouvert, et avec la crainte que l’amélioration trop lente du Web avec de nouvelles fonctionnalités ne le rende inutile. Ceci est augmenté par mon aversion pour les app stores et autres jardins clos. Mais en tant qu'utilisateur, je peux m'identifier au point de vue opposé: je suis parfois étourdi lorsque je ne sais pas quels sites Web je navigue sont capables ou non de faire, et je trouve que les restrictions de plate-forme et les audits sont réconfortants.

Méta-plateformes

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

Je trouve déroutant de comparer Java ou Flash au 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, à l'exception du langage.

Aujourd'hui, Java côté serveur est peut-être une méta-plateforme, 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 plateforme.

Du côté client, Qt, un framework multiplateforme basé sur C ++, ne vient pas avec un runtime séparé, c'est simplement une (bonne!) Bibliothèque multiplateforme pour le développement d'interface utilisateur.

Il en va de même pour Rust: il s’agit d’un langage et d’un gestionnaire de packages, mais ne dépend pas des environnements d’exécution 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 telles que Flutter et Xamarin.

Capacités vs temps

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

L'écart de pertinence
Crédit d'image: Alex Russell

Je peux voir à quel point le graphique ci-dessus a du sens quand on parle des frameworks de développement multiplateformes mentionnés ci-dessus comme Qt, Xamarin, Flutter et Rust, ainsi que des plates-formes serveur comme node.js et Java / Scala.

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

La 3e dimension

Les méta-plates-formes mentionnées précédemment sont en effet en concurrence avec leurs OS hôtes dans la course aux capacités, mais contrairement au Web, elles ne sont pas d'avis confiance et Distribution – la 3ème dimension, qui à mon avis manque 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 distribuées via des 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 serveur.

Les utilisateurs ne savent généralement pas ce qui a été utilisé pour développer leur contenu, mais sont conscients dans une certaine mesure de la façon dont il est distribué. 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 faire 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 sur la façon de revenir en arrière.

Le web est devenu un succès car 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», que leurs téléphones sont basés sur Android ou iOS et s'ils utilisent actuellement un app (sur iOS ou Android, et sur Mac OS dans une certaine mesure). le OS 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.

Applications natives

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 ni ignorée ni prise à la légère. Lorsque l'auteur affirme que «Apple et Mozilla se plaignent des 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 plateformes natives dans la même dimension en matière de confiance.

Certes, les applications natives ont leurs propres problèmes et défis de sécurité. Mais je ne vois pas en quoi c'est un argument en faveur de davantage de fonctionnalité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 être comparés en termes de capacités, sans prendre en compte la 3ème dimension du modèle de confiance et de distribution.

Limitations de l'App Store

L'une des critiques concernant les applications natives dans la théorie est 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 l'article 2.5.6 des consignes de révision de l'App Store d'Apple:

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

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

"Les applications doivent décrire clairement les nouvelles fonctionnalités et les modifications apportées au 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 aux produits à chaque révision.

Cela devient un problème encore plus important lorsque les navigateurs proposent des fonctionnalités expérimentales, comme celles du projet Fugu, qui ne sont pas encore considérées comme un standard. 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 à la fois 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. .

La poursuite de l'apaisement

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

"Être" une application ", c'est simplement respecter 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. La réclamation du poste qui les applications Web sont sécurisées 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 fonctionnalités de bas niveau est auditée par Quelqu'un que 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 le rend encore moins arbitraire – la société à laquelle j’ai acheté mon ordinateur est le seul logiciel d’audit dont les capacités sont inférieures à 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 fournir son propre moteur Web, inciter l'utilisateur à naviguer sur n'importe quel site Web à l'aide de son navigateur intégré et ajouter le code de suivi. il veut, réduisant 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 le fabricant de l'application identifié. 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 peut-être la ligne dans le sable de "Only WebKit" est trop dure. 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?

Autres critiques sur Apple

La théorie prétend que le refus d’Apple de mettre en œuvre des fonctionnalités ne se limite pas aux problèmes de confidentialité / sécurité. Il comprend un lien, qui montre en effet de nombreuses fonctionnalités implémentées dans Chrome et non dans Safari. Cependant, lors du défilement vers le bas, il répertorie également un nombre important d'autres fonctionnalités implémentées dans Safari et non dans Chrome.

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

En outre, les liens intitulés c'est difficile et nous ne voulons pas essayer conduire à Apple déclarations qu'ils mettraient en œuvre des fonctionnalités si les problèmes de sécurité / confidentialité étaient satisfaits. Je pense que mettre ces liens avec ces titres est trompeur.

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

Invite d'autorisation

Google va très loin dans l'innovation dans la 3ème dimension, développant de nouvelles façons de susciter la confiance entre l'utilisateur, le développeur et la plateforme, parfois avec beaucoup de succès, comme dans le cas des activités Web de confiance.

Mais encore, la plupart des travaux de la 3ème dimension en ce qui concerne les API des appareils se concentrent sur les invites d'autorisation et les rendant plus effrayants, ou des choses comme les octrois d'autorisations temporelles 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 utilisateurs 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 que l'engagement est sûr, plutôt que de le décourager et de transférer la responsabilité à l'utilisateur, sans remédiation disponible pour le développeur Web. Plus à ce sujet plus tard.

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 site Web actuel 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?

La prémisse

L'API WebUSB permet un accès complet au protocole USB pour les classes de périphériques qui ne sont pas répertoriées dans la liste des blocs.

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

Il est passionnant de voir les vidéos de Suz Hinton sur la façon dont cette API peut aider à réaliser des choses qui étaient très coûteuses 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.

Drôle de sensation

Mais quand même, 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 semble trop puissant en tant que protocole exposé au Web, même avec des invites d'autorisation.

J'ai donc cherché plus loin.

Vue officielle de Mozilla

J'ai commencé par lire ce que David Baron avait à dire sur les raisons pour lesquelles Mozilla a fini par rejeter WebUSB, dans la position des standards officiels de Mozilla:

«Étant donné que de nombreux périphériques USB ne sont pas conçus pour gérer des interactions potentiellement malveillantes via les protocoles USB et que ces périphériques peuvent avoir des effets importants 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 le sont également. large au risque d'exposer les utilisateurs à eux ou d'expliquer correctement aux 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:

Invite d'autorisation
Invite d'autorisation. (Grand aperçu)

Un domaine particulier Foo souhaite se connecter à une barre de périphérique particulière. Pour faire quoi? et comment puis-je savoir avec certitude?

Lorsque vous accordez l'accès à l'imprimante, à l'appareil photo, au microphone, au GPS ou même à quelques-uns des profils WebBluetooth GATT les plus contenus comme la surveillance de la fréquence cardiaque, cette question est relativement claire et se concentre sur le contenu ou 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.

L'USB est générique

Contrairement aux 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 appareil particulier et auditer le code qui y accède.

L'incident et l'atténuation de Yubikey

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

Puisqu'il s'agit d'un problème de sécurité que l'on dit résolu, j'étais curieux de me plonger dans les efforts d'atténuation de Chrome dans Chrome 67, qui incluent le blocage d'un ensemble spécifique d'appareils et d'un ensemble spécifique de classes.

Liste de blocage de classe / appareil

Ainsi, la véritable défense 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, consistait à bloquer des appareils et des classes d'appareils spécifiques.

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.

Je crains que les personnes qui innovent sur des appareils éducatifs via WebUSB ne se retrouvent dans 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, en fonction de 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 en dépendent. 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. déchets.

Sécurité vs fonctionnalités

La théorie de la contiguïté des plates-formes, à certains égards, considère les capacités et la sécurité comme un jeu à somme nulle, et le fait d'être trop prudent sur les problèmes 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 aux spécifications, 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 la charge des développeurs de micrologiciels et augmenter les coûts de développement, tandis que l'objectif principal 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 utilisateur 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'écran. 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 appareils peuvent choisir d'implémenter plusieurs interfaces, par ex. debug pour adb et HID pour l'entrée du pointeur, et en utilisant un code malveillant qui tire parti d'ADB, devenez un keylogger et parcourez les 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 qu'avant des versions de navigateur pour les correctifs de sécurité associés à leurs appareils.

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 et dispositifs moyens.

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

Mais aussi effrayantes que soient les invites, elles ne peuvent pas expliquer l'étendue 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 cliquerait 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 serait «Autoriser cette page Web à 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 laisseront la communauté confuse.

Prototypage vs produit

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 appareils de qualité produit, des invites génériques globales pourraient avoir du 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. Avoir ces API disponibles uniquement après un geste d'acceptation, comme demander à l'utilisateur de les activer manuellement dans les paramètres du navigateur;
  3. Avoir des invites d'autorisation «effrayantes», comme celles des certificats SSL non valides.

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.

Une proposition alternative

L'une des parties de l'article de blog original avec laquelle je suis d'accord est qu'il ne suffit pas de dire «non» – les principaux acteurs du monde du Web qui refusent certaines API parce qu'elles sont nuisibles devraient également jouer l'offensive et proposer des moyens par lesquels ces capacités sont importantes 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 modestement.

Je pense que la réponse à cela réside dans la troisième dimension de la confiance et des relations, et qu’elle sort du cadre des invites d’autorisation et des listes de blocage.

Invite simple et vérifiée

Le cas principal 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 spécifique avec un ensemble spécifique de paramètres vérifiés, pas pour un 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 l'utiliser ici.

Lors du développement d'une application WebUSB pour une imprimante 3D, je souhaite 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?, affiche une boîte de dialogue de navigateur / 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 ne peut vérifier que certaines des revendications de l'invite:

  • Le domaine demandeur a un certificat enregistré sur AutoDesk, il y a donc une certaine certitude qu'il s'agit d'AutoDesk Inc;
  • Le périphérique demandé s'appelle lui-même «imprimante 3D CreatBot»;
  • Cet appareil, cette classe d’appareil et ce domaine ne figurent pas dans les listes de blocage du navigateur.
  • L'utilisateur a répondu «Oui» ou «Non» à une question générale qui lui avait été posée.

Mais pour afficher une invite et un dialogue véridiques avec les détails ci-dessus, le navigateur devrait également vérifier les éléments suivants:

  • 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é à l'utilisateur;
  • Dans certains cas sensibles, une vérification supplémentaire qu'il s'agit en fait 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 obtenu l'autorisation de «se connecter à» ou de «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 j’imagine que lorsque nous les examinons 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, l'utilisation de WebUSB pour l'impression 3D sera probablement piratée et de courte durée, et les développeurs qui s'y fient devront fournir un pilote «réel» 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 cesseront de fonctionner.

Proposition: autorité d'audit des chauffeurs

Ainsi, les 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 lors d'un voyage dangereux pour télécharger un exécutable aléatoire à partir du Web.

Mais que se passerait-il s'il y avait un vérifié morceau de code, un pilote, qui utilisait l'API WebUSB en interne et effectuait les opérations suivantes:

  • Implémentation de la commande «print»;
  • Affichage d'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 service worker), ou même lorsque le navigateur est fermé.

Un audit d'un pilote comme celui-ci peut s'assurer que ce qu'il fait équivaut à «imprimer», qu'il respecte les paramètres et qu'il affiche 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 du conducteur

Les pilotes n'ont pas besoin d'être audités par Google / Apple, bien que le fournisseur du navigateur / du système d'exploitation puisse choisir d'auditer les pilotes 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 similaires à Let’s Encrypt.)

Il suffira peut-être de dire aux utilisateurs: «Arduino est convaincu que ce code va flasher votre Uno avec ce firmware ”(avec un aperçu du firmware).

Mises en garde

Ceci n'est bien sûr pas exempt de problèmes potentiels:

  • Le pilote lui-même peut être bogué ou malveillant. Mais au moins, il est audité;
  • Il est moins «Webby» et génère une charge de développement supplémentaire;
  • Il n’existe pas aujourd’hui et ne peut pas être résolu par l’innovation interne des moteurs de navigateur.

Autres alternatives

D'autres alternatives pourraient être de normaliser et d'améliorer en quelque sorte l'API des extensions Web inter-navigateurs, et de faire des magasins de modules complémentaires de navigateur existants comme Chrome Web Store une sorte d'autorité d'audit des pilotes, assurant la médiation entre les demandes des utilisateurs et l'accès aux périphériques.

Résumé de l'opinion

Les efforts audacieux de l'auteur, de Google et de ses partenaires pour maintenir la pertinence du Web ouvert en améliorant ses capacités sont inspirants.

Quand je vais dans les détails, je vois la vision plus conservatrice du Web d'Apple et de Mozilla, ainsi que leur approche défensive des nouvelles capacités des appareils, comme ayant un mérite technique. Les problèmes fondamentaux liés au consentement éclairé concernant les capacités matérielles ouvertes sont loin d'être résolus.

Apple pourrait être plus ouvert dans la discussion pour trouver de nouvelles façons d'activer les capacités des appareils, mais je pense que cela vient d'une perspective différente de l'informatique, un point de vue qui faisait partie de l'identité d'Apple pendant des décennies, et non d'un point de vue anticoncurrentiel.

Afin de prendre en charge des éléments tels que les capacités matérielles quelque peu ouvertes du projet Fugu, et en particulier WebUSB, le modèle de confiance du Web doit évoluer au-delà des invites d'autorisation et des listes de blocage de domaines / appareils, en s'inspirant des écosystèmes de confiance tels que les autorités de certification et les distributions de packages.

Lectures complémentaires sur SmashingMag:

Éditorial fracassant(ra, yk, il)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *