DSC とは

Developer Student Clubs（DSC）プログラムは、Google Developer Technologies に関心のある大学生向けのコミュニティ グループであり、学生の開発・リーダーシップ能力の向上を支援するプログラムです。

デベロッパーとして成長することに関心のあるすべての大学・大学院生の参加を歓迎します。 世界中の学生との交流、Google イベントへの参加、現役エンジニアと出会う機会など、さまざまな活動やワークショップを通じて開発能力とリーダーシップ力の向上を支援します。

米国を始め、ヨーロッパ、オーストラリア、東南アジア、アフリカ、インド、中東・北アフリカ、ラテンアメリカ地域などなど、合わせて 106 カ国以上、1265 拠点から世界中の学生たちが活動している DSC プログラム。今年、日本にも展開します。



このような方の参加をお待ちしています。

  • 世界を変えていく・インパクトを作ることに情熱がある方
  • コンピュータ プログラミングやソフトウェア エンジニアリングに技術的な理解をお持ちの方
  • チームを引っ張ってみた経験、リーダーシップのある方
※ 必須条件 : 卒業まで 2 学期（1 年）以上残っている現役大学生・大学院生（休学中の学生含む）の方が応募可能なプログラムです。


DSC を通してできること

  • Google のトレーニング コンテンツを使用して、デベロッパーとしてのスキルを高める
  • 自分のプロジェクトのスケールを拡大するため、チームの仲間を率いるリーダーシップスキルを身につける
  • 地域別の問題解決に向けたプロトタイプとソリューションの構築を学ぶ
  • グローバルなデベロッパー コンテストに参加する
  • Google の一部イベントや会議にアクセスする



2020～2021 学年度のオンライン申請が開始しました

  • オンライン申請期間 : 2021 年 4 月 7 日（水）～ 6 月 1 日（火）
  • 申請書の検討結果発表 : 2021 年 6 月 14 日（月）（個別の連絡）
  • インタビュー : 2021 年 6 月 21 日（月）～ 7 月 21 日（水）
  • 最終 DSC Lead 発表 : 2021 年 7 月 23 日（金）

※各ステップの結果は、個別通知し、上記の日程は変更になる場合がございます。



詳しくはこちら



Reviewed by Takuo Suzuki - Developer Relations Team

Google Maps Platform における機能を向上させ、デベロッパーやエンドユーザーの皆様に一層ご活用いただくために、時に既存の機能を非推奨にしなくてはならないことがあります。たとえば、2020 年は COVID-19（新型コロナウィルス感染症）の感染拡大を抑えるために、数多くの施設が一時的に閉鎖される状況となりました。Google Maps Platform はこれを受けて、 して営業のステータスを 3 つの値で表現できるようにするとともに、臨時休業している店舗を正確に表現できないことから  にしました。 本番環境のコードの変更は慎重に行う必要がありますので、Google Maps Platform チームとしても、機能を非推奨にすることは最小限に抑えるよう努めています。本稿では、プロジェクトに影響を与える可能性がある機能の非推奨に関する連絡を受け取った場合に、Google Maps Platform における機能の非推奨の仕組みをご理解頂き、適切なタイミングで対処頂けるよう解説したものです ...


この記事は Google Maps Platform デベロッパー アドボケイト Angela Yu による Google Cloud Blog の記事 "Reduce Deprecation Stress: Understand SDK Dependencies in Google Maps Platform" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Maps Platform における機能を向上させ、デベロッパーやエンドユーザーの皆様に一層ご活用いただくために、時に既存の機能を非推奨にしなくてはならないことがあります。たとえば、2020 年は COVID-19（新型コロナウィルス感染症）の感染拡大を抑えるために、数多くの施設が一時的に閉鎖される状況となりました。Google Maps Platform はこれを受けて、business_statusフィールドを導入して営業のステータスを 3 つの値で表現できるようにするとともに、臨時休業している店舗を正確に表現できないことから permanently_closed フィールドを非推奨にしました。

本番環境のコードの変更は慎重に行う必要がありますので、Google Maps Platform チームとしても、機能を非推奨にすることは最小限に抑えるよう努めています。本稿では、プロジェクトに影響を与える可能性がある機能の非推奨に関する連絡を受け取った場合に、Google Maps Platform における機能の非推奨の仕組みをご理解頂き、適切なタイミングで対処頂けるよう解説したものです。


非推奨と廃止の違い


まず、ソフトウェアに関する議論でよく混同される 2 つの用語の定義を見てみましょう。
  • 非推奨 : 使用をやめることをおすすめするものです。この理由として、他の良い代替方法や計画的な廃止などが挙げられます。
  • 廃止 : 以前は使用できたものが今後使用できない、またはサポートされないことを表します。廃止されたソフトウェアを呼び出すと、予期しない動作や無効なレスポンスが発生する可能性があります。

SDK における非推奨 : API の非推奨との違い


SDK には、2 つのレベルの非推奨があります。バージョンの非推奨と、機能の非推奨です。SDK のあるバージョンが非推奨になると、そのバージョンは間もなく廃止になります。廃止されたバージョンの SDK の依存関係を使用して構築すると、エラーやクラッシュが発生する可能性があります。そのため、SDK のあるバージョンが非推奨になったというお知らせを確認しましたら、新しいバージョン（理想的には、利用可能な最新のバージョン）に移行する時間を確保するようにしましょう。

次の 2 つの図は、機能の非推奨の 2 つの段階を示しています。最初に、非推奨の機能を含まない新しいメジャー バージョンを導入します。依存関係に古いバージョンを指定することで、非推奨の機能を続けて使用することができます。ただし、コードから非推奨の機能の使用を削除し、依存関係を新しいバージョンに更新するまでは、新しいバージョンでのみ利用できる機能は使用できません。



