Google Developers Japan: 2021

Google Cloud Day: Digital ’21 セッション情報公開のお知らせ

2021年4月12日月曜日

デジタルカンファレンス Google Cloud Day: Digital ’21 開催まで、あと 1 か月半となりました。セッション情報が公開されましたので、気になるセッションをぜひこちらからチェックしてみてください。

今回は、初日の「基調講演」と、翌週に開催される「ハンズオン祭」をご紹介します。

今年の基調講演は、昨年よりさらにパワーアップして、二部構成でお送りします。

前半（10:00-10:45）は「Data-powered innovation」をテーマに、データの利活用や働き方改革を Google Cloud を導入して進めている企業のリーダーに、ご登壇いただきます。また、Google Cloud からは最新のクラウドソリューションをご提案します。

後半（11:00-11:45）は「Open Cloud leading transformation」をテーマに、システムのモダナイゼーションと、従来システムとのハイブリッドクラウド環境によってトランスフォーメーションを実現している企業から、その体験をご紹介いただきます。そして、Google Cloud からは、パートナーエコシステムをより強化している中で Anthos のソリューションをご紹介します。

登壇企業（敬称略）:

株式会社ファーストリテイリング、LIXIL 株式会社、京都大学、ウーブン・プラネット・ホールディングス株式会社、エムスリー株式会社、株式会社エヌ・ティ・ティ・データ、日本ヒューレット・パッカード株式会社

ハンズオン祭

基調講演、ブレイクアウトセッションでの学びを、翌週 6 月 01 日 (火) - 03 日 (木) に開催される「ハンズオン祭」で実践しましょう。

はじめて Google Cloud を利用される方は「はじめてみよう Google Cloud」で、製品の概要や各種機能を、実際に手を動かして体験いただけます。

「Study Jam」では、Qwiklabs（30 日間無料特典つき）を使って Google Cloud を体験でき、Google エンジニアへの質問も可能です。

ハンズオン祭のいずれかのセッションに出席された方の中から、抽選で 50 名様に Google Cloud 特製手ぬぐいをプレゼントします。

※ハンズオン祭への参加は、Google Cloud Day: Digital '21 とは別にお申し込みが必要となります。以下のリンクからご興味のあるセッションへ、それぞれお申し込みください。

☁ 6 月 1 日（火）

10:00 - 13:00 Study Jam Cloud Developer 編 https://goo.gle/2QS4Ymx

14:00 - 17:00 はじめてみよう Google Cloud Cloud Run 編　 https://goo.gle/31BKHDT

☁ 6 月 2 日（水）

10:00 - 13:00　Study Jam Cloud DevOps 編　https://goo.gle/2QVjWs6

14:00 - 17:00　はじめてみよう Google Cloud Kaggle (BQ, BQML) 編　https://goo.gle/39yMC0l

☁ 6 月 3 日（木）

10:00 - 13:00　Study Jam Machine Learning 編　https://goo.gle/3dmMZfM

14:00 - 17:00　はじめてみよう Google Cloud Dialogflow CX 編　https://goo.gle/2Oe4hmI

開催概要

日程 :

2021 年 5 月 25 日 ( 火 ) - 27 日 ( 木 ) : 基調講演、ブレイクアウトセッション

2021 年 6 月 01 日 ( 火 ) - 03 日 ( 木 ) : ハンズオン祭

対象 : 開発者、ビジネスの意思決定者やリーダー

ハッシュタグ : #GoogleCloudDay

————————————————————

お問い合わせ先 : Google Cloud Day: Digital 事務局

google-cloudday-tokyo-office@google.com

————————————————————

4月7日より、DSC Japan が本格始動します

2021年4月7日水曜日

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 における SDK の依存関係について

2021年4月6日火曜日

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

非推奨と廃止の違い

まず、ソフトウェアに関する議論でよく混同される 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 89 での高度なメモリ管理とさらなるパフォーマンスの改善

2021年4月5日月曜日

この記事は Chrome プロダクトマネージャー、Mark Chang による Chromium Blog の記事 "Advanced memory management and more performance improvements in M89" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent }機能の追加やセキュリティの改善をしながらパフォーマンスを向上させるには、深く継続的な注力が必要です。今年のシリーズ記事の初回となる今日の投稿では、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 クライアントから匿名で集計した実データ。Eiji Kitamura - Developer Relations Team

Pixel で検証可能なセキュリティ水準の継続的な向上について

2021年4月2日金曜日

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

モバイルデバイスのセキュリティ評価は難しく、信頼できる方法で企業のクレイムを検証するには、独立した業界の認証（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）が重要なのは、認定を受けたラボが実際にデバイスを評価し、さまざまなテストをして以下を確認しているためです。

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

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

通信の保護（転送データの暗号化） - Wi-Fi トラフィックやその他のネットワークの操作や通信を暗号化するために使用する暗号アルゴリズムと転送プロトコル。
ストレージの保護（保存データの暗号化） - システムオンチップが提供する暗号化、信頼済み実行環境、Titan M や Android OS などのその他個々の改ざんできないハードウェア。具体的には、ファイルベースの暗号化の実装、ハードウェアのルートオブトラスト、鍵ストアの操作（鍵生成など）、鍵の保存、鍵の破棄、鍵階層などを調査します。
認可と認証 - パスワード、PIN、生体認証など、ユーザーのデバイスのロック解除の仕組み。レート制限などの対策手法と、生体認証の場合は他人受入率やなりすまし受け入れ率。
モバイルデバイスの整合性 - Android の確認付きブート、Google Play システムアップデート、シームレス OS アップデートの実装。
監査性 - デバイスのスタートアップやシャットダウン、データの暗号化、データの復号化、鍵の管理などのイベントのログをユーザーや IT 管理者が記録できる機能。
モバイルデバイス設定 - ユーザーや企業の管理者が Android Enterprise を利用してデバイスにセキュリティポリシーを適用できる機能。

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

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 は、さまざまな要件を満たすために独自の制御を作成する手間をかけずに済みます。

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

