Google Chrome SameSite cookie ポリシー

Googleは、2020年初頭にリリース予定のChrome 80以降のユーザーに対して、デフォルトで新しいCookieポリシーの課金を開始します。 この記事では、新しいSameSite cookieポリシー、Adobe Targetによるこれらのポリシーのサポート方法、Targetを使用してGoogle Chromeの新しいSameSite Cookieポリシーに準拠する方法について知る必要があるすべてを説明します。

Chrome 80以降、Web開発者は、Webサイト間で機能するCookieを明示的に指定する必要があります。 これは、GoogleがWeb上のプライバシーとセキュリティを改善するために計画している多くのお知らせの中で初めてです。

プライバシーとセキュリティに関してFacebookが注目を浴びているという事実を考えると、AppleやGoogleなど他の主要プレーヤーは、プライバシーとセキュリティのチャンピオンとして新しいIDを作成する機会を利用して、すぐに利用できます。 Appleは、今年初めにITP 2.1を通じてCookieポリシーに変更を発表し、最近はITP 2.2を採用しました。ITP 2.1では、AppleはサードパーティCookieを完全にブロックし、ブラウザーで作成されたCookieを7日間のみ保持します。 ITP 2.2では、cookieは1日のみ保持されます。 Googleの発表は、Appleの発表ほど積極的ではありませんが、同じ最終目標を達成するための第一歩です。 Appleのポリシーについて詳しくは、Apple Intelligent Tracking Prevention(ITP)2.xを参照してください。

cookieとは何ですか。cookieの使用方法は何ですか。

Googleのcookieポリシーに対する変更点を調べる前に、cookieの種類と使用方法について見ていきましょう。 簡単に言うと、cookieは、Webブラウザーに保存される、ユーザー属性の記憶に使用される小さなテキストファイルです。

Cookieは、Webを閲覧する際のユーザーの操作性を高めるので、重要です。 例えば、eコマースWebサイトで買い物をしていて、買い物かごに何かを追加しても、サインインしたりその訪問で購入しない場合、cookieには品目が記憶され、次回の訪問のために買い物かごに保存されます。 また、お気に入りのソーシャルメディアWebサイトを訪問するたびに、ユーザー名とパスワードの再入力を強制された場合を考えてみましょう。 Cookieはこの問題を解決するものです。Cookieは、サイトが自分を特定するのに役立つ情報を保存するからです。 この種のcookieは、訪問したWebサイトで作成され使用されるので、ファーストパーティcookieと呼ばれます。

サードパーティCookieも存在します。 この例を理解したうえで、次の例を考えてみましょう。

「友達」と呼ばれる仮のソーシャルメディア会社が「共有」ボタンを提供するとします。このボタンを他のサイトで実装し、友達ユーザーが友達フィードでサイトのコンテンツを共有できるようにします。 現在は、ユーザーがニュースWebサイトのニュース記事を読み、「共有」ボタンをクリックして、自動的に友達アカウントに投稿します。

これを行うには、ブラウザーはニュース記事が読み込まれたときにplatform.friends.comから友達の共有ボタンを取得します。 このプロセスで、ブラウザーはユーザーのログイン情報を含むフレンドcookieをフレンドサーバーに送信します。 これにより、友達は、ユーザーのログインを必要とせずに、ユーザーの代わりにニュース記事をフィードに投稿できます。

これは、サードパーティcookieを使用することで可能です。 この場合、サードパーティCookieはplatform.friends.comのブラウザーに保存されるので、platform.friends.comがユーザーの代わりにFriendsアプリで投稿できるようになります。

サードパーティcookieを使用しないでこの使用事例を実現する方法を考えてみると、ユーザーは多くの手動手順に従う必要があります。 まず、ユーザーはニュース記事へのリンクをコピーする必要があります。 2つ目は、ユーザーは別々にFriendsアプリにログインする必要があることです。 次に、「投稿を作成」ボタンをクリックします。 次に、ユーザーがテキストフィールドにリンクをコピーして貼り付け、最後に「投稿」をクリックします。 ご覧のように、サードパーティcookieは、手動の手順を大幅に削減できるので、ユーザーにとって非常に役立ちます。

より一般的に、サードパーティcookieを使用すると、ユーザーがWebサイトを明示的に訪問する必要なく、データをユーザーのブラウザーに保存できます。

セキュリティ上の懸念