SDK で機能 B を非推奨にする例。v3.0 には機能 B が含まれていないため、機能 B をサポートしている最後のバージョンは v2 となります。機能 B の使用を続けるには、v2 の指定が必要となります。v3.0 にアップグレードするには、コードから機能 B の使用の削除が必要です。

非推奨の機能をサポートする最後のバージョンが廃止されると、その機能をサポートするバージョンはなくなり、機能の継続的な使用は保証されませんので、ご注意ください。




SDK でのバージョンの廃止の例。v2 は機能 B をサポートする最後のバージョンであり、サポートが終了しているため、機能 B を今後使用することはできません。SDK に依存するアプリケーションを新しく構築するには、サポートされているバージョンにアップグレードする必要があるため、機能 B の使用をやめる必要があります。

API や SDK における非推奨の微妙な違いについては、非推奨に関するドキュメントをご覧ください。現在非推奨となっているすべての機能を記載しています。


SDK の依存関係の管理方法


Google Maps Platform のモバイル向けの SDK（Maps SDK for Android、Places SDK for Android、Maps SDK for iOS、Places SDK for iOS）をお使いのデベロッパーは、依存関係のバージョンを管理することで、期限前に慌てて修正するのではなく、定期的なバージョン アップなどアプリの開発サイクルに合わせて非推奨の機能を移行するスケジュールを立てられます。

これらの SDK の場合、アプリの依存関係に正確なバージョン番号を指定することをおすすめします。Maps SDK for Android、Places SDK for Android、Maps SDK for iOS、Places SDK for iOS で、SDK の依存関係を管理する方法をドキュメントに記述しているのでご確認ください。

なお、Maps JavaScript API はモバイル向けの SDK とは異なります。バージョンは四半期ごとのスケジュールでリリースされたり廃止されたりするため、常に最新バージョンをデフォルト（v=weekly）で読み込むことをおすすめします。Maps JavaScript API の定期的な更新に備える方法について、詳しくはこちらをご覧ください。


コードを更新するタイミングの選択


最後のステップは、開発サイクルでの定期的なコード保守のスケジュールです。これにより、技術的な負担を最小限に抑えると同時に、SDK の最新の改善点を使用できます。リリースノートやサービスに関する必須のお知らせでは、コードの更新作業に必要となる労力を最小限に抑えるために、移行ガイドを提示したり、非推奨の機能を使用しないよう回避策を提案したりします。

前述の手順を踏むことで、次に非推奨の機能やバージョンに関する通知を受け取った場合に、安心してコードを更新し、最新の SDK のバージョンを導入するタイミングを選択することができます。安定した SDK のバージョンに照らしてモバイルアプリの構築が予測可能となり、ウェブサイトに影響を及ぼす可能性がある変更についての JavaScript リリースノートを受け取った際に何をすべきか（以前のバージョンを指定）が理解できます。前述のヒントにより、コードの更新を事前に計画し、非推奨の通知によるストレスをなくすことができれば幸いです。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。


Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Team

この記事は Chrome プロダクト マネージャー、Mark Chang による Chromium Blog の記事 "Advanced memory management and more performance improvements in M89" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
機能の追加やセキュリティの改善をしながらパフォーマンスを向上させるには、深く継続的な注力が必要です。今年のシリーズ記事の初回となる今日の投稿では、Chrome で継続的に行われているパフォーマンス関連の作業について、技術的詳細を紹介します。今回のリリースでは、Chrome の中核深くまで手を入れ、メモリの割り当てや破棄の方法をアップグレードしています。また、現在の Chrome のスピードとメモリ効率をさらに向上するため、Chrome のビルド、パッケージング、実行の方法も更新しています。 

メモリ管理の改善

Windows 版の Chrome M89 では、ブラウザ プロセスで最大 22%、レンダラで 8%、GPU で 3% と、大幅なメモリの節約を実現しました。さらに、ブラウザの応答性が最大 9% 改善しています。これは、Google の高度なメモリ アロケータである PartitionAlloc を使って実現しました。このアロケータは、割り当ての低遅延性、空間効率、セキュリティの面で最適化されています。PartitionAlloc は、これまでにも、Google のレンダラ コードベースである Blink の内部で広く使われています。M89 より、Android 版と 64 ビット Windows 版の Chrome をアップグレードし、（malloc をインターセプトして）すべての場所で PartitionAlloc を使うようにしました。

現在の Chrome は、メモリの割り当て方法が改善されただけでなく、メモリの使用（と破棄）についてもさらにスマートになりました。現在の Chrome は、画面外の大きなイメージなど、フォアグラウンド タブが使っていないメモリを破棄することで、タブ 1 つにつき最大 100 MiB を回収します。人気サイトの 20% 以上がこのようなサイトに該当します。macOS 版の Chrome では、バックグラウンド タブのメモリ フットプリントも縮小しています。これは、他のプラットフォームでしばらく前から行っていることです。これにより、最大 8%、場合によっては 1 GiB 以上のメモリを節約できます。

さらに、タブ スロットリングに関する実データが集まるにつれて、バックグラウンドのタブの Apple Energy Impact スコアが最大 65% 改善しています。つまり、Mac は熱くならず、ファンも静かになっています。


ビルド、パッケージング、ランタイムの改善

Chrome for Android に特化して、あらゆる種類の Android デバイスにとって快適なブラウザを作るという、他にはない挑戦をしています。今回のリリースでは、パッケージングとランタイムの最適化を適用し、ポケットの中の Chrome のパフォーマンスを向上させています。