Eiji Kitamura - Developer Relations Team

Chrome のリリースサイクルの高速化について

2021年4月2日金曜日

この記事は Chrome オペレーションズ、テクニカルプログラムマネージャー、Alex Mineer による Chromium Blog の記事 "Speeding up Chrome's release cycle" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent }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 の進化が続き、セキュリティ、安定性、スピード、シンプルさをこれまで以上に早くユーザーの皆さんにお届けできることを楽しみにしています。Eiji Kitamura - Developer Relations Team

Chrome 90 ベータ版: WebRTC 用 AV1 エンコーダ、新しいオリジントライアルなど

2021年4月1日木曜日

この記事は Chromium Blog の記事 "Chrome 90 Beta: AV1 Encoder for WebRTC, New Origin Trials, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent }特に記載のない限り、下記の変更は 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 セッション内の環境光条件の推定値を照会できます。これにより、環境光を表す球面調和関数と、「反射」を表すキューブマップテクスチャの両方を取得できます。ライティング推定を追加すると、モデルが自然になってユーザーの環境への「適合度」が上がる可能性があります。今回のリリースに追加されたその他の機能CSSaspect-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 が削除されたことで、これらのプロパティから何かを返す必要はなくなりました。

Eiji Kitamura - Developer Relations Team

Spectre の影響を受けないウェブを作るための概念実証について

2021年3月29日月曜日

この記事は情報セキュリティエンジニア、Stephen Röttger、Artur Janc による Google Online Security Blog の記事 "A Spectre proof-of-concept for a Spectre-proof web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。Spectre最新プロセッサの欠陥アプリケーションレベルの対策簡単な背景Spectre公表されましたブログ投稿ホワイトペーパー確実に対策することはできないプロセスベースの分離Site Isolation（サイト分離）out-of-process iframes = OOPIF（プロセス外 iframe）Cross-Origin Read Blocking = CORB（クロスオリジン読み取りブロック）Cross-Origin Resource PolicyCross-Origin Opener PolicyCross-Origin Embedder Policyウェブブラウザを利用した Spectre のデモ

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

performance.now() を 5 マイクロ秒の精度のタイマーとして使うことで、安定性と引き替えに 8 kB/ 秒でデータを漏洩する PoC

1 ミリ秒またはそれより粗い精度のタイマーを使うことで、60 B/ 秒でデータを漏洩する PoC

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

Spectre ガジェット : 攻撃者が制御する一時的実行を呼び出すコード

サイドチャネル : 一時的実行の副作用を管理する方法

1. ガジェットバリアント 1結論づけています
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

サイドチャネル攻撃への対策

2021年3月29日月曜日

この記事は（Chrome ウェブプラットフォームセキュリティチームを代表して）Mike West による Chromium Blog の記事 "Mitigating Side-Channel Attacks" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent }ウェブプラットフォームは、セキュリティの土台となる境界線としてオリジンに依存しています。また、ブラウザは、あるオリジンから別のオリジンへの明示的なデータの漏洩をうまく防いでいます。しかし、Spectre のような攻撃から、明示的でないデータ漏洩への対策が必要になることがわかります。このような攻撃では、サイドチャネルが悪用され、攻撃者のコードを実行するプロセスに入ったあらゆるデータが攻撃者に読み取られることが実証されています。現在、こういった攻撃の実現性はかなり高く、ユーザーにとってのリスクは現実のものとなっています。機密データが意図せずに攻撃者のプロセスに入り込まないようにしなくてはなりません。ブラウザは、この責任の大部分を背負っています。Chromium の Site Isolation（サイト分離）は、アクセスしたサイトを OS レベルで専用のプロセスに隔離します。Cross-Origin Read Blocking = CORB（クロスオリジン読み込みブロック）は、そのままでは保護されないクロスオリジンリソースの一部が攻撃者に読み込まれることを防ぎます。攻撃者の帯域幅を大幅に増やす API（SharedArrayBuffer など）は、クロスオリジン分離コンテキストにロックされます。しかし、この最後のメカニズムは、ブラウザが単独では行えない作業を指しています。ウェブデベロッパーはアプリケーションを熟知しており、各ページやリソースの漏洩によるリスクを情報に基づいて判断できます。ユーザーのデータが漏洩することを防ぐため、ウェブデベロッパーはホストしているリソースを評価し、適切にリソースを分離するようブラウザに指示するという対策をとる必要があります。概念レベルでは、この対策は次の要素で構成されます。

受信したヘッダーを調べ、一方で Origin ヘッダー、もう一方で Sec-Fetch- で始まる各ヘッダーに注目し、リクエストに応答するべきかどうかを判断します。

攻撃者がリソースをサブリソースとして読み込む機能を制限します。これをするには、Cross-Origin Resource Policy として same-origin を設定します（必要な場合のみ、same-site または cross-origin にします）。

