今日は、実際に 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
CampaignError.HEC_AGREEMENT_REQUIRED
Customers with Housing, Employment, or Credit ads must accept updated personalized ads policy to continue creating campaigns
CampaignError.UNKNOWN
CampaignService.OperationAccessDenied
ReportDefinitionError.INVALID_FIELD_NAME_FOR_REPORT
AdsApp.report
ConversionAdjustment
ConversionAdjustmentLagBucket
ConversionAttributionEventType
ConversionCategoryName
ConversionLagBucket
ConversionTrackerId
ConversionTypeName
AllConversionRate
ConversionRate
CostPerAllConversion
CostPerConversion
CostPerCurrentModelAttributedConversion
ReportDefinitionService.getReportFields
exclusiveFields
