ブラウザー拡張機能の過小評価：ハック可能なソフトウェアの約束（2019）
(geoffreylitt.com)- ブラウザー拡張機能は、スマートフォンやデスクトップのプラットフォームと違って、ユーザーがWebアプリを元の開発者の意図しない形に変えられる、まれなハック可能なソフトウェア生態系である
- Chromeストアに18万個以上の拡張機能があり、Chromeユーザーのほぼ半数が導入していることは、一般ユーザーでも簡単な手段があればパーソナライズされた利用環境を自分で組み立てることを示している
- 拡張機能の幅広い用途は、アプリごとのAPIよりも、人間が読めるクライアントコード、意味のあるマークアップ、標準的なWebレイアウトといったWebのオープン性から生まれている
- パスワード入力、漢字の読み、注釈、広告ブロック、2倍速再生のような拡張機能は、複数のサイトで動作する小さなツールとして、巨大アプリ中心モデルとは異なるソフトウェア体験を作り出す
- 悪意ある拡張機能やプライバシー侵害には引き続き対処が必要だが、アクセシビリティ、互換性、権限のバランスを取れば、ユーザーが使うソフトウェアをより深く変えられる拡張可能性を守ることができる
ブラウザー拡張が特別な理由
- 最近のブラウザー拡張をめぐる議論は、閲覧履歴を収集する悪意ある拡張機能や、Googleによる広告ブロック機能の制限に集中してきたが、それでも拡張機能はユーザー主導のソフトウェアの特別な事例である
- 主要なソフトウェアプラットフォームの中で、ブラウザー拡張機能は、ユーザーが日常的に使うアプリを元の開発者の意図の外側で変更することを許し、奨励する珍しい例外である
- スマートフォンやデスクトップのプラットフォームではこうした変更はまれか不可能だが、ブラウザーでは日常的な活動として定着している
- 拡張機能は、ユーザーがコンピューターの使い方をより深く制御できるという感覚を取り戻させる
ユーザーが自分で組み立てるソフトウェア
- ソフトウェアプラットフォームがある程度以上オープンになると、一般ユーザーがソフトウェアと関わる方法も変わる
- Gmail拡張機能を4つ導入して視覚デザインから中核機能まで変えるなら、ある意味では自分だけのメールクライアントを組み立てたことになる
- ユーザーは、あらかじめ作られたアプリの受動的な消費者にとどまらず、コンピューターの使い方を自分向けに直接構成できる
- Chromeストアには18万個を超える拡張機能があり、Chromeユーザーのほぼ半数がブラウザー拡張機能を導入している
- この人気は、ソフトウェアを簡単に拡張できる方法があれば、多くのユーザーが実際にその機会を活用することを示している
アプリ別APIよりハック可能なプラットフォーム
- ブラウザー拡張機能には、パスワード入力、日本語の漢字の読み、Gmailの視覚デザイン簡素化、記事のハイライトと注釈、あとで読むための保存、2倍速動画再生、広告ブロックなど、非常に幅広い用途がある
- この幅広さの核心は、ほとんどの拡張機能が元の開発者が具体的に想定していない形でアプリケーションを変えている点にある
- 日本の新聞社が記事を公開する際に、漢字読み拡張機能との互換性を考えていなくても、拡張機能は動作しうる
- 拡張機能の開発者は、アプリ開発者の拡張観が反映されたアプリ別APIに縛られず、より大きな創作の自由を持つ
- Webプラットフォームのいくつかの特性が、予定されていなかった拡張可能性を実現している
- 従来のWeb配信方式では、クライアントコードが人間に読める形でブラウザーに送られる
- コードが難読化されていたり別の言語からコンパイルされていたりする場合でも、ソースマップはこの利点を保つうえで重要である
- Webのレイアウトモデルは、標準化された意味論的マークアップを促進する
- パスワードマネージャー拡張機能は、Webページが独自実装ではなくパスワード送信に
formタグを安定して使っているために動作する
- サイトが拡張機能向けに作られていない場合でも、賢い回避策が必要になることはあるが、多くは何年ものリバースエンジニアリングなしに、妥当な作業量で実現できる
- Webサイト開発者と拡張機能開発者の間に緊張が生じることはあっても、サイト開発者に追加作業が発生しないなら、創造的な拡張を受け入れるケースのほうが一般的である
- 少数のユーザーしか望まないニッチな機能は、動機のあるコミュニティメンバーが拡張機能として作れるため、アプリケーション開発者の負担も減る
大きなアプリではなく小さなツール
- 多くのブラウザー拡張機能は、あらゆるWebサイトの利用体験を改善する汎用ツールとして機能する
- 注釈拡張機能は、記事ごとに異なるハイライトツールを要求せず、すべてのWebサイトで使える
- 物理的な蛍光ペンのように、1つのツールを覚えれば多くの文脈に適用でき、大きなレバレッジが得られる
- 多くのソフトウェアプラットフォームでは、OSが横断的ツールを提供し、サードパーティは孤立した独立アプリを提供すると考えられがちだが、ブラウザー拡張ではサードパーティもツールを追加する
- 小さな単位のソフトウェアは、経済性も変える
- ほとんどの拡張機能は無料で、機能の範囲が小さいため、それだけで完全な事業として維持するには小さすぎることもある
- それでも人々は拡張機能を作り、ユーザーはその小さなソフトウェアの断片から大きな利益を得る
- 拡張ストアを探す体験は、スーパーマーケットよりも近所のフリーマーケットに近い
- 大企業が作る大規模ソフトウェアだけが唯一のやり方ではない
Webオープン性のルーツ
- パーソナルコンピューティングの初期から、コンピューターを、ユーザーが自分のアイデアを加え、自分のツールを作るための対話的な媒体と見る哲学的伝統があった
- この伝統は、Smalltalk、Hypercard、そして最近ではDynamiclandのようなシステムに反映されている
- Tim Berners-LeeはWorld Wide Webを作るとき、この伝統の中に位置づけられるシステムを思い描いていた
- 彼のビジョンは「自分が知っていることや考えていることを共有することが、他人の知っていることを学ぶのと同じくらい簡単なシステム」だった
- 彼はWebブラウザーがWebサイトの編集ツールでもあるべきだと考えていたが、Mosaicブラウザーはその機能なしで人気を得てしまい、彼はそれを残念に思っていた
- Webは最終的に、誰もがソーシャルメディアプラットフォームを通じて意見や写真を投稿できる場になった
- ただしFacebookのようなアプリの中では、決められた形式で投稿し、広告を含めてアプリが定めた方法で使わなければならない
- ブラウザー拡張機能は、与えられたテキストボックスに入力する段階を超えて、Web上のどのアプリケーションでも、その使い方を深く変えられるようにする
- 大規模Webサイトを作る企業がユーザー体験のあらゆる細部を決められないようにする分散性を提供する
拡張機能をより良くする方向
- 悪意ある拡張機能がプライバシーを侵害しないようにユーザーを保護する取り組みは必要である
-
アクセシビリティ
- 現状では、拡張機能を使う側から作る側へ移るには、かなりのWeb開発知識を学ぶ必要がある
- ブラウザー内で簡単に拡張機能を開発することも難しい
- 開発者ツールでWebサイトを編集しながら、そのまま小さな拡張機能を公開できるような、滑らかな移行が可能かもしれない
-
互換性
- 拡張機能はサポートされていない方法でWebサイトにフックするため、サイト更新によって一時的に壊れることがある
- 拡張機能の開発者は、変更に合わせて急いで修正しなければならない場合がある
- 明示的な拡張APIに依存せずに、Webサイト開発者と拡張機能開発者が安定して接続できる方法が必要である
- クリーンな意味論的マークアップ、人間が読めるCSS、ソースマップは、拡張機能開発を容易にする既存の慣行である
- クラウドソフトウェアの新バージョン公開後も、ユーザーが3か月間は旧バージョンを使い続けられるなら、拡張機能開発者は新バージョンに合わせて更新する時間を確保できる
-
権限
- Web拡張機能はブラウザークライアントを広く変更できるが、サーバーには手を加えられない
- ソーシャルメディアアプリのサーバーが投稿を時系列で取得するエンドポイントしか提供しないなら、ブラウザー拡張機能で全投稿をキーワード検索できるようにはできない
- クライアントとサーバーの境界を見直せば、拡張機能はさらに深い変更を行える
- より強い権限はセキュリティとプライバシーの問題をさらに難しくするが、拡張可能性を価値として置き、バランスを探るべきである
次のプラットフォームの可能性
- Beaker Browserと分散型Webコミュニティは、中央サーバーなしでWebが動作する方法を探っている
- こうしたアーキテクチャは、ユーザーがWebアプリケーションの「サーバー」側を変更するうえで、より完全な制御権を与える可能性がある
- Tim Berners-Leeの新プロジェクトSOLIDには、ユーザーが自分のデータに対してより大きな所有権を持つという原則が含まれている
- データ所有権が強まれば、ユーザーは拡張機能や他のソフトウェアを通じて、アプリケーションサーバーAPIが許す範囲を超えて柔軟にデータを扱えるようになる
- コンピューティングはまだ若く、プラットフォームは急速に変化している
- 現代のブラウザー拡張機能とスマートフォンプラットフォームは、登場してからまだおよそ10年しかたっていない
- 今後のプラットフォームがどれほどオープンになるかは、私たちが集団として決めるべき問題である
- ブラウザー拡張機能は、ユーザーが使うソフトウェアを日常的にハックし、自分のものにしていく場の一例である
2024年アップデート
- 2019年に書いた文章を5年後に振り返ると、いくつかの関連プロジェクトが加わっている
- Twitter向けの人気ブラウザー拡張機能を作り、日常的に使うソフトウェアの問題を修正する方法として拡張機能を使う経験をまとめた記事を書いた
- MITでDaniel Jacksonと博士課程に取り組む中で、非プログラマーがスプレッドシートからブラウザー拡張機能を作れるようにするWildcardを開発した
- Glenは、ブラウザー拡張機能を持続可能なプロジェクトにしたい人のための収益化プラットフォームExtensionPayに取り組んでいる
- 最近では研究所Ink & Switchで、AIベースの malleable softwareに向けた取り組みを進めている
1件のコメント
Hacker News のコメント
筆者です。この記事は5年前に書いたもので、その後 カスタマイズ可能なソフトウェア の価値に対する確信はさらに強まりましたが、いくつか考えは変わりました。
それでも、拡張に関する議論がセキュリティに偏りすぎて、他の価値を犠牲にしていると思います。カスタマイズ可能性は、場合によってはセキュリティより優先されるほど重要になり得ます。解決策もいくつかあります。インターネット上の見知らぬ誰かからインストールするのではなく、同僚や友人のような信頼関係の中で拡張をやり取りしたり、自分で作った拡張だけを使ったりする方法があります。AI 支援プログラミングによって自作はより現実的になり得ますが、新たなセキュリティ問題も生じます。また、この根本的な緊張を和らげるソフトウェアアーキテクチャのアイデアを持つ人たちにも会いました。例は https://www.wildbuilt.world/p/inverting-three-key-relationsh... にあります。
いま働いている研究所 Ink & Switch では local-first ソフトウェアを作っています。データとコードが自分のデバイス上にある協調ソフトウェアです。プライバシーなどの利点に加え、データとアプリコードがサーバーに閉じ込められていないため、より強力な拡張のための正しい土台だと考えています: https://www.inkandswitch.com/local-first/
Android で自分のカスタムキーボードを作れるのは素晴らしいことですが、誰かが祖父母を説得して、内蔵キーロガー入りのキーボードをインストールさせられるのはまったく良いことではありません。ブラウザ拡張は常にマルウェアの多いエコシステムでしたし、感謝祭に帰省するたびに親の Internet Explorer からツールバーを消す、という冗談は1999年ごろからありました。
「はい、私のスマホの中身を読んで構いません。あなたにはそれが全体で、すべてに見えるでしょう。ただ私からするとフォルダ1つにすぎず、空のフォルダです。新しいスマホなので。」
「はい、これが私の連絡先リストです。ほとんど空で申し訳ありません。高額なプレミアム番号が1つだけありますね。御社の本社がそこへ電話しないことを願います。」
「はい、私のマイクです。ありがとうございます。Rick Astley の物まねは上手でしょう。」
「スマホの写真ですか？ こちらです。全部カブの写真です。お好きですか？」
特に Automerge や Yjs のような汎用 CRDT ツールが local-first ソフトウェアの基盤ファイル形式になり、相互運用可能な同期・協業バックエンドを接続する形に強い関心があります。ユーザーは標準ツールで基礎データに直接アクセスでき、ファイルは相互にリンク・埋め込み・分岐・マージできます。すべての文書を共有し、フォークし、リアルタイム編集できる新しいハイパーメディアプラットフォームを作れます。Ink & Switch の取り組みは本当に素晴らしく、次の発表が楽しみです。
「コードと manifest をディレクトリに入れればブラウザが使う」という機能がありません。昔の greasemonkey がブラウザプロファイルの gm_scripts/ サブディレクトリから通常のファイルをそのまま読み込んでいた時代には、この単純な配布のおかげで userscript をものすごくたくさん作りました。当時は Web サイトの拡張が楽しく簡単だったのに、Mozilla が全部なくしてしまいました。
配布は本当にひどいものです。自分のコンピュータで自分が書いたコードを使うために、変更のたびに拡張をインターネット上のどこかへ送って署名してもらうつもりはまったくありません。しかも最後に確認したとき、署名ツールは信頼しなければならない 100MiB 超の NPM/node アプリで、Linux カーネルのビルドよりも大きいものでした。
2024年において、ブラウザ拡張という枠組み自体が非常に問題を抱えている。ブラウザ拡張の大半は実質的に Google Chrome 拡張であり、Google Chrome は収益を押し上げようとする過程で、どんな API も安全ではないことをはっきり示している。
Chrome API で拡張を作る人は、巨大企業が何の考えもなく踏み潰せる対象に労力を注いでいる可能性があると知っておくべきだ。こうした戦略的にすでに負けている状況で生きたくはないので、議論は Firefox 拡張についてであるべきだと思う。Firefox も実績が良いとは言い切れない。数年前に Google Chrome 互換へ移行したことはいまだに非常に腹立たしい。それでも相手にするには質的により良い側だ。
10年間、Firefox と Chrome の両方で「Ad Limiter」というものを使っていて、コードも同一だった。昨年 Google が広告ブロッカーへの締め付けを強め、脅しのようなメッセージを送ってきたので、Chrome 向けは諦めた。
もちろん特定ブラウザ専用 API も使える。それは単一ブラウザ専用サイトを作るようなもので、本当に良くない。基本は互換であるべきだ。そして拡張のソースコードは常に見られるので、自分のブラウザでうまく動くバージョンに修正できるし、再共有もできる。
人気のあるブラウザ拡張のかなり多くがデータブローカーに買収され、ブラウザ履歴を抜き取るために使われてきたのだから、過小評価されているとは言いにくい。拡張のセキュリティ・プライバシーモデルはかなりひどかった、あるいは今もひどいので、非常に慎重になる必要がある。
たとえば Awesome Screenshot のようなスクリーンショット拡張がブラウザ履歴を吸い上げ、イスラエルのデータブローカーに送っていることを知っている。こうした機能は、おそらくブラウザの標準機能としてあるほうがよい。
「自分が顧客でなければ、自分が商品だ」という言葉は陳腐なほど正しい。では、自分が実際に顧客ならどうだろうか。ブラウザ拡張への不信のかなりの部分は、拡張を直接収益化しにくいことに由来していると思う。拡張でお金を稼げていないところに、誰かが買収したいと言ってまともな小切手を差し出してきたら、特に開発者にサポート負担がある拡張なら、断るのは難しい。もちろん、ほぼ全員がそうであるように私にも値段はあるが、今なら7桁ドル、もしかすると8桁ドルは必要だと思うし、私の拡張にその金を払う人はいないだろう。有料なのでユーザーベースは比較的小さく、まさにそのためにデータ収集や邪悪な計画の大きな機会にもならない。
もちろんデスクトップアプリにもリスクはあるが、歴史的にこの種の買収後のデータ流出パターンは、デスクトップアプリでは比較的まれだ。特に macOS では署名済みアプリがサンドボックス化され、ユーザー権限なしにできることは多くない。
もちろん、こうした拡張の多くはオープンソースなので監査できる。ただ、自分には悪意あるコードを見つける力がないので、AI の良い活用例になるのではないかと気になっている。マルウェア検出用の良いプロンプトを作ることについて、何か考えがあるか気になる。
ブラウザ拡張にもっと細かな権限があればよいと思う。ただし、ソフトウェアが権限を悪用しているかを検証する問題は難しく、Obfuscated C Code Contest や Underhand C Contest を見れば分かる。また、ニュアンスのある権限をユーザーに伝えるのも難しい。ほとんどのユーザーは技術的な内容を読まないか理解できず、簡単に誤導されうる
Chrome で拡張を試すときに、より安全に使うためのコツが一つある。Profiles > Add profile > Continue without account に進んで別プロファイルを作成し、使いたい拡張をそこにインストールすれば、通常プロファイルのタブのログイン、履歴、Cookie などから完全に隔離される。同様に、通常の Chrome と併用して Chrome Beta や Chrome Canary を拡張インストール用に動かすこともできる
たとえば、潜在的に危険な Web 開発用拡張を何十個もこのプロファイルに入れて、個人の銀行取引や会社の Web サイトへのログインに使うプロファイルとはサンドボックスのように分離しておける。すべての拡張で実用的というわけではないが、Web 開発用にはこうしていて、個人用では拡張を数個だけ使っている
私が販売しているブラウザ拡張で本当に要求したい権限は「自分のタブで送受信されるネットワークトラフィックだけを観察できる」なのだが、実際には「すべてのデータを読み取り、変更する」権限を要求しなければならない。そこで説明に上記のコツを共有している: https://chromewebstore.google.com/detail/checkbot-seo-web-sp...
透明性がこの信頼の壁を越える一つの方法になってほしい
[1] 拡張の「Details」をクリックし、「Allow this extension to read and change all your data on websites you visit」オプションを「On specific sites」に変更してから、サイトを許可リストに追加すればよい
「ブラウザ拡張は、コンピュータをどう使うかを深く制御していた感覚を思い出させる」とは、Linux ユーザーたちが一言言いたくなりそうだ
より一般的には、数年前に書いた「Is Open Source a diversion from what users really want?」という記事で議論しようとした問いとかなり似ている部分がある。ビルドシステムをいじらない形でソフトウェアを「ハック」する方法への興奮は、FLOSS が提供する完全で開かれた、理論上は無限のアクセスよりもはるかに大きく見える。なぜそうなのかには明白な理由があるように思えるが、それでも少し残念だ
Reaper のスクリプト可能だがクローズドソースな方式と、Ardour のスクリプト可能かつオープンソースな方式を対比して、ここで議論した: https://discourse.ardour.org/t/is-open-source-a-diversion-fr...
LD_PRELOAD のようなもので面白いハックはできるが、ブラウザ拡張の柔軟性とアクセスの容易さにはまったく及ばない。望むようにあらゆるソフトウェアを修正する権利はあるが、実際にそうする際の摩擦は比較的大きい
Chrome Web Store でおすすめされたChrome 拡張を作ったのだが[1]、怪しいデータブローカーたちが私の拡張を買い取ってスパイウェアを詰め込もうとする依頼を送ってくる数は本当に懸念すべきものだ
純真な開発者が素晴らしいものを作り、誰かが保守してくれるだろうと思って売ったものの、実際にはユーザーに危険を及ぼす可能性がある。Google は権限の使用レビューをかなりうまくやっているように思うが、私の拡張のようにページ上のすべてにアクセスする必要がある拡張もある。データブローカーがそれで何をできるか想像するだけで十分だ。インストール時には注意すべきだ
[1] https://chromewebstore.google.com/detail/css-selector-helper...
いちばん必要なのは、ストアからインストールしたブラウザ拡張に対する view source だと思う。ソースを簡単に見られて、ブラウザ拡張をフォルダとして展開できるべき。
どのWebページにアクセスし、何を変更したのかも簡単に分かるべき。拡張内の圧縮・暗号化されたコードは禁止されるべきで、コードはとても読みやすくあるべき。たとえばこの拡張は「ユーザー活動を記録」すると言っているが、それが実際に何なのかは分かりにくい: https://chromewebstore.google.com/detail/coffeelings/hcbddpp...
Webサイトの完全な一覧は拡張のインストールポップアップで確認できる。Chrome Web Store はすでにコードの難読化を禁止している。圧縮は許可されているが、変数名の品質を強制する意味のある方法がないため。
意図的に難読化されたコードには役に立たないだろうが、ほとんどの拡張に対するセキュリティ・プライバシー研究には役立つはず。
完全な拡張ではないが、userscript とユーザースタイルはかなり多くのことができるし、人々がブラウザ内で作って使えるようにしてくれる拡張もある。たとえば Tampermonkey[0] と Stylus[1] だ。
拡張ほど多くのことはできないとしても、非常に重要だと思う。
[0] https://www.tampermonkey.net/
[1] https://chrome.google.com/webstore/detail/stylus/clngdbkpkpe...
YouTube の “short” 表示から通常の動画表示へリダイレクトしたり、Gmail のスクロールバー右側のばかげた余白を削除するのにも使っている。
JavaScript/TypeScript ではないがプログラミングをしていて、拡張をものすごく多用し、Chrome/Firefox の拡張エコシステムがないブラウザは絶対に使わない パワーユーザー だと思っている。Chrome と VSCode のテーマも作ってみたが、それでもまだこの地点にいる。ピンク/シアンが好きならこちら: https://marketplace.visualstudio.com/items?itemName=mikejk8s...
Chrome のプロンプトを見ただけでは、拡張が何をできて、何を読み、見て、アクセスするのかまったく分からない。「すべてのWebサイトのデータへのアクセスを許可」は本当にすべてのデータなのか？ 自分が入力するものも？ URL から URL へ移動することも分かるのか？ アセットだけを読むのか？ アクセスを制限する Chrome API があって、それを自分は確認できるのか？ 実際に何を心配すべきなのか分からない。
どのWebサイトのどの動画でも拡大できる動画拡大拡張を使っているが、各拡張を自分で監査して、自分のデータをどこかへ複製していないことを確認しなければならないのか？ まったく分からないし、非技術系ユーザーがこれをどうやって知れるというのか。
画面・セッション録画系のスタートアップ製品は特に注意すると思う。ほかに理由がなくても、サプライチェーン攻撃に特に弱い可能性があるため。
だから自分のリストは、自分で作った使い捨て拡張、有名な大型拡張、あるいは自分でコードを監査したものだけにしている。
bookmarklet のほうが好み。編集しやすく、クリックするまで非アクティブで、すべてのブラウザで動作し、モバイルでも使えて、UI にうまく統合されるから。
好きなように移動し、任意のブックマークフォルダに入れ、ショートカットキーも割り当てられる。きれいなコードと bookmarklet の間の変換を簡単にするエディタを作った: https://www.gibney.org/bookmarklet_editor
共有できる良い bookmarklet があるのか気になる。