攻撃者がリソースをドキュメントとしてフレームに含めることができるかを制限します。これをするには、X-Frame-Options: SAMEORIGIN を使ってフレーム化保護にオプトインするか、さらに細かい制御が可能な CSP の frame-ancestors ディレクティブを使います。たとえば、frame-ancestors 'self' https://trusted.embedder とします。

攻撃者がアプリケーションのウィンドウを参照する機能を制限します。これをするには、Cross-Origin Opener Policy を設定します。制限が強い same-origin 値をデフォルトとし、必要な場合のみ same-origin-allow-popups または unsafe-none にするのが最適です。

MIME-type confusion 攻撃を防ぎ、Cross-Origin Read Blocking（クロスオリジン読み込みブロック）などの消極的防御の確実性を高めます。これをするには、正しい Content-Type ヘッダーを設定し、X-Content-Type-Options: nosniff となっていることをグローバルで確認します。

以上のさまざまな防御策を合わせれば、サイト分離が利用できるかどうかにかかわらず、すべてのブラウザでユーザーのデータに対してある程度の保護をプロセスレベルで提供できます。これらの防御策の適用に関する詳しい情報は、Spectre 後のウェブ開発をご覧ください。以上で説明したセキュリティプリミティブがどのようにサイト上のリソースに適用されるかについて、詳しく説明する実例も含まれています。ここで示したのは、明示的でないデータ漏洩からオリジンを守るために、すぐにでも実施できる有用な手順です。今後は、ウェブの各種デフォルトを安全なものに移行し、デベロッパーが何もしなくてもこういった攻撃からユーザーを守れるようにしたいと考えています。Eiji Kitamura - Developer Relations Team

4 月 9 日開催 MLOps 機械学習の実運用基盤の構築に必要な課題について学ぼう

2021年3月26日金曜日

はじめてみよう Google Cloud ハンズオンセミナー機械学習編をオンラインにて開催いたします。

機械学習の実運用基盤の構築では「MLOps」と呼ばれる機械学習に固有のさまざまな課題が生じます。このハンズオンでは、AI Platform Pipelines の使い方を解説し、AI Platform における MLOps 環境の構築方法を紹介します。

このハンズオンでは Google Cloud のカスタマーエンジニアの解説を聞きながらハンズオンを進めるだけでなく、不明点をチャットツールを通じて質問することができます。

Google Cloud プロダクトに興味のある方、知識を増やしたい方はぜひご参加ください。

参加登録受付中：http://goo.gle/gcblog_homlops

————————————————————開催概要名　称　はじめてみよう Google Cloud ハンズオンセミナー機械学習編
日　程　2021 年 4 月 9 日（金）
対　象　Google Cloud Platform を利用したことがあり、機械学習や、
その環境の構築に興味のあるエンジニア
参加費　無料（事前登録制）
登　録　http://goo.gle/gcblog_homlops

————————————————————

Google Cloud Day: Digital 開催のお知らせ

2021年3月17日水曜日

Google Cloud Day: Digitalこちら————————————————————google-cloudday-tokyo-office@google.com————————————————————

フレーズ一致と絞り込み部分一致の変更

2021年3月16日火曜日

この記事は David Wihl による Google Ads Developer Blog の記事 "Changes to phrase match and broad match modifier" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 2 月 4 日に、フレーズ一致と絞り込み部分一致の変更予定についてお知らせしました。キーワードポートフォリオを簡素化し、広告主が関連性の高いユーザー検索に到達できるように、絞り込み部分一致（BMM）の動作にフレーズ一致を組み込み、BMM のサポートを段階的に廃止します。この変更は徐々にロールアウトされ、キーワードのマッチタイプのバックエンド処理が変更されます（AdWords API、Google Ads API、Google 広告スクリプト）。これによってキーワードがシンプルになり、関連顧客層に到達しやすくなります。

アップデート後のフレーズ一致は、両方のマッチタイプの優れた部分、すなわちフレーズ一致の制御と絞り込み部分一致の到達範囲の広さを組み合わせたものになります。フレーズと BMM のキーワードはどちらも動作し続け、2021 年 2 月 18 日より、最初の言語群（英語、ドイツ語、スペイン語、フランス語、イタリア語、オランダ語、ポルトガル語、ロシア語）のキーワードでフレーズまたは BMM 表記を使った場合に、アップデート後のフレーズ一致動作が適用されるようになります。第 2 四半期には他のすべての Google 広告の言語で同じ処理が始まり、2021 年 7 月には完了する見込みです。

2021 年 7 月にアップデート後のフレーズ一致動作がすべての言語に適用されると、広告主は新しい BMM キーワードを作成できなくなります（ただし、古い BMM キーワードは動作し続けます）。

除外キーワードのマッチタイプは、フレーズ一致と BMM の変更による影響を受けません。

この変更によって、AdWords API、Google Ads API、Google 広告スクリプトにはどのような影響を受けますか？

2021 年 7 月以降は、新しい BMM キーワード（matchType が BROAD とトークンが + で始まるキーワードテキスト）を作成できなくなります。このマイルストーンが近づきましたら、改めてお知らせする予定です。

広告主はどのような影響を想定すべきですか？

影響は、それぞれの広告主のフレーズや BMM の利用状況、クエリのカバレッジの包括性の程度によって異なります。

