Webはハードウェア機能を公開する必要がありますか？

公開: 2022-03-10

簡単な要約↬この記事は、Alex Russellによるプラットフォーム隣接理論への回答であり、WebUSBに関する具体的な見解と、前進するためのいくつかの代替案が含まれています。

私は最近、Webの将来について、さまざまなブラウザベンダー間の意見の違いに興味を持っています。特に、ChromiumのProjectFuguなどのネイティブプラットフォームにWebプラットフォーム機能を近づけるためのさまざまな取り組みに関心があります。

主な位置は次のように要約できます。

Google（Intel、Microsoft、Samsungなどのパートナーと協力して）は、Fuguのような多数の新しいAPIを積極的に推進し、革新しており、Chromiumで出荷しています。
Appleはより保守的なアプローチを推し進めており、新しいAPIの多くをセキュリティとプライバシーの懸念を引き起こしているとマークしています。
これは（iOSでのブラウザの選択に関するAppleの制限とともに）、AppleがWebの進行を遅らせていると主張しながら、Safariを新しいIEとしてラベル付けするスタンスを生み出しました。
この点で、MozillaはGoogleよりもAppleに近いようです。

この記事での私の意図は、Googleで特定された主張、特にProjectFuguのリーダーであるAlexRussellによるPlatformAdjacency Theoryの主張を調べ、それらの主張で提示された証拠を調べ、おそらく私自身の結論に達することです。

具体的には、WebUSB（Project Fuguの特に物議を醸しているAPI）に飛び込み、それに対するセキュリティの主張にメリットがあるかどうかを確認し、代替手段が出現するかどうかを確認するつもりです。

プラットフォーム隣接理論

前述の理論は次の主張をします：

ソフトウェアは、コンピューティングのより優れたバージョンであるため、Webに移行しています。
Webはメタプラットフォームです—オペレーティングシステムから抽象化されたプラットフォームです。
メタプラットフォームの成功は、ほとんどのコンピューターに期待されることを達成することに基づいています。
ネイティブプラットフォームでの同じセキュリティ問題を無視しながら、セキュリティ上の理由でWebメタプラットフォームに隣接する機能を追加することを拒否すると、最終的にWebの関連性が低下します。
AppleとMozillaはまさにそれを行っており、隣接するコンピューティング機能をWebに追加することを拒否しているため、「Webを琥珀色にキャスト」しています。

私は、オープンWebの関連性を維持したいという著者の情熱と、新しい機能でWebを拡張するのが遅すぎると、関連性がなくなるのではないかという懸念に関連しています。これは、アプリストアやその他の壁に囲まれた庭が嫌いなことによって補強されています。しかし、ユーザーとして、私は反対の見方に関係することができます。閲覧しているWebサイトが何を実行できるか、または実行できないかがわからない場合、めまいがすることがあります。プラットフォームの制限と監査が快適であることがわかります。

ジャンプした後もっと！以下を読み続けてください↓

メタプラットフォーム

「メタプラットフォーム」という用語を理解するために、私は理論がその名前を何に使用しているかを調べました。JavaとFlashは、どちらも千年紀の変わり目の製品です。

JavaまたはFlashをWebと比較するのは紛らわしいと思います。理論で述べられているように、JavaとFlashはどちらも、当時はブラウザプラグインを介して広く配布されていたため、ブラウザプラットフォーム上にある代替ランタイムになりました。現在、Javaは主にサーバーとAndroidプラットフォームの一部として使用されており、言語を除いて、どちらもあまり共通点がありません。

今日、サーバー側のJavaはおそらくメタプラットフォームであり、node.jsもサーバー側のメタプラットフォームの良い例です。これは、APIのセット、クロスプラットフォームランタイム、およびパッケージエコシステムです。実際、node.jsは常に機能を追加していますが、以前はプラットフォームの一部としてのみ可能でした。

