Mozilla は、インターネット上の個人のプライバシーを「オプション」として扱うべきではない と信じています。私たちのプライバシー原則は、各製品やサービスを設計する際の指針となっています。LightBeam、Ghostery、Privacy Badger といった Firefox 向けアドオンの作成を可能にしているアドオンプラットフォーム、Do Not Track 設定、プライベートブラウジング、ゲストブラウジング、Firefox Sync の高度な暗号化、アプリ許可設定の個別手法、さらには新しい「忘れる」ボタンに至るまで、Mozilla はプライバシーに焦点を当てた機能をデスクトップとモバイルの双方で導入してきました。それでもまだ、さらに良いこと、より多くのことをする必要があると考えています。透明性とコントロールをもたらす機能を通じてユーザが望む Web 体験を提供したい、また、ユーザに Mozilla と Web を信頼して欲しいと願っています。

2014 年 10 月、18 歳から 64 歳まで 7,000 人以上の成人を対象に、米国の調査会社 Harris Poll が Mozilla に代わって世界的なオンライン調査*を実施しました。およそ 4 分の 3 (74%) の回答者が、現在 Web 上にある自分たちの個人情報が 1 年前よりもプライベートではなくなっていると感じています。また、ほぼ同数の成人が、インターネット企業は自分たちについて知りすぎていると答えました。私たちはこうした懸念の解消に役立てるのではないかと考えました。

Mozilla は今日、Polaris という新たな戦略的イニシアチブを発表します。Polaris は、私たち独自のプライバシーに関する取り組みと、業界内の他のプライバシー先駆者をまとめる目的で設立されたプライバシーイニシアチブです。Polaris は、さらに多くのプライバシー機能を私たちの製品へ組み込むため、より効果的に、明確に、直接的に共同研究できるよう設計されています。私たちは、Web のためのプライバシー技術について、ユーザに焦点を合わせた実践的な革新を加速させ、ユーザの Web 体験においてより幅広いコントロール、知識、保護を提供したいと考えています。また、より一般のユーザに向けて提供することに特に焦点を当てたプライバシー機能の技術革新を進めたいと思います。

立ち上げには、Center for Democracy & Technology (CDT) と Tor プロジェクト が参加します。いずれも非営利法人で、Polaris プロジェクトに協力と助言と提供し、政策目標と一致させるために協力してくれます。これらのプロジェクトによる協力と援助は必要不可欠です。「CDT は、Polaris プログラムに関して Mozilla と協力し、ネット上の表現の自由を推進するために欠かせない、ネット検閲との戦いやオンライン匿名性の保護といった問題について助言できることを楽しみにしています」と、CDT の Justin Brookman 氏は述べています。これらの共同研究は、新しい革新的なプライバシー機能を一般向け製品に組み込むという、私たちが自ら課した目標に忠実であり続けるための責任を負わせるだけでなく、知識、焦点、意見に多様性が生まれ、一般の人たちにもたらす機能の改善につながるでしょう。

今日私たちは、Polaris の旗印の下、反検閲技術、匿名性、クロスサイト追跡防止に焦点を当てた 2 つの実験を発表します。まず、Tor プロジェクトが行っている Firefox への変更を Mozilla のエンジニアが評価し、Firefox 自体のプラットフォームコードベースに変更を加えることで Tor の動作がより高速で容易になるかどうかを判断します。Mozilla では、Tor ネットワークの応答性を高め、より多くのユーザが Tor へ参加できるよう、近日中に独自の大容量 中間リレー のホストも開始する予定です。「Tor プロジェクトは、Polaris プログラムの立ち上げパートナーとして Mozilla へ参加できることを嬉しく思います。プライバシー技術、オープンスタンダード、今後の製品に関する共同研究などで互いに協力できることを楽しみにしています」と、Tor プロジェクトの Andrew Lewman 氏は述べています。

2 つ目の実験 (Polaris 初となる製品内実験) は、ユーザの選択を尊重している広告主やコンテンツサイトに不利益をもたらすことなく、侵略的な追跡から逃れたいというユーザを保護する機能をどのようにしたら提供できるかを理解することを目指すものです。このプライバシーツールは今のところ Firefox の Nightly チャンネルでテスト中です。実験そのものは有望ですが、まだ本格的な機能とはなっていません。今後数か月にわたってユーザ体験とプラットフォーム動作のテストと改良を続け、一般向けリリース版へ追加する前にあらゆる関係者からフィードバックを集めるつもりです。

私たちは、プライバシーが単なるコンピュータ上の機能や、有効と無効を切り替えられるだけの設定にとどまらないと考えており、オンラインプライバシー発展のため Polaris で何ができるかを楽しみにしています。プロジェクトの詳細と参加方法は Wiki をご覧ください。

* 調査方法

