デジタル カンファレンス 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
————————————————————
Developer Student Clubs(DSC)プログラムは、Google Developer Technologies に関心のある大学生向けのコミュニティ グループであり、学生の開発・リーダーシップ能力の向上を支援するプログラムです。
米国を始め、ヨーロッパ、オーストラリア、東南アジア、アフリカ、インド、中東・北アフリカ、ラテンアメリカ地域などなど、合わせて 106 カ国以上、1265 拠点から世界中の学生たちが活動している DSC プログラム。今年、日本にも展開します。
非推奨の機能をサポートする最後のバージョンが廃止されると、その機能をサポートするバージョンはなくなり、機能の継続的な使用は保証されませんので、ご注意ください。
API や SDK における非推奨の微妙な違いについては、非推奨に関するドキュメントをご覧ください。現在非推奨となっているすべての機能を記載しています。
なお、Maps JavaScript API はモバイル向けの SDK とは異なります。バージョンは四半期ごとのスケジュールでリリースされたり廃止されたりするため、常に最新バージョンをデフォルト(v=weekly)で読み込むことをおすすめします。Maps JavaScript API の定期的な更新に備える方法について、詳しくはこちらをご覧ください。
Chrome for Android に特化して、あらゆる種類の Android デバイスにとって快適なブラウザを作るという、他にはない挑戦をしています。今回のリリースでは、パッケージングとランタイムの最適化を適用し、ポケットの中の Chrome のパフォーマンスを向上させています。
モバイル デバイスのセキュリティ評価は難しく、信頼できる方法で企業のクレイムを検証するには、独立した業界の認証(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)
エンドユーザー プライバシーとデバイスの機能 - アプリケーション分離やサンドボックス化、フレームワーク アクセス許可により、ユーザー アクティビティごとの分離やプライバシーを提供
この認証(Certification)が重要なのは、認定を受けたラボが実際にデバイスを評価し、さまざまなテストをして以下を確認しているためです。
概念的には、評価対象(TOE)はデバイスのハードウェア(システム オン チップ)とオペレーティング システム(Android)の組み合わせです。上記の脅威に対する対策を検証するため、ラボは以下のセキュリティ機能を確認します。
これが企業にとって重要な理由
Pixel のセキュリティが企業のニーズを確実にサポートできることは、非常に重要です。規制が厳しい業界の多くでは、機密データが考えられる限り最も強固な保護を受けられるように、Common Criteria 認証(Certified)デバイスの利用が義務付けられています。Android Enterprise 管理フレームワークでは、企業がデバイスの管理などをし、エンドユーザーが実行できる操作を制限したり、デバイスを監査してすべてのソフトウェアが適切に設定されていることを保証したりできます。たとえば、企業の IT 管理者は、カメラ、位置情報サービス、アプリのインストール プロセスなどの機能に対するポリシーを強制できます。
これがコンシューマにとって重要な理由
セキュリティは企業だけが心配することではありません。Common Criteria 認証(Certification)で検証している多くの保護は、コンシューマにも適用されます。たとえば、Wi-Fi に接続するとき、ウェブのブラウズを誰にも盗聴されないことを確認したいと思うでしょう。デバイスの紛失や盗難の際は、ロック画面によって他人が個人情報にアクセスする可能性が減ると確信したいはずです。
Google は、すべてのユーザーにセキュリティとプライバシーをお届けしたいと考えています。Pixel デバイスがこの認証(Certification)基準以上を確実に満たせるようにしたいと考えているのはそのためです。今後もこの基準を満たすために注力しますので、どうぞご安心ください。Pixel スマートフォンでは、スイッチを入れた瞬間から充実したセキュリティを利用できます。
これが Android エコシステムにとって重要な理由
認証(Certification)はサードパーティによる検証として有用な形態ですが、以下の、Google が 3 C と呼ぶものに該当することがよくあります。
ここ 3 年間は、OEM パートナーを対象に、この複雑さを軽減するための作業をしてきました。その結果、必要なセキュリティ要件を満たすために要求される機能が Android オープンソース プロジェクトに直接組み込まれることをお知らせします。さらに、すべての管理要件と監査要件を Android Enterprise Management フレームワークに追加しました。昨年は、このために開発したツールを GitHub に公開しました。他の Android OEM が認証(Certification)を受ける際に、この作業のメリットを活用できるようにするためです。
新しい Android OS バージョンでの Pixel スマートフォンの認証(Certification)は継続しますが、Google はその他の Android OEM も、この認証(Certification)や、以下のその他の認証(Certification)を取得できるように取り組んでいます。
今後も、企業とコンシューマの両方を対象にしたセキュリティ対策に注力してまいります。業界の皆さんがこの作業に加わってくれることを歓迎いたします。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 3 月 11 日時点で、Chrome 90 はベータ版です。
デスクトップ版の Chrome に AV1 エンコーダが搭載されます。このエンコーダは、組み込みの WebRTC を利用したテレビ会議に特に最適化されています。AV1 には、以下のようなメリットがあります。
WebRTC は最近正式に W3C と IETF の標準になったので、この追加は特に重要です。
このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルをしています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。
mediaDevices.getCurrentBrowsingContextMedia() メソッドを使うと、getDisplayMedia() と同様に、現在のタブの動画(可能な場合は音声も)から MediaStream をキャプチャできます。getDisplayMedia() とは異なり、この新しいメソッドを呼び出すと、許可するか拒否するかを選択する単純なダイアログ ボックスが表示されます。ユーザーが許可した場合は、現在のタブがキャプチャされます。getCurrentBrowsingContextMedia() のその他の動作は、すべて getDisplayMedia() と同じです。このオリジン トライアルは、Chrome 92 まで行われる予定です。
カメラやマイク、画面キャプチャ、コーデックのデコーダ部分などの出力や、コーデックのデコーダ部分への入力など、MediaStreamTrack のローメディアを操作する API です。WebCodecs インターフェースを使ってローメディアのフレームを表現し、ストリームを使って公開します。この仕組みは、WebRTC Insertable Streams API が RTCPeerConnection からエンコード済みデータを公開する方法と同様です。次のようなユースケースをサポートすることを想定しています。
このオリジン トライアルは、Chrome 92 まで行われる予定です。
WebAssembly が例外ハンドリングをサポートするようになりました。例外ハンドリングを利用すると、コードで例外がスローされたときに制御フローを抜けることができます。例外は、WebAssembly モジュールの既知の例外でも、インポートされて呼び出された関数がスローした未知の例外でも構いません。このオリジン トライアルは、Chrome 94 まで行われる予定です。
Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
ライティング推定を利用すると、サイトから WebXR セッション内の環境光条件の推定値を照会できます。これにより、環境光を表す球面調和関数と、「反射」を表すキューブマップ テクスチャの両方を取得できます。ライティング推定を追加すると、モデルが自然になってユーザーの環境への「適合度」が上がる可能性があります。
aspect-ratio プロパティを使うと、ある要素の横か縦のサイズだけが指定された場合に、もう片方のサイズを自動計算できます。もともとこのプロパティは、アニメーション時に補完されない(つまり、ターゲット値にスナップする)ものとして導入されました。この機能により、あるアスペクト比から別のアスペクト比に変化するときに、スムーズな補完が行われるようになります。
aspect-ratio
カスタム要素が、状態を表す CSS 疑似クラスを介してカスタム要素の状態を公開するようになります。ビルトイン要素には状態が存在します。これは、ユーザーのインタラクションなどによって時間とともに変化する場合があり、疑似クラスを通してウェブ制作者に公開されます。たとえば、フォームのコントロールの中には、"invalid" 状態を持つものがあり、これが :invalid 疑似クラスで公開されています。カスタム要素も状態を持つので、ビルトイン要素と同じように状態を公開できるのは妥当です。
以下のフォーム コントロールの CSS プロパティ appearance と -webkit-appearance のデフォルト値が、'auto' に変更されます。
appearance
-webkit-appearance
'auto'
<input type=color>
<select>
<input type=date>
<input type=datetime-local>
<input type=month>
<input type=time>
<input type=week>
これらのコントロールのデフォルトのレンダリングは変更されません。
overflow に clip 値を指定すると、ボックスのコンテンツがボックスのオーバーフロー クリップエッジでクリップされます。さらに、スクロール インターフェースは提供されず、ユーザーやプログラムはコンテンツをスクロールできなくなります。また、ボックスはスクロール コンテナとは見なされず、新しいフォーマッティング コンテキストは開始されません。そのため、この値を使うと、overflow: hidden を使う場合よりもパフォーマンスが向上します。
overflow
clip
overflow: hidden
overflow-clip-margin プロパティを使うと、要素が境界のどのくらい外側まで描画できるかを指定できます(その範囲を超えるとクリップされます)。デベロッパーは、このプロパティを使ってクリップ境界を拡張することもできます。これは、インク オーバーフローを表示したい場合に特に便利です。
overflow-clip-margin
Permissions-Policy HTTP ヘッダーは、アクセス許可や機能の委譲を制御する既存の Feature-Policy ヘッダーを置き換えます。このヘッダーを使うと、どのオリジンに機能へのアクセスを許可するかをサイトで厳密に制限できます。
Permissions-Policy
Feature-Policy
Chrome 74 で導入された Feature Policy API は、最近 "Permissions Policy" という名前に変わり、それに伴って HTTP ヘッダーの名前も変更されました。同時に、コミュニティは HTTP の構造化フィールド値に基づいた新しい構文を決定しています。
Cross-Origin-Read-Blocking が利用する盗聴されない MIME タイプのリストに application/x-protobuffer を追加し、これを投機的実行攻撃から守ります。application/x-protobuf は、すでに盗聴されない MIME タイプとして保護されています。application/x-protobuffer もよく使われている MIME タイプで、protobuf ライブラリによって "ALT_CONTENT_TYPE" として定義されています。
Cross-Origin-Read-Blocking
application/x-protobuffer
application/x-protobuf
"ALT_CONTENT_TYPE"
FileSystemWritableFileStream.write() にファイルの末尾を超えるデータを渡した場合、0x00(NUL)を書き込んでファイルを拡張します。これにより、疎なファイルを作成できるので、書き込むデータが順不同で届く場合に、コンテンツをファイルに保存する処理を大幅に簡略化できます。 この機能がないと、ファイルのコンテンツを順不同で受け取るアプリケーション(たとえば、BitTorrent のダウンロード)は、事前に、または書き込み中にファイルのサイズ変更が必要になった場合に、手動でそれを行う必要があります。
FileSystemWritableFileStream.write()
0x00
NUL
現在、ウェブ制作者が作成できる範囲型は Range のみです。しかし、Range オブジェクトは「ライブ」であり、これをメンテナンスするのはコストがかかる場合があります。ツリーが変更されるたびに、影響を受けるすべての Range オブジェクトの更新が必要です。新しい StaticRange オブジェクトは、ライブではない軽量の範囲型を表すので、Range と同じようなメンテナンス コストはかかりません。StaticRange を作成可能にすることで、ウェブ制作者は DOM ツリーの変更に応じて更新する必要がない範囲にこれを利用できます。
Range
StaticRange
<picture> 要素内で <source> 要素を使う場合、width と height プロパティがサポートされます。これにより、Chrome が <picture> 要素のアスペクト比を計算できるようになります。これは、<img>、<canvas>、<video> の各要素の動作と一致します。
<picture>
<source>
width
height
<img>
<canvas>
<video>
新しい OscillatorNode オブジェクトを作成するときに、periodicWave に null を設定できなくなります。この値は、OscillatorNode() コンストラクタに渡される options オブジェクトに設定されます。WebAudio 仕様では、この値に null を設定することは許可されていません。これにより、Chrome の動作が仕様と Firefox に一致します。
OscillatorNode
OscillatorNode()
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.0 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
Array、String、TypedArray が at() メソッドをサポートします。このメソッドは、負の数による相対インデックスをサポートします。たとえば、次のコードは指定された配列の最後の項目を返します。
at()
let arr = [1,2,3,4]; arr.at(-1);
このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
'plugin-types' ディレクティブを使うと、<embed> または <object> html 要素で読み込めるプラグインの種類をデベロッパーが制限できます。これにより、デベロッパーはページ内の Flash をブロックできます。Flash のサポートは終了したので、このポリシー ディレクティブは不要になりました。
<embed>
<object>
Chrome では、WebRTC の非標準である RTP データ チャンネルのサポートを削除しました。ユーザーは、標準の SCTP ベースのデータ チャンネルを使用する必要があります。
Chrome は navigator.plugins と navigator.mimeTypes に対して空を返します。Flash が削除されたことで、これらのプロパティから何かを返す必要はなくなりました。
navigator.plugins
navigator.mimeTypes
今日は、実際に Spectre が JavaScript エンジンを侵害することを確認できる概念実証(PoC)コードを共有します。攻撃のデモには Google Chrome を使いますが、これは Chrome に固有の問題ではなく、他のモダンブラウザも同様にこの脆弱性の影響を受けるものと考えられます。攻撃のインタラクティブなデモを開発し、https://leaky.page/ で公開しました。コードと詳しい説明は、こちらの Github をご覧ください。
SharedArrayBuffer
ウェブ プラットフォームは、セキュリティの土台となる境界線としてオリジンに依存しています。また、ブラウザは、あるオリジンから別のオリジンへの明示的なデータの漏洩をうまく防いでいます。しかし、Spectre のような攻撃から、明示的でないデータ漏洩への対策が必要になることがわかります。このような攻撃では、サイドチャネルが悪用され、攻撃者のコードを実行するプロセスに入ったあらゆるデータが攻撃者に読み取られることが実証されています。現在、こういった攻撃の実現性はかなり高く、ユーザーにとってのリスクは現実のものとなっています。
機密データが意図せずに攻撃者のプロセスに入り込まないようにしなくてはなりません。ブラウザは、この責任の大部分を背負っています。Chromium の Site Isolation(サイト分離)は、アクセスしたサイトを OS レベルで専用のプロセスに隔離します。Cross-Origin Read Blocking = CORB(クロスオリジン読み込みブロック)は、そのままでは保護されないクロスオリジンリソースの一部が攻撃者に読み込まれることを防ぎます。攻撃者の帯域幅を大幅に増やす API(SharedArrayBuffer など)は、クロスオリジン分離コンテキストにロックされます。しかし、この最後のメカニズムは、ブラウザが単独では行えない作業を指しています。
ウェブ デベロッパーはアプリケーションを熟知しており、各ページやリソースの漏洩によるリスクを情報に基づいて判断できます。ユーザーのデータが漏洩することを防ぐため、ウェブ デベロッパーはホストしているリソースを評価し、適切にリソースを分離するようブラウザに指示するという対策をとる必要があります。概念レベルでは、この対策は次の要素で構成されます。
以上のさまざまな防御策を合わせれば、サイト分離が利用できるかどうかにかかわらず、すべてのブラウザでユーザーのデータに対してある程度の保護をプロセスレベルで提供できます。
これらの防御策の適用に関する詳しい情報は、Spectre 後のウェブ開発をご覧ください。以上で説明したセキュリティ プリミティブがどのようにサイト上のリソースに適用されるかについて、詳しく説明する実例も含まれています。
ここで示したのは、明示的でないデータ漏洩からオリジンを守るために、すぐにでも実施できる有用な手順です。今後は、ウェブの各種デフォルトを安全なものに移行し、デベロッパーが何もしなくてもこういった攻撃からユーザーを守れるようにしたいと考えています。
Bidding_strategy.type
BiddingStrategyType.ENHANCED_CPC
SharedBiddingStrategy.type
MANUAL_CPC
SharedBiddingStrategy.biddingScheme.enhancedCpcEnabled
TRUE
BIDDING_STRATEGY_NOT_SUPPORTED
CANNOT_ATTACH_BIDDING_STRATEGY_TO_CAMPAIGN
CampaignService.MutateCampaigns()
manual_cpc.enhanced_cpc_enabled
operations: [ { update: { resource_mame: customers/CUSTOMER_ID/campaigns/CAMPAIGN_ID, manual_cpc: { enhanced_cpc_enabled: true } }, update_mask: manual_cpc.enhanced_cpc_enabled } ]
CampaignService.mutate()
biddingStrategyType
biddingScheme.enhancedCpc
<operations> <operator>SET</operator> <operand> <id>CAMPAIGN_ID</id> <biddingStrategyConfiguration> <biddingStrategyType>MANUAL_CPC</biddingStrategyType> <biddingScheme> <enhancedCpcEnabled>true</enhancedCpcEnabled> </biddingScheme> </biddingStrategyConfiguration> </operand> </operations>
デジタル サービスが生活に身近になるにつれて、オンライン情報の安全を保つことの重要性も今までになく増しています。通常、パスワードはハッカーに対する防衛の第一線ですが、パスワードの漏洩につながりかねない情報流出の多さを考えれば、ユーザーは認証情報の保護に注意しなければならないことは明らかです。
これを簡単に行えるようにするため、2019 年に Password Checkup 機能を Chrome に導入し、Chrome に保存しているパスワードが漏洩した場合、通知が届くようになりました。今回、Google 自動入力を通してこの機能を Android アプリにも提供します。アプリで認証情報を自動入力したり保存したりすると、Chrome は侵害されたことがわかっている認証情報のリストと突き合わせて、そのパスワードが侵害されていた場合は、警告を表示します。そのプロンプトから Password Manager ページを開くこともできるので、そこで保存されているパスワードをすべてまとめて見直すこともできます。Android アプリでの Password Checkup は、Android 9 以降で Google 自動入力を使っているユーザーが利用できます。
Android デバイスで Autofill with Google を有効にする方法は次のとおりです
項目が見つからない場合は、こちらのページをご覧ください。デバイス メーカーから詳しい情報を得る方法が記載されています。
動作の仕組み
Google はユーザーのプライバシーを最優先に考えていますが、パスワードなどの機密データを扱う機能では特にそれを重視しています。Google 自動入力は Android の自動入力フレームワークがベースになっています。このフレームワークは、厳格かつ不変なプライバシーとセキュリティを遵守し、次の 2 つの場合にのみユーザーの認証情報にアクセスすることを保証します。1)ユーザーが Google アカウントに認証情報をすでに保存している場合。2)Android OS がユーザーに新しい認証情報を保存することを提案し、ユーザーがアカウントに認証情報を保存した場合。
ユーザーが認証情報を操作したとき(フォームに認証情報を入力する、または初めて保存するとき)、Chrome で使われているものと同じプライバシー保護 API を使い、Google が追跡している既知の侵害されたパスワードのリストにその認証情報が含まれていないかを確認します。
この実装では、以下の点が保証されています。
この API の内部処理の詳細については、Chrome チームによるこちらのブログをご覧ください。
その他のセキュリティ機能
Google 自動入力は、Password Checkup の他にも、データの保護に役立つ機能を提供します。
いつものように、プロダクト全般のセキュリティ向上に関する最新情報をお届けする Google Security ブログにご注目ください。
Chrome 91(2021 年 5 月)より、すべてのプラットフォームで、SharedArrayBuffer や performance.measureUserAgentSpecificMemory() などの API にアクセスする際にクロスオリジン分離が必須になります。Android では Chrome 88 からこの制限が適用されていますが、この対応により、デスクトップにも同じ制限が適用されます。
performance.measureUserAgentSpecificMemory()
今後もこれらの API を使用する場合は、ページで以下のヘッダーを送信し、確実にページがクロスオリジン分離されるようにしてください。
Cross-Origin-Embedder-Policy: require-corpCross-Origin-Opener-Policy: same-origin
なお、これをすると、Cross-Origin-Resource-Policy ヘッダーか CORS ヘッダー(Access-Control-Allow-* など)で明示的にリソースを許可しない限り、そのページでクロスオリジンのコンテンツを読み込めなくなりますので、ご注意ください。
Cross-Origin-Resource-Policy
Access-Control-Allow-*
対応手順の詳細やその他の考慮事項については、web.dev のクロスオリジン分離有効化ガイドをご覧ください。
Feed
FeedItem
CampaignFeed
AdGroupFeed
AdGroupAd
call_view
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。(2021 年 1 月 28 日に Chrome 89 がベータ版としてリリースされた時点の情報です)
ヒューマン インターフェース デバイス(HID)には、新しすぎる、古すぎる、あまりにも一般的でないなどの理由で、システムのデバイス ドライバからアクセスできないロングテールなものがあります。WebHID API は、デバイス固有のロジックを JavaScript で実装する方法を提供することで、この問題を解決します。
ヒューマン インターフェース デバイスは、人間からの入力を受け取ったり、人間に対して出力を提供したりします。デバイスには、キーボード、ポインティング デバイス(マウス、タッチスクリーンなど)、ゲームパッドなどがあります。
たとえば、ゲームパッドのサポートにおいては、一般的でない HID デバイスにアクセスできないのは特に苦痛です。ゲームパッドの入出力はうまく標準化されておらず、多くの場合、ウェブブラウザに特定のデバイス向けのカスタム ロジックが必要となります。これはサステナブルでなく、古いデバイスや一般的でないデバイスといったロングテールがサポートされないことになります。
WebHID のオリジン トライアルは終了し、PC 向けの Chrome 89 でデフォルトで有効になります。使用方法については、一般的でない HID デバイスに接続するで確認できます。ウェブのヒューマン インターフェース デバイス : いくつかの簡単な例のデモもご覧ください。
NFC とは少量のデータを転送する近距離無線通信のことで、通常は専用の 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 は、この機能をウェブサイトで実現し、マイクロコントローラや 3D プリンタなどのデバイスを制御できるようにします。
教育、趣味、工業の分野では、すでにウェブページから周辺機器を制御しています。その場合、デバイスの制御にはアダプターやドライバのインストールが必要です。Web Serial API は、ウェブサイトと周辺機器の直接通信を可能にすることで、ユーザー エクスペリエンスを改善します。
Web Serial API のオリジン トライアルが終了し、PC で有効になります。GitHub でデモが公開されています。使用方法については、シリアルポートの読み書きを行うをご覧ください。
デベロッパーは、ユーザーがソーシャル ネットワークで簡単にコンテンツを共有できるようにするため、各ソーシャル サービス用の共有ボタンを手動でサイトに組み込んでいます。このため、ユーザーが実際に使っているサービスで共有できないことが多く、ページサイズの肥大化やサードパーティ製コードによるセキュリティ リスクも発生しています。受信側では、共有ターゲットとして登録して他のアプリからの共有を受け取ることができるのは、プラットフォームのアプリのみです。
Android 版の Chrome では、Chrome 61 から 75 の間でこれらの機能の追加を始めました。Chrome 89 では、ウェブ共有が Windows と ChromeOS でも利用できるようになります。ただし、共有ターゲットとしての登録は ChromeOS のみでサポートされます。これらのプラットフォームでは、PC のサイトで navigator.share() を使うと、共有ダイアログ ボックスを開くことができます。また、ウェブアプリ マニフェストのエントリを追加すると、PWA を共有ターゲットにすることができます。
navigator.share()
ウェブ共有についての情報は、Web Share API で OS の共有 UI を組み込むをご覧ください。PWA を共有ターゲットにすることについての詳しい情報は、Web Share Target API で共有データを受け取るをご覧ください。
このバージョンの Chrome には、新しいオリジン トライアルはありません。現在のオリジン トライアルに登録するには、オリジン トライアル ダッシュボードをご覧ください。オリジン トライアル自体の詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。
Chrome が AVIF コンテンツのデコードをネイティブにサポートします。Android と WebView は既存の AV1 デコーダを利用します(PC 版でのサポートは、Chrome 85 で追加されました)。AVIF は次世代の画像フォーマットで、Alliance for Open Media が標準化しています。AVIF のサポートには、主に 3 つの目的があります。
新しい Reporting API は、Cross-Origin Opener Policy (COOP) のデプロイに役立ちます。この API は、COOP が強制される際の違反の報告に加え、COOP の報告のみのモードも提供します。COOP の報告のみのモードは COOP を強制しませんが、COOP を強制していれば発生していた潜在的な違反を報告します。デベロッパーは、Chrome DevTools で Reporting API が有効になっているかを確認できます。
ウェブアプリ マニフェストに display_override フィールドが新しく追加されます。これにより、デベロッパーが display フィールドのフォールバック チェーンを明示的に指定できるようになります。次の例では、"minimal-ui" を "standalone" にフォールバックする指定をしています。
display_override
display
"minimal-ui"
"standalone"
{ "display": "standalone", "display_override": ["minimal-ui"], }
この API は、高度なユースケースと表示モードを想定したもので、機能は限られています。詳しくは、Chrome Status のエントリをご覧ください。
Chrome は、他の ReadableStream 関連のクラスと同じように、グローバル オブジェクトで ReadableStreamDefaultController インターフェースを公開します。これにより、インスタンスをストリームのコンストラクタの内部で作成しなければならないという、これまでの制限がなくなります。
ReadableStreamDefaultController
この機能により、ウェブページのメモリ使用量を見積もる performance.measureUserAgentSpecificMemory() 関数が追加されます。このメソッドは COOP/COEP の制限を受けるので、これを使うにはウェブサイトがクロスオリジン分離されている必要があります。
現在のウェブ標準に準拠するため、Chrome はすべての data: URL を潜在的に信頼できるものとして扱います。 これは、認証や機密性に関して最低限の基準しか満たされていない場合でも、ある機能を有効化するためには、URL が安全かどうかを評価しなければならないことがあるためです。ウェブ標準は、それを実現するために「潜在的に信頼できる URL」の定義を使いますが、最新版の Secure Contexts 仕様では、そこに "data" スキームの URL が含まれています。これまでの Blink は、いくつかの data: URL のみを潜在的に信頼できるものとして扱っていました。
ストリーム API では、データ ストリームの作成、構成、使用のためのユビキタスで相互運用可能なプリミティブが提供されます。Chrome は、バイトを表すストリームで拡張バージョンの読み取り可能ストリームをサポートし、バイトを効率的に扱います。具体的には、コピーの回数を最低限にとどめます。
バイト ストリームは、Bring Your Own Buffer(BYOB)のリーダーを取得できます。デフォルトの実装では、ウェブソケットの場合は文字列や配列バッファなどのさまざまな種類の出力を指定できますが、バイト ストリームではバイト出力が保証されます。さらに、BYOB リーダーを扱えることで、安定性のメリットももたらされます。バッファがデタッチされれば、同じバッファに 2 回書き込まれないことが保証され、競合状態を回避できるためです。BYOB リーダーではバッファが再利用されるため、読み取りのたびにガベージ コレクションを行う必要もありません。
Chrome の SVG 要素で 'filter' プロパティの完全な構文が利用できるようになります。これまでは、1 つの url() 参照しかサポートされませんでした。これにより、blur()、sepia()、grayscale() などのフィルタ関数を SVG 要素と非 SVG 要素の両方に適用できるようになります。また、'filter' のプラットフォーム サポートの均一性が増し、一部の「定型」エフェクトを適用しやすくなります。この機能がないときは、grayscale() や blur() といった基本的なフィルタを使う場合でも、SVG の完全な <filter> 要素定義を使う必要がありました。
'filter'
url()
blur()
sepia()
grayscale()
<filter>
Chrome で Web Authentication API に関連する 2 つの新機能がサポートされます。AuthenticatorSelectionCriteria.residentKey プロパティは、ウェブ認証のクレデンシャル登録において、クライアント側で検出可能なクレデンシャルを作成するかどうかを指定します。
AuthenticatorSelectionCriteria.residentKey
Web Authentication の credProps エクステンションは、作成したクレデンシャルがクライアント側で検出可能(discoverable)かどうかをリライング パーティに示します。「クライアント側で検出可能なクレデンシャル」とは、WebAuthn API リクエストでリライング パーティがクレデンシャル ID を提供することなくチャレンジを行えるタイプの WebAuthn クレデンシャルです。ブラウザは、指定された認証器(外部セキュリティ キーか組み込みのもの)からのすべての検出可能なクレデンシャル(discoverable credentials)のリストを表示し、ユーザーがログインに使うものを選択できるようにします。
credProps
scroll-to-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-colors
forced-color-adjust プロパティを使うと、強制カラーモードから特定の要素を除外し、CSS で完全にカラーを制御する状態に戻すことができます。
forced-color-adjust
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 8.9 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
Chrome では、JavaScript モジュールのトップレベルで await キーワードが許可されるようになりました。これにより、モジュールの読み込み処理に非同期呼び出しをシームレスに統合できるようになります。現在のところ、この機能はモジュールを async 関数でラップすることで実現していますが、これにより複雑さを依存モジュール側にとどめつつ、実装の詳細を公開しています。
await
クロスオリジン画像の向きの判定に常に EXIF 情報が利用されるようになります。つまり、CSS で image-orientation: none を設定しても、安全でないオリジンの画像には反映されなくなります。この仕様変更に関する議論は、CSS ワーキング グループ ドラフトに記載されています。
image-orientation: none
このバージョンの Chrome では、以下のサポートの終了および機能の削除が行われます。現在サポートが終了している機能および以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
<link rel=prerender> から発行されるレガシーなプレフィックス付きイベント(webkitprerenderstart、webkitprerenderstop、webkitprerenderload、webkitprerenderdomcontentloaded)が Chrome から削除されます。
<link rel=prerender>
webkitprerenderstart
webkitprerenderstop
webkitprerenderload
webkitprerenderdomcontentloaded
ウィンドウを noopener で開いた場合、Chrome はオープン元の sessionStorage を複製しなくなります。代わりに、空の sessionStorage 名前空間が開始されます。これにより、Chrome が HTML 仕様に準拠します。
sessionStorage