クライアント側では、C ++ベースのクロスプラットフォームフレームワークであるQtには、個別のランタイムが付属していません。これは、UI開発用の（優れた）クロスプラットフォームライブラリにすぎません。

同じことがRustにも当てはまります。これは言語とパッケージマネージャーですが、プリインストールされているランタイムには依存しません。

クライアント側アプリケーションを開発する他の方法は、主にプラットフォーム固有ですが、FlutterやXamarinなどのクロスプラットフォームモバイルソリューションも含まれます。

機能と時間

理論のメイングラフは、時間に対する機能の2D軸でのメタプラットフォームの関連性を示しています。

Qt、Xamarin、Flutter、Rustなどのクロスプラットフォーム開発フレームワークや、node.jsやJava / Scalaなどのサーバープラットフォームについて話すときに、上記のグラフがどのように意味をなすかがわかります。

しかし、上記のすべてには、Webとの重要な違いがあります。

3次元

前述のメタプラットフォームは、実際に機能をめぐってホストOSと競合していますが、Webとは異なり、信頼と配布については意見がありません。3番目の次元であり、私の意見では上のグラフにはありません。

QtとRustは、WebAssemblyを介して配布される、ホストOSに直接ダウンロードおよびインストールされる、またはCargoなどのパッケージマネージャーやUbuntuなどのLinuxディストリビューションを介して管理されるアプリを作成するための優れた方法です。 React Native、Flutter、Xamarinはすべて、アプリストアを介して配布されるアプリを作成するための適切な方法です。 node.jsおよびJavaサービスは通常、Dockerコンテナー、仮想マシン、またはその他のサーバーメカニズムを介して配布されます。

ユーザーは、コンテンツの開発に何が使用されたかについてはほとんど気づいていませんが、コンテンツがどのように配布されているかについてはある程度知っています。ユーザーはXamarinとnode.jsが何であるかを知りません。また、SwiftアプリがいつかFlutterアプリに置き換えられた場合、ほとんどのユーザーはそれを気にしないでしょうし、理想的には気にしないはずです。

しかし、ユーザーはWebを知っています。つまり、ChromeやFirefoxで「閲覧」しているときは「オンライン」であり、必ずしも信頼できないコンテンツにアクセスできることを知っています。彼らは、ソフトウェアのダウンロードとインストールが危険の可能性があることを知っており、IT管理者によってブロックされる可能性があります。実際、Webプラットフォームにとって、ユーザーが現在「Webを閲覧している」ことを知っていることが重要です。そのため、たとえば、全画面モードに切り替えると、ユーザーに明確なプロンプトが表示され、そこから戻る方法が示されます。

Webは透過的ではないため成功していますが、ホストOSから明確に分離されています。ランダムなWebサイトがハードドライブ上のファイルを読み取らないようにするためにブラウザを信頼できない場合は、おそらくどのWebサイトにもアクセスしません。

また、ユーザーは、コンピューターソフトウェアが「Windows」または「Mac」であり、電話がAndroidまたはiOSベースであるかどうか、現在アプリを使用しているかどうか（iOSまたはAndroid、およびMac OSである程度）を知っています。。 OSと配布モデルは、一般的にユーザーに知られています。ユーザーは、OSとWebを信頼して、さまざまなことを実行し、信頼度を変えます。

そのため、Webは、その独自の配布モデルを考慮せずに、クロスプラットフォーム開発フレームワークと比較することはできません。

一方、Webテクノロジーは、ElectronやCordovaなどのフレームワークを使用したクロスプラットフォーム開発にも使用されます。しかし、それらは正確には「ウェブ」ではありません。 Javaやnode.jsと比較した場合、「Web」という用語は「WebTechnologies」に置き換える必要があります。また、このように使用される「Webテクノロジー」は、必ずしも標準ベースである必要はなく、複数のブラウザーで機能する必要もありません。 Fugu APIについての会話は、ElectronとCordovaにいくらか接しています。

ネイティブアプリ