本調査は、イギリス、フランス、スペイン、ドイツ、ブラジル、インド国内の成人 7,077 人 (18 歳から 64 歳まで) を対象に、2014 年 10 月 22 日から 29 日までの間、Mozilla の依頼を受けた Harris Poll 社によって、Global Omnibus 製品を通じオンラインで実施されました。年齢、性別、人種、教育、地域、収入別の回答者数は、実際の人口比率に合わせるため必要に応じて重み付けされています。また必要に応じ、このデータもオンライン成人人口の構成を反映させるために重み付けされています。重み付けの変数など詳しい調査方法については press@mozilla.com までお問い合わせください。

[これは Mozilla Privacy Blog の記事 Introducing Polaris Privacy Initiative to Accelerate User-focused Privacy Online の翻訳です]

原文: Content Security Policy 1.0 Lands In Firefox on June 11, 2013 by imelven

Content Security Policy (よく CSP と略されます) は、ページ内にコンテンツを含めることが可能なサイトを制限する、Web ページ向けの手段です。また、インラインスクリプトの実行を許可するかや、インラインのスタイル/CSS をページに適用することを許可するかの制限もできます。一般的に、CSP は Web 開発者に対してコンテンツの強力な制御を可能にして、さまざまなセキュリティ問題の軽減を助けます。CSP の主な利点の一つは、デフォルトでインラインスクリプトを実行させないことです。これは、XSS (クロスサイトスクリプティング) や他のスクリプトインジェクションの脅威を大幅に軽減する助けになります。CSP のすばらしい紹介として、Mike West の投稿 “An Introduction to Content Security Policy” をご覧ください。

ドキュメントでコンテンツ制限を指定できるというアイデアは、少なくとも 2007 年にさかのぼります。当時このアイデアは Mozilla Project の Gervase Markham とセキュリティ研究者の Robert ‘rsnake’ Hansen によって議論されました。Brandon Sterne と Sid Stamm は公式な仕様が存在するよりはるか前に、Firefox 向けに CSP の初期プロトタイプの実装作業を行いました。CSP の ‘前仕様 (pre-spec)’ 実装は 2011 年 3 月に Firefox 4.0 へ投入して、X-Content-Security-Policy ヘッダを使用しました。 CSP のコンセプトはかなり急速に牽引力を得て、Chrome は 2011 年 8 月に X-Webkit-CSP ヘッダを使用して最初の実装を公開しました。セキュリティや Web の専門家による多くの議論を経て、2011 年 11 月に Content Security Policy 1.0 の W3C 仕様のワーキングドラフトが公開されました。時間をかけてコンセプトが発展や改良したことにより、ワーキングドラフトで示された構文は、初期の Firefox 実装で使用されるものとはかなり異なっていました。1 年後に CSP 1.0 仕様が勧告候補に達して、実装する準備が整いました。Chrome は 2 月公開の Chrome 25 で、接頭辞なしのヘッダを使用した CSP 1.0 仕様をサポートしました。Internet Explorer 10 は CSP の ‘sandbox’ ディレクティブをサポートしましたが、現時点で他の CSP ディレクティブは未サポートです。

当初の Firefox CSP 実装と CSP 1.0 仕様とで何が変わりましたか?

1. ヘッダの接頭辞を削除
   仕様では、X-Content-Security-Policy ではなく Content-Security-Policy ヘッダを定義しています。CSP をサポートするブラウザに適用するポリシーを持つために、サイトが複数の CSP ヘッダを (異なる構文で!) 送信しなければならない状況がなくなるので、よいことです。同一の Content-Security-Policy ヘッダが Firefox、Chrome、IE 10 (sandbox のみ) および仕様を実装する他のブラウザで動作するでしょう。何らかの理由でサイトが X-Content-Security-Policy ヘッダと Content-Security-Policy ヘッダの両方を送信する場合は接頭辞付きのヘッダが無視されて、接頭辞なしのヘッダから得たポリシーだけが適用されます。
2. 使用できるディレクティブの変更
   ポリシーで使用できるディレクティブが若干変わりました。当初の Firefox CSP 実装では、未指定のディレクティブ向けに使用されるデフォルトポリシーを指定するために ‘allow’ ディレクティブを使用しました。これは CSP 1.0 で ‘default-src’ ディレクティブに置き換えられました。加えて、当初の Firefox の実装では XMLHttpRequest オブジェクトが接続できる生成元を制限するために、‘xhr-src’ ディレクティブを使用しました。1.0 仕様では、‘xhr-src’ が ‘connect-src’ に置き換えられました。また、XHR に加えて EventSource や WebSocket オブジェクトが接続できる場所も制限します。
3. デフォルトの動作の変更
   当初の Firefox の Content Security Policy 実装は Fail-Close であり、将来の構文に対して下位互換性がありませんでした。CSP 1.0 では、default-src ディレクティブがないときにすべてのソースを許可するようにフォールバックします。
