Safari による User-Agent 固定化と Web における Feature Detection

Intro

少し前に Safari Technology Preview 46 がリリースされた。

https://webkit.org/blog/8042/release-notes-for-safari-technology-preview-46/

Service Worker のアナウンスに目がそちらに盗まれている一方、しれっと以下の一文がある。

Froze the user-agent string to reduce web compatibility risk and to prevent its use for fingerprinting

すぐには無理だろうと思ったが、 TP47 でもこれを打ち消すアナウンスはなかったため、これを取り上げることにした。

TP はあくまで Preview であり、これが このままリリースされるとは限らない 点に注意したい。

今回は、これがそのままリリースされた場合の影響について考察するため、現在の User-Agent の使われ方を解説する。

Freeze User Agent

リリースノートの一文は、初見では何か違う意味かとも思ったが、これはやはり Safari の User-Agent を今後変更しないという意味のようだ。

Safari 開発者の Tweet で、モチベーションが補足されている。

https://twitter.com/rmondello/status/943545865204989953

STP 46 freezes Safari's user agent string. It will not change in the future. This fixes two issues:: Updating the string breaking websites sniffing for particular versions of Safari, It being used for fingerprinting. Don't UA sniff; detect features directly.

ちなみに MacOS High Sierra の Safari TP46 と Safari 11.0.2 の UA は以下のようになっている

(TP46):   User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1 Safari/605.1.15
(11.0.2): User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/604.4.7 (KHTML, like Gecko) Version/11.0.2 Safari/604.4.7

(一応その次の TP47 でも値は変わっていないが、これまで TP Update で UA が変わっていたのかは未確認)

実際の UA の用途はいくつかあるが、ここでは Tweet でも言及されている Finger Printing と Feature Detection の視点から見ていく。

Finger Printing

User-Agent 単体では大別しかできないが、そこに対して他の情報を組み合わせていけば、徐々に一意性が増してゆく。

• IP Address
• Accept-Language
• Client Hints (DPR, Width, Device Memory)
• E-Tag
• HSTS
• etc

「それが誰であるか」は特定できなくとも、それが「さっきと同じ人である」がわかれば、それだけで Tracking が可能だ。

もし 3rd Party Cookie を付与できれば確実だが、 Cookie 付与前、 Cookie 削除後、 Private Browse などでもユーザを特定したいというニーズはある。

User Metrics

サービスの Access Log や、 Analytics 系のツールでは、必ずと言って良いほど User Agent を収集しているだろう。

これは、ユーザの傾向や、サポートブラウザの決定などに使われる重要なメトリクスとなっている。

今回のように User Agent が Freeze すると、 "PC" の "MacOS" の "Safari" であることまではわかるが、それ以降の細かいバージョンまではわからなくなる。

一方で Web の仕様が Living Standard になり、ブラウザの自動アップデートが普及しつつある現在では、細かいバージョンまでを見る用途も限定されてきている。

このビジネスインパクトはそのメトリクスの用途によるが、ユーザの大まかな傾向は、どの デバイス の、どの OS の、どの ブラウザ かまでわかれば一般的な用途はカバーできそうだ。

後述するがそもそも、サポートブラウザの決定は UA を元にすべきではない。

ただし、特定のバージョンの脆弱性やバグに対して細かいハンドリングを余儀なくされるケースでは、他にそれをフックする変数がない限り難しくなる。

本来、特定バージョンの実装不備については、ブラウザ側の速やかな自動バージョンアップによって解決されるべきなので、リリースサイクルが比較的長い Safari では、そこは少し懸念がありそうだ。

UserAgent Detection

UA のもう 1 つの用途として、利用したい機能をそのブラウザがサポートしているかで分岐する Feature Detection がある。

同一実装に対する不備の場合わけとは少し違い、有無そのものを調べる用途だ。

古くは、 CSS の実装が壊滅的だった IE だけ別の CSS を返すといった用途のため、 UA を解析するといったものだ。

もっと古くは、サービスそのものが 特定のブラウザしかサポートしない といったことが、普通に行われていた。

当時 Netscape Navigator が、コードネームの Mozilla を UA に含んでおり、それを見て(Sniffing)処理を分岐していたサービスがあったようだ。

サーバ側の疑似コードとしてはこのようなイメージだ。

if (UserAgent.match(/Mozilla.*/)) {
  // Netscape 用の処理
}

すると、競合だった IE は素直に MSIE... で始まる UA を送ると、そのサービスが動作せず、ユーザに「使えないブラウザ」と認定されてしまう。

そこで、やむをえず IE も UA を Mozilla... で始まる文字として実装をした。

その後、いわゆる HTML5 期、 IE を外した Chrome や Safari のみに提供するサービス実装も登場したため、後発の Edge は UA に Chrome や Safari を含むこととなった。

現在、多くのブラウザが Mozilla... で始まり、他の実装名を含む、ぱっと見なんなのかわからない文字列となっているのは、こうした歴史的な経緯がある。

つまり、「ブラウザを識別し処理を分岐したいサービス開発者」と「そうしたサービスと互換性を保持したいブラウザベンダ」のいたちごっこが原因と言える。

こうしたことは、歴史が長いソフトウェアではよくある話だ、 Windows 9 が出なかった理由も同様の理由と言われている。

ブラウザが独自実装による差別化で戦争をしていた時代ならまだしも、今から処理の分岐条件に UA を用いるのは、あまり良い手ではない。

その時点でのブラウザが望む機能を持っていなかったとしても、リリースが進めば改善される可能性がある。

基本的に、開発者は UA ではなく、依存したい機能そのものの有無を確認し、処理を分岐すべきである 。

Feature Detection

機能の有無による分岐は Feature Detection と呼ばれ、対象機能によりいくつかの方法がある。

if (navigator.serviceWorker !== undefined) {
  // service worker supported
}

if (String.prototype.padStart !== undefined) {
  // padStart supported
}

function supportsStaticImport() {
  const script = document.createElement('script')
  return 'noModule' in script
}

function supportsDynamicImport() {
  try {
    new Function('import("")')
    return true
  } catch (err) {
    return false
  }
}

@supports (display: flex) {
  /* flexbox supported */
}

Accept-Encoding: gzip, deflate, br
Accept: image/webp,image/apng,image/*,*/*;q=0.8

// Previous Response
Accept-CH: DPR, Viewport-Width

// Next Request
Viewport-Width: 1366
DPR:1