uBlock Origin Lite開発者、Firefoxストアのサポートを終了
(neowin.net)- uBlock Origin Lite は Firefox Add-ons Store での配布が中止され、開発者の Raymond Hill は拡張機能を セルフホスティング に移行
- Mozilla のレビューチームは 9月初旬、すべてのバージョンをポリシー違反と表示し、ユーザーデータ収集および “minified, concatenated or otherwise machine-generated code” の含有を問題視
- Hill は、その指摘は JavaScript を基本的に理解していれば成り立たないと反論し、レビュー手続きを “nonsensical and hostile” だと見なした
- Mozilla はその後、GitHub Issue に含まれたメールでミスを認めて謝罪したが、uBlock Origin Lite は依然として addons.mozilla.org では見つからない
- Firefox ユーザーは GitHub から最新バージョンを入手する必要があり、既存の uBlock Origin for Firefox は引き続き提供・サポートされる
Firefox Add-ons Storeでの配布中止
- uBlock Origin Lite の開発者 Raymond Hill は、Firefox Add-ons Store のレビューチームによる “nonsensical and hostile” なレビュー手続きを何度も経験した後、ストアのサポートを終了
- 9月初旬、Mozilla は uBlock Origin Lite のすべてのバージョンをポリシー違反と表示
- レビュアーは、この拡張機能がユーザーデータを収集しているように見えると判断
- “minified, concatenated or otherwise machine-generated code” が含まれている点も問題視
- Hill は、JavaScript を基本的に理解している人なら、その指摘が成り立たないことは数秒で分かると反論
セルフホスティング移行とユーザーへの影響
- Hill は拡張機能を Firefox Add-ons Store から取り下げ、セルフホスト版 へ移行
- Firefox で uBlock Origin Lite を引き続き使いたいユーザーは、GitHub から最新バージョンをダウンロードする必要がある
- このバージョンは自動更新に対応している
- クローズ済みの GitHub issue の最後のメッセージには、Mozilla がミスを認めて謝罪したメールが含まれている
- それにもかかわらず、uBlock Origin Lite は Mozilla Add-ons Store から削除されたままで、addons.mozilla.org ではもう見つからない
uBlock OriginとManifestバージョンの文脈
- 既存の uBlock Origin for Firefox は引き続き提供・サポートされる
- Lite 版は Manifest V3 ベース の拡張機能で、プロセッサーやメモリーなどのリソース使用負荷がより軽く、効率的
- Hill は、Chrome が uBlock Origin を未サポート拡張機能として表示し始めた後、uBlock Origin Lite への移行を勧めていた
- Mozilla は近い将来に Manifest V2 ベースの拡張機能 のサポートを終了する予定がないため、uBlock Origin は Firefox および MV2 対応ブラウザーで引き続き存在し、動作する
1件のコメント
Hacker News の意見
職場で中規模のブラウザ拡張機能を管理しており、Firefox にも提供していたが、手動審査の後に Mozilla ストアへ戻そうとして、この1年ずっと苦労している
米国にいるのだが、審査担当者はヨーロッパ、おそらくルーマニアあたりに2人ほどしかいないようで、応答時間が長く、「プライバシーポリシーが必要だ」のように既にあるものを見落としたり、ビルド成果物を見て「機械生成・難読化コード」だと言ったり、案内に従わず間違ったディレクトリで「ソースを再現できない」と言ったりするような単純なミスを解決するのに2週間ずつかかり、非常に苛立たしい
再現可能なビルドを要求する一方で、正しい yarn バージョンをインストールできず、README に太字で何度も書いておいた正確なインストールコマンドや、Node バージョンのインストール手順、自動化スクリプトといった基本的なセットアップ手順にも付いてこられません
民間企業が非公開の NPM モジュールを使うという「狂ったこと」をすると、さらに厄介になります。事前設定したアカウントへのアクセスを提供したり、審査用アカウントの権限を付与すると言っても、Mozilla は「審査中に外部アカウントを使うのは難しい」と言います
ブラウザの審査チームとやり取りしなければならないこと自体が、もはや Firefox を勧めない大きな理由です。せいぜい無能で、Google 検索契約の収入を最大限吸い上げているだけで、代替となる安全なブラウザを本気で提供しようとしているようには見えません
ところが、その拡張機能は Rust から wasm ファイルをビルドする構成で、何度かやり取りした結果、その wasm は再現可能である必要がないという結論になりました。拡張機能の中核で、ロジックの99%が入っているにもかかわらずです
JS が再現できたところで、wasm の中に任意の潜在的な悪意あるコードを隠せるなら、何の意味があるのか分かりません
しばらくは AMO 側の「再現可能なビルド」を単純にするため、事前ビルドした wasm をソースパッケージや npm に入れる案まで真剣に検討しましたが、それでは実際のビルド方法からさらに遠ざかってしまいます
場合によっては、審査担当者が仮想マシンを使い回している、あるいはそもそも使っていないとも聞いたことがあります
審査フォームには git リンクを貼り付ける入力欄があり、指定されたメモリとディスク容量の VM を立ち上げ、git を clone した後に
docker build -t ./docker/review/Dockerfileを実行する、きちんと文書化された自動化パイプラインがあるものだと思っていました審査担当者たちも仕事の満足度の面から、こうしたツールを組織に強く求めていそうなものですが、意外です。怒ったアプリ所有者たちにどれほど悩まされているのか、想像するのも難しいです
結局その会社は、利用量が少なく審査があまりに苦痛だったため、Firefox 拡張機能の更新頻度を下げました。その会社で Firefox を使っていた唯一のエンジニア、もしかすると唯一の社員だった立場としては残念でした
ある程度の技術が必要な仕事である一方、かなり退屈でもあり、そうしたより面白い仕事のほうが報酬も良い可能性が高いです
Mozilla で働いていますが、Addons とは距離があるので、そちらがどんな圧力を受けているのかは分かりません
それでも自分が運営するなら、今の相手は gorhill です。彼を全権限を持つアドオン審査担当者にして、自分の拡張機能だけ審査してよいと言うでしょう
彼の能力や信頼性を検証する必要はありません。どんな契約者や社員よりも、はるかに多くの過去データが彼を裏付けています
彼が唯一無二のケースというわけでもありません。以前ほどボランティア中心ではありませんが、今でも多くの重要な貢献はボランティアから生まれており、少なくとも SpiderMonkey チームには外部貢献者と有給貢献者の間に壁はありません
gorhill を審査チームの正式メンバーにできない理由はなさそうです。今の状況を見ると彼がすぐ受け入れるとは思えませんが、他の人や組織に与えられる特例を与えるよりも妥当です
彼はすでに Firefox の能力と成功に大きく貢献しているのだから、既に存在し価値もある審査にも貢献してもらえばよいのです。自分の審査だけでも十分だと思います
さて、Slack で誰にちょっかいを出せばいいか探さないといけません
スーパースターであっても、セキュリティ慣行が緩まないよう、他の人にコードを見てもらうべきです
このような特権を認めれば、境界線上にいる他のスーパースターたちも同じ権限を望むでしょう
科学出版でも、編集長であっても自分の論文は他の人が査読し、意思決定プロセスは本人の見えないところで進みます。それが科学にとって良いことです
良いアイデアかもしれませんが、Mozilla が評判を一貫して評価していないという新たな不満を受ける可能性があります
https://wiki.mozilla.org/Add-ons/Reviewers/Guide/Reviewing
代わりに ESR/Developer/Nightly 版を使い、
xpinstall.signatures.requiredを false に設定しなければならず、セキュリティが大きく低下します1週間以内には戻ってくると思いますし、Firefox では通常の uBlock Origin よりバッテリーを節約できるので重要です
タイムラインを正しく理解しているなら、gorhill は過剰反応したように見える。過去5年以上、Mozilla がやってきたほぼすべてのことに対して、普段はかなり厳しく批判的な立場から見てもそう思う
Mozilla がすべてのアドオン改訂版を手動で、安全に、かつ期限内にレビューするのは現実的に難しく、結局は自動化と大幅な遅延のどちらかを選ばざるを得なかったはず。自動化には偽陽性が必然的に発生する
代替案は何だろうか。リリース前レビューを完全になくすことだろうか。ユーザーとしては、そうならないことを望む。実際に、派手なサプライチェーン攻撃が野放しの環境で実行されていることまで確認されている状況だ
レビュー方針は gorhill 自身も守っている。スパイウェアを入れろと脅迫されても、リリース前に見つかる可能性があるなら、彼を物理的に脅迫する標的にする魅力は少し下がる
Gorhill や他の上位拡張機能開発者たちは Firefox に実際の価値を提供しており、長年にわたって良好な振る舞いを示してきた
好き勝手に公開してよいという意味ではないが、レビュアーが有名プラグインを拒否しようとするなら、二人目が確認すべきだ。今回のミスも当然見つけられたはずだ
「Firefox は開発者リレーションにあまり投資していない」という、また別の事例のように感じる。彼らに大きく依存していることを考えると驚きだ
uBlock Origin Lite に840万ユーザーがいるなら、gorhill に Mozilla の専任担当者がいないのは理解しがたい。拡張機能に問題があれば電話で知らせるべきレベルだ
Mozilla が使っている自動スキャンツールが「これは Google Tag Manager だ」と検出し、不審なスクリプトを含むアドオンに通常送る警告を出した可能性が高い
ただしメールには「Mozilla Add-ons チームが手動でレビューした」と明確に書かれている
それが嘘であるか、手動レビュアーが自分の実行した自動ツールに偽陽性があり得ることを理解していなかったかのどちらかだ
Mozilla のようなプラットフォームで自動の悪用検出を行うこと自体は問題ないが、コミュニケーションで嘘をつくべきではない。そうでなければ、アドオンのブロックを扱うときに自分が何をしているのか分かっている人を雇うべきだ
セルフホスト拡張機能であっても、提出時にレビューを通過できず任意の時間待たされる必要があり、フィルタリングルールが拡張機能にパッケージングされる状況では時間が重要だという。承認通知を受け取ると、再び拡張ファイルを手動でダウンロードして名前を変更し、その後 GitHub にアップロードし、
update_urlを新バージョンに手動でパッチする必要があるとのこと2024.9.12.1004を提出してからセルフホストの承認を受けるまで5日かかり、執筆時点では2024.9.22.986もまだ承認されていなかった趣味でやるにはまったく楽しくなさそうだ
https://github.com/uBlockOrigin/uBOL-home/issues/197
彼は uBlock を趣味でやっている個人開発者で、寄付も受け取っていないので、私たちに何か借りがあるわけではない
レビュー手続きが自分の時間とエネルギーを注ぐほど円滑かどうかを判断する権利があり、今回はそうではないと判断しただけだ
拡張機能をオープンソースにしているのだから、誰でも代わりに uBlock Origin Lite を公開できる
https://github.com/uBlockOrigin/uBOL-home/issues/197
これは自動レビューではなく、不十分な手動レビューだった
作者は AMO のレビュー手続きに何が含まれるかについても追加で説明しており、そのストレスを引き受けたくないと言っている。また、やや有害なバージョンのプラグインが残っている点にも触れている
ストレスを引き受けたくないというのは、完全に理解できる反応だ
一般ユーザーに配布するには、拡張機能を門番に提出しなければならないというのが非常に苛立たしい
gorhill が GitHub で述べていたように、セルフホスト版の承認にも数日かかったが、これは受け入れがたい
ソフトウェアを配布するのに Microsoft の承認が必要だと想像してみてほしい。Android ですらここまで閉じてはいない
署名の強制と XUL の廃止は、Mozilla が行った最悪のことだった。Google も同じで、さらに悪いが、それは Google なら予想されることであって、Mozilla に期待していたことではない
XUL 廃止後しばらく VimFx を維持していたので分かる。変わり続ける内部 API に追随するのは難しかったが、彼らも製品を開発しなければならないので責めることはできなかった
VimFx のメンテナンスを諦めさせた本当の理由は署名の強制だった。「自分のコード」ですら、まともなユーザー体験で実行できないように、どんどん締め付けを強めていった
望んでいた方向性は、WebExtensions を互換性と廃止保証のある推奨方式として提供し、他の API の互換性は気にせず、内部 API を使う外部の「フルアクセス」拡張機能は引き続き許可する、というものだった
ストアで「この拡張機能はサポートされていない API を使用しているため、いつ壊れてもおかしくなく、すべての個人情報を盗む可能性がある」と警告し、インストールボタンを真っ赤にしても、許可はすべきだった
開発者が管理する署名キーと更新 URL を使うセルフ配布の拡張機能も、引き続きサポートすべきだった
こうした API には互換性保証がないのだから、追加作業もそれほど多くなかったはずだ。恐ろしい警告を追加する少しの UI 作業と、ストア外更新コードの維持程度だったはず
ますます多くのプラットフォームがこの方向に進んでおり、Windows も将来そうなっても驚かない
モバイルでは、Mozilla のリポジトリ外から拡張機能をインストールするには Nightly ビルドが必要なようで、これは彼らの考え方がモバイルエコシステムの他の部分に汚染されつつあることを示唆している
アドオンをストアから削除するような極端な措置を取る前に、Mozilla は審査で質問や懸念があるならまず連絡すべきだ
有名人であるか、フォロワーが多いか、アプリや拡張機能が非常に人気でない限り、 timely に解決されることは期待しにくい
Gorhill の完全版 uBlock Origin は、Firefox に残されたほぼ唯一のセールスポイントかもしれない
Mozilla の最高経営陣が最近受け取った途方もない金額があれば、代わりに一流の人材でチームを一つ組み、Mr. Gorhill が必要とするすべての作業を専任させることができたはずだ
直近では、どのユーザーも求めていない privacy preserving attribution 機能を追加した
この拡張機能がなぜ AMO に存在するのか分からない。記事によれば「Lite/Manifest v3 版」らしいが、Firefox 向けに広告をきちんとブロックする版ではなく、旧式ブラウザ向けの劣化版をなぜインストールするのだろう
宣言的なドメインリストはキャッシュしやすく、不要な拡張機能の起動を減らす。権限が少なければ、将来マルウェアに感染したバージョンがストアに上がったときの影響もはるかに小さくなる
uBlock のルールエンジンは非常に強力で、カスタムルールセットがどんなウェブサイトにもコードを注入できるほどだ。これはカスタムルールだけでなく、アカウントやホスティングがハッキングされたり、後で売却されたりする可能性のある内蔵ルールにも当てはまる
もちろん、私が Lite 版を使うという意味でも、Google の選択に同意するという意味でもない。彼らは代替 API を提供せずに広告ブロック APIを殺したのだから
いずれにせよコードは公開されており、Google Chrome を使い続ける人もいるのだから、Firefox でもこの版を提供することはできる
より良い問いは、Firefox が私の望むことを拒むなら、なぜ Firefox を使うのかということだ
これはかなり過酷に見える。Mozillaはミスをし、謝罪し、ミスを修正し、おそらく手続きも改善したのに、作者はそれでも拡張機能を取り下げてMozillaを批判している。
私には、作者がこれをあまりに個人的に受け止めたか、審査手続きの改善を求めて強いメッセージを投げたように思える。その過程で、プロジェクトの可視性はいくらか損なわれた。
https://github.com/gorhill/uBlock/issues/38#issuecomment-918...
だからMozillaの審査手続きにも嫌気が差してやめると言うのは、予測できることだ。
そのとき彼はプロジェクトを良心のない任意の人物に譲り、その人物はすぐに収益化しようとした。Raymondはその結果を嫌い、自分の以前のプロジェクトを批判しなければならなくなり、結局、多くの追加作業を挟んだだけで、ほぼ出発点に戻った。
こうしたプロジェクトは、作者がコミュニティに価値ある贈り物をしており、コミュニティがそれを受け入れて感謝していると感じられるときにうまく回る。
自分の創作物を感情のない「審査」手続きに提出しなければならず、誰もまともに見ていなかったことが明らかな形で拒否されれば、それは単なる意欲低下ではなく侮辱だ。
私でも去っただろう。
作者との事前の双方向コミュニケーションなしに、アドオンが再び削除されないという保証すらしなかった。
Mozillaにはプレスリリースのページがあるのだから、何が間違っていて今後どう変えるのかを公に明確に出せたはずだ。この拡張機能が優れていると認め、ユーザーに提供され続けるよう資金を拠出することもできた。
だが代わりに、審査担当者が大失敗した後、面目を保つために可能な最小限のことだけをした。最初の審査で挙げられた根拠は明らかに誤っており、初級のJS開発者でも分かるレベルだ。
それどころかAI審査者のほうがましだっただろう。ChatGPT 4o miniは、このファイルは難読化コードには見えず、空白・改行・コメントが削除された圧縮形式でもなく、コメント・インデント・構造化された関数があるため、難読化コードの特徴ではないと判断した。
Firefox「ストア」を運営する人たちのように、冷たく無感情ではいられないのだろうか。
彼の立場なら自分は違う行動をしたかもしれないとしても、どこかの時点で十分ということはある。
それにMozillaは謝罪していない。謝罪警察をやるつもりはないが、あれは“apologize”という単語が入った形式的なカスタマーサポート風の文にすぎない。
その程度で十分だったし、誰もそれ以上を期待してはいないが、それが何であるかはそのまま認められる。
正当な対応だ。uBOはキラー拡張機能なのに、MozillaはGoogle式のひどい機械主導の拡張機能審査手続きを押し通すなら、少なくとも現存する最も重要な拡張機能の一つには例外を設けるべきだとは思わなかったようだ。
Mozillaが「ミスに気づいた」としても、gorhillがこの件全体に完全に腹を立て、協力を拒むのは理解できる。
彼らのミスは、多くの拡張機能・オープンソース開発者と同じように、彼がわずかな感謝と増え続ける要求を対価に雑務に耐えるだろうと想定したことにある。
結果はまったく理想的ではないが、残念ながら責任は全面的にMozillaにある。
メインの拡張機能はChrome/EdgeよりFirefoxのほうが常に新しい。
そうやって広告ブロッカーを処理するわけだ。すでにChromiumに広範な支配力を持っているので、残る実質的な代替は、攻撃するのがはるかに難しいSafariだけだ。
GoogleがFirefoxの広告ブロック拡張機能を止めることはできないが、Firefoxを事実上の放置ソフトウェアのように運営するようMozillaを促して、死なせることはできる。
Mozilla Foundationが自分たちの立場をここまでひどく台無しにしたのは恥ずべきことで、これらの行動を単なる無能だけで片づけるのは難しい。
Firefoxがこれをサポートしていなかったら、別のブラウザを使っていただろう。Mozillaがきちんとできることがますます減っている状況なら、gorhillを丁重に扱うべきだ。
Raymond HillがuBlock Origin、つまりManifest v2版に同じ措置を取らないことを本当に願っている。
他の人に自己ホスト型拡張機能のインストールを勧めるのは、あまり気が進まない。
MozillaとRaymond Hillがこの問題を一緒に解決できない、あるいは解決しないのは残念だ。こうした拡張機能がそんな審査を受けるべきではなかったことは理解できるし、彼がもう気にかけたくないことも理解できるが、この状況がuBlock Originプロジェクトの長期的な安定性にどんな影響を与えるのか心配だ。
全体の状況は明らかに健全には見えない。
https://github.com/uBlockOrigin/uBOL-home/issues/197#issueco...
取るに足らないプラットフォームが一つ意地を張ったからといって、プロジェクトが危険だと示唆するのはばかげている。
リリースから約1週間たっているのに、Firefoxアドオンサイトで入手できる最新バージョンは1.59だ。