Mozilla Flux

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

拡張機能のデジタル署名の有効期限問題

最近、多数の拡張機能が一斉に更新されたことに気付いた方も多いのではないだろうか。Firefoxのアドオンマネージャから個別の拡張機能の項目を開くと、名称が例えば"Make Link 11.03.1-signed.1-signed"のようになったものが見つかるはずだ。

f:id:Rockridge:20160501220028p:plain

この.1-signedは、Mozilla Add-ons(AMO)に登録されている拡張機能に対し、Mozillaが自動的にデジタル署名を付与したことを示す。.1-signedが2つ並んでいるということは、自動的な署名付与が2回行われたことを意味するわけだ。そして、最近の一斉更新は、この2回目の署名付与が行われたことによる(Bug 1267361)。

なぜわざわざ2回目の署名付与が必要だったのかといえば、1回目の署名の有効期限が1年に設定されており、そのままでは期限切れになった拡張機能が使えなくなるからだ(Bug 1267318)。Firefox 43の初期設定で未署名の拡張機能は無効化されるようになっている*1。放置すれば数週間以内に混乱が生じることは必至だったので、Mozillaは有効期限を5年とする新たなデジタル署名を付与した。

また、ひとまずデジタル署名の有効期限を無視する修正がFirefox 46以降とFirefox ESR 45に加えられた(上記Bug 1267318)。近日中にリリースされるとみられる修正版であれば、Mozillaによる2回目の署名(以下「新署名」)が付与されていない拡張機能であっても、無効化されずに済む。

問題となるのは、拡張機能に対する署名チェックが入ったFirefox 43から(非ESR版)Firefox 45までを使用し、かつ、AMOに登録されていない拡張機能をインストールしている場合だ。新署名が付与されないまま元の署名の有効期限が切れてしまうので、対象となる拡張機能は無効化されることになる(以下の表を参照)。その場合、Firefox本体を最新版にアップデートすることが安全で確実な対処法ではあるが、about:configからxpinstall.signatures.requiredをfalseに変更する手もある。

Firefox 46以上/ESR 45 Firefox 43 - 45
拡張機能(新署名あり) 問題なし 問題なし
拡張機能(新署名なし) 問題なし 問題あり

なお、さすがに.1-signed.1-signedのように名前が間延びするのはMozillaとしても見映えが悪いと考えているようで、今後は.1-signedが.1-signed-2に置き換わるといった形にするようだ。

*1:未署名の拡張機能を有効化する設定は、削除時期がFirefox 47に延期された

OS X 10.6/10.7/10.8のサポートはFirefox 47まで Windows XPのサポートは当面継続(追記あり)

ESR版以外は8月まで

Mozillaは、FirefoxにおけるOS X 10.6/10.7/10.8のサポートを2016年8月で終了すると発表した。サポート終了後もFirefoxを使い続けることは可能だが、新機能やセキュリティアップデートの提供は受けられなくなる。現在の予定では、Firefox 47が2016年6月7日(米国時間。以下同じ)にリリースされた後、同年8月2日にFirefox 48がリリースされることになっているので、上記の発表に照らしてみると、OS X 10.6/10.7/10.8をサポートするのはFirefox 47までとなる。

他方、Firefox ESR 45ではOS X 10.6/10.7/10.8をサポートし続ける。ESR 45系列のサポートは2017年5月ころまでは続くとみられ、2016年8月以降もOS X 10.6/10.7/10.8上でFirefoxを使い続けるのであれば、今の時点で法人向け延長サポート版(ESR)に乗り換えるべきだろう。ただし、Appleが既にOS X 10.6/10.7/10.8のサポートを終えている点には注意が必要だ。Mozillaが対応するのもESR 45.8までである。

OS Xに関するサポート変更は、2012年11月にFirefox 17で10.5のサポートを終了して以来のこととなる。2016年3月11日に突如として提案が出され、主要開発者の間でも意見が分かれたものの、最終的に実行に移されることになった。

Windows XPのサポートは当面継続

こうなると気になるのはWindows XPのサポートだが、こちらは当面継続される。Firefox 46のリリース前に、XPはESR 45系列限定でサポートすることにしてはどうかとの提案が出されたものの、XP上におけるFirefoxの利用状況を調査している最中だとして、採用されなかった。Mozillaは、Windows版Firefoxに関し、バイナリファイルにSHA-2ベースのデジタル署名を付すこと(Bug 1079858)や、ビルド環境をVisual Studio 2015に移行すること(Bug 1124017)について、コストをかけてWindows XP(SP2以降)に対応させているし、直近のFirefox 46でもXP上でMP4/H.264/AAC形式の動画・音声ファイルを再生できるようにしている(Bug 1250766)。OS X 10.6/10.7/10.8との差は明らかだ。

