Quantcast
Channel: Google Developers Japan
Viewing all articles
Browse latest Browse all 2211

Chrome 83 ベータ版: XSS からの保護、フォーム コントロールの改善、安全な CORS など

$
0
0
この記事は Joe Medley による Chromium Blog の記事 "Chrome 83 Beta: Cross-site Scripting Protection, Improved Form Controls, and Safe Cross-origin Resource Sharing" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.comの一覧でご確認ください。2020 年 4 月 16 日の時点で Chrome 83 はベータ版です。

DOM 操作のための Trusted Types

DOM ベースのクロスサイト スクリプティング(DOM XSS)は、ウェブ セキュリティにおいて特によく見られる脆弱性です。意図せずにアプリケーションに含まれている可能性もあります。新しいテクノロジーである Trusted Types は、デフォルトで DOM XSS 脆弱性のないアプリケーションを書いてメンテナンスする上で役立ちます。Trusted Types は、危険な API を保護することでこれを実現します。

Element.innerHTMLなどのプロパティについて考えてみましょう。このプロパティによって、サイトで有害な HTML 操作が行われてしまう可能性があります。Trusted Types を使うと、スクリプトでこのプロパティが使われたときにエラーがスローされます。これを行うには、新しいコンテンツ セキュリティ ポリシーを設定します。次に例を示します。


Content-Security-Policy: require-trusted-types-for 'script';
report-uri //my-csp-endpoint.example


Trusted Types について詳しくは、Trusted Types で DOM ベースのクロスサイト スクリプティング脆弱性を防ぐをご覧ください。

フォーム コントロールの改善

HTML フォームのコントロールは、多くのインタラクティブなウェブを支える柱です。デベロッパーが簡単に使えるだけでなく、ユーザー補助機能も組み込まれており、ユーザーも使い慣れています。しかし、フォーム コントロールのスタイルは非常に一貫性のないものになっています。最初期のフォーム コントロールは、オペレーティング システムの表示と一致していましたが、その後のコントロールには、作られた当時に人気のあったデザイン スタイルが用いられています。この一貫性のなさのため、デベロッパーは余分な時間とコードを費やして開発する必要がありました。

昨年 1 年間、Chrome と Edge が協力し、HTML フォーム コントロールの外見と機能の改善に取り組みました。これには、コントロールやその他のインタラクティブ要素のフォーカス状態を認識しやすくすることも含まれています。下のイメージは、Chrome のいくつかのコントロールの旧バージョンと新バージョンを示しています。

旧バージョン:


新バージョン:

新しいフォーム コントロールは、既に Microsoft Edge に導入されており、Chrome 83 でも利用できるようになりました。詳しくは、Microsoft の記事 Microsoft Edge と Chromium のフォーム コントロールを改善するか、Chromium ブログの投稿フォーム コントロールとフォーカスのアップデートをご覧ください。

新しいクロスオリジン ポリシー

ウェブ API の中には、Spectre などのサイドチャネル攻撃のリスクを高めるものもあります。このリスクを緩和するため、ブラウザは cross-origin isolated と呼ばれるオプトインベースの分離環境を提供します。これを実現するのが、2 つの新しい HTTP ヘッダーである Cross-Origin-Embedder-PolicyCross-Origin-Opener-Policyです。この 2 つのヘッダーがある場合、将来的にウェブページで以下の特権機能を安全に使うことができるようになります。
  • Performance.measureMemory()
  • JS Self-Profiling API
cross-origin isolated 状態では、document.domainの変更も禁止されます。


詳しくは、COOP と COEP を使ってウェブサイトを「cross-origin isolated」にするをご覧ください。

オリジン トライアル

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

ネイティブ ファイル システム

新しいオリジン トライアルである Native File System API は、Chrome 83 から Chrome 85 で行われる予定です。この API を使うと、ユーザーのローカル端末上のファイルを操作するウェブアプリを実現できます。たとえば、IDE、写真や動画のエディタ、テキスト エディタなどが考えられます。ユーザーがアクセス権を与えると、アプリは API を使ってユーザーの端末にあるファイルやフォルダを直接読み取ったり保存したりできるようになります。この処理は、プラットフォーム独自のファイルを開くまたはファイルを保存するダイアログ ボックスを通して行われます。詳しくは、Native File System API: 簡単にローカル ファイルにアクセスするをご覧ください。