Webプラットフォームに機能を追加する場合、3番目の次元である信頼と配布モデルを無視したり軽視したりすることはできません。著者が「新しい機能からのリスクについてのAppleとMozillaの姿勢は、受け入れられている現存するネイティブプラットフォームのリスクによって信じられている」と主張するとき、彼は信頼に関してWebとネイティブプラットフォームを同じ次元に置いています。

確かに、ネイティブアプリには独自のセキュリティ問題と課題があります。しかし、ここのように、それがより多くのWeb機能を支持する議論であるかどうかはわかりません。これは誤りです。結論は、ネイティブアプリのセキュリティ問題を修正することであり、WebアプリはOS機能を備えた関連性のあるキャッチアップゲームであるため、セキュリティを緩和することではありません。

信頼と配布モデルの第3の側面を考慮に入れなければ、ネイティブとWebを機能の観点から比較することはできません。

AppStoreの制限

理論におけるネイティブアプリについての批判の1つは、iOSでのブラウザーエンジンの選択の欠如についてです。これはAppleに対する一般的な批判の糸ですが、これには複数の見方があります。

批判は特にAppleのアプリストアレビューガイドラインのアイテム2.5.6についてです：

「Webを閲覧するアプリは、適切なWebKitフレームワークとWebKitJavaScriptを使用する必要があります。」

これは反競争的であるように思われるかもしれません、そして私はiOSがどれほど制限的であるかについて私自身の予約を持っています。ただし、アイテム2.5.6は、残りのアプリストアレビューガイドラインのコンテキストなしでは読むことができません。たとえば、アイテム2.3.12：

「アプリは、「新機能」のテキストで新機能と製品の変更を明確に説明する必要があります。」

アプリがデバイスのアクセス許可を受け取り、そこにある任意のWebサイトからコードを実行できる独自のフレームワークを含めることができれば、アプリストアのレビューガイドラインにあるこれらの項目は無意味になります。アプリとは異なり、Webサイトは、リビジョンごとに機能や製品の変更を説明する必要はありません。

これは、ブラウザがプロジェクトFuguの機能のように、まだ標準とは見なされていない実験的な機能を出荷する場合、さらに大きな問題になります。ブラウザとは誰が定義しますか？アプリが任意のWebフレームワークを出荷できるようにすることで、アプリストアは基本的に、「アプリ」が未監査のコードを実行したり、ストアのレビュープロセスを回避して製品を完全に変更したりできるようにします。

Webサイトとアプリの両方のユーザーとして、私は両方ともコンピューティングの世界にスペースがあると思いますが、可能な限りWebに移行できることを望んでいます。しかし、Web標準の現状と、BluetoothやUSBなどの信頼とサンドボックスの側面がどのように解決されていないかを考えると、アプリがWebからコンテンツを自由に実行できるようにすることがユーザーにとってどのように役立つかわかりません。。

幸福の追求

別の関連するブログ投稿では、同じ作者がネイティブアプリについて話すときに、このいくつかに取り組んでいます。

「「アプリ」であるということは、恣意的で変更可能な一連のOS規則に適合しているだけです。」

「アプリ」の定義は恣意的であり、その定義はアプリストアポリシーを定義する人に依存するという考えに同意します。しかし、今日、同じことがブラウザにも当てはまります。 Webアプリケーションがデフォルトで安全であるという投稿からの主張もやや恣意的です。「ブラウザとは」の砂に線を引くのは誰ですか？ブラウザ内蔵のFacebookアプリは「ブラウザ」ですか？

アプリの定義は任意ですが、重要でもあります。低レベルの機能を使用するアプリケーションのすべてのリビジョンが、信頼できる誰かによって監査されるという事実は、たとえその誰かが恣意的であっても、アプリを彼らのものにします。その誰かが私が支払ったハードウェアの製造元である場合、それはさらに恣意的ではなくなります。私がコンピューターを購入した会社は、そのコンピューターの機能が低い監査ソフトウェアの1つです。

すべてがブラウザになることができます

