cookieは命名で失敗し「魔術的な」技術と勘違いされてる。実際はすごくシンプル。①サーバがSet-CookieヘッダでIDを通知する、②クライアントは以降CookieヘッダにそのIDを設定する、③それによりサーバはクライアントを区別できるようになる。ただそれだけ。もったいぶってる説明はほぼ間違ってる。

TL; DR

Cookieという単語に「魔術的な」意味など元々なかったし、本来単なるデータストアである(ゆえにセッション IDも格納できる)。元ツイートの主張はおかしいし、元ツイートが腐しているspeakerdeckの内容はそんなに間違っていない。

結論として、元ツイが「現在のCookie」の話しかしていないから論点がずれている。歴史的なCookieの在り方はデータストアだった。また、現在でも一部でデータストア的に使用されている

元ツイートの主張

Cookieの機能はクライアント IDを指定・保存することだけ。他の機能はない
ブコメの指摘もあたらない(データストアではない)
Cookie(正確にはHTTP Cookie、以下同)は命名に失敗している
speakerdeckは嘘と間違いだらけの有害コンテンツ

なるほどね。それでは1つずつ見ていこう。

Cookieはクライアント IDを保存するだけのもの

現在にフォーカスを当てれば、Cookieは「基本的にセッション IDを格納する場所」と説明すれば良いが(Slideもそう書いてるよ？)、元々はデータストアである。元ツイは歴史的ファクトと現代的実装のスタンダードを混同しているように感じる。2022年に「Cookieっていうのはー、ユーザ名とか個人情報を保存しておける便利なデータストアだよ」っていうと単なるやべー奴だが、1997年から 2000年ごろまでは普通にそういった実装がなされていた。性善説の時代だったのである。

「嘘だろ」と言われそうなので、1997年のRFC2109を引用する

https://datatracker.ietf.org/doc/html/rfc2109

         POST /acme/shipping HTTP/1.1
         Cookie: $Version="1";
                 Customer="WILE_E_COYOTE"; $Path="/acme";
                 Part_Number="Rocket_Launcher_0001"; $Path="/acme"
         [form data]

普通にユーザー名とか買い物かごの中身をCookieに保存している。今この実装をする奴はヤベーが、1997年はそういう時代だったのである。

         Cookie: $Version="1";
                         session_id="1234";
                         session_id="1111"; $Domain=".cracker.edu"

セッション IDの例もあるが、なんと数字4桁である。今こんなことをしたら確実に徳丸本の角で頭を殴られる。当時のインターネットがいかに性善説の上に成り立っていたか分かるだろう。

とにかく今はデータストアじゃないんだよ

この主張も誤りである。例えばja.wikipedia.orgでは、アカウント名や利用者のおおよその住所などをCookieに仕込んでいる。セキュリティ的にザルだと思うなら、ぜひ直接殴り合って欲しい。

元ツイではMagic Cookieを「魔術的なクッキー」と解釈している(なんでも魔法のようにできる多機能な……って感じ？)ようだが、ここでいうMagicとは魔術のことではないだろう。Magic NumberとかMagic WordのMagic(利用者が理解していなくても有効なもの)と考えた方が意味が通る。これはMagic Cookieの語源となったfotune cookieの語義に通じるところもある。

fortune cookieとは。文字が書かれた紙片を封入した焼き菓子である。HTTP Cookieはクライアント・サーバとも内容について問わない(紙片に何を書いてもいい)し、捨てても無視しても構わない(食べなくても割らなくても良い)ためにこの名前がついたのだろう。任意の情報をラップしたものというメタファーとして適切に思えるし、Magicという形容詞も適切であると考える。

1つあたり容量が4kBしかないのも可愛らしい。クッキーでいいんじゃないか。逆に何だったら良かったのか。

speakerdeckの内容は有害。デタラメ

そんなに間違ったことは書いていない気がするが……。現在ほとんど使われない技術が書いてあったとして、それが何……？とはなる。Slideはaxiosの使い方を示してるだけだし、2年前の記事に対して「情報が古い」ってツッコミも微妙ではある。

総括

結局何に怒って何を否定しているのかよく分からなかった。SunのX端末を使っていたということなので、最近の事情しか知らないというわけでもなさそうなのだが。

ツリーを眺めているとあまり期待はできなさそうだが、元ツイの人はもう少し丁寧な議論をして欲しいところだ。

余談

fseekやXの実装におけるMagic Cookieについては、調べる余裕がなかった
Cookieが実装される前のAmazon(1993～)はたしかクエリ文字列でセッション IDを引き回していた

Permalink | 記事への反応(0) | 12:35

2022-05-20

■増田を完全匿名で利用する

登録時のメールアドレスはIP記録しない海外のサービスを利用

接続時にはVPN サービスを利用

追跡cookie等を利用せず増田に書き込むブラウザを分ける

これでいい。開示請求などされようが無駄無駄！

Permalink | 記事への反応(0) | 09:35

2022-05-03

■Googleのキ〇チガイ性

ずっとCookie削除せずYouTube見ていると、

途中で動画の投稿日が表示されなくなったり、

視聴者数が表示されなくなったりすること。

