Mozilla Flux

Mozilla関係の情報に特化したブログです。

MozillaがPocketを買収 その狙いとは

MozillaがFirefoxにPocket(旧Read It Later)を統合すると決めたのは、2015年4月のことだった。それから2年近くを経て、Mozilla CorporationはPocketの開発企業であるRead It Later, Inc(以下RIL社)を買収し、完全子会社化する。この買収に伴い、Firefoxに統合済みの部分だけでなく、Pocketのコードは全面的にオープンソース化される予定だ(Bug 1343006)。ただ、有料版の扱いなど現時点では不明な部分も残る。

Mozillaの発表によれば、今回の買収はPocketが持つコンテンツのレコメンデーション機能を評価したものだという。だが、Pocketを統合した当初の目的は、そうした機能を取り入れることではなかった。MozillaはFirefoxに独自の「あとで読む」機能を実装し、デバイス間で保存リストを共有可能にしようとしていたのだが、それよりもRIL社と提携してPocketを統合するほうが、大きなメリットを得られると判断したのである。RIL社のNate Weiner CEOもインタビューの中で、Mozilla側から統合の話を持ちかけたことを示唆している。

MozillaとRIL社の取引は、レベニューシェア契約を含むものであったと判明しているが、おそらくMozillaにさほどの利益をもたらすものではなかったはずだ。今回の買収にあたり、Pocketに月間アクティブユーザーが1000万人いて、保存されたコンテンツが30億に達することが強調されているけれども、RIL社は総勢25人という小さな会社にすぎない。Mozilla以外の複数社から投資を受けてこの規模なので、米Yahoo!と複数年契約を結んで潤沢な手元資金を有する1000人規模のMozilla Corp.が、RIL社を買収して収入を増やそうとしたとは考えにくい。

Mozillaの意図を読み解く鍵は、Context Graphプロジェクトにある。その全貌はいまだ判明していないが、ユーザーの行動履歴を踏まえておすすめのWebコンテンツを提示する機能を提供しようとするものであることは確かだ。つまり、レコメンデーションである。将来のFirefoxに搭載されるほか、スマートフォン向けアプリとしても提供されることになっている。

ここでいう行動履歴には、Webの閲覧履歴やブックマークだけでなく、位置情報も含まれる。そして、匿名化された多数の行動履歴をあらかじめMozillaが収集・分析しておき、その結果をレコメンデーションに使う点が重要だ。Mozillaは今回の発表の中で、Pocketのコアチームと技術がContext Graphの取り組みを加速させるだろうと述べている。レコメンデーションの精度向上に応用するというわけだが、Pocketが擁する30億もの保存データを使わない理由はないだろう。

ユーザーの行動履歴の中にPocketの保存データを含めるメリットは2つ考えられる。1つはユーザーデータの多角的な収集だ。ユーザーが全く興味のないコンテンツを「あとで読む」ために保存する可能性は低い。ブックマークやWebの閲覧履歴と照らし合わせることで、ある特定のタイプのユーザーがどのようなコンテンツを好むのか、より深く分析できそうだ。もう1つはユーザーデータの広範な収集だ。将来的にアプリ版が大ヒットすればともかく、Firefoxでの利用をメインに考える以上は収集できるデータもFirefoxユーザーのものに限られる。だが、PocketはFirefox以外のブラウザに対応しているし、アプリ版もある。Pocketの保存データを加えることで、Firefoxユーザーを母集団とする偏りを是正できるかもしれない。

Mozillaの真の狙いがPocketの持つ大量のデータにあるのだとすれば、Pocketがブランドも含め現状のまま存続するという今回の発表内容もうなずける。データはWebの現状を的確に反映した最新のものに更新され続けてこそ意味があるわけで、FirefoxがPocketというサービスを囲い込むのは愚かな行為だからだ。ChromeやSafariのユーザーにもどんどんつかってもらい、アプリ版も広く展開していくのが正解なので、おそらくその方向に進むだろう。また、RIL社の完全子会社化も、Pocketに蓄積されたデータを独占するという側面がありそうだ。