4. インラインスクリプトと eval() の使用許可に関する変更
   インラインスクリプトや eval() の使用を許可するようオプトインする方法が変わりました。当初の Firefox の CSP 実装では、これを行うために ‘options’ ディレクティブで値 inline-script および eval-script を使用しました。例えば、当初の CSP ポリシーで “allow ‘self’ ; options inline-script eval-script” は、CSP で保護されたドキュメントと同じ生成元からのコンテンツ読み込みと、インラインスクリプト実行および eval() の使用を許可します。
   CSP 1.0 では、この状況を制御するために ‘script-src’ ディレクティブにキーワードが追加されました。‘script-src: unsafe-inline’ がインラインスクリプト許可のオプトイン、‘unsafe-eval’ が eval() の使用許可のオプトインです。CSP を使用する価値を少し落としますが、両方にオプトインするために、両方のキーワードを指定することができます! 例えば CSP 1.0 ポリシーで ‘default-src ‘self’ ; script-src ‘unsafe-inline’ ‘unsafe-eval’ は、CSP で保護されたドキュメントと同じ生成元からのコンテンツ読み込みと、インラインスクリプト実行および eval() の使用を許可します。
5. インラインスタイルのブロック
   当初の Firefox の CSP 実装では、インラインスタイルをまったくブロックしませんでした。これは CSP 仕様に後で追加されたもので、<style> 要素や他の style 属性を持つ要素を注入することによる攻撃を防ごうとするものです。それらの攻撃は、スクリプトの実行を許可していない場合でも実施できます。ページからデータを取り出すために CSS セレクタを使用して、要素を別の要素の前面に重ねるために属性を使用するといった一部の潜在的な攻撃が、フィッシング攻撃を可能にします。

Firefox の CSP 1.0 実装と仕様との間にまだ相違点はありますか?

はい、小さな違いがいくらかあります。

• frame-ancestors ディレクティブをまだサポートしています。このディレクティブは X-Frame-Options ヘッダに似ており、どのサイトが Web ページをフレーム化できるかを制限します。X-Frame-Options は非推奨になり、また当初明示された問題点をいくつか抱えています。frame-options ディレクティブによって、この機能を CSP に移すことが提案されました。frame-options は策定中の “User Interface Security Directives for Content Security Policy” 仕様の一部として提案された、新しい CSP ディレクティブです。将来、Firefox の frame-ancestors ディレクティブは、frame-options が選ばれることにより非推奨になるでしょう。
• report-uri ディレクティブは、CSP 違反のレポートをどこへ送信するかを指定するポリシーを可能にするものです。Firefox ではこれが、CSP が指定されたドキュメントの生成元へのレポート送信に制限されています。レポートを取り巻く適切な制限や懸念に関する議論が、W3C の WebAppSec ワーキンググループや Mozilla で行われています。Bug 843311 をご覧ください。
• インラインスタイルがブロックされるとき、SMIL アニメーション要素もブロックされます。これの最大の原動力は Bug 704482 です。Mario Heiderich が報告した、スクリプトの実行を許可しない場合でもキーストロークを読み取れる高度な攻撃です。ここで私たちは慎重に取り組み、またこれを W3C の WebAppSec ワーキンググループに持ち込む予定です。
• Firefox は ‘sandbox’ ディレクティブをサポートしていません。このディレクティブは CSP 1.0 のオプションですが、CSP 1.1 の一部には含められる予定です。

Firefox の CSP は将来どうなりますか?

ある時点で、X-Content-Security-Policy ヘッダを非推奨にする予定です。本投稿の動機のひとつが、接頭辞のない Content-Security-Policy ヘッダを使うようにサイトを移行するときであることを、人々にわかってもらうことです。Firefox は Web コンソールに、接頭辞付きのヘッダは将来非推奨になることを知らせるメッセージを表示します。

加えて、私たちは W3C の WebAppSec で CSP 1.1 仕様の策定に関わっており、Mozilla の Dan Veditz が本仕様のエディターの一人になっています。私たちは特に、script-src および style-src ディレクティブ向けの新たな nonce-source ソースに興奮しています。このソースはポリシーで指定されたものと同じ正当な nonce を提示する場合に、特定のインラインスクリプトやスタイルのホワイトリスト化を可能にします。nonce-source は最近 Blink に実装され、また Firefox では開発中です。詳しくは CSP 1.1 仕様のセクション 4.10.1 “Usage” をご覧ください。なお、この仕様は現在急速に発展中であることにご注意ください!

Mozilla にて私たちは、CSP のインラインスタイルのブロックについてさらに議論しました。特に、eval() のブロックと似た機能を追加したいという希望があります。その根拠は、文字列からスタイルを構築することも本質的に危険であるためです。これは Bug 873302 で扱っており、また一部の議論は、元の ‘インラインスタイルのブロック’ バグ側にあります。私たちはごく近い将来にこのアイデアを、より多くのフィードバックを得るために W3C の WebAppSec ワーキンググループに持ち込む予定です。Mozilla 内では、.innerHTML の使用をブロックする CSP ディレクティブの作成も提案されました (また、ワーキンググループ内でも多少議論しました)。.innerHTML による script 要素の挿入がインラインスクリプトをブロックする CSP でブロックされるとしても、.innerHTML 内の信頼されない入力を使用することで他にもさまざまな問題が生じる可能性があります。