新しい Play 機能や Android 機能を使うと、Android で Chrome を再パッケージングできます。これにより、リソースの枯渇によるクラッシュが減少し、メモリ使用量は 5%、スタートアップ時間は 7.5%、ページ読み込みは最大 2% 改善しました。Android App Bundle を使うと、各ユーザーのデバイス構成に合わせて最適化した APK を Play ストアで生成できます。コードやリソースを分割 APK にパッケージングして、ベース APK とともにインストールすることもできます。また、Android O の機能である isolatedSplits を使うと、これらの分割機能をオンデマンドで読み込むことで、Chrome 全般のスタートアップ コストを削減できます。

最新の Android デバイス（Android Q 以降かつ 8 GB 以上の RAM）をお使いの方のために、Chrome を 64 ビットバイナリとして再ビルドしました。これにより、ページの読み込みが最大 8.5% 速く、スクロールや入力のレイテンシが 28% 少なくなり、さらに安定した Chrome を提供できるようになっています。

加えて、Android で Chrome の起動が 13% 速くなる機能、フリーズドライ タブを組み込んでいます。この機能により、軽量版のタブが保存されるようになり、このタブのサイズはスクリーンショットと同じくらいでありながら、スクロール、ズーム、リンクのタップをサポートします。スタートアップ時には、実際のタブがバックグラウンドで読み込まれるまでの間、このフリーズドライ タブを利用してページにすばやくアクセスできます。以下の動作例をご覧ください。



Google のチームは、あらゆるデバイスに最速、最強のブラウザをお届けするために、常に懸命に作業を進めています。ここでお知らせしたパフォーマンスの改善を提供できることをうれしく思います。今後もさらに改善を続けますので、ご期待ください。

すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Android セキュリティおよびプライバシー チーム、Eugene Liderman による Google Online Security Blog の記事 "Continuing to Raise the Bar for Verifiable Security on Pixel" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

モバイル デバイスのセキュリティ評価は難しく、信頼できる方法で企業のクレイムを検証するには、独立した業界の認証（Certification）によるものである必要があります。スマートフォンの場合、特に確実なエンドツーエンドの認証（Certification）に Common Criteria（CC）Mobile Device Fundamentals（MDF）Protection Profile があります。Common Criteria は、31 か国に広がる大規模なセキュア IT プロダクトの相互認証（mutual recognition）を確立する原動力です。ここ数年間、すべての OS のバージョンで継続的に認証（Certification）を受けているスマートフォン メーカーは、Google、Samsung、Apple の 3 社のみです。2 月初頭には、現在サポート対象で、Android 11 を実行する Pixel スマートフォンのすべての認証（Certification）が完了しました。Google は、最新の OS バージョンで認証（Certification）を受けた最初のメーカーです。

この認証（Certification）は、コンシューマや企業が直面する現実の脅威に対するデバイスの防御力を評価するために設計されています。次の表は、CC MDF 保護プロファイルに示されている脅威と対策の概要です。

脅威

対策

ネットワークの盗聴 - 攻撃者がワイヤレス通信チャンネルなどのネットワーク インフラストラクチャ上に存在する

ネットワーク攻撃 - 攻撃者がワイヤレス通信チャンネルなどのネットワーク インフラストラクチャ上に存在する

通信の保護 - 安全な暗号化通信を保証する IPsec、DTLS、TLS、HTTPS、Bluetooth などの標準プロトコル

認可と認証 - ネットワークやバックエンドの安全な認証（Authentication）

モバイル デバイス設定 - ユーザーや企業の管理者が定義するセキュリティ ポリシーを設定して適用する機能

物理アクセス - 物理アクセス可能な攻撃者は、モバイル デバイスから認証情報を含むユーザーデータの取得を試みる可能性がある

ストレージの保護 - デバイスに含まれるデータを安全に保存（すなわち、保存データの暗号化） 

認可と認証 - パスワード、PIN、指紋、顔認証など、既知のロック解除要素を利用した安全なデバイス認証（Authentication）

悪意や欠陥のあるアプリケーション - モバイル デバイスに読み込まれたアプリケーションに、悪意のあるコードや悪用可能なコードが含まれる可能性がある 

通信の保護 - 安全な暗号化通信を保証する IPsec、DTLS、TLS、HTTPS、Bluetooth などの標準プロトコル

認可と認証 - ネットワークやバックエンドの安全な認証（Authentication）

モバイル デバイス設定 - ユーザーや企業の管理者が定義するセキュリティ ポリシーを設定して適用する機能

モバイル デバイスの整合性 - ソフトウェア、ハードウェアの両方における重要な機能のデバイスの整合性

エンドユーザー プライバシーとデバイスの機能 - アプリケーション分離やサンドボックス化、フレームワーク アクセス許可により、ユーザー アクティビティごとの分離やプライバシーを提供

恒常的な存在 - 攻撃者がデバイスに恒常的に存在する場合、デバイスは整合性を失い、それを取り戻せないことを意味する 

モバイル デバイスの整合性 - ソフトウェア、ハードウェア両方における重要な機能の整合性を保証するためのデバイスの整合性が保たれている

エンドユーザー プライバシーとデバイスの機能 - アプリケーション分離やサンドボックス化、フレームワーク アクセス許可により、ユーザー アクティビティごとの分離やプライバシーを提供


この認証（Certification）が重要なのは、認定を受けたラボが実際にデバイスを評価し、さまざまなテストをして以下を確認しているためです。

  1. すべての対策があらかじめ定義された標準や基準を満たしている。
  2. すべての対策が公表されているとおりに機能する。

