ChromeのUA文字列の固定化はどうなるか

Chromeでは現在，UA Client Hintsという，ブラウザの名前やバージョンを取得するための新しいHTTPヘッダとAPIの実装が進んでいます。これまで使われていたUser-Agentヘッダや，navigator.userAgentプロパティが返すUA文字列の代わりとなるものです。

そしてChromeは2020年1月に，UA文字列の固定化とUA Client Hintsへの移行計画を発表しました。

UA文字列はブラウザのマイナーバージョンまで含めた細かいバージョン，OSのバージョン，パソコンのアーキテクチャ，モバイル端末では機種モデル名など，多くの情報が含まれています。これらがフィンガープリンティングに使われる可能性があるため，必要な情報だけを提供させるようにし，ユーザーのプライバシーを向上させたいわけです。

当初は2020年中の固定化とUA Client Hintsへの投入を予定していましたが，UA Client Hints仕様では足りないユースケースがあることや，移行期間の短さに伴う開発者からの反発もあり，現在まで実施されていません。

しかしながら，UA Client Hintsの試験実装は進み，そこから得たフィードバックを反映し仕様も更新されています。そう遠くないうちに，UA Client Hintsの投入は行われるのではないかと思います。

UA文字列の固定化も，今後2～3年かけてというよりは，可能な限り短い期間で行いたいのではないかと感じています。というのも，どのみちUA文字列における問題が表面化するからです。Chromeのバージョンは2020年末時点で87ですが，6〜8週間のリリースサイクルで更新されるため，2021年末には96に，そして2022年の半ばには100を超えてしまいます。

何が問題かというと，バージョンが3桁になるため，2桁を見越したナイーブな正規表現のコードに影響が出ることです。Chrome 10と判定される，はたまたChromeと認められないかもしれません。そんなコードがあるのか？と思うかもしれませんが，なかなかあるようで，これまでもOperaのバージョンが10になった際にUA文字列のバージョンを9.8にするといった対応をとっています。数年前にiOSも10になりましたが，互換性に影響されたサイトも少なからずありました。

リリースサイクルの短さもあり，Chromeのバージョンを細かくチェックするコードはそこまでないかもしれませんが，桁が増えることによるエラーは容易に起こりそうです。壊れてしまう前に固定化を行い，そのうえでバージョンが必要な場合はUA Client Hintsを使うように促したいのではと思っています。

SafariのUA文字列の半固定化も注目

UA文字列といえば，2020年11月リリースのmacOS Big Surで，macOSのメジャーバージョンが11に上がったことも気になるトピックです。macOSは20年近くバージョンが10のままであり，UA文字列を処理するコードがバージョン10以外の状況を考慮していないことは容易に考えられます。

実はAppleは2018年にWebKitの開発版において，OSやブラウザのバージョンを固定したものの正式リリースまでの間に取りやめています。ChromeのUA文字列固定化と同様に，プライバシーの向上をねらった変更でしたが，既存のウェブサイトとの互換性の問題からその時はあきらめています。

固定化ではありませんが，macOS 11になってバージョンが変わると，それはそれで互換性に影響がでてしまいます。AppleはmacOSのバージョンを11ではなく，少し前のmacOS 10のバージョンにすることで対応しています。macOS 11リリース直後のSafariでは，OSのバージョンが10.15.6と同等のものになっていました。macOS 11への移行が進むと11に変わるのかもしれませんが，しばらくは10のようで11という状況が続きそうです。

また，2020年11月には自社製造のMac用チップM1搭載したMacが発売されました。UA文字列にはOSのバージョンだけではなく，CPUのアーキテクチャも含まれているのですが，互換性への影響からかM1チップのMacにおいても，UA文字列の内のアーキテクチャはIntelのままになっています（内部的には，Intelで固定されています⁠）⁠。

つまり，macOS 11のSafariは，Safariのバージョンを除き大部分のUA文字列を固定したことになります。OSやアーキテクチャでSafariバージョンを区別したいケースがどれほどあるのかは分かりませんが，UA文字列だけでの判別は難しいため別の方法が必要になります。

Googleのプライバシー・サンドボックスの取り組み

2020年1月にGoogleは，向こう2年でChromeからサードパーティCookieのサポートを終了したいという声明を発表しました。

サードパーティCookieは様々な用途に使われますが，クロスサイトトラッキング（サイトを超えたユーザーの追跡）に使われ，そこからユーザーの意図しないまま行動データが収集されプライバシーを侵害するという問題があります。EUのGDPRや，米国カリフォルニア州のCCPAなど，ユーザーのデータを保護する法整備も進んでおり，Cookieもその対象になっています。

しかしサードパーティCookieはシングルサインオンなどにも利用されており，ブロックによって使っているサイトへの影響も出てしまいます。また，サードパーティCookieのブロックにより，フィンガープリンティングなどよりブロックが難しいとされるテクニックが使われてしまう危険性もあります。また，サードパーティCookieの一律ブロックがウェブのマネタイズを損なうという懸念もあるようです。

このため，Googleはプライバシーを尊重しつつ，ウェブの収益モデルも維持するようなCookie代替技術として，プライバシー・サンドボックスという技術を提案しています。サードパーティCookieや他のターゲティングに用いられた技術を機能ごとに仕様をわけます。コンバージョン計測にはConversion Measurement API，興味ベースのターゲティングにはFLoC，シングルサインオンにはWebIDといった仕組みが提案されています。

この仕様は，W3CのWeb Advertising Business Groupという，広告やパブリッシャー関連の会社が集うグループで議論されています。

2年での廃止を掲げていますが，1年近くが経過したものの，プライバシー・サンドボックスで検討されている仕様のうち，実装まで進んでいるのは少ししかありません。もともとそこまでの短期間で，カバー範囲が広い機能を実装にこぎつけるのは無理があるのではと思っていましたが，現状をふまえると少なくとも2021年中にドラスティックな変化は起こらないでしょう。とはいえ，仕様の策定や試験実装は進んでいくでしょう。