Apple App Storeが本質的に行う「ブラウザとは」の線を引くことなく、すべてのアプリが独自のWebエンジンを出荷し、アプリ内ブラウザを使用して任意のWebサイトを閲覧するようにユーザーを誘導し、追跡コードを追加することができます。アプリとウェブサイトの3次元の違いを崩壊させたいのです。

iOSでアプリを使用すると、現在、自分のアクションがAppleと特定のアプリメーカーの2人のプレーヤーに公開されていることがわかります。 SafariまたはSafariWebViewでWebサイトを使用すると、私のアクションはAppleと、現在表示しているWebサイトのトップレベルドメインの所有者に公開されます。識別されていないエンジンでアプリ内ブラウザーを使用すると、アプリの製造元であるAppleと、トップレベルドメインの所有者にさらされます。これにより、アプリの所有者が外国のWebサイトでのすべてのクリックを追跡するなど、回避可能な同一生成元違反が発生する可能性があります。

「OnlyWebKit」の砂の線が厳しすぎるのではないかと思います。ユーザーのブラウジングを追跡するためのバックドアを作成しないブラウザの代替定義は何でしょうか？

Appleに関するその他の批判

理論によれば、Appleが機能を実装することを拒否したのは、プライバシー/セキュリティの懸念だけではない。リンクが含まれています。これは、SafariではなくChromeに実装されている多くの機能を実際に示しています。ただし、下にスクロールすると、ChromeではなくSafariに実装されている他の機能もかなりの量表示されます。

これら2つのブラウザプロジェクトの優先順位は異なりますが、「ズームアウトするとゲームが明確になる」という明確な声明や、AppleがWebを琥珀色にキャストしようとしているという厳しい批判からはほど遠いものです。

また、「難しい」というタイトルのリンクは、セキュリティ/プライバシーの懸念が満たされた場合に機能を実装するというAppleの声明につながることを試みたくありません。これらのタイトルにこれらのリンクを配置することは誤解を招くと思います。

私は、機能の実装とWebの進歩に関して、GoogleはAppleよりもはるかに強気であるというよりバランスの取れた声明に同意します。

許可プロンプト

Googleは、信頼できるWebアクティビティの場合のように、ユーザー、開発者、プラットフォーム間の信頼を仲介する新しい方法を開発し、時には大きな成功を収めて、3次元で長い革新的な方法を採用しています。

しかし、それでも、デバイスAPIに関連する3次元での作業のほとんどは、アクセス許可プロンプトとそれらをより恐ろしいものにすること、またはタイムボックスアクセス許可付与やブロックリストされたドメインなどに焦点を当てています。

「怖い」プロンプトは、この例で時々見られるようなプロンプトであり、悪意のある可能性があると思われるページにユーザーがアクセスするのを思いとどまらせることを目的としているように見えます。それらは非常に露骨であるため、これらの警告は、開発者がより安全なAPIに移行し、証明書を更新することを奨励します。

デバイスアクセス機能については、エンゲージメントを促進し、エンゲージメントが安全であることを保証するプロンプトを考え出すことができれば幸いです。Web開発者が修正できるようにすることなく、エンゲージメントを思いとどまらせてユーザーに責任を譲渡するのではありません。これについては後で詳しく説明します。

私は、MozillaとAppleが「実装を拒否する」のではなく、少なくともその分野で革新を試みるべきであるという議論に同意します。しかし、多分彼らはそうですか？たとえば、AppleのisLoggedInは、将来のデバイスAPIが構築される可能性のある、3次元での興味深く関連性のある提案だと思います。たとえば、指紋が発生しやすいデバイスAPIは、現在のWebサイトがユーザー。

WebUSB

次のセクションでは、WebUSBについて詳しく説明し、WebUSBで何が可能か、3次元でどのように処理されるかを確認します。信頼と配布のモデルは何ですか。十分ですか？選択肢は何ですか？

前提

WebUSB APIを使用すると、ブロックリストにないデバイスクラスのUSBプロトコルにフルアクセスできます。