主にフレーズ一致を使っている広告主は、クリックやコンバージョンが徐々に増えることが想定されます。
- これらのキーワードについてのクエリが追加され、それに対するマッチングが有効になるためです。たとえば、フレーズキーワードが「ザンビアの観光」である場合、それまでは BMM のみで有効だった「ザンビアの観光スポット」が一致するようになります。
主に BMM を使っている広告主は、クリックやコンバージョンがわずかに減ることが想定されます。

減少の大半は、BMM でキーワードの一部にのみ部分一致が適用される場合です。例 : テニス + シューズ
また、キーワードの意味にとって語順が重要になる場合は、語順も考慮されるようになります。そのため、これまで BMM に一致していたものが除外される場合もあります。

対応が必要な事項は何ですか？

広告主のトラフィックが変動する可能性があります。これまで、あるマッチタイプでキーワードに一致していたユーザークエリが、フレーズまたは古い BMM のキーワードに一致する可能性があります。そのため、さまざまなキーワードでボリュームが変動します。広告主にとっては、アカウントを管理し、追加のボリュームに対応する必要がある場合は予算を調整することが重要になります。その他のベストプラクティスは、お知らせに記載されています。

ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。

Google Ads API チーム、David Wihl
Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

ポートフォリオ拡張クリック単価入札戦略の提供終了について

2021年3月9日火曜日

この記事は Adam Ohren による Google Ads Developer Blog の記事 "Sunsetting Portofolio Enhanced CPC Bid Strategies" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 3 月 22 日より、ポートフォリオ（共有）拡張クリック単価（ECPC）入札戦略の提供を終了します。AdWords API と Google Ads API のすべてのバージョンで、以下の動作がブロックされます。

新しいポートフォリオ ECPC 戦略の作成
ポートフォリオ ECPC 戦略のキャンペーンへのアタッチ

なお、標準（ポートフォリオでない）ECPC 戦略は影響を受けません。

	影響を受けるポートフォリオ拡張クリック単価戦略
Google Ads API	`Bidding_strategy.type` = `BiddingStrategyType.ENHANCED_CPC`
AdWords API	`SharedBiddingStrategy.type` = `MANUAL_CPC`, `SharedBiddingStrategy.biddingScheme.enhancedCpcEnabled` = `TRUE`

変更点の説明
新しいポートフォリオ ECPC 戦略の作成、ポートフォリオ ECPC 戦略のキャンペーンへのアタッチに関するすべての操作で、次のいずれかのエラーが発生します。

	作成時のエラー	アタッチ時のエラー
Google Ads API	`BIDDING_STRATEGY_NOT_SUPPORTED`	`CANNOT_ATTACH_BIDDING_STRATEGY_TO_CAMPAIGN`
AdWords API	`BIDDING_STRATEGY_NOT_SUPPORTED`	`CANNOT_ATTACH_BIDDING_STRATEGY_TO_CAMPAIGN`

移行の説明
標準 ECPC を優先するため、将来的にポートフォリオ ECPC 戦略は完全に削除する予定です。この変更に備えて、あらかじめすべてのポートフォリオ ECPC 戦略を標準 ECPC 戦略に移行しておくことができます。以下の手順をご覧ください。

残されたポートフォリオ ECPC キャンペーンと戦略は、後ほどすべて自動的に移行されます。移行の前には、このブログで最新情報を投稿します。

Google Ads API を使って自分で移行する場合
CampaignService.MutateCampaigns() を使い、manual_cpc.enhanced_cpc_enabled フィールドを true に設定してキャンペーンを更新します。リクエストには、忘れずに update_mask を設定してマッチングをしてください。

operations: [
  {
    update: {
      resource_mame: customers/CUSTOMER_ID/campaigns/CAMPAIGN_ID,
      manual_cpc: {
        enhanced_cpc_enabled: true
      }
    },
    update_mask: manual_cpc.enhanced_cpc_enabled
  }
]

AdWords API を使って自分で移行する場合
CampaignService.mutate() を使い、biddingStrategyType を MANUAL_CPC、biddingScheme.enhancedCpc フィールドを true に設定してキャンペーンを更新します。

<operations>
  <operator>SET</operator>
  <operand>
    <id>CAMPAIGN_ID</id>
    <biddingStrategyConfiguration>
      <biddingStrategyType>MANUAL_CPC</biddingStrategyType>
      <biddingScheme>
        <enhancedCpcEnabled>true</enhancedCpcEnabled>
      </biddingScheme>
    </biddingStrategyConfiguration>
  </operand>
</operations>

ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。

Adam Ohren（Google Ads API チーム）
Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

Android に新しい Password Checkup 機能が登場

2021年3月9日火曜日

この記事は Android チーム、ソフトウェアエンジニア、Arvind Kumar Sugumar による Google Online Security Blog の記事 "New Password Checkup Feature Coming to Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent }デジタルサービスが生活に身近になるにつれて、オンライン情報の安全を保つことの重要性も今までになく増しています。通常、パスワードはハッカーに対する防衛の第一線ですが、パスワードの漏洩につながりかねない情報流出の多さを考えれば、ユーザーは認証情報の保護に注意しなければならないことは明らかです。これを簡単に行えるようにするため、2019 年に Password Checkup 機能を Chrome に導入し、Chrome に保存しているパスワードが漏洩した場合、通知が届くようになりました。今回、Google 自動入力を通してこの機能を Android アプリにも提供します。アプリで認証情報を自動入力したり保存したりすると、Chrome は侵害されたことがわかっている認証情報のリストと突き合わせて、そのパスワードが侵害されていた場合は、警告を表示します。そのプロンプトから Password Manager ページを開くこともできるので、そこで保存されているパスワードをすべてまとめて見直すこともできます。Android アプリでの Password Checkup は、Android 9 以降で Google 自動入力を使っているユーザーが利用できます。