概念的には、評価対象（TOE）はデバイスのハードウェア（システム オン チップ）とオペレーティング システム（Android）の組み合わせです。上記の脅威に対する対策を検証するため、ラボは以下のセキュリティ機能を確認します。

これが企業にとって重要な理由

Pixel のセキュリティが企業のニーズを確実にサポートできることは、非常に重要です。規制が厳しい業界の多くでは、機密データが考えられる限り最も強固な保護を受けられるように、Common Criteria 認証（Certified）デバイスの利用が義務付けられています。Android Enterprise 管理フレームワークでは、企業がデバイスの管理などをし、エンドユーザーが実行できる操作を制限したり、デバイスを監査してすべてのソフトウェアが適切に設定されていることを保証したりできます。たとえば、企業の IT 管理者は、カメラ、位置情報サービス、アプリのインストール プロセスなどの機能に対するポリシーを強制できます。

これがコンシューマにとって重要な理由

セキュリティは企業だけが心配することではありません。Common Criteria 認証（Certification）で検証している多くの保護は、コンシューマにも適用されます。たとえば、Wi-Fi に接続するとき、ウェブのブラウズを誰にも盗聴されないことを確認したいと思うでしょう。デバイスの紛失や盗難の際は、ロック画面によって他人が個人情報にアクセスする可能性が減ると確信したいはずです。

Google は、すべてのユーザーにセキュリティとプライバシーをお届けしたいと考えています。Pixel デバイスがこの認証（Certification）基準以上を確実に満たせるようにしたいと考えているのはそのためです。今後もこの基準を満たすために注力しますので、どうぞご安心ください。Pixel スマートフォンでは、スイッチを入れた瞬間から充実したセキュリティを利用できます。

これが Android エコシステムにとって重要な理由

認証（Certification）はサードパーティによる検証として有用な形態ですが、以下の、Google が 3 C と呼ぶものに該当することがよくあります。

  • Complex（複雑） - デバイスのハードウェア、オペレーティング システム、その間にあるものすべてを含む評価スコープであるため。
  • Costly（高価） - すべての形式とモデルの組み合わせ（SoC + OS）について、認定を受けたラボで実際に評価作業をする必要があり、個々のテストは数百件にのぼるため。
  • Cumbersome（厄介） - かなり長い評価手続きで、初回は最長で 18 か月を要するため。

ここ 3 年間は、OEM パートナーを対象に、この複雑さを軽減するための作業をしてきました。その結果、必要なセキュリティ要件を満たすために要求される機能が Android オープンソース プロジェクトに直接組み込まれることをお知らせします。さらに、すべての管理要件と監査要件を Android Enterprise Management フレームワークに追加しました。昨年は、このために開発したツールを GitHub に公開しました。他の Android OEM が認証（Certification）を受ける際に、この作業のメリットを活用できるようにするためです。

新しい Android OS バージョンでの Pixel スマートフォンの認証（Certification）は継続しますが、Google はその他の Android OEM も、この認証（Certification）や、以下のその他の認証（Certification）を取得できるように取り組んでいます。

  • アメリカ国立標準技術研究所の Cryptographic Algorithm と Module Validation Programs。これは暗号アルゴリズムとモジュールの評価で、アメリカの公共部門やその他多くの規制のある業界で求められています。Android 11 では、Conscrypt の主要モジュールである BoringSSL がこの検証を終えています（認定番号 3753）。
  • アメリカ国防総省の Security Technical Implementation Guide（略称 STIG）。アメリカ国防総省のネットワークに技術を導入する方法をまとめたガイドラインです。かつては Android OEM に独自の実装や制御があったので、それによって異なる STIG が存在していましたが、Google の作業の成果によって、現在は 1 つの Android STIG テンプレートに統合されています。そのため、Android OEM は、さまざまな要件を満たすために独自の制御を作成する手間をかけずに済みます。

今後も、企業とコンシューマの両方を対象にしたセキュリティ対策に注力してまいります。業界の皆さんがこの作業に加わってくれることを歓迎いたします。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chrome オペレーションズ、テクニカル プログラム マネージャー、Alex Mineer による Chromium Blog の記事 "Speeding up Chrome's release cycle" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Chrome は 10 年以上にわたり、6 週間ごとに新しいマイルストーンを公開し、ユーザーとウェブにセキュリティ、安定性、スピード、シンプルさをもたらしてきました。Chrome のテストとリリースのプロセスを改善し、パッチ間隔を短縮するために隔週のセキュリティ アップデートを導入した結果、リリース サイクルを短縮して新機能をさらに早く提供できる見込みが立ちました。そこで、2021 年第 3 四半期の Chrome 94 から、新しいマイルストーンを 4 週間ごとにリリースする方式に移行することをお知らせします。

さらに、8 週間ごとにマイルストーンがアップデートされる Extended Stable オプションを新しく追加します。Extended Stable は、エンタープライズの管理者や Chromium を埋め込みで利用しているユーザーで、アップデートの管理に追加の時間が必要な方が利用できます。Extended Stable では、重要な問題を修正するセキュリティ アップデートは 2 週間ごとにリリースされますが、このアップデートには、4 週間ごとのオプションで提供される新機能やセキュリティの修正は含まれません。 

Chrome OS ユーザーの皆さんにも、複数の安定版リリース オプションを提供する予定です。Chrome OS の管理者には、今後の数か月間で、管理対象のデバイスに対するマイルストーンのアップデート オプションについてさらに詳しくお伝えします。