Arduinoボードへの接続やAndroid携帯のデバッグなどの強力な機能を実現できます。

このAPIが、以前は非常に費用がかかっていたものを達成するのにどのように役立つかについてのSuzHintonのビデオを見るのはエキサイティングです。

例として、プラットフォームがよりオープンで、教育用ハードウェア/ソフトウェアプロジェクトをすばやく反復できる方法を見つけてほしいと心から願っています。

変な感じ

しかし、それでも、WebUSBが何を可能にするのか、そしてUSB全般に関する既存のセキュリティ問題を見ると、私はおかしな気持ちになります。

USBは、許可プロンプトがあっても、Webに公開されるプロトコルとしては強力すぎると感じます。

だから私はさらに研究しました。

Mozillaの公式見解

私は、Mozillaの公式の標準的な立場で、MozillaがWebUSBを拒否することになった理由についてDavidBaronが言わなければならなかったことを読むことから始めました。

「多くのUSBデバイスは、USBプロトコルを介した潜在的に悪意のある相互作用を処理するように設計されておらず、それらのデバイスは接続先のコンピューターに重大な影響を与える可能性があるため、USBデバイスをWebに公開することによるセキュリティリスクも大きいと考えています。ユーザーをそれらにさらすリスクを冒したり、意味のあるインフォームドコンセントを得るためにエンドユーザーに適切に説明したりするのは幅広いです。」

現在の許可プロンプト

この投稿を公開した時点でのChromeのWebUSB権限プロンプトは次のようになります。

特定のドメインFooが特定のデバイスバーに接続したいと考えています。何をすべきか？どうすれば確実に知ることができますか？

プリンター、カメラ、マイク、GPS、または心拍数モニタリングなどのより多くのWebBluetooth GATTプロファイルへのアクセスを許可する場合、この質問は比較的明確であり、デバイスではなくコンテンツまたはアクションに焦点を当てます。周辺機器からどのような情報が必要か、または周辺機器でどのようなアクションを実行したいかが明確に理解されており、ユーザーエージェントがこの特定のアクションを仲介して確実に処理します。

USBは一般的です

特別なAPIを介して公開される上記のデバイスとは異なり、USBはコンテンツ固有ではありません。仕様の冒頭で述べたように、WebUSBはさらに進んでおり、キーボードや外付けドライブなどのよく知られたデバイスクラスではなく、未知またはまだ発明されていないタイプのデバイス用に意図的に設計されています。

したがって、プリンター、GPS、カメラの場合とは異なり、WebUSBを使用してデバイスに接続するためのページ許可を付与すると、コンテンツ領域で何が許可されるかをユーザーに通知するプロンプトを考えることはできません。特定のデバイスとそれにアクセスしているコードの監査。

Yubikeyのインシデントと軽減

少し前の良い例は、ChromeのWebUSBがUSB電源の認証デバイスからのデータをフィッシングするために使用されたYubikey事件です。

これは解決されたと言われているセキュリティの問題であるため、特定のデバイスセットと特定のクラスセットをブロックするなど、Chrome67でのChromeの緩和策について詳しく知りたいと思いました。

クラス/デバイスブロックリスト

そのため、現在非常に一般的な許可プロンプトに加えて、実際に発生したWebUSBエクスプロイトに対するChromeの実際の防御は、特定のデバイスとデバイスクラスをブロックすることでした。

これは、新しいテクノロジーや実験のための簡単な解決策かもしれませんが、WebUSBが普及すると（そしてもしそうなら）、達成するのはますます難しくなります。

WebUSBを介して教育機器を革新する人々は、困難な状況に陥る可能性があるのではないかと心配しています。プロトタイピングが完了するまでに、彼らは、彼らとは関係のないセキュリティ問題に基づいて、ブラウザのバージョンと一緒にのみ更新される、絶えず変化する非標準のブロックリストのセットに直面する可能性があります。