ここまでは長すぎました。現在 Content-Security-Policy ヘッダをどれで使用できるかだけを教えてもらえますか?

• Firefox : 現在はデスクトップ版の Firefox 23 (Aurora) およびそれ以降です。Android 版 Firefox と Firefox OS がすぐ後に続きます。
• Chrome : 25 およびそれ以降
• Internet Explorer : 10 およびそれ以降 (sandbox ディレクティブのみ)

謝辞

• Mozilla で始めに CSP の開発を先導しました: Brandon Sterne
• Mozilla の Security Engineering & Security Assurance、特に Sid Stamm、Brian Smith、Daniel Veditz、Garrett Robinson、Mark Goodwin、Frederick Braun、Tanvi Vyas
• CSP に熱中した仲間たち: Mike West、Adam Barth、Brad Hill、Devdatta Akhawe、Neil Matatall、Joel Weinberger、Kailas Patel

4 月 27 日、28 日の 2 日間にわたって行った Mozilla Hackathon 2013 が無事終了しました。
今回は、乃木坂の Mozilla Japan 新オフィスに合計 28 名の参加者が集まり、
それぞれに持ち寄った作業を行いました。

今回も 10 年以上 Mozilla で活躍されているベテランコントリビューターや有名なアドオンの開発者から
Mozilla のイベントに初めて参加される方まで、様々な方が参加されました。

初日は 13 時からスタート。
参加者は、翻訳や製品ローカライズを行うチーム、アドオンや Firefox OS 用アプリの開発を行うチーム、
そして Firefox それ自身の実装や改良を含むプラットフォーム開発を行うチーム、の3グループに分かれ、
自己紹介タイムをはさみつつ、18時過ぎまで作業を行いました。
その後、参加者のほぼ全員による懇親会が行われました。

2日目の作業開始時刻は午前 9 時。
精力的に作業を行い、15 時からの成果発表を迎えました。
各人・各チームがそれぞれの作業内容とその成果を発表し、2日間にわたるイベントを締めくくりました。

参加された方々は、真剣に作業される一方、他の方々との交流も大切にされていました。
今後もこのようなオフラインでの交流の機会となるようなイベントを開催できればと思います。
今回参加されなかった方も、機会がありましたらぜひご参加ください！

集中！

Run! Firefox!

議論をする人々

チームごとに集まって作業。

2日目の昼食。大量のサンドウィッチ！

と、それを撮影する人々。

NFC が利用できる端末の上におくと… Firefox が起動します！

追い込み中。

発表会の様子。
作業内容と成果物の報告を行いました。

誕生日の方を、みんなでお祝いしました。

スレッドだけでは済まない: アムダールの法則を見れば、スレッドも、SIMDの名でも知られるいわゆる「データ並列化」も、画像や音声・動画のデコーディングのみならずエンジンのあらゆるステージにおいて、より細かい粒度で必要とされることが分かる。しかしC++のスレッドを使うことは、他の手法と比べてより困難なバグとセキュリティ脆弱性を作りこむことを意味する。

私は、万一ということもあるかと思って、メモリ安全でないSMPカーネルプールの深みに飛び込んだSGIで、80年代の終わりに学んでいた。AppleとGoogleは、彼らのソースコードの多くをマルチスレッド化、そしてSIMDによる並列化すらできるし、おそらくやるだろうが、それにはしばらく時間がかかるし、生産性を重視し、無難なヒットを打ってくるだろう。Servoは、メインの実装言語、Rust、が並列性と同じくらい安全性を重視していることもあり、より安全な設計がされている。だから、私にはこれは技術的に筋の良い賭けに見える。

超並列ハードウェアに対する他のアプローチも考えられ、未来のハードウェアまだ十分にデザインされていない。だから、私たちはウェブエンジンの研究を進めていかなければならないと思う。

きわめて重要な責務

ここまで考察してきたこと以外に、私たちの立場からも私たちのパートナーの立場からも、新たなきわめて重要な責務があることに、私たちは気付いた:世界は新しくて、きれいで、安全で並列化された、オープンソースのウェブエンジンを必要としているのだ。単にマルチコアデバイス向けのものではなく、— 私たちとパートナーではその動機は異なるが — 途方もない資金力を持ちロックインを好む競合が支配するエンジン、すなわちWebKit、への依存を避けるためのものとして。

このような安全で並列化されたエンジンは、ウェブ標準をより宣言的で 暗黙のうちに並列化が行われるような方向に推し進めるためにも、配布されウェブ標準のフィードバックを受けるべきだ。

単なる切り替えコストや標準化の進展、そして私たちの使命や価値、それ以上のものが私たちにかかっているのである。