新しいリリース スケジュールに関するドキュメントは、最新の状態に更新しています。また、branches@chromium.org で Chromium のコントリビューターの皆さんからのフィードバックをお待ちしています。新しいリリース スケジュールの導入に向けて、リリース カレンダーにも仮のアップデートをしています。このカレンダーは、常に最新の状態に更新します。

今後も Chrome の進化が続き、セキュリティ、安定性、スピード、シンプルさをこれまで以上に早くユーザーの皆さんにお届けできることを楽しみにしています。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chromium Blog の記事 "Chrome 90 Beta: AV1 Encoder for WebRTC, New Origin Trials, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 3 月 11 日時点で、Chrome 90 はベータ版です。

AV1 エンコーダ

デスクトップ版の Chrome に AV1 エンコーダが搭載されます。このエンコーダは、組み込みの WebRTC を利用したテレビ会議に特に最適化されています。AV1 には、以下のようなメリットがあります。

  • 他の動画エンコーディングよりも圧縮効率が高いため、帯域幅の消費を抑えて画質を改善できる
  • 帯域幅が低いネットワークで動画が利用できる（30 kbps 以下で動画が利用可能）
  • VP9 などのコーデックに比べて、画面共有の効率が大幅に向上する

WebRTC は最近正式に W3C と IETF の標準になったので、この追加は特に重要です。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルをしています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。

新しいオリジン トライアル

getCurrentBrowsingContextMedia()

mediaDevices.getCurrentBrowsingContextMedia() メソッドを使うと、getDisplayMedia() と同様に、現在のタブの動画（可能な場合は音声も）から MediaStream をキャプチャできます。getDisplayMedia() とは異なり、この新しいメソッドを呼び出すと、許可するか拒否するかを選択する単純なダイアログ ボックスが表示されます。ユーザーが許可した場合は、現在のタブがキャプチャされます。getCurrentBrowsingContextMedia() のその他の動作は、すべて getDisplayMedia() と同じです。このオリジン トライアルは、Chrome 92 まで行われる予定です。

MediaStreamTrack Insertable Streams（別名 Breakout Box）

カメラやマイク、画面キャプチャ、コーデックのデコーダ部分などの出力や、コーデックのデコーダ部分への入力など、MediaStreamTrack のローメディアを操作する API です。WebCodecs インターフェースを使ってローメディアのフレームを表現し、ストリームを使って公開します。この仕組みは、WebRTC Insertable Streams API が RTCPeerConnection からエンコード済みデータを公開する方法と同様です。次のようなユースケースをサポートすることを想定しています。

  • 特殊効果 : 背景を削除したり、おかしな帽子をかぶったり、ボイス エフェクトを加えたりするなど、エンコード前やデコード後のメディアを操作することを指します。
  • 機械学習 : リアルタイム物体識別、注釈付けなどのアプリケーションを指します。

このオリジン トライアルは、Chrome 92 まで行われる予定です。

WebAssembly の例外ハンドリング

WebAssembly が例外ハンドリングをサポートするようになりました。例外ハンドリングを利用すると、コードで例外がスローされたときに制御フローを抜けることができます。例外は、WebAssembly モジュールの既知の例外でも、インポートされて呼び出された関数がスローした未知の例外でも構いません。このオリジン トライアルは、Chrome 94 まで行われる予定です。

完了したオリジン トライアル

Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。

WebXR AR ライティング推定

ライティング推定を利用すると、サイトから WebXR セッション内の環境光条件の推定値を照会できます。これにより、環境光を表す球面調和関数と、「反射」を表すキューブマップ テクスチャの両方を取得できます。ライティング推定を追加すると、モデルが自然になってユーザーの環境への「適合度」が上がる可能性があります。

今回のリリースに追加されたその他の機能

CSS

aspect-ratio の補完

aspect-ratio プロパティを使うと、ある要素の横か縦のサイズだけが指定された場合に、もう片方のサイズを自動計算できます。もともとこのプロパティは、アニメーション時に補完されない（つまり、ターゲット値にスナップする）ものとして導入されました。この機能により、あるアスペクト比から別のアスペクト比に変化するときに、スムーズな補完が行われるようになります。

カスタム状態疑似クラス

カスタム要素が、状態を表す CSS 疑似クラスを介してカスタム要素の状態を公開するようになります。ビルトイン要素には状態が存在します。これは、ユーザーのインタラクションなどによって時間とともに変化する場合があり、疑似クラスを通してウェブ制作者に公開されます。たとえば、フォームのコントロールの中には、"invalid" 状態を持つものがあり、これが :invalid 疑似クラスで公開されています。カスタム要素も状態を持つので、ビルトイン要素と同じように状態を公開できるのは妥当です。

appearance と -webkit-appearance への 'auto' 値の実装

以下のフォーム コントロールの CSS プロパティ appearance と -webkit-appearance のデフォルト値が、'auto' に変更されます。

  • <input type=color> と <select>
  • Android のみ : <input type=date>、<input type=datetime-local>、<input type=month>、<input type=time>、<input type=week>

これらのコントロールのデフォルトのレンダリングは変更されません。

overflow: clip プロパティ

overflow に clip 値を指定すると、ボックスのコンテンツがボックスのオーバーフロー クリップエッジでクリップされます。さらに、スクロール インターフェースは提供されず、ユーザーやプログラムはコンテンツをスクロールできなくなります。また、ボックスはスクロール コンテナとは見なされず、新しいフォーマッティング コンテキストは開始されません。そのため、この値を使うと、overflow: hidden を使う場合よりもパフォーマンスが向上します。

overflow-clip-margin プロパティ

overflow-clip-margin プロパティを使うと、要素が境界のどのくらい外側まで描画できるかを指定できます（その範囲を超えるとクリップされます）。デベロッパーは、このプロパティを使ってクリップ境界を拡張することもできます。これは、インク オーバーフローを表示したい場合に特に便利です。

