近況報告たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。動向はもえじら組ブログで。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。Version既にTwitter等でお知らせしていますが、ツリー型タブのバージョン2.0~3.0.13とマルチプルタブハンドラのバージョン2.0~3.0.6に脆弱性がありました。3.0.7以降で修正済みです。自動更新を停止していたり、古いバージョンのFirefox用に古いTST・MTHを使用していたりすると、脆弱性を突かれる恐れがあります。更新またはアンインストールを強くお勧めします。詳細な説明はGitHubのissueに日本語でも記載していますが、端的に言うと「他のアドオンと連携するために独自に提供していたAPIの仕様がガバガバだった」という事になります。通常、WebExtensionsベースのアドオンでは明示的に宣言されインストール時に許可された範囲の情報しか取得できない。タブの現在のタイトル、URL、アイコンもそのような情報の一種。TSTやMTHは動作上どうしてもタブのタイトルやアイコンを知らなくてはいけないので、それらの権限を要求する旨宣言している。インストール時にもそのあたりの事が警告される。TSTやMTHは、他のアドオンの求めに応じてツリーの情報や選択されたタブの情報を返したりプッシュ式に通知したりするためのAPIを提供している。APIから得たtabs.Tabのオブジェクトに基づいて、それとの互換性を保つようにしていたため、その中に無条件でタブのタイトル、URL、アイコン、およびプライベートウィンドウのタブの情報が含まれていた。これらの情報が、本来は取得するために特別な権限が必要な物であるという事を失念していた。APIを使って呼び出す物だが、browser.runtime.sendMessage()の呼び出しには特別な権限は要らない。よって、TSTやMTHがインストールされている環境では、どんな権限でインストールされたアドオンからでも、全く無警告に、そういった情報を参照できてしまうという状態だった。一応、この「脆弱性」を使って悪さをするアドオンとしてこういう物が実際にある、というような報告はまだ受けていません。作者が自主的に行った仕様の再チェックで脆弱性が見つかったという事になります。「誰も気付かないような所、仕様の穴を突いたイリーガルな使い方をすると情報を盗み出せる」というような物ではなく、技術情報としてドキュメントも公開しているAPIを堂々と使って、WebExtensionsのアドオンごとの制限を突破して情報を取得できる、しかもその情報自体は実は2017年のバージョン2.0リリースの時から1年半以上もの間ずっと公知だったという、我ながら書いていて情けなくなるお粗末な状況なので、この脆弱性を利用した悪意あるアドオンが既に存在していても、全くおかしくはないと思っています。いうことで、もしそのようなアドオンを見つけた方がいらっしゃいましたら、お手数ですがどうかタレコミをお願いします。折良く(?)、Mozillaのアドオンコミュニティの担当者の方からおすすめアドオンの件について連絡を頂いたので、ついでにこの件についても相談してみました。何か進展があったらまた告知すると思います。それにしても、何故こんなにお粗末な事をやらかしてしまったのか。理由はいくつか考えられます。1つは、XULアドオン時代の設計思想を引きずってしまっていたこと。XULアドオン時代にはFirefoxのアドオンはすべての情報にフルアクセスというのが当たり前でした。TSTやMTHのAPIには、呼び出し元ごとに返す情報に差を付けないといけないという考えが全くありませんでした。聞かれた事はなんでも返していい、何故ならどうせ呼び出し元のアドオンだって、それらにアクセスしようと思えばいくらでもできるんだから。これがXULアドオン時代の考え方でした。他方、WebExtensionsでは、各アドオンは事前に許可された範囲の情報しかアクセスできないので、ユーザーは各アドオンの権限だけを気にすれば良いという事になっています。この事ばかりが強く印象に残っていたことと、とにかくXUL版から機能を移植するという事にばかり気を取られていたために、アドオン同士の間ですらもアクセスできる情報の範囲に差があるという事が、頭の中からすっかり抜け落ちていたのだと思います。「アドオン同士の権限に差がある」というWebExtensionsの世界に合わせるには、TSTやMTHのAPIにもその考え方を反映しないといけなかったんですね。APIから入手した情報は、相手のアドオンにとっても同様に正当な手順で入手できる情報だ、とは限らないのです。それを忘れて呼び出し元の求めに応じてなんでも返してしまっていたというのは、「内緒にするから教えて」と言って教えてもらった情報を、他人にホイホイ言いふらすようなものです。2つ目の理由は、permissionsで宣言する権限の影響範囲を正しく把握しきっていなかったこと。tabsという権限の名前からはいかにも、タブに関する事なら何をするのにも、例えばタブの一覧を取得するのにすらも必須であるような印象を受けます。TSTやMTHのAPIを呼ぶには呼び出し側のアドオンがタブのIDを知っている必要があり、タブのIDを知っているなら当然tabsの権限も持っているはず、ならタブのプロパティ全部渡しても問題無いはず(どうせ呼び出し側のアドオンが自分でも同じ情報を取得できるんだから)。いうのが、これらのAPIを作った時点での自分の認識だったのだと思います。APIはtabsの権限無しでも呼ぶ事ができます。tabs/activeTabの権限の有無は、タブの一覧を取得できるかどうかではなく、返されるタブの情報にタイトルやURLなどのセンシティブな情報が含まれるかどうかという点にだけ影響します。TSTやMTHをWebExtensionsで実装するにあたって、まだWebExtensionsの仕様への理解が浅かったかなり初期の時点でtabsの権限を設定したきりだったために、この勘違いがずっと正されないまま今に至ってしまっていたのでしょう。他のアドオンを作る時にも、自分はひょっとしたらtabsの権限が不要なのに要求してしまっているという例があるかもしれません。今回のことから得られた教訓は、以下のようにまとめることができると思います。それぞれの権限が何を可能にするのか、その権限が無いと何ができなくなるのかを、ちゃんと理解しておく。不要な権限は要求しないようにして、常に必要最小限の権限だけをpermissionsには列挙する。APIから自分の権限で取得したオブジェクトをそのまま使い回して、他のアドオン向けのメッセージに含めてはいけない。センシティブでない事が分かっている情報だけをホワイトリスト形式で抽出して、スクラッチでメッセージを組み立てること。Tab(ツリー型タブ)以外の物をまとめた。ボタンでポップアップが表示されるタイプの物を除外した、サイドバー常時表示型の物だけです。TabsSidebery(手動操作で設定を有効化する必要あり)ftt:TSTの欠点である不安定さを原理的に排除する方針で設計されているとのこと。TabsSidebar+Tabs2Listじっくり使い込んだわけではないけど、これらの中ではSideberyがぱっと見の出来がいいように見えた。(2019年7月10日追記)また、新顔のfttも興味深い。TSTと同様に他のアドオンとの互換性を維持することを目標に置きつつ、WebExtensionsのタブ関係のAPIをもう一層ラップするライブラリを用いて、安定性を損ねる原因となっている複雑な非同期処理を排除しているらしい。多機能ではないシンプル路線での有望株だと思う。TSTをWebExtensionsに移行したときは、その時点でも既に結構な数の縦型タブバーアドオンがあったので、「縦型タブバーとしては後発だ」と認識してたんだけど、その後もまだまだ新しい物が作られてるというのは興味深いです。Chromeには存在せずFirefoxやOperaなどでしか使えないため、ブラウザのシェア的にはそこで頑張っても社会的にはあまり報われませんので。以前、アドオンの勉強会でFirefoxのWebExtensionsに固有のAPIを紹介した時に「Chromeで使えないなら使わない」という反応をもらった事を考えると、まだまだ自分の他にもへそ曲がりがいるものなんだなあ、とちょっと嬉しくなってしまいます。Reduxでも1万2千人で、TSTの約13万人とは10倍の開きがあって、なんでこんなにTSTのユーザー数が多いのか?と我ながら不思議に思ってしまう。単純に歴史が古いから(XUL時代を含めると12年)だけでしょうか。先行者利益というか残存者利益というか。古くからあるから出来が良いのかっていうと別にそんな事ないんですけどね。実際、1000とかメチャクチャ大量のタブがある状態で試してみると、ここに挙げたアドオンはどれもTSTに比べると圧倒的に起動が速かったし。いうかTSTが桁外れにクソ遅かった(これは僕が動作速度や処理効率に比較的無頓着なせいだと思ってる)。3.0でだいぶ高速化はしたつもりだけど。2019これはただの苦労話です。Tab、TST)の大規模改修をやりました。見た目は変えなかったのであまり代わり映えしませんし、挙動を決定づけるロジックもほぼそのままなのですが、それらが乗っかる基盤にあたる部分が入れ替わった感じです。何を改修したのか、どういう成果があったのか、という事を説明するために、TSTのこれまでの歴史を振り返ってみます。WebExtensionsに移行した時の話ではあまり触れなかった、細かい実装の話が多めですが、誰の役に立つかは分かりません。いうbug(※bugzilla.mozilla.orgではシステム上でトラックされているタスクを一般的に「bug」と呼ぶ)でどうやら何かアドオン(拡張機能)作ってみましょう的なイベント?の準備が進められているらしいという事を、人から教えて頂いた。script等の話が出てきてるのを見て、ちょっとキナ臭いというか不安というかそういう思いが頭をよぎった。このキャンペーンサイト(多分)の内容を素直に受け取ると「WebExtensionsのAPIを使ってアドオンを作ろう。他のブラウザにも移植しやすいよ。」というような話になってると思うんだけど、いやちょっと待ってくださいよ。V3に移行しちゃったら、それ動かないじゃんすか。V3に移行するってことじゃんすか。V3に行っちゃって、そしたらChromiumベースでないFirefoxだけ置いてけぼりじゃんすか。いう事に、遅まきながら気付いたわけです。Meetupに参加されていた方が実装上困っておられた事について「Firefoxでは(Chromiumに無い独自拡張の)APIがあるから、Firefox向けにだけちょっと便利にするみたいなことはできるよ」的な話をしたら、「いやあ......Chromeで使えないんじゃ、その機能は使えないですね......」と敬遠された時に、改めて思い知ったのですよね。V3に追従する予定はないみたいな話をどっかで又聞きした気がしてますが、いやいやそんな悠長なこと言うとれんやないですか。V3に対応は絶対しなきゃいけないじゃないですか。ほんとどうなるんだこれ。難しい事は脇に置いて、「アドオンを作る人」「ベンダが提供しているUIに気に入らないところがあってイラッてなったときに自分で手を動かして解決したい人」という立場から「こうだったらいいのに」という事を書き留めておきますと、ブラウザ本体が提供するUIが気に食わない時に努力次第でゴッソリ置き換えられる余地は欲しい。TabやVimiumのような)こういう物を実現するにあたっては、筋の良い設計にしようとするとどうしたって「永続的なバックグラウンドプロセスが全体を統括する」という設計になるので、それができる余地は欲しい。常時見える状態で画面上の領域を占有できる余地は欲しい。V3は、自分が欲している物とはかけ離れている。サイトごとの権限と機能の権限は、確かに別々に記述できるべきだと思う。V2/現行WebExtensionsのpermissionsの書き方はあまりにダサイ。フィルタリングを宣言的に簡単に設定できることは、単純に良い事に思える。現行のwebRequestのような「クライアントサイドでリクエストやレスポンスの書き換えを任意に行える機能」は、新しい事をやる余地を残すために必要だと思う。現状のようにシレッと他の権限と一緒に一言だけの注意書きで確認を求められる程度ではなく、「黄色と黒の縞々」みたいな禍々しい外観で激しく警告するような事は必要だと思うし、もっと細かく権限の段階を分けた方が良いと思う。このページは拡張機能の何々によって内容が改変されています、みたいな警告をロケーションバーあたりに表示しておくというのもありかもしれない。自己責任で愚行権を行使できる余地は認められていて欲しい。いうのが欲しい人はApple製品を使うのが筋だと思う。技術屋が高級ブランド家電屋になろうというのが無理がある。いう風な事を自分は思っています。2019ちょっと前に話題になったChromeの拡張機能のAPIの新バージョンの案の概要を把握するために、変更点のまとめの部分だけを読んでみた。全訳するのも大変なので、適宜つまみながら。動機APIや権限の仕組みに対して大規模な変更を行う物なので、マニフェストバージョンを3に上げる。拡張機能が実際に使用しているAPIや権限の中には、パフォーマンス、セキュリティ、プライバシー、および人間工学的な観点から、ユーザー体験を低下させている物が多数ある。新しいマニフェストバージョンではそういった負の影響を与える要素を一掃し、新しいAPIや機能だけを使えるようにする予定である。拡張機能の作者達に向け、移行を容易にするための明確な手順と、新基準に拡張機能を移行するに足る追加のインセンティブを用意するつもりである。マニフェストV3では、安全・高速・プライバシーに配慮された拡張機能を容易に開発できるようにし、一方で、危険・低速・プライバシー情報の漏洩に繋がる拡張機能を開発しにくいようにする。拡張機能の品質を高め、ユーザーに積極的に勧めやすいような物にする。マニフェストV3に基づいて開発される拡張機能は、外部からの攻撃(その拡張機能を狙ってXSSを仕掛けてくるような悪意あるWebサイトなどからの攻撃)と、内部からの攻撃(悪意ある拡張機能)の両方に対して、より強力なセキュリティ機構を保証するのが望ましい。ユーザーは安心して拡張機能をインストールできることが望ましく、そのためには、その拡張機能が重大な損害をもたらし得ない事を保証する必要がある。その結果、自動および手動でのレビューをより容易にする。ユーザーは拡張機能に対してより広範な制御権を持つことが望ましい。ユーザーは各拡張機能に対して、どの個人情報の使用を許可するかを制御できることが望ましい。マニフェストV3に基づいて開発された拡張機能は、より高速になる事が望ましい。長時間動作するバックグラウンドプロセスは禁止されるべきである。APIは高速・効率的である事が保証されている必要があり、性能を劣化させるような誤った使い方がしにくいようなAPI設計となっていることが望ましい。Workersへ移行する。コンテンツのデータへのアクセスの制限については、activeTabスタイルの、実行時にのみアクセスが許可されるモデルへ移行する。リモートに置かれたコードについては、直接の実行を禁止する。クロスオリジンの通信は、コンテントスクリプトはWebページのスクリプトと同じルールに基づくこととして、拡張機能のページは過去にアクセスしたことがあるサイトに対してはクロスオリジンの通信を可能とする。PromiseベースのAPIとする。優先度2(高い)Webからアクセスできるリソースについては、拡張機能の実行コンテキストから切り離された安全な領域に登録されたリソースを、動的に生成されるURLで読み込む形とする。動的なコンテントスクリプトについては、それに特化した権限の仕組みを設ける。リソースの読み込みをブロックする使い方を制限する。