[これは Mozilla Add-ons Blog の記事 Major compatibility changes coming for Firefox 25 の翻訳です]

Mozilla では数週間前に Firefox 21 をリリースしたばかりですが、それと同時に 22 が Beta、23 が Aurora、24 が Nightly へ移行しました。Firefox 25 は 10 月下旬 までリリースされませんので、まだ十分に時間の余裕があります。しかし 24 が延長サポート版 (ESR) となる予定であることから、これは重要なリリースとなります。一部の大幅な変更は、潜在的な影響を最小限に抑えるため、ESR の次のバージョンへ投入されるからです。

Firefox 25 ではアドオンの互換性に影響する 2 つの大きな変更が計画されており、開発者の皆さんが前もって認識し早めに対策を取れるよう、ここで告知しておきたいと思います。変更点はまだ今後変わる可能性もありますので、適宜告知を行っていきますが、7 月に出る Nightly ビルド、あるいは 8 月中に出る Aurora ビルドは必ずチェックしておくべきでしょう。アドオンは主に以下の変更の影響を受ける可能性があります。

Australis

これは長期間にわたって作業が進められてきた Firefox テーマの大幅な刷新です。その目的のひとつは UI の簡素化で、アドオンについても考慮されています。

中でもツールバーの仕組みに大幅な変更が行われる予定です。アドオンバーを完全に削除するという提案に関しては 堂々巡りの議論 が行われています。最終決定はまだ行われていないようですが、最良のシナリオでもカスタマイズ対象が見つけづらくなり、最悪の場合は完全に削除されるでしょう。

メインのツールバーもアドオンのボタンやウィジェットのための専用エリアです。しかしユーザが作成した独自のツールバーは削除される模様です。概して、最小限のツールバー UI を提供すべきということです。多くのアドオンは既にそうなっていますが、ツールバーボタンを追加するための API が今後大幅に変わる可能性もあり、すべてのアドオンが対応を迫られるかもしれません。

Australis の変更点は UX Nightly Branch をインストールすることで事前にテストできます。その結果何かフィードバックがあれば、原文のコメント欄 でお知らせください。

セッション復元

Firefox ソースコードの他の部分と同様に、セッション復元もまたパフォーマンス向上のため非同期対応が行われているところです。Bug 874381 とその依存バグを見れば、このモジュールにアドオンに影響するいくつかの変更が行われていることに気付くでしょう。具体的には、多くのアドオンが依存している (__SS で始まる) プライベート変数が削除されました。

影響を受けるアドオンは yoric のブログ記事 にリストアップされており、一部の開発者には既に連絡が行っています。ですが念のため、あなたのアドオンがそれらのプライベート変数に依存していないか自分自身でも確かめて、必要な場合は 25 での削除に先立ち対策を行うようお願いします。

Firefox 25 のリリースが近づいてきたら、より詳しい情報を提供できるはずですし、おそらく関連するドキュメントもまとめられるでしょう。現時点では、この記事が参考となり、来たる大幅な変更に向けて皆さんが調査を始められることを願っています。

先ほど Firefox 23 Aurora (プレベータ版) がリリースされました。Firefox 23 のサイト互換性情報 を投稿しましたので、Web 開発者の皆さんはご確認ください。今回のバージョンでは、SSL 使用ページ内に混在している非 SSL コンテンツ (スクリプト、スタイルシート、動画など) が初期設定でブロックされるという点に注意が必要です。

なお、Firefox 22 (現在のベータ版) で予定されていた、初期設定でのサードパーティ Cookie のブロックは、事前に使用状況データの収集解析を行うため、延期されました。

もし一覧に漏れや間違いがあるときは、下のコメント欄でお知らせいただければ幸いです。

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

[これは Mozilla Add-ons Blog の記事 Add-on Compatibility for Firefox 21 の翻訳です]

Firefox 21 が 5 月 14 日 [日本時間同日深夜] にリリースとなります。Firefox 21 の変更点でアドオンの互換性に影響を及ぼす可能性のあるものを以下にまとめました。Firefox 21 for Developers により詳しい情報が載っていますので、こちらも併せてご覧ください。