Android デバイスで Autofill with Google を有効にする方法は次のとおりです

スマートフォンの [ 設定 ] アプリを開く

[ システム ] > [ 言語と入力 ] > [ 詳細設定 ] をタップする

[ 自動入力サービス ] をタップする

[ Google 自動入力サービス ] をタップして設定を有効化する

項目が見つからない場合は、こちらのページをご覧ください。デバイスメーカーから詳しい情報を得る方法が記載されています。 動作の仕組み Google はユーザーのプライバシーを最優先に考えていますが、パスワードなどの機密データを扱う機能では特にそれを重視しています。Google 自動入力は Android の自動入力フレームワークがベースになっています。このフレームワークは、厳格かつ不変なプライバシーとセキュリティを遵守し、次の 2 つの場合にのみユーザーの認証情報にアクセスすることを保証します。1）ユーザーが Google アカウントに認証情報をすでに保存している場合。2）Android OS がユーザーに新しい認証情報を保存することを提案し、ユーザーがアカウントに認証情報を保存した場合。ユーザーが認証情報を操作したとき（フォームに認証情報を入力する、または初めて保存するとき）、Chrome で使われているものと同じプライバシー保護 API を使い、Google が追跡している既知の侵害されたパスワードのリストにその認証情報が含まれていないかを確認します。この実装では、以下の点が保証されています。

デバイスの外部に送信されるのは、暗号化された認証情報のハッシュのみ（データベースのパーティション化のため、ハッシュ化したユーザー名の最初の 3.25 バイトは暗号化せずに送信される）。

サーバーは、同じプレフィックスを持つ、侵害されたことがわかっている認証情報のリストを暗号化したハッシュとして返す。

認証情報が実際に侵害されたものであるかどうかを判断する処理がユーザーのデバイス上で実行される。

サーバー（Google）は、暗号化されていないユーザーのパスワードのハッシュにはアクセスしない。クライアント（ユーザー）は、侵害された可能性がある認証情報の暗号化されていないハッシュのリストにはアクセスしない。

この API の内部処理の詳細については、Chrome チームによるこちらのブログをご覧ください。 その他のセキュリティ機能 Google 自動入力は、Password Checkup の他にも、データの保護に役立つ機能を提供します。

パスワード生成 : あまりに多くの認証情報を管理しなければならない場合、ユーザーは同じパスワードを複数のアカウントに流用しがちです。パスワード生成機能を使えば、Chrome が一意で安全なパスワードを生成し、Google アカウントへの保存まで行ってくれます。そのため、パスワードを覚える必要すらなくなります。Android アプリでは、パスワードフィールドを長押ししてポップアップメニューから [ 自動入力 ] を選ぶことで、パスワード生成をリクエストできます。

生体認証 : 認証情報や支払い情報を自動入力する際に生体認証を要求すると、デバイスの保護をさらに強化できます。生体認証は Google 自動入力設定から有効化できます。

いつものように、プロダクト全般のセキュリティ向上に関する最新情報をお届けする Google Security ブログにご注目ください。 Eiji Kitamura - Developer Relations Team

Google Ads API の InvoiceService が正式版に

2021年3月8日月曜日

この記事は Pierrick Voulet による Google Ads Developer Blog の記事 "The Invoice Service of Google Ads API is out of beta" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Google Ads API の v6 より、すべての API ユーザーで InvoiceService が利用可能になります。これより前の API バージョンでは、引き続き、許可されたアカウントのみを対象にこのサービスをサポートします。

このサービスを利用すると、Google 広告アカウントの月ごとの請求書を取得できます。返される各 Invoice には、データ（調整、管理コスト、税金、アカウント予算など）が含まれており、PDF ファイルとしてダウンロードできます。Google 広告管理者アカウントは、このデータを利用して顧客の請求書を自動処理できます。使ってみたい方は、専用のガイドをご覧ください。

ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。

Google Ads API チーム、Pierrick Voulet
Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

Chrome 91 より SharedArrayBuffer の利用に制限が付きます

2021年3月8日月曜日

この記事はテクニカルプログラムマネージャー、Lutz Vahl による Chromium Blog の記事 "Heads Up: Restriction on SharedArrayBuffers are coming in M91" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent }Chrome 91（2021 年 5 月）より、すべてのプラットフォームで、SharedArrayBuffer や performance.measureUserAgentSpecificMemory() などの API にアクセスする際にクロスオリジン分離が必須になります。Android では Chrome 88 からこの制限が適用されていますが、この対応により、デスクトップにも同じ制限が適用されます。今後もこれらの API を使用する場合は、ページで以下のヘッダーを送信し、確実にページがクロスオリジン分離されるようにしてください。

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

なお、これをすると、Cross-Origin-Resource-Policy ヘッダーか CORS ヘッダー（Access-Control-Allow-* など）で明示的にリソースを許可しない限り、そのページでクロスオリジンのコンテンツを読み込めなくなりますので、ご注意ください。対応手順の詳細やその他の考慮事項については、web.dev のクロスオリジン分離有効化ガイドをご覧ください。Eiji Kitamura - Developer Relations Team