頭おかしいと思う。

Permalink | 記事への反応(1) | 19:51

2022-04-20

■

はてぶの画面右上の「お知らせ」ドロップダウンで、スターもらった通知部分を押すと

クリックした瞬間にURLが書き換えられてcookie的なものがパラメータに付与されるのって、前からあったっけ？

キモい挙動やめてほしい

Permalink | 記事への反応(0) | 16:19

2022-04-13

■anond:20220413162853

session.cookieのドットがどこから来たのか問題が解決しないぞ

Permalink | 記事への反応(1) | 16:38

■anond:20220413163451

だからsession.cookieがセッションクッキーなのが分かんねんだよ

Permalink | 記事への反応(0) | 16:35

■anond:20220413160429

session.cookieって書かれると「sessionのcookie」とは違うものを表そうとしているのではないかという可能性を否定できないんだよね

たとえば元増がdocument.cookieという例を挙げてるけど、これはブラウザが提供するDOM インタフェースには必ずdocumentというグローバルオブジェクトが含まれると仕様上決まっており、このオブジェクトは必ずプロパティ cookieを持つ、という前提があるからこそこれだけで通じるわけで

同じルールでsession.cookieとか書かれると、「ん？sessionなんていうグローバルオブジェクトあるの？聞いたことないけど…」と混乱する

Permalink | 記事への反応(3) | 16:23

■anond:20220413160429

セッション Cookieのことをsession.cookieとは書かないだろ

document.cookieとかwindow.sessionStorageとかブラウザが持ってるJava ScriptのAPIなのかと勘違いされてしまう

それに問題は2つあって

１．PSLに登録したドメインではcookieが使用できなくなる

２．ブラウザが期限切れになったはずのセッション Cookieをどのように扱うのか（を知らなかった）

https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies

セッション Cookie は現在のセッションが終了すると削除されます。
ブラウザーはいつ「現在のセッション」が終わったと見なすかを定義し、ブラウザーによっては再起動時にセッションの復元を使用することができます。
そのため、結果的にセッション Cookie が無期限に持続することがあります。

Baseのエンジニアはドキュメントまともに読んでないんだよ

これに2週間かかるのはさすがにアホだ

Permalink | 記事への反応(0) | 16:19

■

Cookieはブラウザ内に情報を保存する仕組み

ブラウザがウェブサイトにアクセスした際、ユーザに見えないところで使われている。

ウェブサイト側から「ブラウザさん、次からウチに来るときはこの箱持ってきてや」と頼むと、ブラウザが「おう、ほならしまっとかんとな」といって保存しておく。

ブラウザは箱をサイトごとに整理して持っておき、次に同じサイトに行くときは前にもらった箱を持っていく。

箱にはラベルがついていて、中にはデータが入っている。

Cookieは箱

CookieのKey名は箱についてるラベル

セッションは、ブラウザが持ってきた箱を見て「こないだ来た人やね」と区別する仕組み

Permalink | 記事への反応(0) | 16:08

■anond:20220413155955

なぜ我々はsession.cookieを変更しなければならなかったのか

👇

なぜ我々はセッション Cookieのキー名を変更しなければならなかったのか

👇

PSLに登録したらbase.ecでcookieを登録できなくなったどうしよう！そうだcookieのdomain属性を変更してサブドメインに保存するようにしよう！と思ったらやっぱりcookieのキー名を変更しなければならなかったよ！なぜならセッション Cookieの仕様を勘違いしてたからさ！

👇

PSLとセッション Cookieの仕様を勘違いしてはまった話

ってことですか！？

Permalink | 記事への反応(1) | 16:06

■anond:20220413153121

俺もwebは全く知らないけど、これを読んで理解する必要があるとしたらどういう手順で考えるかというと、

とりあえず頭から読んでいって、随時session.cookieとは何なのかについて頭の中で仮説を立てる
- ブラウザに紐付いてる情報かもな？なんらかのアカウントに紐付いてるのかも？サイトに紐付いてるのかも？など。
文章を読み進めながら、複数の仮説を支持または否定するエビデンスが出てくるかどうかを観察していく
- TLD, eTLDという概念が出てくるあたりで、cookieはおそらくドメインに紐づく情報なのだろうということが分かってくる。それがアカウントごとなのかブラウザ側で保持されているものなのかはわからないけど、TLDに紐付けるとセキュリティがどうこうとか言っているので、おそらく個別ユーザーで閉じないかなり広いアクセスを持ちうるグローバルな情報っぽいなという気がしてくる。
- そのあたりで、TLDやeTLDへの紐付けができないことに対してsession.cookieという話題が出てきていることから、あーなるほど、おそらくセキュリティリスクを下げるためにセッションという単位で上手くアクセスを制限したcookieの紐付けのような概念があるっぽいなという気がしてくる。
それ以上の仮説の絞り込みや確認はこの記事に書かれていることからは分からないと思われるので、上記の更新された仮説をもとに当たりをつけてsession.cookieを調べて仮説が正しいかどうかを確認する。
- https://ips.nekotype.com/2441/ ググってすぐ出てくるこの辺を見るとやっぱりその通りっぽいなと分かる。おわり。