2014年4月にサポートを終えたOSにMozillaが対応し続ける理由は、Windows XP上のFirefoxユーザーが多いからである。Mozillaの調査によれば、Firefoxのリリース版/Beta版ユーザーのうち約12%がWindows XP上で利用しており、このXP上のユーザーのうち約16%がXP SP2にとどまっている。他方、OS X上での利用者は10.6以降のバージョン全体で6.7%となっており、XPのサポートを終了した場合の影響が、OS X 10.6/10.7/10.8の場合の比ではないことがわかる。

しかも、別の調査によれば、Windows XP上でFirefoxを使用するユーザーのうち40%から53%は、CPUまたはRAMが要求水準を満たさずWindows 7以降にアップグレードできない状態にあるとされている。つまり、買換えを待たないとOSが更新されないわけで、XP上のFirefoxユーザーの数が短期間に大きく減少することはなさそうだ。

のしかかる負担

もっとも、Windows XPのサポートは、Mozillaにとって次第に重荷になりつつある。最近の例を挙げると、Firefoxは、ICU(International Components for Unicode)という外部のライブラリを統合しており、これによってUnicodeやJavaScriptの国際化をサポートしているのだが、このICUが2016年10月ころにリリース予定のバージョン58でWindows XPをサポートしなくなるのだという。ICU 58を導入しないとUnicode 9.0のサポートが遅れる一方、これをそのまま導入するとWindows XPのサポートを続けられなくなる、ということで議論になっている

これは1つの例にすぎないが、こうしたWindows XP向けの余分な作業が積み重なることで、Firefoxの開発の障害となることを懸念する声があるのも事実だ。

とはいえ、上記のとおりWindows XP上のFirefoxユーザー数は到底軽視できる規模ではないので、たとえばFirefox 48までアップデートしたユーザーに対し、Firefox ESR 45への移行を求めることになれば、おそらく混乱は免れない(だからこそサポートをESRに限定する旨の提案はFirefox 46のリリース前に行われた)。それに、GoogleがChrome 50以降、Windows XP/Vistaのサポートを終了させたことは、Firefoxにとってシェア回復のチャンスとも考えられる。

Firefox 52(2017年3月ころリリース)まではWindows XPのサポートを続け、その先はESR限定のサポートとするのが穏当なように思うが、どうなるだろうか。

(16/05/03追記)
OS X 10.6/10.7/10.8のサポートはFirefox 48まで継続されることが判明した。Mozilla Corp.でDirector of Engineering, Releases and Engineering Productivityを務めるLawrence Mandel氏が明らかにした。Firefox 49のリリース予定日は2016年9月13日なので、サポートを同年8月で終了するというアナウンスは正確ではなく、実際には9月半ばの終了となる。

(16/05/04追記)
Mozilla Corp.の従業員の中からも、Windows XPのサポートをFirefox ESRに回すとすればESR 52からだろうとの観測が出ている。ICUについては、開発の中心にいるIBMに対してという趣旨とみられるが、(大口のユーザーである)Mozillaが頼めば、XPのサポート終了をしばらく先延ばしにしてくれるらしい。

(16/05/05追記)
Bug 1269811 - Stop updates for Firefox 49 and later on MacOS X 10.6-10.8も参照のこと。既にFirefox Nightly 49ではOS X 10.6に対するアップデートの提供を停止したという。

(16/05/28追記)
OS X 10.6/10.7/10.8のサポートの件は5月3日に追記した内容のとおりなのだが、経緯は思っていたよりもややこしかった。もともとの計画は、本文に書いたとおりFirefox 47でサポートを終えるというものだった。しかし、Firefox 48でサポートを終えるのだと主要開発者さえも誤解したので、本当にFirefox 48でサポートを終える(=Firefox 49からはサポートしない)ことにした。

その結果、5月5日に追記したとおり、OS X 10.6/10.7/10.8上のユーザーに対してはFirefox 49へのアップデートが提供されなくなる。代わりに、Firefox ESR 45系列へのダウングレードパスが提供される可能性がある。