上記では触れなかった純粋なビジネス的始点で見て言えるのは、WebKitのようなエンジン(もしくはこの文において似たような位置づけのもの、例えば中国におけるTridentのラッパー)を使うと、流通シェア競争に製品を陥らせるということだ。一般的に言って、フロントエンドの技術革新は難しくない;どのみちコピーは簡単だ。AndroidにおけるDolphinがいい例だ。もしくは、Maxthonが20%以上あった市場シェアを一年で1%以下に落としたこと、中国市場で1%以下のシェアになっていることを考えてみればいい。フロントエンドの技術革新を特にしていないQihoo/360が同じ期間に0%から20%までシェアを拡大していることも考えてみるといい。

プラットフォームの深い部分の技術革新は難しくなることがあり、そして私たちの経験によれば、その革新こそ全ての人に恩恵のあるウェブの前進につながるものである。JSのパフォーマンスが一例である。他の例としては、権限を持ったネイティブアプリケーションスタックにしか使えなかったデバイスAPIを含めるようにウェブを拡張することが挙げられる。複数の相互運用されているオープンソース実装やユーザーが所有するベンダー非依存な資産によって、プラットフォームの技術革新が標準に基づき、そして標準化されている限り、「実装と技術革新の質」を確保する難しさは問題にならない、というのが私の意見である。

Mozillaの話に戻ろう。私たちは競合勢力のようにデスクトップにおける流通力を持たないが、それでもうまくやっており、もっとうまくやる態勢も整っている。これこそ、ユーザーに対する素晴らしい証明であり、私たちの使命と私たちが作っている製品の、ユーザーにとっての価値である。そしてデスクトップ版のFirefoxに加え、(特にウェブアプリケーションの実行ランタイムとしての)Firefox OSとAndroid版Firefoxは、次の数年間でモバイル分野において大きな流通シェアを得ると私は信じている。

さあがんばろう

さあ、がんばってやり抜こう。HTML5と手軽に使える<video>要素の共同創始者によって創られた、残された数少ない独立系ウェブプラットフォーム、Prestoがなくなってしまったそうだ。OperaがWebKitプロジェクトの中でも良き戦いを続けてくれることを私は願っている。Mozilaコミュニティーは、Operaファンのあらゆるレベルの貢献(標準化、ハッキング、雇用)をいつでも歓迎する。

私たちには未来は分からない、しかしSarah Connorが刻んだように、「運命は自ら作るしかない」のだ。どんなことが起こっても、Mozillaは耐え抜く。

/Brendan Eich

その他の意見:

• Christian Heilmann
• Robert O’Callahan

原文: Building A Paid App For Firefox OS

Firefox OS の Firefox Marketplace をぱっと見たところでは Apple Store や Google Play と大差なく見えるかもしれないが、重要な違いがあります: あなたを Mozilla にロックインしたり、Firefox OS 端末にロックインしたりすることはありません。レシート プロトコルによって、どのオープン Web デバイスでも動作する Web  アプリを販売できるようになります。Mozilla 以外の マーケット もレシートフォーマットを実装することで Firefox OS のアプリ販売に参加でき、ユーザは何処のストアで課金したアプリを使ってもその違いに気づくことはありません。

他のデバイスが レシート プロトコルを実装すれば、理論的には 一度買えば何処でも使える ようになります。もちろんこれは、鶏か卵かの問題であり、Mozilla は卵となって、分散的なレシートコンセプトを実証し、プロトコルの改善を続けます。Mozilla はレシートが正しく機能し、課金アプリができるかぎりポータブルで「Web らしい」ものとなるよう他のベンダーと協力していきます。

開発者のみなさんへ

自分のアプリのレシートを検証 する責任は各アプリにあります。Firefox OS でアプリを販売しようとしている開発者は、この投稿を読めばレシート検証の実装をするにあたって幸先の良いスタートが切れるでしょう。仕様に準拠した Web ランタイムやマーケットプレイスを実装しようと考えている方にも役立つかと思います。

navigator.mozApps JavaScript API でアプリケーションのデバイスレシートにアクセスできます。レシートを検証する最も簡単な方法は、receiptverifier.js などのクライアントサイドライブラリを読み込み、レシートに埋め込まれたホスト型の検証サービス URL を使うことです。receiptverifer のドキュメントに詳細が書かれていますが、アプリの起動時に次の JavaScript を呼び出すだけでとても簡単です:

mozmarket.receipts.Prompter({
  storeURL: "https://marketplace.firefox.com/app/your-app",
  supportHTML: '<a href="mailto:you@yourapp.com">email you@yourapp.com</a>',
  verify: true
});

じゃじゃーん！これは高水準なショートカット検証であり、レシートが確認できないか無効である場合にはアプリ内に問い合わせ画面が表示されます。verifier のドキュメントには低水準の検証方法も書かれています。