Google Ads API v6.1 のお知らせ

2021年3月5日金曜日

この記事は Josh Radcliff による Google Ads Developer Blog の記事 "Announcing v6.1 of the Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
今日は、Google Ads API の v6.1 リリースをお知らせします。v6.1 の一部の機能を使うには、クライアントライブラリとクライアントのコードをアップグレードする必要があります。更新版のクライアントライブラリとコードサンプルは、来週公開されます。このバージョンには、互換性のない変更はありません。

主な機能は以下のとおりです。

レスポンシブ検索広告の追加に関する最適化案の取得と管理
ユーザーの招待状の管理
change_event リソースへのクエリが返すリソースタイプのリストに、Feed、FeedItem、CampaignFeed、AdGroupFeed、AdGroupAd の各リソースを追加
新しいコンバージョンメトリクス（コンバージョン日付ごと）
新しい call_view リソース（電話番号表示オプションと電話専用広告に関するレポート用）

さらに詳しく知りたい方へ
以下のリソースが役立ちます。

ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。
Josh Radcliff（Google Ads API チームを代表して）
Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

Firebase を使いテストからリリースと最適化までを円滑に行う

2021年3月5日金曜日

タップルAndroid Developers サイトFirebase の Web サイトFirebase Remote ConfigFirebase A/B TestingFirebase Crashlyticsぜひこちら

Chrome 89: 高度なハードウェアインタラクション、PC でのウェブ共有など

2021年3月2日火曜日

この記事は Chromium Blog の記事 "Chrome 89 Beta: Advanced Hardware Interactions, Web Sharing on Desktop, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent }特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネルリリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。（2021 年 1 月 28 日に Chrome 89 がベータ版としてリリースされた時点の情報です）
WebHID APIヒューマンインターフェースデバイス（HID）には、新しすぎる、古すぎる、あまりにも一般的でないなどの理由で、システムのデバイスドライバからアクセスできないロングテールなものがあります。WebHID API は、デバイス固有のロジックを JavaScript で実装する方法を提供することで、この問題を解決します。ヒューマンインターフェースデバイスは、人間からの入力を受け取ったり、人間に対して出力を提供したりします。デバイスには、キーボード、ポインティングデバイス（マウス、タッチスクリーンなど）、ゲームパッドなどがあります。たとえば、ゲームパッドのサポートにおいては、一般的でない HID デバイスにアクセスできないのは特に苦痛です。ゲームパッドの入出力はうまく標準化されておらず、多くの場合、ウェブブラウザに特定のデバイス向けのカスタムロジックが必要となります。これはサステナブルでなく、古いデバイスや一般的でないデバイスといったロングテールがサポートされないことになります。WebHID のオリジントライアルは終了し、PC 向けの Chrome 89 でデフォルトで有効になります。使用方法については、一般的でない HID デバイスに接続するで確認できます。ウェブのヒューマンインターフェースデバイス : いくつかの簡単な例のデモもご覧ください。Web NFCNFC とは少量のデータを転送する近距離無線通信のことで、通常は専用の NFC デバイスとリーダー間の通信に使用します。建物に入るためにバッジをスキャンしたことがある方なら、NFC を使っているかもしれません。 Web NFC を利用すると、ウェブアプリから NFC タグの読み書きができます。これにより、博物館で展示情報を提供する、在庫を管理する、カンファレンスのバッジに情報を登録するなど、ウェブでさまざまな新しいユースケースを実現できるようになります。Web NFC は、Android 版の Chrome 89 でデフォルトで有効になります。

Chrome Dev Summit での Web NFC カードのデモNFC の読み書きは簡単なオペレーションで行うことができます。ペイロードの構築や解釈にいくつかの命令が必要になりますが、複雑ではありません。うれしいことに、ウェブで NFC デバイスと連携するという記事もありますので、ぜひご覧ください。実際に試してみることができるいくつかのサンプルもあります。次のようなイメージです。NFC タグに文字列を書き込む :

if ("NDEFReader" in window) {
  const ndef = new NDEFReader();
  await ndef.write("Hello world!");
}

NFC タグのメッセージをスキャンする :

if ("NDEFReader" in window) {
  const ndef = new NDEFReader();
  await ndef.scan();
  ndef.onreading = ({ message }) => {
    console.log(`Records read from a NFC tag: ${message.records.length}`);
  };
}