Permissions-Policy ヘッダー

Permissions-Policy HTTP ヘッダーは、アクセス許可や機能の委譲を制御する既存の Feature-Policy ヘッダーを置き換えます。このヘッダーを使うと、どのオリジンに機能へのアクセスを許可するかをサイトで厳密に制限できます。

Chrome 74 で導入された Feature Policy API は、最近 "Permissions Policy" という名前に変わり、それに伴って HTTP ヘッダーの名前も変更されました。同時に、コミュニティは HTTP の構造化フィールド値に基づいた新しい構文を決定しています。

Cross-Origin-Read-Blocking による application/x-protobuffer の保護

Cross-Origin-Read-Blocking が利用する盗聴されない MIME タイプのリストに application/x-protobuffer を追加し、これを投機的実行攻撃から守ります。application/x-protobuf は、すでに盗聴されない MIME タイプとして保護されています。application/x-protobuffer もよく使われている MIME タイプで、protobuf ライブラリによって "ALT_CONTENT_TYPE" として定義されています。

File System Access API での末尾を超えたファイルのシーク

FileSystemWritableFileStream.write() にファイルの末尾を超えるデータを渡した場合、0x00（NUL）を書き込んでファイルを拡張します。これにより、疎なファイルを作成できるので、書き込むデータが順不同で届く場合に、コンテンツをファイルに保存する処理を大幅に簡略化できます。
この機能がないと、ファイルのコンテンツを順不同で受け取るアプリケーション（たとえば、BitTorrent のダウンロード）は、事前に、または書き込み中にファイルのサイズ変更が必要になった場合に、手動でそれを行う必要があります。

StaticRange コンストラクタ

現在、ウェブ制作者が作成できる範囲型は Range のみです。しかし、Range オブジェクトは「ライブ」であり、これをメンテナンスするのはコストがかかる場合があります。ツリーが変更されるたびに、影響を受けるすべての Range オブジェクトの更新が必要です。新しい StaticRange オブジェクトは、ライブではない軽量の範囲型を表すので、Range と同じようなメンテナンス コストはかかりません。StaticRange を作成可能にすることで、ウェブ制作者は DOM ツリーの変更に応じて更新する必要がない範囲にこれを利用できます。

<picture> の <source> 要素での幅と高さの指定のサポート

<picture> 要素内で <source> 要素を使う場合、width と height プロパティがサポートされます。これにより、Chrome が <picture> 要素のアスペクト比を計算できるようになります。これは、<img>、<canvas>、<video> の各要素の動作と一致します。

WebAudio: OscillatorOptions.periodicWave を null 不可能に

新しい OscillatorNode オブジェクトを作成するときに、periodicWave に null を設定できなくなります。この値は、OscillatorNode() コンストラクタに渡される options オブジェクトに設定されます。WebAudio 仕様では、この値に null を設定することは許可されていません。これにより、Chrome の動作が仕様と Firefox に一致します。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.0 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。

Array、String、TypedArray の相対インデックス メソッド

Array、String、TypedArray が at() メソッドをサポートします。このメソッドは、負の数による相対インデックスをサポートします。たとえば、次のコードは指定された配列の最後の項目を返します。

let arr = [1,2,3,4];
arr.at(-1);

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

コンテンツ セキュリティ ポリシー ディレクティブ 'plugin-types' の削除

'plugin-types' ディレクティブを使うと、<embed> または <object> html 要素で読み込めるプラグインの種類をデベロッパーが制限できます。これにより、デベロッパーはページ内の Flash をブロックできます。Flash のサポートは終了したので、このポリシー ディレクティブは不要になりました。

WebRTC RTP データ チャンネルの削除

Chrome では、WebRTC の非標準である RTP データ チャンネルのサポートを削除しました。ユーザーは、標準の SCTP ベースのデータ チャンネルを使用する必要があります。

navigator.plugins と navigator.mimeTypes で空を返却

Chrome は navigator.plugins と navigator.mimeTypes に対して空を返します。Flash が削除されたことで、これらのプロパティから何かを返す必要はなくなりました。


Reviewed by Eiji Kitamura - Developer Relations Team

3 年前、 によってウェブのセキュリティ境界についての考え方が変わりました。ウェブブラウザはアプリケーション間のデータ漏洩を防げるという保証が によって損なわれたことは、すぐに明らかになりました。その結果、ウェブブラウザ ベンダーが協力し合い、継続的にプラットフォームの堅牢化に取り組んでいます。しかし、この種の攻撃は依然として懸念され続けており、ウェブ デベロッパーが を導入することも求められています。 この投稿では、ウェブユーザーに対する Spectre の悪用に関して、Google セキュリティ チームが行った調査の結果を共有します。また、JavaScript で書かれた高速で柔軟な概念実証（PoC）も提示し、ブラウザのメモリから情報が漏洩することを示します。この概念実証やそのバリアントは、さまざまなオペレーティング システム、プロセッサ アーキテクチャ、ハードウェア世代で動作することを確認しています ...
この記事は情報セキュリティ エンジニア、Stephen Röttger、Artur Janc による Google Online Security Blog の記事 "A Spectre proof-of-concept for a Spectre-proof web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

3 年前、Spectre によってウェブのセキュリティ境界についての考え方が変わりました。ウェブブラウザはアプリケーション間のデータ漏洩を防げるという保証が最新プロセッサの欠陥によって損なわれたことは、すぐに明らかになりました。その結果、ウェブブラウザ ベンダーが協力し合い、継続的にプラットフォームの堅牢化に取り組んでいます。しかし、この種の攻撃は依然として懸念され続けており、ウェブ デベロッパーがアプリケーション レベルの対策を導入することも求められています。