cookieはユーザーの操作性と電力広告を強化しますが、クロスサイト要求偽造(CSRF)攻撃のようなセキュリティの脆弱性を導入する可能性もあります。 例えば、ユーザーがクレジットカードの請求書を支払うために銀行サイトにログインし、ログアウトせずにサイトを離れ、同じセッションで悪質なサイトを閲覧した場合、CSRF攻撃が発生する可能性があります。 悪質なサイトには、ページが読み込まれたときに実行される、銀行サイトへのリクエストを行うコードが含まれている場合があります。 このユーザーは依然としてバンキングサイトで認証されるので、セッションcookieを使用してCSRF攻撃を開始し、ユーザーの銀行口座から資金移動イベントを開始できます。 これは、サイトを訪問するたびに、すべてのcookieがHTTPリクエストに添付されるからです。 セキュリティ上の懸念があるためGoogleは現在、セキュリティを軽減しようとしています。

ターゲットでcookieを使用する方法

以上に、Targetがcookieをどのように使うかを見てみましょう。 まずTargetを使用するには、サイトにTarget JavaScriptライブラリをインストールする必要があります。 これにより、サイトの訪問者のブラウザーにファーストパーティCookieを配置できます。 ユーザーがWebサイトを操作するときに、JavaScriptライブラリを介してユーザーの行動および関心データをTargetに渡すことができます。 Target JavaScriptライブラリは、ファーストパーティcookieを使用して、ユーザーに関する識別情報を抽出し、ユーザーの行動と関心データにマッピングします。 このデータはTargetによってパーソナライズアクティビティに力を与えるために使用されます。

ターゲットでも(場合によっては)サードパーティCookieが使用されます。 異なるドメインに存在する複数のWebサイトを所有し、それらのWebサイト間でユーザージャーニーを追跡する場合は、クロスドメイン追跡を利用してサードパーティCookieを使用できます。 Target JavaScriptライブラリでクロスドメイン追跡を有効にすると、サードパーティcookieを使用してアカウントが開始します。 ユーザーがドメイン間をホップすると、ブラウザーはTargetのバックエンドサーバーと通信し、このプロセスでサードパーティCookieが作成され、ユーザーのブラウザーに配置されます。 ユーザーのブラウザー上に存在するサードパーティcookieを使用して、Targetは、1人のユーザーに対して異なるドメイン間で一貫したエクスペリエンスを提供できます。

Googleの新しいcookieレシピ

Googleは、ユーザーを保護するためにCookieがサイト間で送信される際の保護を提供するため、SameSiteと呼ばれるIETF標準のサポートを追加する予定です。このサポートを追加するには、Set-CookieヘッダーにSameSite属性コンポーネントを使用してCookieを管理する必要があります。

Strict、Lax または None の 3 つの異なる値を SameSite 属性に渡すことができます。

説明
Strict この設定を含む cookie には、最初に設定されたドメインへの訪問時にのみアクセスできます。つまり、Strict は、サイト全体で cookie の使用を完全にブロックします。このオプションは、銀行など、高いセキュリティを必要とするアプリケーションに最適です。
Lax この設定を持つcookieは、HTTP GETのような、優れたHTTPリクエストを持つ同一サイトのリクエストまたはトップレベルのナビゲーションでのみ送信されます。 したがって、cookieがサードパーティで使用できる場合にこのオプションを使用できますが、セキュリティ上の利点が強化され、CSRF攻撃による被害を防ぐことができます。
None この設定を使用するCookieは、現在のCookieと同じように機能します。

上記の点を考慮して、Chrome 80ではユーザーに対して次の2つの独立した設定が用意されています。"SameSite by default cookies"と"SameSiteを使用しないcookieは、セキュリティで保護する必要があります。" これらの設定は、Chrome 80ではデフォルトで有効になります。

SameSiteダイアログボックス

  • SameSite by default cookie:設定した場合、SameSite属性を指定しないすべてのCookieが自動的に使用されま SameSite = Laxす。
  • SameSiteを使用しないcookieは、セキュリティで保護する必要があります:設定する場合、SameSite属性を持たないCookie、またはセキュリティで保護する SameSite = None 必要があります。セキュアとは、このコンテキストでは、すべてのブラウザーリクエストが HTTPS プロトコルに従う必要があることを意味します。この要件に準拠しない cookie は拒否されます。この要件を満たすには、すべてのWebサイトでHTTPSを使用する必要があります。

Google のセキュリティのベストプラクティスに従う Target

Adobe時には、セキュリティとプライバシーに関する業界の最新のベストプラクティスを常にサポートしたいと考えています。 Targetは、Googleが導入した新しいセキュリティとプライバシー設定をサポートしています。

「SameSite by default cookies」設定では、Targetは、ユーザーの影響や介入を一切受けずに、引き続きパーソナライゼーションを提供します。 TargetGoogle Chrome によってフラグ SameSite = Lax が適用されるので、 はファーストパーティ cookie を使用し、引き続き適切に機能します。

「Cookie without SameSite must be secure(同じサイトのCookieを保護する必要があります)」オプションで、Targetのクロスドメイントラッキング機能をオプトインしない場合、Targetのファーストパーティcookieは引き続き機能します。