Web Serial APIシリアルポートは、データをバイト単位で送受信できる双方向通信インターフェースです。Web Serial API は、この機能をウェブサイトで実現し、マイクロコントローラや 3D プリンタなどのデバイスを制御できるようにします。教育、趣味、工業の分野では、すでにウェブページから周辺機器を制御しています。その場合、デバイスの制御にはアダプターやドライバのインストールが必要です。Web Serial API は、ウェブサイトと周辺機器の直接通信を可能にすることで、ユーザーエクスペリエンスを改善します。 Web Serial API のオリジントライアルが終了し、PC で有効になります。GitHub でデモが公開されています。使用方法については、シリアルポートの読み書きを行うをご覧ください。 PC でのウェブ共有デベロッパーは、ユーザーがソーシャルネットワークで簡単にコンテンツを共有できるようにするため、各ソーシャルサービス用の共有ボタンを手動でサイトに組み込んでいます。このため、ユーザーが実際に使っているサービスで共有できないことが多く、ページサイズの肥大化やサードパーティ製コードによるセキュリティリスクも発生しています。受信側では、共有ターゲットとして登録して他のアプリからの共有を受け取ることができるのは、プラットフォームのアプリのみです。 Android 版の Chrome では、Chrome 61 から 75 の間でこれらの機能の追加を始めました。Chrome 89 では、ウェブ共有が Windows と ChromeOS でも利用できるようになります。ただし、共有ターゲットとしての登録は ChromeOS のみでサポートされます。これらのプラットフォームでは、PC のサイトで navigator.share() を使うと、共有ダイアログボックスを開くことができます。また、ウェブアプリマニフェストのエントリを追加すると、PWA を共有ターゲットにすることができます。ウェブ共有についての情報は、Web Share API で OS の共有 UI を組み込むをご覧ください。PWA を共有ターゲットにすることについての詳しい情報は、Web Share Target API で共有データを受け取るをご覧ください。オリジントライアルこのバージョンの Chrome には、新しいオリジントライアルはありません。現在のオリジントライアルに登録するには、オリジントライアルダッシュボードをご覧ください。オリジントライアル自体の詳細については、ウェブデベロッパーのためのオリジントライアルガイドをご覧ください。今回のリリースに追加されたその他の機能AVIF 画像のデコードChrome が AVIF コンテンツのデコードをネイティブにサポートします。Android と WebView は既存の AV1 デコーダを利用します（PC 版でのサポートは、Chrome 85 で追加されました）。AVIF は次世代の画像フォーマットで、Alliance for Open Media が標準化しています。AVIF のサポートには、主に 3 つの目的があります。

ページ読み込みを高速化して全般的なデータ消費量を削減するため、使用する帯域幅を減らします。AVIF を使うと、JPEG や WebP に比べて画像のファイルサイズを大幅に削減できます。

HDR カラーをサポートします。AVIF は、ウェブでの HDR 画像のサポートに向けた一歩です。JPEG の色深度は、実質的に 8 ビットに限られています。輝度、色ビット深度、色域の面でディスプレイの機能が強化されていることから、JPEG では失われる画像データを保存したいと考えるウェブ関係者が増えています。

エコシステムの関心に対応します。ウェブにおいて大きな存在感を持つ企業が、ウェブに AVIF 画像を掲載することに興味を示しています。

Cross-Origin Opener Policy Reporting API新しい Reporting API は、Cross-Origin Opener Policy (COOP) のデプロイに役立ちます。この API は、COOP が強制される際の違反の報告に加え、COOP の報告のみのモードも提供します。COOP の報告のみのモードは COOP を強制しませんが、COOP を強制していれば発生していた潜在的な違反を報告します。デベロッパーは、Chrome DevTools で Reporting API が有効になっているかを確認できます。ウェブアプリマニフェストでの display のオーバーライドウェブアプリマニフェストに display_override フィールドが新しく追加されます。これにより、デベロッパーが display フィールドのフォールバックチェーンを明示的に指定できるようになります。次の例では、"minimal-ui" を "standalone" にフォールバックする指定をしています。

{
  "display": "standalone",
  "display_override": ["minimal-ui"],
}

この API は、高度なユースケースと表示モードを想定したもので、機能は限られています。詳しくは、Chrome Status のエントリをご覧ください。ReadableStreamDefaultController インターフェースの公開Chrome は、他の ReadableStream 関連のクラスと同じように、グローバルオブジェクトで ReadableStreamDefaultController インターフェースを公開します。これにより、インスタンスをストリームのコンストラクタの内部で作成しなければならないという、これまでの制限がなくなります。performance.measureUserAgentSpecificMemory() この機能により、ウェブページのメモリ使用量を見積もる performance.measureUserAgentSpecificMemory() 関数が追加されます。このメソッドは COOP/COEP の制限を受けるので、これを使うにはウェブサイトがクロスオリジン分離されている必要があります。潜在的に信頼できる data: URL現在のウェブ標準に準拠するため、Chrome はすべての data: URL を潜在的に信頼できるものとして扱います。
これは、認証や機密性に関して最低限の基準しか満たされていない場合でも、ある機能を有効化するためには、URL が安全かどうかを評価しなければならないことがあるためです。ウェブ標準は、それを実現するために「潜在的に信頼できる URL」の定義を使いますが、最新版の Secure Contexts 仕様では、そこに "data" スキームの URL が含まれています。これまでの Blink は、いくつかの data: URL のみを潜在的に信頼できるものとして扱っていました。 Streams API: バイトストリームストリーム API では、データストリームの作成、構成、使用のためのユビキタスで相互運用可能なプリミティブが提供されます。Chrome は、バイトを表すストリームで拡張バージョンの読み取り可能ストリームをサポートし、バイトを効率的に扱います。具体的には、コピーの回数を最低限にとどめます。
バイトストリームは、Bring Your Own Buffer（BYOB）のリーダーを取得できます。デフォルトの実装では、ウェブソケットの場合は文字列や配列バッファなどのさまざまな種類の出力を指定できますが、バイトストリームではバイト出力が保証されます。さらに、BYOB リーダーを扱えることで、安定性のメリットももたらされます。バッファがデタッチされれば、同じバッファに 2 回書き込まれないことが保証され、競合状態を回避できるためです。BYOB リーダーではバッファが再利用されるため、読み取りのたびにガベージコレクションを行う必要もありません。SVG 要素での完全な 'filter' プロパティ構文のサポートChrome の SVG 要素で 'filter' プロパティの完全な構文が利用できるようになります。これまでは、1 つの url() 参照しかサポートされませんでした。これにより、blur()、sepia()、grayscale() などのフィルタ関数を SVG 要素と非 SVG 要素の両方に適用できるようになります。また、'filter' のプラットフォームサポートの均一性が増し、一部の「定型」エフェクトを適用しやすくなります。この機能がないときは、grayscale() や blur() といった基本的なフィルタを使う場合でも、SVG の完全な <filter> 要素定義を使う必要がありました。WebAuthentication API: ResidentKeyRequirement と credProps エクステンションChrome で Web Authentication API に関連する 2 つの新機能がサポートされます。AuthenticatorSelectionCriteria.residentKey プロパティは、ウェブ認証のクレデンシャル登録において、クライアント側で検出可能なクレデンシャルを作成するかどうかを指定します。 Web Authentication の credProps エクステンションは、作成したクレデンシャルがクライアント側で検出可能（discoverable）かどうかをリライングパーティに示します。「クライアント側で検出可能なクレデンシャル」とは、WebAuthn API リクエストでリライングパーティがクレデンシャル ID を提供することなくチャレンジを行えるタイプの WebAuthn クレデンシャルです。ブラウザは、指定された認証器（外部セキュリティキーか組み込みのもの）からのすべての検出可能なクレデンシャル（discoverable credentials）のリストを表示し、ユーザーがログインに使うものを選択できるようにします。CSS::target-text 疑似要素scroll-to-text フラグメントにデフォルトのユーザーエージェントのハイライトとは違うスタイルを設定できるようにするため、ハイライト疑似要素を追加します。フロー関連の角丸プロパティフロー関連の角丸プロパティで、物理プロパティではなく論理マッピングを使って角を制御できるようになります。これにより、ページの向きや表記の方向によって異なる角丸の半径を設定することも可能になります。また、Chrome が CSS Logical Properties and Values 仕様に準拠することになります。以下の論理プロパティが追加されました。