より完備な例としては、テストに使用しているアプリ Private Yacht のコードをチェックアウトしてください。このアプリでは receiptverifier.js ライブラリでクライアントサイドの確認をどのように行っているかだけでなく、サーバサイドの確認を Node.js を使ってどのように行っているかご覧頂けます。他にも Python ライブラリ (更に Django 用ライブラリ) を用意しており、サーバ側でのレシート確認にお使いいただけます。仕組みはどうなっているのか？各レシートは JSON Web Tokens のマッシュアップです。プロパティにはレシートの確認に使える検証サービスがホストされているリンクも含まれます。レシートをオフラインで検証することも可能ですが、定期的な鍵の同期が必要になりますし、オフライン検証では今のところ払い戻しや再発行などが上手く扱えません。デフォルトでは、レシートはアプリの manifest に記載の installs_allowed_from パラメータのストア URL のいずれかにのみ許可されています。開発者としてあなたは各マーケットプレイスと明示的に支払いの関係を作り、アプリを売ったと主張できるサイトを制限できます。誰がアプリのレシートを提供できるかというホワイトリストとして機能します。クライアントサイド JavaScript はゆるい性質があるので、サーバサイド (つまり、アプリのサーバで) でレシートを検証することでよりしっかりと制御できるようになります。

Firefox Marketplace の課金アプリはまだ完全に有効になっていませんが、間もなくです。今のうちにレシート確認をアプリに統合していただければ、アプリの登録フローが課金をサポートする時に備えられます。

詐欺防止

だれもが Web でアプリを販売できるようにすることは、Mozilla の Opwn Web アプリのビジョンにおいてきわめて重大です。しかしながら、(DRM なしで) アプリを完全に保護しながらレシートを分散化させることは困難なことです。現時点ではユーザが課金アプリにアクセスできるように自身のクライアントに対して行える、DNS プロキシなどの攻撃がありますが、少し例を挙げれば、CSP, CORS や HSTS といったもので緩和できます。今日の iOS や Android の課金アプリの状況も 大差はありません。マーケットプレイスのホワイトリストをより効果的に出来るよう現在すすめられている取り組みもありますし、Mozilla ではより多くの開発者とより多くのストアが参加するようシステムを改善していくつもりです。署名付きの パッケージ型アプリ へと切り替えればもう一つの資産保護レイヤーを提供できますが、これは権限の問題を解決するために設計されたものです。

例によって、問題があればバグを報告してください！アプリプラットフォームのバグであれば Core (component: DOM: Apps) あるいは Marketplace (component: Payments/Refunds) へと報告してください。

Mozilla Missionの訳です。
Mozilla Japan には直接対応するページ自体がないようですが、何かの参考になれば、ということで。

私達はより良いインターネットを築いていきます

原文はこちら https://blog.mozilla.org/community/2013/04/26/well-always-have-paris-summit-2013/

（投稿者 mdouglass, 投稿日 2013年4月26日）

僕達にはパリの思い出があるじゃないか (映画 カサブランカより)