これに対処せずにこのAPIを標準化すると、それに依存している開発者にとって逆効果になると思います。たとえば、誰かがモーションディテクタ用のWebUSBアプリケーションの開発にサイクルを費やす可能性がありますが、セキュリティ上の理由またはOSがモーションディテクタを処理することを決定したために、モーションディテクタがブロックされたクラスになり、WebUSB全体の努力が無駄。

セキュリティと機能

プラットフォーム隣接理論は、ある意味で、機能とセキュリティをゼロサムゲームと見なしており、セキュリティとプライバシーの懸念について保守的すぎると、プラットフォームの関連性が失われる可能性があります。

例としてArduinoを取り上げましょう。 Arduino通信はWebUSBで可能であり、主要なユースケースです。 Arduinoデバイスを開発している人は、サイトがWebUSBを使用して（ユーザーの許可を得て）デバイスにアクセスしようとする新しい脅威シナリオを検討する必要があります。仕様に従って、このデバイスメーカーは、「署名されたファームウェアのみを受け入れるようにデバイスを設計する」必要があります。これはファームウェア開発者に負担をかけ、開発コストを増加させる可能性がありますが、仕様の全体的な目的はその逆を行うことです。

WebUSBが他の周辺機器と異なる点

ブラウザでは、ユーザーインタラクションと合成インタラクション（Webページによってインスタンス化されるインタラクション）には明確な違いがあります。

たとえば、Webページは、リンクをクリックするか、CPU/ディスプレイをウェイクアップするかを自分で決定することはできません。ただし、外部デバイスは可能です。たとえば、OSによっては、マウスデバイスがユーザーに代わってリンクをクリックし、ほとんどすべてのUSBデバイスがCPUをウェイクアップできます。

したがって、現在のWebUSB仕様でも、デバイスはいくつかのインターフェイスの実装を選択できます。たとえば、adbのデバッグやポインター入力のHID、ADBを利用する悪意のあるコードの使用、キーロガーになり、ユーザーに代わってWebサイトを閲覧できます。適切な悪用可能なファームウェアフラッシュメカニズム。

そのデバイスをブロックリストに追加すると、ファームウェアがADBまたはその他の許可された形式のフラッシュを使用して侵害されたデバイスには遅すぎ、デバイスメーカーは、デバイスに関連付けられたセキュリティ修正について、以前よりもブラウザーバージョンに依存するようになります。

インフォームドコンセントとコンテンツ

インフォームドコンセントとUSBの問題は、前述のように、USB（特に一般的なWebUSBのユースケースでは）がコンテンツ固有ではないことです。ユーザーはプリンターとは何か、カメラとは何かを知っていますが、ほとんどのユーザーにとっての「USB」は単なるケーブル（またはソケット）であり、目的を達成するための手段です。USBがプロトコルであり、Webサイト間でUSBを有効にすることを知っているユーザーはほとんどいません。およびデバイスとは。

1つの提案は、「このWebページにデバイスの乗っ取りを許可する」という「怖い」プロンプトを表示することでした（これは、一見無害に見える「接続したい」よりも改善されています）。

しかし、プロンプトが表示されるほど恐ろしいことですが、ブラウザが詳しく知らないUSB周辺機器への生のアクセスで実行できる可能性のあることの幅を説明することはできません。説明した場合、正しい心のユーザーは「はい」をクリックしません。」、それがバグのないことを完全に信頼しているデバイスであり、悪意のない最新のものであると本当に信頼しているWebサイトでない限り。

そのようなプロンプトは、「このWebページがコンピュータを乗っ取る可能性を許可する」と表示されます。このような恐ろしいプロンプトがWebUSBコミュニティにとって有益であるとは思わないので、これらのダイアログを絶えず変更すると、コミュニティが混乱することになります。

プロトタイピングと製品

私はこれに対する可能な例外を見ることができます。 WebUSBおよびその他のプロジェクトFuguAPIの前提が、製品グレードのデバイスではなくプロトタイピングをサポートすることである場合、すべてを網羅する汎用プロンプトが理にかなっている可能性があります。