Performance.measureMemory()

新しい Performance.measureMemory()関数は、ウェブページのメモリの使用状況を見積ることで、本番環境のウェブアプリやウェブページのメモリの使用状況を測定します。以下のようなユースケースが考えられます。
  • メモリの使用状況とユーザー指標との相関関係を分析する
  • メモリのリグレッションを検知する
  • A/B テストで機能のリリースを評価する
  • メモリを最適化する
現在、ウェブ デベロッパーは非標準の performance.memory API を使うしかありません。これはページ読み込みの 20% を使用します。詳しくは、performance.measureMemory() でウェブページの合計メモリ使用量をモニタリングするをご覧ください。

優先度付きの Scheduler.postTask()

Scheduler.postTask()メソッドを使うと、ネイティブ ブラウザのスケジューラによるタスク(JavaScript コールバック)のスケジューリングが可能です。その際に、user-blockinguser-visiblebackgroundという 3 段階の優先度レベルが利用できます。さらに、TaskControllerオブジェクトが公開されるので、そこから動的にタスクをキャンセルしたり優先度を変更したりできます。

WebRTC Insertable Streams

WebRTC Insertable Streams APIを使うと、WebRTC の MediaStreamTrack のエンコードおよびデコードの際にカスタムのデータ処理を行うことができます。利用例の 1 つとして、ピア接続間で中間サーバーを通して送信されるデータのエンドツーエンドの暗号化があげられます。Insertable Streams を使うには、RTCPeerConnection インターフェースの新しいパラメータのいずれか 1 つを追加します。今回のリリースにおけるその他の WebRTC のアップデートは、次のセクションに記載されています。

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

ARIA アノテーション

新しい ARIA アノテーションによって、スクリーン リーダーが意味を持つコメント、サジェスチョン、テキストのハイライト表示(<mark>と同じ)にアクセスできるようになります。また、関連情報と要素を意味的につなげて、説明、定義、脚注、コメントを他の要素と結びつけることができます。
これまで、アノテーションはライブ リージョン ハックを使わなければ実現できませんでした。この方法はセマンティクスほど信頼できず、目が不自由な方向けの表示としては不十分でした。そのため、スクリーン リーダーはオンライン ワード プロセッサとの連携機能を十分にサポートできませんでした。

'-webkit-appearance' CSS プロパティの 'auto' キーワード

-webkit-appearance CSS プロパティに新しく autoキーワードが追加されました。このキーワードは、対象要素のデフォルトの外見を表します。これは将来の完全に標準化された appearanceプロパティによる、非標準の -webkit-appearanceプロパティの置き換えに向けた一歩です。

Barcode Detection API

Chrome が Barcode Detection API をサポートします。この API は、スクリプトで提供されたイメージ内にあるバーコードを検出してデコードする Shape Detection API の一部です。イメージは、<image><video><canvas>の各タグなど、任意の種類のイメージ バッファ ソースから取得できます。これまで、ウェブページでバーコードを検出するには、大きなサードパーティ製ライブラリを含める必要がありました。この API は、Google Play Servicesがインストールされた端末でのみ利用できます。認定外の端末では利用できません。Barcode Detection API の詳細や、その他の Shape Detection API については、Shape Detection API: 1 枚の写真には 1000 の単語、顔、バーコードの価値があるをご覧ください。

CSS contain-intrinsic-size

contain-intrinsic-sizeプロパティを使うと、contain: sizeが適用された場合に使われるプレースホルダのサイズを指定できます。contain-intrinsic-sizeを指定すると、その要素のレイアウトは、このプロパティで指定された固定サイズの子要素が 1 つあるかのように振る舞います。ただし、明示的に幅や高さが指定されている場合は除きます。

このプロパティは、まだ利用できない、またはまだレンダリングされていないサブツリー コンテンツのプレースホルダのサイズ指定を行うために導入されました。これまでは、要素自体のサイズを変更する以外にこれを行う方法はありませんでしたが、この方法はコンテナ内の要素のレイアウト方法に影響するため、好ましくありません。サンプルは、WICG で公開されています