この投稿では、ウェブユーザーに対する Spectre の悪用に関して、Google セキュリティ チームが行った調査の結果を共有します。また、JavaScript で書かれた高速で柔軟な概念実証（PoC）も提示し、ブラウザのメモリから情報が漏洩することを示します。この概念実証やそのバリアントは、さまざまなオペレーティング システム、プロセッサ アーキテクチャ、ハードウェア世代で動作することを確認しています。

この発見をセキュリティ コミュニティと共有する目的は、ウェブ アプリケーションの所有者に、Spectre による脆弱性がユーザーのデータのセキュリティに与える可能性がある影響について深く理解してもらうためです。さらに、Google 全体の経験に基づき、ウェブ制作者が利用できる対策やウェブ アプリケーションで実現できるベスト プラクティスについても説明します。

簡単な背景

Spectre の脆弱性は、2018 年 1 月に一般に公表されました。プロセッサ（CPU）の設計上の脆弱性の一種を攻撃者が利用して、CPU が後続の命令を投機的に実行する際に、プログラムで意図された制御フローを変えることができます。たとえば、CPU が長さチェックに合格すると推測しても、実際には境界外のメモリにアクセスすることになります。CPU の状態は推測ミスが明らかになるとロールバックされますが、この動作による副作用は管理できるため、攻撃者にデータが漏洩する可能性があります。

2019 年、Chrome の JavaScript エンジンである V8 の担当チームは、ブログ投稿とホワイトペーパーを公開し、ソフトウェア レベルではこのような攻撃に確実に対策することはできないという結論を出しました。この問題に対する確実なソリューションとしては、ウェブブラウザなどのアプリケーションに、プロセスベースの分離のような低レベル プリミティブに合わせたセキュリティ境界が必要になります。

これと並行して、ブラウザのベンダーや標準化団体は、この種の攻撃からウェブユーザーを守るためのセキュリティ メカニズムを開発しました。これには、一部のブラウザ構成で実現できるデフォルトの保護を提供するためのアーキテクチャの変更（Site Isolation（サイト分離）、out-of-process iframes = OOPIF（プロセス外 iframe）、Cross-Origin Read Blocking = CORB（クロスオリジン読み取りブロック）など）と、ウェブ デベロッパーがアプリケーションに広く適用できるオプトイン セキュリティ機能（Cross-Origin Resource Policy、Cross-Origin Opener Policy、Cross-Origin Embedder Policy など）の両方が含まれています。

これらのメカニズムは非常に重要ですが、これで Spectre の悪用を防ぐことはできません。むしろ、攻撃者が読み取ることができるメモリに機密データが含まれないようにするための措置です。そのため、この対策の確実性を評価するには、セキュリティ エンジニアがアプリケーションに対する投機的実行攻撃の実際の影響について理解する際に役立つ、セキュリティ ツールを開発することが重要になります。

ウェブブラウザを利用した Spectre のデモ

今日は、実際に Spectre が JavaScript エンジンを侵害することを確認できる概念実証（PoC）コードを共有します。攻撃のデモには Google Chrome を使いますが、これは Chrome に固有の問題ではなく、他のモダンブラウザも同様にこの脆弱性の影響を受けるものと考えられます。攻撃のインタラクティブなデモを開発し、https://leaky.page/ で公開しました。コードと詳しい説明は、こちらの Github をご覧ください。




Intel Skylake CPU で Chrome 88 を実行している場合、デモのウェブサイトでは 1 kB/ 秒のスピードでデータが漏洩する可能性があります。なお、このコードはわずかに変更するだけで他のバージョンの CPU やブラウザにも適用できると考えられます。ただし、Google のテストでは、大きな変更を加えなくても、この攻撃を Apple M1 ARM CPU などの他のいくつかのプロセッサで成功させることができました。

実験にあたり、異なる特性を持つ他の PoC も作成しました。いくつかの例を示します。
  • performance.now() を 5 マイクロ秒の精度のタイマーとして使うことで、安定性と引き替えに 8 kB/ 秒でデータを漏洩する PoC
  • 1 ミリ秒またはそれより粗い精度のタイマーを使うことで、60 B/ 秒でデータを漏洩する PoC

現在の PoC を公開することにしたのは、セットアップ時間が無視できる程度であり、SharedArrayBuffer のような高精度なタイマーがなくても動作するからです。

PoC の主な構成要素は、以下のとおりです。
  1. Spectre ガジェット : 攻撃者が制御する一時的実行を呼び出すコード
  2. サイドチャネル : 一時的実行の副作用を管理する方法

1. ガジェット

公開した PoC では、単純なバリアント 1 のガジェットを実装しました。コンパイラが挿入した長さチェックが成功することを予測する分岐予測のトレーニング後に、JavaScript 配列の境界外への投機的なアクセスが発生します。このガジェットではソフトウェア レベルの対策を取れますが、Chrome の V8 チームは、他のガジェットではそうはいかないと結論づけています。「一部の Spectre のバリアント、とりわけバリアント 4 に対しては、ソフトウェアで効果的に対策するのは不可能であるとわかりました」と述べています。

セキュリティ コミュニティの皆さんには、さらに調査をし、他の Spectre ガジェットを利用したコードを作成することをお勧めします。

2. サイドチャネル