しかし、それを実行可能にするためには、次のことが起こらなければならないと思います。

これがプロトタイピングであるという期待を設定する仕様で言語を使用します。
これらのAPIは、ユーザーがブラウザの設定で手動で有効にするなど、オプトインジェスチャの後でのみ使用できるようにします。
無効なSSL証明書の場合のように、「恐ろしい」許可プロンプトが表示されます。

上記がないので、これらのAPIはプロトタイプではなく実際の製品用であると私は思います。そのため、フィードバックは保持されます。

代替案

私が同意する元のブログ投稿の一部の1つは、「いいえ」と言うだけでは不十分であるということです。特定のAPIが有害であるとして拒否するウェブ世界の主要なプレーヤーも、攻撃を行い、これらの機能が重要である方法を提案する必要があります。ユーザーと開発者に安全に公開することができます。私は主要なプレーヤーを代表していませんが、謙虚にやっていきます。

これに対する答えは、信頼と関係の3次元にあり、許可プロンプトとブロックリストの枠の外にあると私は信じています。

簡単で検証済みのプロンプト

私が行う主なケースは、プロンプトは周辺機器ではなくコンテンツまたはアクションに関するものである必要があり、インフォームドコンセントは、特定の検証済みパラメーターのセットを使用した特定の単純なアクションに対して付与できることです。デバイスの「引き継ぎ」や「接続」などの一般的なアクション。

3Dプリンターの例

WebUSB仕様では、例として3Dプリンターが紹介されているので、ここで使用します。

3Dプリンタ用のWebUSBアプリケーションを開発するとき、ブラウザ/ OSプロンプトで、 [AutoDesk3ds-maskにモデルをCreatBot3Dプリンタに印刷することを許可しますか？] 、リファインメント、厚さ、出力寸法などのいくつかの印刷パラメータと、印刷される内容のプレビューを含むブラウザ/ OSダイアログが表示されます。これらのパラメータはすべて、ドライブバイWebページではなく、信頼できるユーザーエージェントによって検証される必要があります。

現在、ブラウザはプリンタを認識しておらず、プロンプトの一部のクレームのみを確認できます。

要求元のドメインにはAutoDeskに登録された証明書があるため、これがAutoDeskIncであることがある程度確実です。
要求された周辺機器は、それ自体を「CreatBot3dプリンター」と呼びます。
このデバイス、デバイスクラス、およびドメインは、ブラウザのブロックリストにありません。
ユーザーは、尋ねられた一般的な質問に「はい」または「いいえ」と答えました。

ただし、上記の詳細を含む真実のプロンプトとダイアログを表示するには、ブラウザは次のことも確認する必要があります。

許可が与えられると、実行されるアクションは3Dモデルを印刷することであり、それ以外は何もありません。
選択したパラメータ（細かさ/厚さ/寸法など）が尊重されます。
印刷される内容の検証済みプレビューがユーザーに表示されました。
特定の機密性の高いケースでは、これが実際にAutoDeskであるという追加の検証が行われ、おそらく取り消し可能な短期間のトークンのようなものが使用されます。

上記を確認せずに、3Dプリンターに「接続」または「引き継ぐ」許可を与えられたWebサイトは、バグ（または依存関係の1つにある悪意のあるコード）が原因で巨大な3Dモデルの印刷を開始できます。

また、想像上の本格的なWeb 3D印刷機能は、WebUSBが提供できる機能よりもはるかに多くのことを実行します。たとえば、さまざまな印刷要求のスプールとキューイングが可能です。ブラウザウィンドウが閉じている場合、それはどのように処理されますか？考えられるすべてのWebUSBペリフェラルのユースケースを調査したわけではありませんが、コンテンツ/アクションの観点からそれらを見ると、ほとんどの場合、USBアクセス以上のものが必要になると思います。

