凍結ユーザーエージェント文字列

Chromeやその他の主要なブラウザは、ユーザーエージェントの文字列をフリーズしようとしています。これは、ユーザーエージェント文字列がまだ存在することを意味します（リクエストヘッダーに表示され、 navigator.userAgentを介してjavascriptでアクセス可能です）が、ブラウザ/プラットフォーム/バージョンを検出する機能は時間とともに減少します。 Googleは、この動きはユーザーのプライバシーを保護し、指紋の認識を防ぐことであると公式に説明しました。

フロントエンド開発フィールドは常に推奨されています。ユーザーエージェントの検出を避けてください。多くのWebサイトは、ユーザーエージェントの検出を誤って使用しているため、善よりも害を及ぼします。ユーザーエージェントの検出を回避する最良の方法は、実際の要件に基づいてテストすることです。

ブラウザが特定の機能をサポートするかどうかをテストする必要がありますか？ブラウザが機能をサポートする必要があると仮定する抽象的な概念に依存するのではなく、機能を直接テストします。

JavaScriptでは、多くの機能をテストすることは非常に簡単です。APIが存在するかどうかを確認してください。

 if（navigator.geolocation）{
  navigator.geolocation.getCurrentPosition（showposition）;
} それ以外 {
  console.warn（ "ジオロケーションがサポートされていない"）;
}

CSSでは、 @supportsネイティブメカニズムを使用できます。

 @supports（display：grid）{
  。主要 {
    ディスプレイ：グリッド;
  }
}

これは、ブール値を返すJavaScript APIによって検出できます。

 css.supports（ "display：flex"）;

すべてのWebプラットフォーム機能がテストが簡単であるわけではありませんが、通常、ユーザーエージェントプロービングは必要ありません。困難に遭遇した場合、Modernizrが対応するテストを提供するかどうかを確認できます。これは、適切にテストされており、予見しない可能性のあるエッジケースを処理するため、機能テストのゴールドスタンダードです。 Modernizrライブラリを使用して、明確な論理ブランチを取得します。

 if（Modernizr.RequestanimationFrame）{
  //サポート} else {
  //サポートされていない}

ブラウザの種類、プラットフォーム、およびバージョンを本当に知る必要がある場合は、ユーザーエージェントクライアントのヒント（UA-CH）を使用できます。

たとえば、プラットフォーム情報を取得するには、リクエストにSec-CH-Platformヘッダーを設定できます。これは、理論的には応答で取得できます。これには、情報の積極的なリクエストが必要であり、それにより問題のあるプライバシーフィンガープリント認識の問題を回避します。同様に、モバイルデバイスを検出するためのSec-CH-Mobileヘッダーがありますが、これはいくつかの疑問を提起します。「モバイル」デバイスは何ですか？この情報に基づいてどのように決定を下すべきですか？

通常、サーバー側のブラウザ、プラットフォーム、およびバージョンの情報を理解することが望ましいです（さまざまな状況で異なるコードを送信します）。これはクライアント側と同じくらい重要ですが、サーバー側ではテストすることはできません。フローズンユーザーエージェント文字列は、サーバーがUA-CHの使用に移行できるように十分に長く持続できるはずです。

ジョン・アルネ・セテレスは懸念を表明した：

私は15年以上にわたってモバイルWebフィールドで働いてきましたが、大小を問わず、ユーザーエージェントヘッダーに基づいてデバイスの検出に依存している多くのWebサイトがあることを知っています。 Googleの観点から見ると、UA-CHに切り替えるのは簡単ですが、それはまさにこの変更を促進するチームがその影響を理解していない場所です。

デバイス検出ベースの機能は、フロントエンドコードだけでなく、非常に重要であり、広く使用されています。大規模なソフトウェアシステムとそのバックエンドコードは、インフラストラクチャスタック全体と同様に、デバイスの検出に依存しています。

私のメインコードベースでは、少量のサーバー側UA検出を行います。フレンドリーなAPIでUA由来の情報を公開するブラウザと呼ばれるRails Gemを使用します。私はこのように書くことができます：

 browser.safariの場合？
  ＃Safariコードエンド

また、クライアントで使用するために、クライアントにこの宝石の情報を公開します。フロントエンドとバックエンドに使用するインスタンスはわずかしかなく、これらのインスタンスは他の方法で簡単に処理されるようです。

過去には、最初のページが読み込まれたときに役立つ方法でフロントエンド情報をサーバーに戻すのは少し難しいことでした（UAがビューポートのサイズやその他の情報を知らなかったため）。非常に賢い操作を行って、スケルトンページを読み込み、ビューポートの幅と画面サイズを測定するためにJavaScriptコードの小さな部分を実行してから、Cookieを設定してページを強制的に更新しました。 Cookieが存在する場合、サーバーには必要な情報があり、これらのリクエストではスケルトンページがまったくロードされません。

これは複雑ですが、サーバーはサーバー側のビューポート幅情報を取得できます。これは、小さな画面リソース（異なるHTMLなど）を送信するなどの操作に非常に役立ちます。これは不可能です。

UA-CHを通常のクライアントプロンプトと混同してはならないため、これについて言及しました。 Accept-CHヘッダーを送信するようにサーバーを構成し、クライアントが送信される情報をホワイトリストにコードさせることができるはずです。たとえば

<meta content="DPR, Viewport-Width" http-equiv="Accept-CH">

これは、サーバーが後続のページの読み込みでクライアントからこの情報を取得できることを意味します。これは素晴らしいAPIですが、FirefoxとSafariはそれをサポートしていません。両方のブラウザがUA-CHに興味を持っている場合、UA文字列が凍結されているため、改善されるかどうか疑問に思います。

以上が凍結ユーザーエージェント文字列の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。