ただし、クロスドメイントラッキングを使用して複数のドメインでTargetを利用するオプトインを行う場合、Chromeでは、サードパーティcookieにSameSite = Noneおよびセキュアフラグを使用する必要があります。 つまり、サイトでHTTPSプロトコルを使用している必要があります。 Targetのクライアント側ライブラリは、自動的にHTTPSプロトコルを使用し、TargetのサードパーティcookieにSameSite = NoneおよびSecureフラグを付加して、すべてのアクティビティが引き続き配信されるようにします。

必要なアクション

TargetをGoogle Chrome 80以降のユーザーに対して引き続き使用するために必要なことを理解するには、次の表を参照してください。次の列が表示されます。

  • ターゲットJavaScriptライブラリ:mbox.jsを使用している場合は、at.js 1。x または at.js 2.サイト をxonします。
  • SameSite by default cookies = Enabled:ユーザーが「デフォルトで同じサイトのCookie」を有効にしている場合、その影響と、作業を続けるために必要なことが何であ Target るか。
  • SameSiteを使用しないcookieはセキュア=有効:ユーザーが「SameSiteを使用しないCookieはセキュリティで保護する必要がある」を有効にしている場合、その影響と Target 継続して動作する必要がある作業は何か。
ターゲットJavaScriptライブラリ SameSite by default cookies = 有効 Cookies without SameSite must be secure = 有効
mbox.jsのファーストパーティcookieのみを使用する場合。 影響なし。 クロスドメイントラッキングを使用していない場合は影響しません。
mbox.jsでクロスドメイントラッキングが有効になっている。 影響なし。 サイトでHTTPSプロトコルを有効にする必要があります。
Target ユーザーを追跡するためにサードパーティcookieを使用し、Googleはサードパーティcookieに対して「保 SameSite = None 護」フラグを設定するよう求めます。セキュアフラグを使用するには、サイトでHTTPSプロトコルを使用する必要があります。
at.js 1.x ファーストパーティcookieを使用する場合。 影響なし。 クロスドメイントラッキングを使用していない場合は影響しません。
at.js 1.x (クロスドメイントラッキングが有効になっている場合) 影響なし。 サイトでHTTPSプロトコルを有効にする必要があります。
Target ユーザーを追跡するためにサードパーティcookieを使用し、Googleはサードパーティcookieに対して「保 SameSite = None 護」フラグを設定するよう求めます。セキュアフラグを使用するには、サイトでHTTPSプロトコルを使用する必要があります。
at.js 2.x 影響なし。 影響なし。

ターゲットは何をする必要がありますか。

新しいGoogle Chrome 80+ SameSite cookieポリシーに準拠するために、アドビのプラットフォームで必要なことは何ですか?

ターゲットJavaScriptライブラリ SameSite by default cookies = 有効 Cookies without SameSite must be secure = 有効
mbox.jsのファーストパーティcookieのみを使用する場合。 影響なし。 クロスドメイントラッキングを使用していない場合は影響しません。
mbox.jsでクロスドメイントラッキングが有効になっている。 影響なし。 Target サー SameSite = None バー呼び出し時に、サードパーティcookieにセキュリティ保護フラグを追加し Target ます。
at.js 1.x ファーストパーティcookieを使用する場合。 影響なし。 クロスドメイントラッキングを使用していない場合は影響しません。
at.js 1.x (クロスドメイントラッキングが有効になっている場合) 影響なし。 at.js 1.x (クロスドメイントラッキングが有効になっている場合)
at.js 2.x 影響なし。 影響なし。

HTTPSプロトコルを使用する場合に先に進まないと、どのような影響がありますか。

影響を及ぼす唯一の使用例は、Targetからmbox.jsまたはat.js 1までの間で、クロスドメイントラッキング機能を使用している場合です。x では、標準設定ではサポートされていません。Googleが必要とするHTTPSに移動しないと、Googleが使用するサードパーティCookieがGoogleによって破棄されるので、ドメイン間の実訪問者にスパイクが発生します。 また、サードパーティCookieが破棄されるので、ユーザーがドメイン間を移動する際に、Targetは、そのユーザーに対して一貫性のあるパーソナライズされたエクスペリエンスを提供できません。 サードパーティCookieは、主に、所有するドメイン間を移動する単一のユーザーを識別するために使用されます。

まとめ

Adobeは、業界がより安全な消費者向けWebを構築するために努力しているので、エンドユーザーのセキュリティとプライバシーを確保する方法で、お客様がパーソナライズされたエクスペリエンスを提供できるよう支援することに全力を尽くしています。 必要な作業は、前述のベストプラクティスに従ってTargetを利用し、Google Chromeの新しいSameSite Cookieポリシーに準拠することだけです。

このページ