もっとも、Pocketが擁するデータをMozillaの別のサービスに使うのであれば、利用規約やプライバシーポリシーの改訂が必要になってくるだろう。Mozillaはこれまでオプトイン方式でユーザー情報を収集する方針を貫いてきており、子会社となったPocketにもこの方針を適用するのが自然なはずだが、その場合レコメンデーションの精度を高めるためにできるだけ多くのデータを収集したいという要請とバッティングする。今後どのような形で折り合いを付けていくのか興味深い。動向に注目したい。

Firefoxでレガシーなアドオンが使えるのは2017年11月半ばまで

窓の杜で既報だが、The Road to Firefox 57 – Compatibility Milestones | Mozilla Add-ons BlogでWebExtensionsへの移行プランが発表された。周辺情報も交えつつ解説しよう。

まず、今回の移行プランでは、WebExtensions限定化の時期がFirefox 57のリリース時(2017年11月14日:米国時間)であることが改めて確認された。昨年11月の発表以来、影響の甚大さゆえに先送りされるのではとの噂が絶えなかったが、Mozillaはそうした観測を否定した。

また、レガシーなアドオンの定義や、移行対象のプラットフォームが明確化された点も見逃せない。XUL/XPCOMベースやAdd-on SDKベースの拡張機能だけでなく、埋め込み型WebExtensionsと完全テーマもレガシーなアドオンに含まれる。ここに埋め込み型WebExtensionsが含まれるということは、Firefox 57以降、WebExtensions APIのみで構築された拡張機能しか動作が許されないことを意味する。そして、プラットフォームの面では、Thunderbird/SeaMonkey向けのアドオンが対象外であると明言された。逆に言えば、Android版FirefoxはWebExtensions限定化の影響を受けるわけだ。

マルチプロセス化(e10s)との関係

最近のFirefoxは、バージョンアップごとにマルチプロセス機能(e10s)が有効化される範囲を拡大してきている。拡張機能の互換性はe10sの有効・無効を決めるうえで大きな要素だ。Firefox 50の時点では、WebExtensionsベースの拡張機能のほか、作者がe10sと互換性あり(MPC=true)に設定した拡張機能がインストールされている場合にだけ、e10sが有効化されるようになっていたが、Firefox 51になって、ホワイトリストに掲載された700を優に超える拡張機能(Firefox Beta版でのテストを経て問題なしと判断されたもの)も、e10s有効化の妨げにならなくなった(Bug 1329015)。Firefox 52もほぼ同じ基準になるようだ。

移行プランにおけるFirefox 53のリリース時(2017年4月18日:米国時間)の記載は、こうした経過を踏まえたものである。Firefox 53では、作者がe10sと互換性なし(MPC=false)に設定しない限り、e10sは有効化されるのが原則。例外的に、Mozillaが互換性に問題ありと判断した拡張機能がインストールされているとe10sを無効化する。

e10sの原則有効化と歩調を合わせるようにして、Mozilla Add-ons(AMO)ではレガシーアドオンの新規投稿を受け付けなくなる。既存のレガシーアドオンの更新は可能だが、野良アドオンにデジタル署名を付すことができなくなるとみられ、少なからず影響が出そうだ。

WebExtensionsの別プロセス化

移行プランでは、Firefox 54から56までに関する言及は少ない。Firefox本体のcontentプロセスの複数化(e10s-multi)とサンドボックス化の進展によって、レガシーなアドオンに互換性の問題が生じるかもしれないと記載されているのみだ。

だが、この間にWebExtensionsベースの拡張機能はFirefox本体のプロセスから独立して動作するようになる可能性が高い(Bug 1190679)。この拡張機能専用プロセスは、本体よりも強固なサンドボックス化が施される予定である(Bug 1334557)。ただ、Chromeのように拡張機能ごとにプロセスを割り当てることまではしない。

WebExtensions限定化

Firefox 57のリリース時にWebExtensions限定化の措置が執られた後も、AMOではレガシーなアドオンの掲載を続け、作者が更新できるようにする。掲載をいつまで続けるかは現在のところ未定だ。

