00:04
はい、9月21日水曜日ですね。地獄は朝9時を回りました。
えーと、台風はだいぶ影響したのかな?
だいぶ、まあ曇ってありますけど、全然雨も降らなくなったなって感じです。
こちらは東京ですけどね。はい、おはようございます。
ひめみのきーすことくわはらです。
では、本日も朝活を始めていきたいと思います。
えーと、今日はですね、何を読むかまだいろいろ探ってたんですけど、
また、気になったクッキーの話ですね。
3rd Party Cookieの話の記事を見つけたので、
やっぱりこの辺はウェブエンジニアとしては知っておかなきゃなっていう思いもあって、
読んでいこうと思います。
はい。
更新ですね、2023年に受けたGoogleの方のブログがあって、
そこの記事のリンクも貼られてたんですけど、
すでに新しいやつですね。
The Second Half of 2024っていうのがあって、
2024年の前半の方か、セカンドなので後半か、
の目標というか、想定のブログ記事も更新されたりするので、
その辺も含めて読んでいこうかなと思っております。
はい、ちょっと9時10分と時間が過ぎてしまったので、
今日はちょっと時間、後ろ倒しになってしまう感じですね。
はい、では早速入っていきたいかなと思います。
えー、改めて、
New Recipes for 3rd Party Cookiesっていうところですね。
じゃあいきましょう。
プライバシー保護の観点から、
Web プラットフォームは3rd Party 製クッキーのサポートから脱却し、
まずロックダウンを行い、最終的には2023年の後半から
2024年後半にサポートを終了する予定ですというふうに言ってます。
はい。
これ前日してましたね。
いろんな、僕もWebとかTwitterから情報を得たんですけど、
配信の想定が2023年後半から2024年の後半になったっていうところは、
別の記事のリンクも、
浅瀬どっかで読んだ気もしますね。
っていうふうになってそうですね。
はい。
お話から具体的なところに入っていこうと思いますが、
まずは背景ですね。
バックグラウンド。
What does 3rd Party mean? っていう意味ですね。
3rd Party Cookieの意味ってのはまずそもそも何ですかってところからです。
3rd Party CookieとはWebページ上の3rd Partyコンテキストから
設定または送信されるクッキーのことですよと。
クッキーの説明はちょっと今回割愛します。
調べていただけると出てくると思いますので、
皆さんちょっと調べてください。
3rd Partyコンテキストとは、
登録可能なドメイン、ETLプラスワンと呼ばれることもあります。
EのTLDプラスワンと呼ばれたりするんですね。
登録可能なドメインがトップレベルページのものと
異なるフレームまたはリソースのことですよと。
それを3rd Partyコンテキストと呼ぶらしいです。
これはクロスサイトと呼ばれることもあります。
はいはいはい、なるほど。
クロスサイトね。
一応一枚画像が貼ってますけど、
例としてですね。
03:01
http://domain1.com//page1.htmみたいなのがファーストパーティですねと。
その下にiframeでhttp://domain2.com//subframe.htm
これが3rd Partyです。
あとはイメージ画像ですね。
イメージ画像はhttp://domain3.com//tracker.gifみたいなやつ。
これも3rd Partyと呼ばれたりします。
こんな例を今回画像が貼ってました。
今言った通り、
http://domain2.comとhttp://domain3.comというのは
http://domain1.comが提供する親ページに対するクロスサイトの3rd Partyです。
対象的に、
http://sub.domain1.comからのリソースはクロスオリジンですが、
http://domain1.comへの同一サイト、つまり第一頭ですよということは言ってますね。
はいはいはい。
クロスオリジンとクロスサイトという別の話の関連をちょっと述べてましたね。
よくやりますよね。
webページの中にiframeとかあったりとか、
別のドメインからの画像ですね。
例えばs3に画像置いておいて、画像だけはそこから取りに行くとか。
結構やりますね。
そういう時はクロスサイトのアプリケーションということになりますね。
親のドメインと別のドメインですから。
サブドメインの時の方は、
同一サイト、第一頭にはなるんですけど、
いわゆるファーストパーティーにはなるんですけど、
クロスオリジンという形になるそうですね。
重要なのはドメイン2.comとドメイン3.comからのフレームまたは画像というのは、
ドメイン1.comのクッキージャー、
クッキージャーってなんだ。
クッキージャー、クッキージャーってなんだ。
あ、ほんまクッキージャーって書いてますね。
これちょっとまず僕がわからない。
クッキージャーってのがあるんですね。
のクッキーを見たり変更したりできずですね。
ちょっともう一回行こう。
重要なのはドメイン2.comとドメイン3.comからのフレームまたは画像というのは、
ドメイン1.comのクッキージャーのクッキーを見たり変更したりできず、
ドメイン1.comで実行中のスクリプトというのは、
埋め込まれたドメイン2.comまたはドメイン3.comコンテキスト用のクッキーを見たり設定したりできないよっていうことですね。
はいはいはい。
実行中のスクリプトは埋め込まれたドメインコンテキスト用のクッキーを見たり設定はもちろんできないよってことを言ってます。
はい、了解です。
まあでもそれはクッキーの、そもそもの仕様からしてそうですよねって感じ。
さらにもう既にスクリプトも実行されてるんであればまさにそうですよね。
他のクロスサイトのクッキーは見ることはできないと。
または設定もできないということですね。
今のが一応背景の一つ目。
What does third-party mean?ですね。
はい、third-partyってそもそも、
third-partyクッキーってそもそも何ですか?みたいなところのお話でした。
続いて背景もう1回、もう1個続きますね。
バックグラウンド、existing restrictionsですね。
リストリクションですね。神々やな。
リストリクションですね、はい。
既存の制限というところです。
はい、いきましょう。
まず問いが投げられてますね。
06:00
9ですけど、なぜプライバシー保護団体はthird-partyクッキーを心配するのですか?
というふうにおっしゃったんですね。
で、アンサーとして、なぜなら、
それらは特定のユーザーのウェブ上での閲覧を追跡する簡単な方法だからですと。
まあそうね、はい。
ちょっと我が家の目の前で言います。
早速救急車と消防車がうるさいですね。
じゃあ戻ります。
なぜ保護団体はthird-partyクッキーを心配するかは、
特定のユーザーのウェブ上での閲覧を追跡する簡単な方法ですよと。
例えば、無関係なサイトの束というのが、
広告サーバーからの広告を含むとしましょうと。
広告からのコンテンツに設定されたthird-partyクッキーによって、
その広告サーバーはユーザーが訪問したサイトのセットというのを識別することができますと。
例えばユーザーが訪れた3つのページを考えてみましょうというところで、
今3つの画像が貼られていますね。
一個一個いきます。
1つ目の画像はユーザーが、1つ目のサイトになるんですけど、
https://runnersworld.comみたいなサイトですね。
これはまだfirst-partyです。
その中にイメージが貼られているとして、
そのイメージのドメインはhttp://domain3.comの何たら.jpgみたいなのがあるんですね。
これはthird-partyです。
third-partyクッキーはユーザーID、コール、ほげほげみたいなやつで設定されているとしましょう。
2つ目のサイトは別のURLですね。
https://何たらかんたらでやってますけど、
3つの画像を今比較したんですけど、要は別々のサイトですね。
3つの別々のサイトに行きます。
それはもちろんドメインは違います。
それぞれのドメインはfirst-partyです。
ただその中に埋め込まれている画像は全部同じところを見に行ってるって感じですね。
third-partyの画像は全部同じですし、
クッキーの値もユーザーID、コール、ほげほげって値は全部一緒だと。
あとはそういう条件をしたとしましょうというところですね。
この場合の説明が続きますね。
この場合、広告主っていうのは自分の広告が
スタートレックのウェブサイトに流れていることを知るだけでなく、
この特定のユーザーが以前にランニングや薬に関連するサイトをずれたことも知ることができるため、
訪問者がプライバシーの侵害とみなすかもしれない方法で
広告をターゲットすることができますと。
あー、なるほどですね。
結局ユーザーが同じようなものを見てるねっていうのを
いろんなサイトで流れてるんだから、
全然関係ないところでレコメンデーションすることができるってことですね。
まあまあ、プライバシーの侵害とみなされたらそうかもしれないですね。
このため、ブラウザーっていうのは何十年も前から
third-partyクッキーの制御をサポートしてきましたが、
通常はデフォルトでオフになっているか、
もしくは簡単にバイパスされるものでしたと。
で、最近では全てのクッキーをデフォルトで
same-site="lux",ですね。
に対する2020年の変更を含め、
ブラウザーはオンバイデフォルトの制御と制限を導入し始めていますよと。
しかしこれらの制限のいずれも将来的に
ブラウザー号になるようになる範囲には及びませんという風に言っています。
09:02
あー、なるほどね。
まあまあ、いろんなところの制限とか制約とか
条件とかがあるかもしれないので、
それは今後どうなるかちょっとわからないですけどね。
はい、今のところ現状はそんな感じです。
割とthird-partyクッキーについていろいろ見直しが図られていますけど、
将来的にブラウザーが行うようになることの範囲には及ばないよという話をしていました。
まあまあ、いろんな記事のリンクが貼られていますね。
バイパスの話もそうですし、コントロールとか制御の話もそうですし、
さっき言ったsame-site="lux",の設定がバイデフォルトになっていますよとか、
その辺の記事のリンクも貼られていますので、
それぞれ見てくださいという感じです。
今日こそちゃんと後ほどこの記事をツイートしますので、
後ほど見てもらえればと思います。
続いていきましょう。
フルメニューofreplacementsですね。
だいたい品のフルメニュー。
だいたい品と訳されてあるけど、品じゃない気がしますけどね。
何十年にわたってthird-partyのクッキーの上に構築されてきたシナリオをサポートされるには、
新しいパターンと技術が必要ですよねという話の展開がここからされるそうですね。
いくつかのレシピがここで来るそうです。
一つ目ですね。
The Easy Recipeということで、簡単なレシピですね。
チップスですけども。
このチップスからいきましょう。
2020年、クッキーというのはデフォルトでsame-site="lux")にされ、
third-partyのコンテキストで設定・送信されるクッキーをデフォルトでブロックするようになりましたよと。
third-partyの文脈では、まだクッキーの設定を必要とするウェブ開発者の回避策はもちろん単純になりました。
クッキーが設定されるとき、属性same-site="none")を追加すると新しい動作が無効になり、
クッキーが自由に設定・送信されるようになります。
この2年間でクッキーを起因するほとんどのサイトがその属性を送るようになりました。
これGoogleちゃんと調査したんでしょうけど、そんな感じなんでしょうね。
same-site="none")で結局上書きをしていると皆さん。
チップスの提案です。
独立したパーティション化された状態を持つクッキーですね。
というのをチップスの提案として入れているそうです。
それは何かというと、新しいしかしより設定された逃げ道を提供します。
開発者は自分のクッキーをパーティション化して、それがもはやthird-partyクッキーではなく、
その代わりにパーティション化されたクッキーであるということを選択することができるようになります。
例えばさっき見てたrunnersworld.comみたいなサイトに埋め込まれた
domain3.comのコンテキストで設定されたパーティション化されたクッキーというのは、
他のドメインですね。
startrek.com内に埋め込まれたdomain3.comのコンテキストでは見えません。
同様にgas-x.comという別のドメインですね。
に組み込まれた同じドメイン、domain3.comのコンテキストでクッキーを設定しても、
他の2つのページでのクッキーの値には影響はしません。
ユーザーがトップレベルのブラウザのナビゲーションとしてドメイン3.comを訪れた場合、
12:02
他のトップレベルページのコンテキストでそのオリジンのサブフレームに設定されたクッキーは
アクセスできないままとなります。
これが望んでいたクッキーの制御ですよね。
smsite-luxが倍増でよくなったし、その辺のところができるようになったということですね。
今のが一応先ほど述べた3つの画像の使い方の話ですね。
それぞれのサイトで別々のクッキーの値が設定されていれば、
それは全然アクセスすることができないよということを言っていますね。
続いていきますけれども、
新しいパーティション属性の使い方は結構簡単で、
set cookie headerに次のように追加するだけですよと言っています。
set cookieに--hostの-id、
パーティションドゥという属性を付けてあげると。
これだけでいいらしいですね。
あとはsamesite="none")にしたりとか、
セキュアを付けたりとか、
path="/.みたいないつも通りの設定をヘッダーに付けてあげればいいよという話でした。
割と簡単ですね。パーティションドゥを付ければ。
皆さんは結構そういうのを使っていたっぽいですね。
で、chipsのサポートというのにまた戻りますけど、
サポートというのは全ての主要なブラウザにわたって後半にわたることが期待されています。
私は当初ですね、新しい属性を明示的に指定することを
作者に要求することに少し懐疑的でした。
まあまあまあ、使う人によってまちまちだから
オプションとして設定できるようにしてるってのは正しいけど、
この方は一応最初は疑問だったらしいですね。
サードパーティーのコンテキストにある全てのクッキーを
パーティションとして扱わないのでしょうか?っていうところですね。
なんでそんなことをやらないの?っていうところだったんですけど、
最終的には明示的な宣言が望ましいとする議論に賛成するようになりました。
現状ではレガシーアプリケーションというのはすでに
same site equal none宣言で更新される必要があります。
したがってもしこの属性を要求しなければ、
明示されていないレガシーアプリケーションを動作させることはできないでしょうと言っています。
はあはあはあ、逆に言うとそういうところへの
理解が深まったって感じなんですね。
うーん、はい、今のが一つ目の簡単なレシピでしたね。
はい、とにかくsame site equal noneで設定してあげれば、
上書きしてあげれば基本的にはクッキーを自由に送ることができますよと。
ただ別のドメインで使われている同一ドメインの画像とかの方に設定されたクッキーというのは
別に他のサイトでは影響しないのでそこは問題ないよって話をしていますね。
続いてexplicit recipeですね。
ちょっと別のアクセスですけど、
ストレージアクティブAPIというところが次のレシピだそうです。
はい、いきましょう。
ストレージアクセスAPIってこれもリンクが貼られてますね。
そもそもストレージアクセスAPIってなんぞやって感じはしますけど、
モジュラーに載ってますね。
ハズストレージアクセスっていうモジュラーのリンクが貼られてました。
ストレージアクセスAPIっていうのは
ウェブサイトがサードパーティーのコンテキストで
ストレージを使用する許可を要求することを可能にしますと。
はあはあはあ、許可を求めることを可能にしますと。
15:03
マイクロソフトエッジは
ブラウザのトラッキング防止機能の影響を緩和するメカニズムとして
2020年にこのAPIをサポートするSafariとFirefoxにも加わりましたと。
同じ流れに載ってたってことですね。
逆に言うとSafariは最初からそれを入れてたんですね。
意外とSafariってウェブのことをちゃんと見てたんだな。
ストレージアクセスAPIは多くの利点がありますが、
主要なブラウザが普遍的にサポートしていたため、
ゲーム上ではスラムダンクとは言えませんと。
スラムダンクとは言えないという言い方が面白いですね。
要は全部ブラウザではちゃんとやってるわけではない。
しかも普遍的にサポートしてるわけではないので、
ぶっちゃけるとあんま使えないよねって話かな。
まあでもこんなのがあったんですね。
ストレージアクセスAPIっていうのは。
全然知りませんでした。
こういうところがやっぱり技術力って感じしますね。
反省します。続いていきましょう。
続いてのニッチレシピですね。
ファーストパーティーセッツっていうようなレシピが
次のレシピだそうです。
場合によってはクッキーがサードパーティーとして扱うことは
法律または組織的なものというよりも
技術的な制限を意味します。
例えばマイクロソフトはxbox.comとかoffice.com
teams.microsoft.comを所有してますけども、
これらのオリジンは
共通のETLD1を共有しておらず
これらのサイトからのページは互いに
クロスサイトのサードパーティーとして扱われることを意味しています。
ETLD1ってどこか説明がありましたね。
冒頭にありましたけど、いわゆるセームサイトのことですね。
セームサイトの名前を
レジストレーブドメインですね。
登録されたドメインっていう風なことを
ETLD1と言ったりするらしいです。
失礼しました。
マイクロソフトは今言ったxboxとかofficeとか
teamsのドメインに対して
オリジンは今日共通のETLD1を
共有しておらず
これらのサイトからのページっていうのは
互いにクロスサイトのサードパーティーとして扱われることを意味しています。
ファーストパーティーセッツの提案っていうのは
単一のエンティティによって
所有運営されているサイトが
プライバシー機能に関してはファーストパーティーとして扱われることを
可能にしますよと言ってます。
もともと新しいクッキー属性であるセームパーティーっていうのは
クロスオリジンのサブリソースのコンテキストが
トップレベルのオリジンと同じ
ファーストパーティーセットにある場合に
サイトがクッキーを含めることを要求できるようにしていましたが
最近の提案ではこの属性が削除されています。
タイトル通りニッチレシピっていう感じなので
こんなことやったことないなっていう感じでした。
セームパーティーってのがあったんですね。
言った通りですね。
サードパーティーで扱われるというよりは法的または組織的な
18:00
技術的な制限をするっていうような
ニュアンスは確かにそうだなと感じましたね。
ファーストパーティーセッツっていうところで
単一のエンティティによって所有運営されているサイトが
ファーストパーティーとして扱われることを可能にしたということですね。
いろんなドメインとか
いろんなプロダクトを持っている大きい会社さんが
それぞれのドメインで展開をしているという場合には
適用できるという感じはします。
その時のクッキーの扱いっていろんな制限があったりするので
MSはそのセームパーティーか
ファーストパーティーセッツっていうのを一応使っていたらしいですね。
なるほどでした。
続いてのレシピですね。
The Authentication Recipeですね。
この辺が現実界っぽい気がしますけど認証のレシピですね。
FedCMAPIというのがあるそうです。
また知らない名前が出てきた。
3年前に説明したように認証っていうのは
サードパーティークッキーの重要なユースケースですが
サードパーティークッキーに対するブラウザの制限によって
妨げられていますと今は。
Federated Credential Management API
これがFedCMAPIってことですね。
Federated Credential Management API
っていうのは
ブラウザとウェブサイトが協力して
参加ウェブサイトにおけるユーザーのログイン状態を
ブラウザに認識し制御できるようにすることを意味しています。
クッキーの説明文にあるように
私たちは以下の条件が全て当てはまる場合にのみ
FedCMがあなたにとって有用であることを期待しています。
3つありますね。
1つがIDプロバイダーであること。IDPですね。
2つ目がサードパーティークッキーの段階的配信の影響を受けています。
3つ目があなたの信頼当事者というのが
サードパーティーであることということですね。
FedCMっていうのは大きく複雑でかつ重要な仕様であり
もっぱら認証シナリオを解決することを
目的としていますというところでした。
全然ちょっと使ったことがなかったんですけど
FedCM APIというのがあるんですね。
こちらの記事もリンクが貼られていまして
これはですね、Google.comですね。
Developer.google.comのブログに飛ばされるそうですね。
これはちょっと気になったので
明日もしかしたら読むかなと思いますね。
ではでは戻りましょう。
この記事長いな。もうちょいで。
今日ですね、僕の開始が10分遅れたので
10分後ろ倒しになる予定ですので
もし時間が来た方は全然抜けていただいていいと思います。
コンプレキシティ・アバンダンスですね。
複雑な問題が山積みになってますよって言ってます。
サードパーティークッキーのサポートからの脱却っていうのは
ウェブサイトの構築方法に大きな影響を及ぼします。
望ましいシナリオの互換性を維持しながら
望ましくないシナリオ、トラッカーのサポートを有意義に中断する
ということは本質的には非常に困難ですよ。
私はこれを乗客でいっぱいの飛行機が
21:02
飛行中に旅客機のエンジンを交換しようとすることに
似ているなというふうに例えています。
なかなかそのぐらいの影響がでかいものなんですね。
クッキーだからそうなんですけど。
ウェブにおけるクッキーっていうのは
飛行中の旅客機のエンジンとこの人は捉えていると。
ちょっと面白いな。そういう捉え方を僕は初めて聞いたので。
では行きましょう。
コンビナトリックスですね。
コンビナトリックスってなんだ?
僕が分からないですね。
コンビナトリックス。
辞書で調べたら何も見つかりませんでしたと書いてある。
A単語あるんだろうな。
すみません戻ります。
サードパーティークッキーの削除に対処するための
新しいアプローチを追加するとき
それらがすべてどのように相互作用するかを
慎重に検討する、推論する必要がありますと。
例えば使用っていうのは
chipsだったり、ファーストパーティーセットだったり
ストレージアクセスAPIの動作がどのように交差するか
っていうのを定義する必要があり
ウェブ開発者はブラウザーが新機能の一部しかサポートしない場合を
考慮する必要があります。
既存の機能との連携性だったり関わりっていうところを
ちゃんと定義できてる方に結構重要ですよね。
続いてなぜか知らないけど
翻訳されない。
そんなことあります?
英語を日本語に翻訳してほしいんだけど
なぜか翻訳されない。
僕は英語がわかんないんだよな。
いやマジでなんでだ。急にバグった。
DeepAさんたまに翻訳してくれる時があるんだよな。
英語のまま残される時があったりして
これはなんでだろうなって感じがします。
えー、ちょっと待ってよ。
そしたらですね、切り取ってみよう。
切り取ってもあかん。
Cookie is not the only type of storage.
クッキーっていうのは
たった一つのストレージのタイプではないよってことを
言ってますね。
このまま自分が訳しながら読むのは苦手なんだよな。
他の複雑さっていうのがあって
それは何かっていうと
クッキーっていうのは唯一のフォームストレージ
インデックスデビとかローカルストレージとかセッションストレージとか
あとホゲホゲみたいなやつですね。
っていうものではなくて
24:00
and various other cookie storageだっていう風に言ってます。
クッキーライクなストレージか。
クッキーライクな全てのストレージのようなものですよと言ってますね。
すでにwebプラットフォームに存在している
クッキーライクなストレージのようなものだという風に言ってますね。
クッキーライクストレージってところにまた記事のリンクが貼られていて
これは全然別の記事ですね。
MDMじゃなくて全然知らないサイトの記事です。
ただ2018年の記事なんでちょっと古いんですけど
この辺の仕様はあんま変わってないんでしょうねっていうので
読んでもいいかもしれないですね。
続いていきましょう。
このままだと時間かかるんで
動いてはいるけど
この翻訳だけなぜか翻訳されないと
全部英文で書いてきやがったな
このままちょっと読んでいこう。
onlyですから
唯一のクッキーにリミティングを制限すること
without accounting for other forms
他のフォームへのアカウントを
考慮することなしに
唯一のクッキーに制限すること
我々が望むようなプライバシーに
サイトを持っていくことはできないでしょう
That said, cookies are one of the more interesting forms of storage when it comes to privacy as they do.
これはどういうことを言っているかというと
クッキーっていうのは
より面白い、興味深いフォームだと
ストレージのより興味深い
フォームだっていう風にクッキーを言ってますよと
when it comes to privacy
それはどういうことかというと
4つぐらい書かれてますね
この4つだけでも翻訳してくれたらすごく嬉しいんだが
訳されませんでした
pageを読み込む前にサーバーに送られることができるというのが一つと
JavaScriptを許可することなしに
オペレート、運用することができるということですね
あとは
context exist
存在する既存のコンテキスト
上はnoだから
ノースクリプトエクセクション
スクリプトの実行なしに
27:00
イメージエレメントのようなケースで運用することもできるよと
あとはエトセトラでいろんなこともできますよとおっしゃってますね
なそうです
続いて本文は
続きはクッキーザースペシャルと言ってますね
急にここで翻訳戻ったな
クッキーは特別だとおっしゃっています
クッキーからシナリオを移行することのもう一つの共有回転というのは
長年にわたって追加されてきた巧妙な機能のいくつかを失うことだと言ってますね
長年にわたって追加されてきた巧妙な機能のいくつかを失う
そのような機能の一つは
httponly宣言でクッキーがJavaScriptからアクセスできないようにしますと
この機能はクロスサイトスクリプティング攻撃の影響を鈍らせるために設計されました
侵害されたページに注入されたスクリプトが
クッキーを読み取ることができなければ
そのクッキーは遠隔の攻撃者に漏れることはまずありませんよと
攻撃者はXSSを受けたページを直ちに悪用することを余儀なくされ
ソックパペットとかブラウザーとかそんな感じですね
この辺の記事のリンクを貼られてます
実行可能な攻撃の処理が制限されることになりますよと
これはいい話ですね
IDプロバイダーによって認証トークンを
httponlyクッキー経由のみか
送信する、伝送することを要求し
認証トークンをJavaScriptで直接利用できなければならない場合
プロバイダーというのは有効期間を大幅に短縮して
そのトークンを駐属しますと
例えば1週間の代わりに1時間だけにしてしまうとかですね
クッキー1時間にして持ってしまえばそれはそうでしょうけど
なかなか短いですね
もう一つのクッキーの機能っていうのは
TLSトークンバインディングで
これは感染したPCからのトークン盗難攻撃を防止しようとする
不明瞭な機能になりますと
マルウェアや悪意のある内部者が
トークン結合されたクッキーデータをPCから直接盗んだ場合
そのクッキーデータというのは
他のデバイスからは機能しませんと
なぜならクッキーを認証するのに使われた
秘密鍵の材料は侵害されたクライアントデバイスから
エクスポートすることができないからですね
この非エクスポート性の特性というのは
通常TPMのようなセキュリティハードウェアによって制御されています
トークン結合というのはクッキーに協力で
ユニークな機能を提供しますが
様々な理由によりこの機能は
広くサポートされていませんよということでした
なるほどね
セキュリティ観点ではかなり強そうな機能なんですけど
今はあんまりサポートされていないですね
ちょっと辛いなって感じはしますけど
でラストですね
最後
サードパーティークッキーの非推奨は
やっぱり万能じゃないよということですね
残念ながらサードパーティークッキーを廃止しても
トラッキングがなくなるわけではないですよと
ユーザーを追跡する方法というのは明白なもの
あなたのサイトにログインしているとか
ユニークなIPアドレスを持っているから
不明瞭なもの
様々なフィンガープリントのメカニズムまで
数多くありますと
30:01
しかしサードパーティーのクッキーを廃除することは
ブラウザメーカーがプラットフォームに
プライバシーサンドボックスを組み込むための
貴重な一歩となりますと
ウェブプラットフォームの
プライバシー空間というのは魅力的な時期で
これがどのように解決されるかというのが
私はちょっと欲しいですよという風に
述べられてこの記事は締められております
というところでした
はい、というので一応この記事は以上になります
いろんなレシピがあったし
確かにいろんなやり方もあってそうなというのと
全然知らなかったというレシピもあって
勉強にはなりましたけど
結局まだ物事は解決しないというのはありますし
サードパーティークッキーの戦いは
まだまだ続くなというのはありますね
一応その完全なる廃止が
来年の後半ではなくて
2024年の後半だということが
言及されているので
そこまで一応猶予はあるんですけど
そのままどんな解決策というか
どういうところに着地をするのかという
更新をまだまだ待ちたいなというところですね
はい
という感じでちょっと遅くなりましたし
途中DeepLさんが動かなくなって
完全にグダグダな感じになってしまって
申し訳なかったですけど
一旦今日の記事はこれでしょう
朝方は終了しようと思います
サードパーティークッキーの話は
Webエンジニアとしては
特にこのままずっと続けるし
サード側による人間はクッキーとはほぼほぼ
お付き合いしていかなきゃいけないので
しっかり今後も追っていきたいと思いますし
クッキーのお話、更新出たらまた改めて
逐一読んでいこうかなと思っていますので
まあまあ
ちょっと更新を待ちましょうという感じですね
では
今日の朝方はこちらで以上にしたいと思います
今日も参加していただきました
多くの方が大変にありがとうございました
明日はもうちょっとJS周りの方の
記事を読もうかなと思います
最近ちょっと俯瞰的な視点での
記事が多かったので
もうちょっとテクノロジーによった記事も
たまには読みたいなと思うので
その辺読んでいこうかなと思いますので
ゆるりとご参加いただければ幸いです
では終了したいと思います
今日も一日頑張っていきましょう
お疲れ様でした