CSS の色調整: color-scheme メタタグ

現在は、多くのオペレーティング システムに「ダークモード」プリファレンスが搭載されています。既にウェブページをダークテーマに変換するオプションを提供しているブラウザもあります。prefers-color-schemeメディアクエリを使うと、制作者が独自のダークテーマをサポートし、構築したエクスペリエンスを完全に制御できるようになります。このメタタグでは、サイトでダークテーマの完全サポートを明示的にオプトインできます。これにより、ブラウザは別のユーザー エージェント シートを読み込み、変換は適用しなくなります。詳しくは、color-scheme CSS プロパティと対応するメタタグでダークモードのデフォルト スタイルを改善するをご覧ください。

<button> の display:inline-grid/grid/inline-flex/flex

displayのキーワードである inline-gridgridinline-flexflexが、align プロパティが適用されている <button>要素に対して機能するようになります。(デモ

Shared Worker の ES モジュール('module' タイプ オプション)

Shared Worker の JavaScript がモジュールをサポートするようになります。コンストラクタの type 属性に moduleタイプを設定すると、Worker のスクリプトが ES モジュールとして読み込まれ、Worker のコンテキストで import 文が利用できるようになります。この機能を使うと、組み合わせ可能なプログラムを簡単に書けるようになり、ページや Worker 間でプログラムを共有しやすくなります。詳しくは、「モジュール Worker でウェブをスレッド化する」のShared Worker に関する部分をご覧ください。

font-display: optional の改善

Chrome で font-displayの動作方法がいくつか変更されます。
  • font-displayoptionalに設定しても、再レイアウトが発生しなくなります。
  • ウェブフォントを十分高速に読み込める場合にフォールバック レンダリングを行わなくてもいいように、フォントのプリロードは(すべての font-display値について)レンダリングをわずかにブロックできるようになります。
この結果、font-display: optionalとプリロードの両方が使われている場合、フォントの交換によるレイアウトの切り替えが起こらなくなります。詳しくは、オプショナル フォントのプリロードによってレイアウトの切り替えと非表示テキストのフラッシュ(FOIT)を防ぐをご覧ください。

IndexedDB のトランザクション耐久性の緩和

IDBDatabase.transaction()にオプション引数 durabilityを渡せるようになります。
これにより、データのストレージへのフラッシュを制御し、明示的に耐久性とパフォーマンスをトレードオフできるようになります。これまでは、IndexedDB のトランザクションを書き込んだ場合、Firefox はフラッシュを行いませんでしたが、Chrome は行っていました。これにより、データが OS の中間キャッシュでなく端末のディスクに書き込まれることが保証されるので、耐久性が増加します。残念ながら、この機能はパフォーマンスに大きく影響します。
有効なオプションは、"default""strict""relaxed"です。"default"オプションは、ユーザー エージェントが提供する現在のデフォルトの動作に従うことを表します。次に例を示します。現在の値は、IDBTransaction.durabilityを使って読み取ることができます。

const iDBTransaction = database.transaction(
  [ "storeName" ],
  "readwrite",
  {
    durability: "relaxed"
  }
);


レンダリングエンジン外の CORS

レンダリングエンジン外の CORS(Out-Of-Renderer Cross-Origin Resource Sharing、OOR-CORS)は、ネットワーク アクセスを調査する新しい CORS 実装です。Chrome のこれまでの CORS 実装は、Blink のコア部分、XHR および Fetch API のみが利用でき、アプリケーションの他の部分では簡易実装が使われていました。そのため、いくつかの内部モジュールが発行する HTTP リクエストを CORS で点検することはできませんでした。新しい実装は、この欠点に対応しています。

<input type=time> の範囲の逆転

Chrome で、typetimeである <input>要素の範囲の逆転がサポートされます。これにより、0 時をまたぐ時間の入力を表現できるようになります。範囲の逆転とは、最大が最小より小さいことを指します。この場合、input 要素は最小よりも小さいか最大よりも大きい値を許可しますが、その間の値は許可しません。この機能は、長い間仕様に掲載されていましたが、Chrome では実装されていませんでした。

"JIS-B5" および "JIS-B4" @page のサポート

Chrome が @page ルールで次の 2 つのページサイズをサポートします。この 2 つは、どちらも CSS Paged Media Module Level 3 仕様に記載されています。
  • "JIS-B5": 幅 182 mm 、高さ 257 mm
  • "JIS-B4": 幅 257 mm 、高さ 364 mm
この機能により、Chrome は標準のこのセクションの実装をすべて完了したことになります。

@supports selector() 機能クエリ関数

新しい @supports関数は、CSS セレクタの機能検知を提供します。ウェブ制作者は、実際にセレクタに一致するスタイルルールの指定を適用する前に、この機能を使って UA がセレクタをサポートしているかどうかを照会できます。次に例を示します。

@supports selector(::before) {
div { background: green };
}

WebRTC

オリジン トライアルに記載した項目に加え、以下のウェブ RTC 機能が Chrome に追加されます。

RTCPeerConnection.canTrickleIceCandidates

canTrickleIceCandidates boolean プロパティは、リモートピアが候補のトリックルを扱えるかどうかを示します。この機能は、SDP セッション記述の情報を公開します。

RTCRtpEncodingParameters.maxFramerate

このエンコード パラメータを使うと、送信前に動画レイヤーのフレームレートを制限できます。新しいフレームレートは RTCRtpSender.setParameters()を使って設定します。新しい設定は、現在のピクチャが完了した後に適用されます。この設定は、RTCRtpEncodingParameters.maxFramerateで読み出すことができます。maxFramerateを 0 に設定すると、次のフレームで動画がフリーズします。

RTCRtpSendParameters.degradationPreference

RTCRtpSendParametersdegradationPreferenceという新しい属性が追加されます。これを使うと、帯域幅や CPU などの制約により、設定されたフレームレートや解像度でエンコードできない場合に、どのように質を低下させるかを制御できます。たとえば、画面共有アプリのユーザーは、アニメーションよりも画面の読みやすさを優先したいでしょう。ビデオ会議のユーザーは、高解像度よりもスムーズなフレームレートを好むはずです。degradationPreferenceに設定できる値は、"maintain-framerate""maintain-resolution""balanced"です。

WebXR DOM オーバーレイ

DOM オーバーレイは、ハンドヘルド端末のイマーシブ AR 機能です。この機能を使うと、2 次元ページ コンテンツをインタラクティブな透過レイヤーとして WebXR コンテンツやカメライメージの上に表示できます。そのため、DOM を使って WebXR エクスペリエンスのユーザー インターフェースを作れるようになります。VR では、インライン セッションは必然的に DOM の中になります。一方、AR にはインライン モードはありません。一部のユースケースでは、これが特に重要になります。この機能を試したい方は、Chrome 83 で 2 つサンプルのどちらかをご利用ください。現在、この機能は ARCore ベースのハンドヘルド端末でのみ利用できます。

JavaScript

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

Intl.DateTimeFormat の fractionalSecondDigits オプション

Chrome 83 の Intl.DateTimeFormatオブジェクトに fractionalSecondDigitsプロパティが追加され、秒の端数の表示形式を制御できるようになります。ECMAScript の Date オブジェクトは、ミリ秒の精度で時間情報を保存します。この情報を出力しなければならないウェブ デベロッパーもいます。このプロパティの値は 0 から 3 の間の整数で、DateTimeFormatが出力する小数点以下の桁数を表します。

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

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

サンドボックス化された iframe でのダウンロードの拒否

Chrome では、サンドボックス化された iframe でダウンロードが許可されなくなります。ただし、この制限は、サンドボックス属性リストの 'allow-downloads'キーワードを使って解除できます。今回の変更により、コンテンツ プロバイダは悪意のあるダウンロードや不正なダウンロードを制限できます。ダウンロードは、システムにセキュリティ脆弱性をもたらす場合があります。Chrome およびオペレーティング システムでは追加のセキュリティ チェックが行われますが、サンドボックス化された iframe でのダウンロードをブロックすることも、サンドボックスの目的と一致するものと考えています。

Reviewed by Eiji Kitamura - Developer Relations Team

Viewing all articles
Browse latest Browse all 2211

Trending Articles