一般

• プラットフォームとアプリケーションのリソースが分離され、個別に読み込めるようになりました。Firefox の Metro 対応を行うにあたって、広く利用されている各種 JavaScript モジュールを含め、いくつかの変更が必要となりました。
  • Firefox 20 およびそれ以前では、resource:///modules/、resource://gre/modules/、resource://app/modules/ は同じ場所を指します。
  • Firefox 21 およびそれ以降では、resource://gre/modules/ と resource://app/modules/ は異なる場所を指し、従ってそこに含まれるモジュールも別々となります。resource:///modules/ は resource://app/modules/ を指します。ただし、開発者が必要とするモジュールの多くは /gre/ にあります。最も簡単なテスト方法は、Firefox 21 もしくはそれ以降のバージョンを開き、あなたの拡張機能でモジュールのインポートに使用している URL を読み込んでみることです。従来通り動作するようであれば、修正の必要はありません。
• XBL スコープが有効となりました。XBL バインディングをコンテンツページに挿入する場合、クロームに対する、あるいはクロームからの関数呼び出しが特定の状況で失敗するようになり、追加のコードが必要となります。詳しくはバグを参照してください。
• language 属性を通じてより上位の JavaScript バージョンを指定できる機能が削除されました。これは、XUL ドキュメント内であっても、language 属性を使って JavaScript のバージョンを明示的に設定することができなくなったということです。
• SpiderMonkey から E4X が削除されました。E4X は今後使用できません。
• -moz-orient プロパティが auto キーワードに対応し、それがデフォルト値となりました。
• -moz-user-select:none が -moz-user-select:-moz-none と同じ挙動になりました。
• parseInt 関数が 10 進数でパースされるようになりました。parseInt("042") は 42 となります。

Places

• Places から廃止予定となっていた同期 API が削除されました。一部の同期間数が削除されました。変更点の一覧はバグの最初のコメントを参照してください。これはニュースグループでも 事前に告知されていました。
• nsINavHistoryFullVisitResultNode が削除されました。これにより、一部のアドオンで使用されている 2 つの定数、nsINavHistoryResultNode.RESULT_TYPE_FULL_VISIT と nsINavHistoryResultNode.RESULT_TYPE_DYNAMIC_CONTAINER も併せて削除されたことに注意してください。
• PlacesUIUtils.showBookmarkDialog から廃止予定となっていた 3 番目の引数が削除されました。
• FUEL からライブブックマーク対応が削除されました。
• onBeforeDeleteURI と onBeforeItemRemoved が削除されました。
• Places のクエリ結果におけるノード置換が廃止され、nodeReplaced ビュー通知が削除されました。nsINavHistoryResultObserver.nodeReplaced も削除されました。

XPCOM

• nsIDownloadManagerUI が旧式のダウンロード ID を使っている問題が修正されました。オプションのダウンロード ID 引数は nsIDownload オブジェクトとなりました。
• ContentChild の nsIConsoleListener において、addref、release 両メソッドがスレッドセーフ化されました。この変更は Bug 852220 によって行われました。簡単に言えば、メッセージが記録されたときに、即座に nsIConsoleListener オブジェクトが通知されると期待すべきでないということです。リスナーを削除してしまうとメッセージを失う可能性があります。
• NodeIterator と TreeWalker から expandEntityReferences が削除されました。
• nsSelectionIterator が削除されました。nsISelectionPrivate.getEnumerator も削除されました。

新機能

• 言語パックが初期設定で再起動不要となりました。
• 安全な PRNG が DOM 内に露呈されるようになりました。window.crypto.getRandomValues で暗号学的にランダムな値を得ることが可能となりました。

この一覧に載っていない変更点や間違いを見つけたらコメント欄でお知らせください。もしあなたのアドオンが Firefox 21 で動かなくなった場合は、筆者の方でも調査したいと思います。

AMO に登録されているアドオンの 自動互換性テストと対応バージョンの更新 はまもなく行われますので、AMO にアドオンを登録している方はメールをチェックしてみてください。

原文: 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