FirefoxのBeta版をそれと気付かずに使うユーザーが多いらしい

Mozillaが最近調査したところによると、FirefoxのBeta版ユーザーの多くは、Beta版を使用していることに気付いておらず、アップデートが多すぎると文句を言う人も少なくないのだそうだ。たしかに、アップデートの頻度はずいぶん違う。リリース版なら次のメジャーアップデートまでにせいぜい2回くらいだが、Beta版では10回以上になるからだ。

f:id:Rockridge:20160424225052p:plain

それにしても、Beta版を使用していることに「気付かない」というのは盲点だった。ダウンロードするときに、Beta版であることが明示されているではないか。だが、考えてみるとDeveloper Editionのように色彩を変えたアイコンは使っていないし、Beta版の意味を知らなければ、Webサイトに「安定した状態の新機能を試す」と書いてあっても、新機能も使えるFirefoxなのかと思うだけかもしれない。起動時に「これは正式版ではありません」と表示が出るわけでもなく、注意すればバージョン番号の差で分かるが、現在のように数字が大きくなってくると、46だろうが47だろうが一緒のように感じられても不思議ではない。

f:id:Rockridge:20160424225117p:plain

Mozillaは対策を検討中で、アップデートをより目立たないものにする、Beta版の安定性を改善する、リリース版に移行させるといったアイデアが出ている。ここでは、ユーザーに気付かないままBeta版を使ってもらうか、それともリリース版に乗り換えてもらうかという選択がある。素直に考えれば、ふつうのFirefoxを使っているつもりのユーザーには、期待に沿ってリリース版を使ってもらうべきなのだろうし、Firefox Test Pilotモックアップ)が正式公開されれば、そちらに誘導することでリリース版のまま新機能を試したいというニーズも満たせる。

ただ、Are We Stable Yet?を見るとデスクトップ版Firefox Betaには2016年4月23日時点で160万のADIがあり、これに近い数のデイリーアクティブユーザー(DAU)が存在している。このうちの何割かはTelemetryを通じてMozillaに利用データを送信しているはずで、単にリリース版に誘導するだけでは(無自覚な)Betaテスターが減ってしまう。リリース版への移行だけが選択肢になっていない背景には、こうした事情もありそうだ。

ElectronアプリがGecko上で動く未来

Mozillaは、Electron APIをGecko上で動作させるためのラッパを開発中で、その開発プロジェクトはElectron(電子)を踏まえてPositron(陽電子)と呼ばれている。今のところまだElectronベースのアプリを走らせることができるまでには至っていない。

ElectronはChromiumとNode.jsを利用しているが、ChromiumのところにGeckoを代入するとして、Node.jsはどうするのか。その回答がSpiderNodeで、こちらはMozilla製JavaScriptエンジンであるSpiderMonkey上でNode.jsを動作させることを目的としたプロジェクトである。

V8以外のJavaScriptエンジンにNode.jsを移植するといえば、MicrosoftのChakraCoreが有名だ。2016年1月に取り組みが発表され、注目を集めた。SpiderNodeプロジェクトでは、このNode.js on ChakraCoreの開発状況を参照しつつ、ChakraShimならぬSpiderShimと呼ばれるV8 API shimを構築していく。

これらのプロジェクトは、Mozilla CorporationのCTOであるDavid Bryant氏によれば、Webをあらゆるところに埋め込んでいくための手段であり、そうすることが、すべての開発者に対して広く有用であるという。

GeckoがElectronアプリに対応するのであれば、Electronベースで実験が行われるProject Tofinoの成果も、理屈の上ではGeckoに直接フィードバックできるわけだが、はたしてそこまでを視野に入れたものなのだろうか。

MozillaがProject Tofinoでブラウザの新たなあり方を模索中

新たなパラダイムの探究

Firefoxはその成功ゆえに革新が難しくなるというイノベーションのジレンマに陥っている。そうした問題意識を背景に、ブラウザのユーザーインターフェイス(UI)のコンセプトが、1996年ではなく、2016年に作られたとしたらどうなるかを実験していくのが、Project Tofinoだ。プロジェクト名は、着想を得た場所がカナダのバンクーバー島にある同名の地域であったことに基づく。

プロジェクトのトップはMark Mayo氏。Mozilla CorporationでFirefox部門のSenior Vice Presidentを務める人物である。また、Firefox部門のLead DesignerであるPhilipp Sackl氏もプロジェクトに加わっている。しかも、チームのメンバーを少数に絞ってTofinoとバンクーバーに集め、他のメーリングリストやミーティングからも外して専従させるという力の入れようだ。