今週は、オフサイトで、驚異的な Mozilla People チームと過ごしました。常に、私の部隊と実際の時間を過ごしたのです（彼らの目玉を覗き込みながら）。 多くの Mozillians のように、私は普段、主にIRC(#peoplepeople)を通して共に働いている人々と連絡をとり、Eメール、その他のビデオソフトも使っています。そんなわけで、これは良い経験でした。

私にとって、それほどうまくいっていないのが、パリの件です。以前の投稿でも書いたとおり、パリはとても人気のある都市である ─10月には特に─ 2013年の10月4日〜6日の週末には特別に─ことがわかりました。この経験はサミットにとってとても重要で、目下のところ Mozilla にふさわしい場所（ホテルなど、イベントが開催できるところ）を見つけることができず、他の場所を探しています。サミットの場所として探しているのは、Mozillarian たちがつながっていると感じられる場所です。私達のすべてのために、ハックし、つながり、分け合い、交換し、成果を見せ、食べ、飲み、お互いに楽しめる場所であって欲しいと思います。そして、もしパリで私達の考えるような催しができないとしたら、他のどこで開催できるでしょうか？

カリフォルニアのベイエリアの会場としては、サンタ クララ マリオット がふさわしいと思います。（通りの向かいにアミューズメントパークがあります！）

この話題について何かわかり次第みなさんにお伝えするため、来週も投稿を続けます。サミット計画部会は引き続きパリで開催される予定です。

質問は、IRC のチャネル #summit2013 まで。 Mardi

原文: The Baseline Compiler Has Landed on April 5, 2013 by Kannan Vijayan

水曜日に、私たちは Firefox Nightly に Baseline コンパイラを投入しました。始めから終わりまで 6 か月の作業の後、私たちはついに苦労の末の産物をメインリリースストリームにマージできます。

Baseline コンパイラとは何か?

Baseline (いいえ、これに *Monkey のコードネームはありません) は、IonMonkey の新たなウォームアップコンパイラです。これは短期的にはパフォーマンス向上を、また長期的には新たなパフォーマンス向上の機会をもたらします。それは JaegerMonkey を不要にするための扉を開き、そして SpiderMonkey のメモリ使用量を大きく削減するという別の変化を与えることも可能にするでしょう。新たな言語機能の第一段階の最適化を実装することを容易かつ迅速にするとともに、それらを IonMonkey での高い段階の最適化に改良することを容易にします。

Kraken、Sunspider、Octane ベンチマークのスコアは投入段階で 5-10% 向上しており、また SpiderMonkey をよりよくするための Baseline の活用を続けることによる改善を続けます。AreWeFastYet の Web サイトをご覧ください。グラフは範囲選択 (クリック & ドラッグする) することで拡大できます。

別の JIT? なぜ別の JIT?

現在まで、Firefox は 2 つの JIT を使用していました: JaegerMonkey と IonMonkey です。Jaeger は “かなり高速な” 汎用の JIT で、Ion は “実に高速な” 強力に最適化する JIT です。最初のうちはホットコードが Jaeger でコンパイルされ、それが本当にホットである場合は Ion で再コンパイルされます。この手法は段階的なコードの最適化を可能にするので、確実にホットなコードに対してとても重厚なコンパイルを行います。しかしこの手法の成否は、さまざまな段階のコンパイルで費やす時間と各段階で得られる実際のパフォーマンス向上との間でよいバランスをとることにかかっています。

簡単に言うと、現在は JaegerMonkey を IonMonkey 用の一時しのぎのベースラインコンパイラとして使用していますが、そのような処理向けには設計されていません。Ion は Ion のことを考慮したベースラインコンパイラを必要としており、それが Baseline とは何かの答えです。

より充実した説明では、いつものように微妙なニュアンスの違いがあります。これから、それを 3 つの章で見ていきます: 現行リリースでの動作、なぜ問題であるのか、Baseline はどのようにして問題の修正を助けるか。

現在の事実

簡単に言うと、こちらが現行リリースの Firefox の JIT コンパイル手法です:

1. すべての JavaScript 関数はインタプリタで実行し始めます。インタプリタは実に遅いのですが、JIT で使用する型情報を収集します。
2. 関数がややホットになると、JaegerMonkey でコンパイルされます。Jaeger は生成した JIT コードの最適化に、収集された型情報を使用します。
3. 関数は Jaeger の JIT コードで実行されます。それがさらにホットになると、IonMonkey で再コンパイルされます。IonMonkey のコンパイラは JaegerMonkey より多くの時間を費やして、実に最適化された JIT コードを生成します。
4. 関数の型情報が替わった場合は、既存の JIT コード (Jaeger のものと Ion のもの両方) が破棄されて関数はインタプリタ実行に戻り、JIT のライフサイクル全体を再度たどります。

SpiderMonkey の JIT コンパイル方法がこのように構成されている、よい理由があります。

おわかりのとおり、Ion は高度に最適化されたコードを生成するためコンパイルに長い時間をかけて、重厚な最適化手法をたくさん適用します。これは、Ion のコンパイルを過度に早く働かせるとコンパイル後に型情報が替わりやすくなり、Ion のコードが無効になることが多くなるかもしれないということです。それはエンジンで、破棄されるであろうコンパイルにかけた多くの時間全体が無駄になることを引き起こします。一方、コンパイルまであまりに長く待つと、コンパイルまでに関数をインタプリタ実行するところで過度に時間を費やすでしょう。

JaegerMonkey の JIT コンパイラは IonMonkey の JIT コンパイラほどの時間を費やしません。Jaeger は収集された型情報をコード生成の最適化に使用しますが、Ion が生成したコードを最適化する際ほど多くの時間は費やしません。こちらは “かなり高速な” JIT コードを生成しますが、Ion より高速な生成方法です。

よって Jaeger はインタプリタと Ion の間に挟まっており、確実にホットなコードは Ion でコンパイルされてより高速になり、またややホットなコードは Jaeger でコンパイルされます (型情報の変更によりたびたび再コンパイルされますが、Jaeger はコンパイルが高速なので問題ありません)。

この手法は SpiderMonkey がパフォーマンスを犠牲にするインタプリタで実行する時間が可能な限り少ないようにするのと併せて、確実にホットな JavaScript コード向けの Ion によるコード生成の利点を得るようにします。よってすべてがうまくいく、そうでしょうか?

いいえ。そうではありません。

問題点

上記の手法はすばらしい初期の折衷案ですが、いくつか重大な問題を引き起こしています:

1. JaegerMonkey も IonMonkey も型情報を収集しませんが、型情報に頼って JIT コードを生成していました。それらは、JIT コードに関連づけられた型情報が安定している限り実行されます。型情報が変化すると JIT コードは無効にされて、さらに型情報を収集するためインタプリタ実行に戻されます。
2. Jaeger と Ion の呼び出し規則は異なっていました。Jaeger はヒープに割り当てられたインタプリタのスタックを直接使用したのに対して、Ion は (より高速な) ネイティブ C スタックを使用しました。これは、Jaeger と Ion のコード間の呼び出しを非常に高コストにしました。
3. インタプリタで収集された型情報は、ある特定の状況で制限されました。既存の型推定 (TI) システムは、ある種の型情報をうまく取り込みました (例えば、コード内の指定された場所で読み取るプロパティから見えると考えられる値の型) が、別の種類の型情報についてはとても下手でした (例えば、プロパティが取得されていたオブジェクトの型)。これは、Ion が実行可能な種類の最適化を制限しました。
4. TI の基盤は、型の分析情報を永続的に追跡するために追加のメモリを多く要求しました (今でも要求します)。初めに TI の設計や実装を行った Brian Hackett 氏は Ion 向けのメモリオーバーヘッドを劇的に削減できると考えましたが、それは Jaegar 向けに行うのよりもはるかに多くの時間がかかるようでした。
5. 多くの Web コードは、Jaegar によるコンパイル段階へ入るのにも不十分なほどホットではありません。Jaeger は Ion よりコンパイルにかかる時間が短いのですがそれでも高コストであり、また出力されたコードは常に型情報の変化により破棄される可能性がありました。このため、Jaegar によるコンパイルのしきい値はいまだにかなり高く設定されており、それゆえ多くのホットではないコードがインタプリタで実行されました。例えば SpiderMonkey はこの問題のために、SunSpider ベンチマークで大きく出遅れていました。
6. Jaeger は実に複雑であり、扱うのが困難です。

解決策

Baseline コンパイラは、これらの短所を解決するよう設計されました。Baseline の JIT コードはインタプリタのように既存の TI エンジンに情報を与えます。さらに、インラインキャッシュ (IC) チェーンを使用することでより多くの情報を収集します。 実行中に Baseline の JIT コードが作成する IC チェーンは Ion によって調査されて、Ion の JIT コードをより最適化するために使用されます。Baseline の JIT コードは無効にならず、また再コンパイルも不要です。動的な変化を追跡およびそれに対応して、必要に応じて IC チェーンの新たなスタブを追加します。Baseline のネイティブコンパイルと最適化された IC スタブは、インタプリタより 10 倍から 100 倍高速な実行を可能にします。また Baseline は Ion の呼び出し規則を踏襲して、インタプリタスタックに代わり C スタックを使用します。最後に、ベースラインコンパイラの設計は JaegerMonkey や IonMonkey よりとてもシンプルであり、IonMonkey と共通のコードを多数共有しす (例えばアセンブラ、JIT コードコンテナ、トランポリンなど)。またこれは、Baseline が新たな型情報を収集したり、新たなケースの最適化を行ったりするように拡張することを実に容易にします。

要するに、Baseline はインタプリタと JIT の間のよりよい中間層を提供します。Baseline は動的なコードに対してインタプリタのように安定的かつ弾力的で、高い段階の JIT に提供する型情報を収集して、また新機能を扱うための更新が容易です。しかし JIT として一般的なケース向けの最適化を行って、インタプリタより大幅な高速化を実現します。

私たちはどこへ進むのか?

今は Baseline を有効にする重要で大きな変化の一握りであり、これから注視していくことがあります:

• 型推定で使用するメモリの削減によるメモリ消費の大幅な低減
• 型推定がインライン関数のよりよい最適化を可能にすることによるパフォーマンス向上
• IonMonkey と Baseline のさらなる統合により、高度に多相的なオブジェクト操作コードのパフォーマンスを向上させる
• getter/setter、proxy、ジェネレータといった高度な機能のさらなる最適化

また、最近の出来事についてもお話ししましょう… asm.js や OdinMonkey を取り巻くニュースによる波乱を受けて、高度な JavaScript が最適化の観点で劣った存在になることに関する懸念が (重要な意見として) 浮かび上がりました。Baseline の投入と継続的な作業が、JS チームが高度でとても動的な JavaScript をできるだけ早くすることに関心を持ち、また持ち続けるために説得力がある合図として仕えることを少しでも望んでいます。

謝辞

Baseline は Jan De Mooij と私 (訳注: Kannan Vijayan 氏) が、Tom Schuster 氏と Brian Hackett 氏による重要な貢献とともに開発しました。開発作業は、すばらしいファジングテスターである Christian Holler 氏と Gary Kwong 氏にとても助けられました。

もちろん、Baseline はそれ自身では目的を果たさないことは特筆しなければなりません。IonMonkey チームによってすばらしい作業が行われ、また他の JS チームは Baseline が存在する理由を与えてくれます。

(4/10 訳注追記: 文中で「Javas」と記載している箇所がありましたが、「JavaScript」の誤りですので修正しました。ご指摘ありがとうございました。)