border-start-start-radius

border-start-end-radius

border-end-start-radius

border-end-end-radius

強制カラープロパティforced-colors メディア機能は、ページでユーザーが選択した限定カラーパレットをユーザーエージェントが強制しているかどうかを検出します。強制カラー調整プロパティforced-color-adjust プロパティを使うと、強制カラーモードから特定の要素を除外し、CSS で完全にカラーを制御する状態に戻すことができます。JavaScriptこのバージョンの Chrome には、V8 JavaScript エンジンのバージョン 8.9 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。トップレベルの awaitChrome では、JavaScript モジュールのトップレベルで await キーワードが許可されるようになりました。これにより、モジュールの読み込み処理に非同期呼び出しをシームレスに統合できるようになります。現在のところ、この機能はモジュールを async 関数でラップすることで実現していますが、これにより複雑さを依存モジュール側にとどめつつ、実装の詳細を公開しています。デベロッパーノートEXIF の画像の向きクロスオリジン画像の向きの判定に常に EXIF 情報が利用されるようになります。つまり、CSS で image-orientation: none を設定しても、安全でないオリジンの画像には反映されなくなります。この仕様変更に関する議論は、CSS ワーキンググループドラフトに記載されています。サポートの終了と機能の削除このバージョンの Chrome では、以下のサポートの終了および機能の削除が行われます。現在サポートが終了している機能および以前に削除された機能のリストは、ChromeStatus.com をご覧ください。<link rel=prerender> のプレフィックス付きイベントの削除<link rel=prerender> から発行されるレガシーなプレフィックス付きイベント（webkitprerenderstart、webkitprerenderstop、webkitprerenderload、webkitprerenderdomcontentloaded）が Chrome から削除されます。noopener で開いたウィンドウでの sessionStorage の複製停止ウィンドウを noopener で開いた場合、Chrome はオープン元の sessionStorage を複製しなくなります。代わりに、空の sessionStorage 名前空間が開始されます。これにより、Chrome が HTML 仕様に準拠します。Eiji Kitamura - Developer Relations Team

Google Cloud Day: Digital ’21 セッション情報公開のお知らせ

4月7日より、DSC Japan が本格始動します

既存機能の非推奨化によるストレスを軽減: Google Maps Platform における SDK の依存関係について

Chrome 89 での高度なメモリ管理とさらなるパフォーマンスの改善

Pixel で検証可能なセキュリティ水準の継続的な向上について

Chrome のリリースサイクルの高速化について

Chrome 90 ベータ版: WebRTC 用 AV1 エンコーダ、新しいオリジントライアルなど

Spectre の影響を受けないウェブを作るための概念実証について

サイドチャネル攻撃への対策

4 月 9 日開催 MLOps 機械学習の実運用基盤の構築に必要な課題について学ぼう

Google Cloud Day: Digital 開催のお知らせ

フレーズ一致と絞り込み部分一致の変更

ポートフォリオ拡張クリック単価入札戦略の提供終了について

Android に新しい Password Checkup 機能が登場

Google Ads API の InvoiceService が正式版に

Chrome 91 より SharedArrayBuffer の利用に制限が付きます

Google Ads API v6.1 のお知らせ

Firebase を使いテストからリリースと最適化までを円滑に行う

Chrome 89: 高度なハードウェアインタラクション、PC でのウェブ共有など

ラベル

ブログアーカイブ

Feed

ラベル

ブログ アーカイブ

Feed

ブログアーカイブ