WebExtensions限定化の措置はNightlyチャンネルから順に投入されていくため、Firefox Nightly 57のユーザーは、より早い段階で措置の影響を受ける。もっとも、Nightly/Auroraチャンネルに関しては、レガシーなアドオンをインストール可能にする設定が導入される可能性が高い。Nightly/Auroraチャンネルにはアドオンのデジタル署名チェックを回避する設定もあるため、AMOからレガシーなアドオンが排除された後も、Firefox本体の設定が残っている限り修正版を野良アドオンとして利用することができそうだ。ただ、Firefox本体に搭載されたe10sとの互換性を保つための仕組み(e10s shim)が削除されるため、本当に古い拡張機能はどうしようもない。

最後に、Mozilla Corp.でAdd-ons Developer Relations Leadを務めるJorge Villalobos氏による今回の移行プランに関するコメントを紹介しておく。

I fully admit the timing was bad. The opportunity and resources to launch WebExtensions came up when we were already into the initial e10s migration process, and the plans for Firefox also shifted in a way that WebExtensions can be the only path forward. We can’t support legacy add-ons for 2 years more because the APIs they rely on won’t exist then. Supporting them for longer only means extending the frustration of constant breakage, both for developers and users.

タイミングが悪かったことは完全に認める。WebExtensionsを起ち上げる機会とリソースが出てきたときには、既にe10sへの移行プロセスが始まっていたし、Firefoxの計画も変わって、WebExtensions以外に進める道はない。依存しているAPIがなくなってしまうので、レガシーなアドオンをもう2年サポートしろと言われても無理なんだ。サポート期間を延ばしても、頻繁に動かなくなってフラストレーションが溜まるだけだよ。開発者にとっても、ユーザーにとってもね。

現在開いているタブの隣に新規タブを開く(Firefox 51以降)

既にはてなブックマークには記録した情報で、Twitterにも流しているが、使っていて便利な機能なのでブログでも紹介しておきたい。

Firefoxのタブバーには、一番右端に表示されているタブの右隣に新規タブボタンがある。「+」のアイコンが目印だ。このアイコンをクリックすると、全タブの最右端に新規タブが開かれる。この「全タブの最右端」というのがくせもので、既に多数のタブがある場合、タブバーがスクロールして新規タブが表示されることになるため、直前まで開いていたタブがタブバーから消えてしまう。

Firefox 51では、Ctrlキーを押しながら新規タブボタンをクリックすることで、現在開いているタブ(以下「アクティブなタブ」)の隣に新規タブが開かれるようになった(Bug 528005)。直前まで開いていたタブの脇に新規タブをドラッグする手間が省けるわけだ。

f:id:Rockridge:20170212174237p:plain

ちなみに、常にアクティブなタブの右隣に新規タブを表示させるための拡張機能も存在する。Always Rightがそれで、Mozillaの中の人が作者なのでFirefoxの仕様変更がある際にも対応してくれそうだ。

ただ、「常に」ということなので、あるページのリンクを順次新しいタブで開いていく場合、後で開いたものほどアクティブなタブの右隣に来る。好みが分かれるところだろう。

(17/02/12追記)

Firefox 51から53までWebゲームプラットフォームとしての機能を段階的に強化(再追記あり)

MozillaはこれまでもFirefoxをWebゲームの強力なプラットフォームにすべく改良を重ねてきたが、Firefox 51以降の3バージョンの間にそのステージを1段階引き上げる。3Dの表現力だけならPlayStation 3/Xbox 360世代に匹敵する水準となり、ゲームのロードから開始までの時間が短縮され、動作の安定性も向上する。具体的にどのような変化が起きるのか紹介しよう。

Firefox 51

最近リリースされたFirefox 51では、WebGL 2が初期設定で有効化された。これを踏まえたプレイアブルなデモが、PlayCanvasの"After the Flood"である。大洪水後の荒廃した未来の町並みが美しいグラフィックスで描写されており、2012年3月に公開されたBrowserQuestと比べると、表現力の進歩を実感できるだろう。

www.youtube.com

WebGL 2はOpenGL ES 3.0がベースになっており、WebGL 1(OpenGL ES 2.0ベース)とは緩やかな後方互換性を保っている。WebGL 2の処理パイプラインの構造はWebGL 1のものをほとんど踏襲しているが、新機能の追加によって3D APIの表現力が増強されている。たとえば複数のテクスチャに対し同時に書き込みができるようになり(Multiple render targets)、複数のインスタンスを1回の描画命令で描画することが可能になった(Instanced geometry drawing)。また、3Dテクスチャや2Dテクスチャ配列がサポートされ、頂点シェーダで計算した結果を頂点バッファオブジェクトに書き込むこともできる(Transform feedback)。