投機的実行によって秘密データが漏洩する場合、キャッシュ サイドチャネルが使われるのが一般的です。メモリ内の特定の場所がキャッシュに存在するかどうかを管理すると、投機的実行によるメモリへのアクセスがあったかどうかを推測できます。JavaScript で難しいのは、キャッシュ アクセスとメモリ アクセスを判別できるほどの高精度タイマーを見つけることです。モダンブラウザは、タイミング攻撃を防ぐため、クロスオリジン分離が行われていない状況で performance.now() API のタイマーの精度を粗くし、SharedArrayBuffer を利用できないようにしています。

V8 チームは、2018 年時点ですでに、タイマーの精度を粗くすることは Spectre の対策としては不十分であると報告しています。攻撃者はタイミングの差を自由に増幅できるからです。ただし、そこで述べられている増幅テクニックは、秘密データを複数回読み取る方法に基づいているので、情報の漏洩が確率的なものである場合は、攻撃の効率を低下することができます。

今回の PoC では、新たなテクニックを使ってこの制限を回避しました。最近の CPU でよく使われる Tree-PLRU キャッシュ エビクション戦略の動作を悪用すれば、秘密データを 1 回読み取ることで、キャッシュのタイミングを大きく増幅することができます。これにより、低精度タイマーでも、効率よくデータを漏洩することができました。このテクニックの詳細については、https://leaky.page/plru.html のデモをご覧ください。

この PoC は、大きく改変しない限り、悪用目的で再利用できるとは考えられません。しかし、Spectre のリスクを示す上では、説得力のあるデモとなります。特に、このリスクを考慮してセキュリティ評価をする必要があるウェブ アプリケーション デベロッパーにとっての明らかなシグナルとなり、サイトを保護する積極的なアクションにつながることを期待しています。

ウェブにおける Spectre 対策の導入

投機的実行による脆弱性は本質的に低レベルで発生するため、適切なパッチにはユーザーのデバイスのファームウェアやハードウェアの変更が必要になる場合があり、包括的な修正は難しくなります。オペレーティング システムやウェブブラウザのデベロッパーは、可能な限り重要な組み込みの保護機能を実装しています（Google Chrome の out-of-process iframes（プロセス外 iframe） や Cross-Origin Read Blocking（クロスオリジン読み込みブロック）による Site Isolation（サイト分離）、Firefox の Project Fission など）。しかし、既存の API 設計では、データが意図せずに攻撃者のプロセスに流れ込む可能性が残ります。

ウェブ デベロッパーは、この点を考慮してサイトをさらに確実に分離することを検討する必要があります。そのためには、新しいセキュリティ メカニズムを使い、攻撃者によるクロスオリジン リソースへのアクセスを積極的に防ぎます。このような保護は、Spectre スタイルのハードウェア攻撃や一般的なウェブレベルのクロスサイト漏洩の対策となりますが、デベロッパーはそういった脆弱性によるアプリケーションへの脅威を評価し、その対策のデプロイ方法を理解する必要があります。Chrome のウェブ プラットフォーム セキュリティ チームは、この評価に役立ててもらうため、デベロッパー向けの具体的なアドバイスを含む Spectre 後のウェブ開発とサイドチャネル攻撃への対策を公開しました。このガイドに従って以下の保護をすることを強くお勧めします。
  • Cross-Origin Resource Policy（CORP）と Fetch メタデータ リクエスト ヘッダーを使うと、イメージやスクリプトなどのリソースを埋め込むことができるサイトを制御して、攻撃者が制御するブラウザのレンダリング プロセスにデータが渡るのを防げます。詳しくは、resourcepolicy.fyi と web.dev/fetch-metadata をご覧ください。
  • Cross-Origin Opener Policy（COOP）を使うと、アプリケーション ウィンドウで他のウェブサイトからの予期しないインタラクションの受け取りを拒否できます。これにより、ブラウザはプロセス内でウィンドウを分離できるようになります。これは重要なプロセスレベルの保護を追加することになり、完全なサイト分離を有効化できないブラウザで特に重要になります。詳しくは、web.dev/coop-coep をご覧ください。
  • Cross-Origin Embedder Policy（COEP）を使うと、アプリケーションがリクエストした認証済みリソースの読み込みを明示的にオプトインできます。 現在、Chrome や Firefox の機密性が高いアプリケーションでプロセスレベルの分離を保証するには、COEP と COOP の両方を有効化する必要があります。詳しくは、web.dev/coop-coep をご覧ください。
アプリケーションでは、これらの分離メカニズムに加えて、X-Frame-Options ヘッダーや X-Content-Type-Options ヘッダーなどの標準の保護も有効化し、SameSite Cookie を使うようにしてください。多くの Google 製アプリケーションでは、このようなメカニズムをすでに導入しているか、現在導入の過程にあります。このようなメカニズムは、デフォルトのブラウザ保護が十分でない場合に、投機的実行のバグに対する保護となります。

覚えておくべき重要な点は、この記事で説明したすべてのメカニズムは重要で強力なセキュリティ プリミティブですが、Spectre に対する完全な保護を保証するものではないことです。また、アプリケーションに固有の動作を考慮したデプロイ方法の検討も必要です。セキュリティ関連のエンジニアや研究者の皆さんには、この Spectre の概念実証の利用と貢献をお願いいたします。サイトのセキュリティ状況の確認や改善に役立てていただきたいと考えています。

ヒント : ウェブサイトを Spectre から守るために役立てていただけるよう、Google セキュリティ チームは Spectroscope を作成しました。これは Chrome 拡張機能のプロトタイプで、アプリケーションをスキャンして、さらなる防御が必要になる可能性があるリソースを見つけます。ウェブ分離機能の導入と合わせてご検討ください。

Reviewed by Eiji Kitamura - Developer Relations Team