Google Chrome 70 が木曜日にベータ版としてリリースされ、いくつかの有意義な改善と、開発者の興味を引く難解な機能が追加されました。
Android、Chrome OS、Linux、macOS、Windows の Chrome ベータ チャンネルで利用可能 (iOS ベータ版では Apple の TestFlight プログラムへの参加が必要) Chrome 70 では、Web アプリで画像内の顔の検出、バーコードの読み取り、画像内のテキストの解析などを実行できる Shape Detection API が実装されています。
この API はモバイル Web アプリにとって特に有望であり、画像内の顔の特徴の位置を返したり、バーコードや QR コードを文字列に変換したり、写真にあるラテン アルファベットのテキストを読み取ったりできるようになります。
Chrome チームは、ブラウザの Web 認証 API を更新し、既にサポートされている他の 2 つのタイプであると をPublicKeyCredential補完する3 番目のタイプの認証情報を追加しました。PasswordCredentialFederatedCredential
このPublicKeyCredentialタイプでは、非対称鍵ペアをサポートするメカニズムを使用してログインできます。これは、パスワードよりも安全である可能性があります。これをサポートするデバイスは、Androidの指紋リーダーとmacOSのTouchIDセンサーの2つです。つまり、Web Authentication APIを実装したウェブサイトは、PublicKeyCredentialこれらの生体認証センサーのいずれかから渡された情報を読み取ってユーザーをログインさせることができるということです。
プライバシー強化も実施されています。Android版Chrome 70ベータ版では、iOS版Chrome 69に倣い、user-agentブラウザが訪問したウェブサイトに渡す文字列からOSビルド番号を削除します。
このデータは、他の技術的指標と併せて、ブラウザフィンガープリントと呼ばれるものを作成するために使用できます。これにより、ユーザーを特定のデバイス構成や機能を通じて追跡できます。このデータが存在しない（iOSでは、Safariの同時実装に合わせて、削除ではなく「15E148」として凍結されています）ことで、ブラウザフィンガープリントの精度が低下し、特定のオペレーティングシステムバージョンに対するエクスプロイトの提供が困難になるはずです。
大画面と最高傑作
同様に、Chrome はウェブページにダイアログボックスが表示された場合、全画面モードを終了するようになりました。これは、ウェブアプリがデータや権限を要求した際に、ユーザーが判断を下すために必要なコンテキストを提供するためです。
公式：Google Chrome 69 が World Wide Web を廃止（URL 形式）
続きを読む
Chrome 70 ベータ版は、8月に公式標準となったウェブセキュリティプロトコルの改良版である TLS 1.3 を実装しています。TLS 1.3 は、クライアントとサーバー間のラウンドトリップを削減することで以前のバージョンよりも効率性を高め、ハンドシェイクネゴシエーションの暗号化を強化することでセキュリティを強化しています。
このブラウザアップデートでは、Media Source Extensions APIを介してmp4コンテナ内のOpusコーデックのサポートも追加され、Opusでエンコードされたオーディオのストリーミングが可能になります。また、Windows 10版ChromeにWeb Bluetoothのサポートが追加されました。この件に関するGoogleのブログ投稿では、介入レポートなどの開発者向け追加機能についてさらに詳しく説明されています。
今週初め、Google Chrome セキュリティ製品マネージャーのエミリー・シェクター氏は、Google はコミュニティからのフィードバックに応えて、デスクトップ版と Android 版の Chrome 69 のアップデートを通じて、ブラウザのアドレスバーに表示される URL のサブドメイン「www」と「m」を非表示にする Chrome 69 の習慣を元に戻すことを決定したと述べた。
Chrome 70（10月中旬に安定版リリース予定）では、「www」は省略されますが、「m」は省略されません。Chromiumのバグ報告スレッドで、シェクター氏は次のように説明しています。「大規模なサイトの中には、ユーザーが管理する「m」サブドメインが存在するため、M70（マイルストーン70）では「m」を省略しません。サイトで「www」サブドメインをユーザーが管理できるようにすべきではないというコミュニティの合意が広がっています。」
Google の URL 処理の変更に懐疑的な人々の間では、チョコレート ファクトリーの目的は、ウェブサイトの Accelerated Mobile Page (AMP) バージョンをいつ提供するかを隠すことだという意見もある。AMP は Google に力を与え、パブリッシャーに力を奪う技術だと主張する人もいる。
Googleは、これらのサブドメインの扱いを特別なケースとしてウェブ標準化団体に検討させる予定です。「ブラウザがUIでこれらの特別なケースをどのように扱うべきかを標準化する予定はありません」とシェクター氏は述べました。「コミュニティとさらに議論する機会を得た後、後日、『m』サブドメインについて再検討する予定です。」
Schechter のバグ報告投稿に追加されたコメントから判断すると、コミュニティは URL を変更しないことを望んでいるようです。®