上記の理由により、3D印刷にWebUSBを使用することは、おそらくハッキーで短命であり、それに依存する開発者は、ある時点でプリンターに「実際の」ドライバーを提供する必要があります。たとえば、OSベンダーが3Dプリンターの組み込みサポートを追加することを決定した場合、そのプリンターをWebUSBで使用しているすべてのサイトが機能しなくなります。

提案：ドライバー監査機関

そのため、「周辺機器を引き継ぐ」などの包括的な権限には問題があり、本格的なパラメータダイアログを表示してその結果が尊重されることを確認するための十分な情報がないため、送信したくありません。 Webからランダムな実行可能ファイルをダウンロードするための危険な旅行中のユーザー。

しかし、WebUSB APIを内部的に使用し、次のことを行う監査済みのコード、ドライバーがある場合はどうなるでしょうか。

「print」コマンドを実装しました。
ページ外の印刷ダイアログを表示しました。
特定のUSBデバイスのセットに接続されています。
ページがバックグラウンドにあるとき（たとえば、Service Worker内）、またはブラウザーが閉じているときにも、そのアクションの一部を実行しました。

このようなドライバーの監査により、ドライバーが行うことは「印刷」に相当し、パラメーターを尊重し、印刷プレビューが表示されることを確認できます。

これは、認証局に似ていると思います。これは、ブラウザベンダーからある程度切り離されている、Webエコシステムの重要な部分です。

ドライバーシンジケーション

ドライバーはGoogle/Appleによる監査を受ける必要はありませんが、ブラウザー/OSベンダーは独自にドライバーを監査することを選択できます。 SSL認証局のように機能します—発行者は非常に信頼できる組織です。たとえば、特定の周辺機器の製造元、多くのドライバーを認定する組織、またはArduinoのようなプラットフォームです。（Let's Encryptに似た組織がポップアップすることを想像します。）

「Arduinoは、このコードがこのファームウェアでUnoをフラッシュすることを信頼しています」（ファームウェアのプレビュー付き）とユーザーに言うだけで十分かもしれません。

警告

もちろん、これには潜在的な問題がないわけではありません。

ドライバー自体はバグがあるか悪意がある可能性があります。しかし、少なくともそれは監査されています。
「ウェビー」が少なく、追加の開発負担が発生します。
それは今日存在せず、ブラウザエンジンの内部革新によって解決することはできません。

その他の選択肢

他の代替手段は、クロスブラウザーWeb拡張機能APIを何らかの方法で標準化および改善し、Chrome Webストアなどの既存のブラウザーアドオンストアを、ユーザー要求と周辺アクセスの間を仲介するドライバー監査機関にすることです。

意見のまとめ

著者、Google、およびパートナーの機能を強化することでオープンWebの関連性を維持するための大胆な取り組みは、刺激的なものです。

詳細を見ると、AppleとMozillaのWebに対するより保守的な見方と、新しいデバイス機能に対する防御的なアプローチが技術的なメリットをもたらしていることがわかります。オープンエンドのハードウェア機能に関するインフォームドコンセントに関する主要な問題は、まだ解決されていません。

Appleは、デバイス機能を有効にする新しい方法を見つけるための議論でもっと前向きになる可能性がありますが、これはコンピューティングに関する別の観点から来ていると思います。これは、反競争的な観点からではなく、何十年もの間Appleのアイデンティティの一部であった観点です。

プロジェクトFuguのややオープンエンドのハードウェア機能、特にWebUSBなどをサポートするには、Webの信頼モデルを、認証局や認証局などの信頼エコシステムからインスピレーションを得て、許可プロンプトやドメイン/デバイスブロックリストを超えて進化させる必要があります。パッケージ配布。

SmashingMagの詳細：

ウェブサイトのパフォーマンスを改善することが地球を救うのにどのように役立つか
広告なしのウェブに向けて：オンライン経済の多様化
優れたコードを書くことを超えた未来はありますか？
Webデザインでの倫理の使用