Mozillaは今後、WebGL 2 APIのパフォーマンスを向上させるほか、一部の制約を緩和するなどAPI自体も洗練させていくとしている。

Firefox 52

Firefox 52ではWebAssemblyが初期設定で有効化される予定だ。JavaScriptのサブセットにすぎないasm.jsとは異なり、WebAssemblyはバイナリフォーマットを採用しているのでコンパクトだ。2016年3月時点で、そのサイズは非圧縮のasm.jsよりも42%小さいとされていた。現在はさらに差が開いている可能性がある。

パフォーマンスの面でも、WebAssemblyはasm.jsよりも良好なスループットを達成している。また、コンパイル時間の短縮も図られており、Unityのテストで3420ミリ秒から1492ミリ秒になったという話もある(Bug 1317033)。

このWebAssemblyに関連して、Large-Allocation Headerという機能が32bit版向けにFirefox 52で有効化されるかもしれない(Bug 1331083)。この機能はマルチプロセス化(e10s)を前提にするもので、ドキュメントにこのヘッダが付いていると、読み込み予定のページに独立したプロセスが割り当てられる。そのプロセスでは大量の連続的なメモリを確保できるので、WebAssemblyベースのゲームを読み込む際に有効であるというわけだ。

以上とは別に、Firefox 52ではSharedArrayBufferおよびAtomics APIが初期設定で有効化される(Bug 1312446)。SharedArrayBufferは、スレッド間で共同利用できるバッファを作ることができるというもので、そのバッファの操作やスレッドの制御を行うのがAtomics APIだ。

SharedArrayBufferが導入された背景については、A Taste of JavaScript’s New Parallel Primitives ★ Mozilla Hacksに説明がある。その和訳であるJavaScript の並列処理機能を味見してみる | Mozilla Developer Street (modest)から引用しておく。

これらに代表される JS (注:JavaScript)の適用範囲の拡大は、パフォーマンスの驚異的な改善によって可能となりました。それは JS エンジンに実装された Just-in-Time(JIT) コンパイラや、より高速な CPU によってもたらされました。

しかし、JIT による実行速度向上のスピードは低下しつつあります。また CPU 速度の改善はほとんど頭打ちになっています。CPU の高速化に代わる手法として利用されているのは、複数の CPU(実際は CPU のコア)の利用です。これは携帯電話からデスクトップにいたるまで広く利用され、ローエンドの環境を除けば、最低でも 2 つ以上の CPU が利用できるようになっています。このような状況でプログラマがプログラムの性能を向上させたいなら、複数のコアの並列利用を選択するでしょう。これは Java、Swift、C#、C++ のようなマルチスレッドプログラミングが可能な言語で書かれたネイティブアプリの話ではありません。Web Worker と、その遅いメッセージパッシング機構、そしてデータコピーの回避手段がほとんどないという、複数の CPU を利用するには極めて制限された機能しか持たない JavaScript での話です。

つまりは JS には問題があるのです:Web 上の JS アプリケーションが、ネイティブに代わる有力な選択肢であり続けるためには、JS を複数 CPU の上で動作させられるような機能を JS に持たせなければなりません。

要するにSharedArrayBufferは、PC側の複数CPUコアを利用して、並列に計算させることでJavaScriptの処理速度を向上させるための仕組みだ。重いゲームを動かす際に力を発揮することは、いうまでもない。

Firefox 53

Firefox 53では、別記事に書いたとおり、適格性のあるWindowsユーザーに対し軽量インストーラ(スタブインストーラ)が初期設定で64bit版をインストールするようになる(Bug 797208)。64bit版はOOM(out of memory:低メモリ)クラッシュが減って安定性が向上するだけでなく、パフォーマンスも向上することがベンチマーク結果から明らかになっている。

Windows版でQuantum Compositor(旧名GPUプロセス)が初期設定で有効化される点も見逃せない(Bug 1330554)。Geckoのcompositorに独立したプロセスを割り当てるこの機能は、GPUドライバが原因のクラッシュを45%も減少させる。64bit版である場合やDirect3D 11を使用する場合には、クラッシュ率を全般的に引き下げる効果も認められている。