プロジェクトの期間は3か月で、この間に製品化可能なコンセプトを生むべく実験を繰り返すが、ものにならなかったときはお蔵入りになる。

Browser.htmlとは別物

注意が必要なのは、Servoブラウザエンジンの実験的なフロントエンドであるBrowser.htmlとは別物だという点。Servoはhtml5everと呼ばれるHTMLパーザやWebRenderと呼ばれるグラフィクス・サブシステムを搭載したブラウザエンジンのプロトタイプであり、2016年6月に最初のα版のリリースが予定されている

Servoのα版を公開するにあたり、フロントエンド部分がないと使い物にならないため、付属してくるのがBrowser.htmlである。これ自体がXULではなくHTMLでネイティブアプリを構築する実験となっており、決して「新ブラウザ」の類ではない。そして、Project TofinoはServoからは独立したプロジェクトだ。

Electron/Reactを利用

Project Tofinoの実験は、アプリケーションのフレームワークとしてElectronを、UI用のJavaScriptライブラリとしてReactを用いる。ElectronはChromiumとNode.jsがベースなので、Project Tofinoの成果物は基盤部分においてChromeと共通になる。

Gecko/XULベースでないのは、Electron/Reactのほうが小さなチームで試作品を作るのに向いているからだと説明されているが、MozillaがXULの廃止に向けて動いていることや、上記のとおりServoのフロントエンドが実験中であることを考え合わせると、要するにGeckoは成熟しすぎ、Servoは未熟すぎるのだろう。

従来のブラウザを超えたデザイン

まさに実験が始まろうとしているところなので、Project Tofinoがどのような形になるかは未知数といわざるを得ない。ただ、若干のコンセプトは示されており、従来のブラウザはドキュメントを読むことを基本的なコンセプトにしてきたが、Project Tofinoではそこを出発点にはしないという。

また、最初期のスケッチ(2016年3月1日付け)を見ると、「タスク」ごとにページをまとめるアイデアや、Firefoxのツールバーに相当する部分をサイドバーに置くアイデアが出ているようだ。

f:id:Rockridge:20160410233032p:plain

応用先も未知数

お蔵入りの可能性も十分にあるので、今から心配しても仕方がない面もあるが、仮に製品化可能な斬新なコンセプトが生まれたとして、その使いどころは悩ましい。

新コンセプトをFirefoxに適用するとなれば、UIの大改造を伴うから、インパクトはAustralis導入の比ではないだろう。UIが変わってしまえばWebExtensionsベースの拡張機能であっても互換性を維持しづらくなる。UIは慣れの部分も大きく、いかに優れたコンセプトであっても、ユーザーの強い反発は免れない。かといって、コンセプトの一部のみを移植することもできない。UI全体が生み出すユーザー体験にこそ意味があるからだ。

他方、α版段階のServoと組み合わせるとなれば、製品化に時間がかかりすぎる。そもそも、Servo自体が試作品であり、そのまま製品の基盤になると保証されているわけではないのだ。

あと考えられるのは、Firefox OS搭載ブラウザぐらいか。スマートフォン向けはコミュニティに委ね、Connected Devices(IoT)に特化していくわけだから、例えばスマートTVに載せた場合、既存ユーザーの反発もほとんどなさそうではある。ただ、Firefox本体に比べて利用者はかなり限られよう。

いずれにせよ謎の多いプロジェクトであり、推移を見守るほかない。Mozillaがイノベーションのジレンマを打ち破れることを祈ろう。

(16/04/13追記)
A nail in the coffin for Firefox? Mozilla struggles to redefine browser - CNET日本語版)によれば、Project Tofinoの発表後、Mozilla Corporationの内部で、発表はフライングであり、Positronについて触れずにGecko/Firefoxの将来性に不安を抱かせた点でも間違いだった、との意見が出たらしい。Mayo氏も発表の中で事前に社内で大きな抵抗を受けたことを強く示唆していたが、新しい動きを潰そうとするのは健全とはいえないだろう。最近、Mozilla FoundationのMitchell Baker理事長が、All Change, All the Time | Mitchell's Blogの中で、変化の大切さを繰り返し強調していたのだが、その背景には抵抗勢力を牽制する意図があったのかもしれない。