(17/02/12追記)
Firefox 51以降の動きを紹介する主旨なので本文では触れていないが、2016年中にWeb Audio APIの仕様変更に追随するなど、オーディオ面でも性能は向上している。

(17/03/09追記)
Firefox 52の初期設定でWebAssemblyが有効化された(Bug 1342060)。他方、Large-Allocationヘッダは、Firefox 53(32bit版のみ)で有効化される見通しである。

(17/03/13追記)
WebAssembly + WebGL 2.0を駆使したZen Gardenデモが公開されている。高精細な3D画面が次々に展開されていく美麗なデモではあるが、ファイルサイズが約100MBあり、動作にかなりのマシンパワーとメモリを必要とする。Webの最先端を示すものといえよう。

www.youtube.com

その一方で、軽量インストーラが初期設定で64bit版をインストールするようになる時期は、Firefox 55へと後退した。64bit版でFlashの非同期レンダリングのサポートが遅れていることが原因である。ただ、Firefox 53のWindows向けインストーラでは、オプション画面でユーザーが32bit版と64bit版のいずれをインストールするか選択できる

(17/05/03追記)
Firefox 52/53ではSharedArrayBufferおよびAtomics APIの有効化が見送られた(Bug 1342095Bug 1354160)。投入はFirefox 54となる。

(17/05/14追記)
SharedArrayBufferおよびAtomics APIの有効化はFirefox 55へと延期された

2017年10月上旬までにWindows向け64bit版Firefoxの自動アップデートが開始(追記あり)

Mozillaは、米国時間の2017年3月7日にリリース予定のFirefox 52でAdobe Flash以外のプラグインのサポートを終了させた後、64bit版へのシフトを本格的に進めていく。

同年4月18日にリリース予定のFirefox 53では、適格性のあるWindowsユーザーに対し軽量インストーラ(スタブインストーラ)が初期設定で64bit版をインストールするようになる(Bug 797208)。適格性のあるWindowsユーザーとは、64bit版Windows 7以降を使用し、3.8GB以上の仮想アドレス空間にアクセス可能なハードウェアを使用しているユーザーのことをいう。物理メモリは64bit版Windows 7以降の動作環境である2GBを満たしていればOK。なお、OS X(macOS)向けFirefox 53は、Intel 64bit版に一本化される(Bug 1295375)。

そして、Firefox/Win64 - MozillaWikiおよびその改版履歴によれば、適格性のあるWindowsユーザーが32bit版Firefoxを使用している場合、2017年8月8日にリリース予定のFirefox 55か、同年10月3日にリリース予定のFirefox 56で、64bit版への自動アップデートが行われる。

自動アップデートの時期がFirefox 55と56のいずれになるかは、予想の難しいところだが、最近のMozillaのアグレッシブな姿勢からすると、Firefox 55のほうが可能性が高そうだ。もっとも、Firefox 55の時点では対象ユーザーの30%程度にアップデートの提供をとどめておき、発見された問題を潰したうえで、Firefox 56において100%に引き上げるといったことも考えられる。いずれにせよ、おそらく2017年末には、64bit版Firefoxのユーザー数が32bit版のそれを上回っているだろう。

(17/01/21追記)
本記事執筆後、Firefox/Roadmap - MozillaWikiにおいて自動アップデートの時期がFirefox 55になると発表された。

(17/05/09追記)
本文で記載したプランは変更されている。Firefox/Win64 - MozillaWikiの最新情報によれば、軽量インストーラ(スタブインストーラ)が初期設定で64bit版をインストールするようになるのは、Firefox 55からである。また、64bit版への自動アップデートは、Firefox 56.0.1のリリースとともに行われる。ただ、Firefox 56のリリース時期が9月26日に前倒しされたため、10月上旬までに自動アップデート開始という点は実現されそうだ。

(17/09/18追記)
最新の情報をMozillaがWindows向けFirefox 56.0に対し64bit版56.0.1への自動アップデートを提供予定 - Mozilla Fluxに記載したので、そちらも併せて参照してほしい。