HTTP/Tokyoに参加しました。この記事では発表された内容を説明するのではなく、どのような勉強会だったのかということを書きます。
会場提供は株式会社トレタさんでした。レストラン・飲食店向け予約管理システムを作っていて、その業界において日本ではシェアNo1とのことです。
Response Status codes 3xx (@haormauyraa)
今回の勉強会を企画されたあらいさんの発表です。3xx系のステータスコードの話でした。300,305,306など普段使わないステータスコードを知る機会になりました。
425 Too Early (@flano_yuki)
www.slideshare.net
TLS1.3において使われるHTTPのステータスコードの話でした。
- Early Dataの説明
- Too Earlyの説明
- 動作確認
- おまけの話
という流れで、発表の構成がよくてとてもわかりやすかったです。スライドを追うだけでも理解できると思います。おまけでは418に関わる小話で、425に関連付けて418も覚えられるような面白い話でした。
複雑なものを短い時間でわかりやすく説明できるのは凄いですね。
Cookie (@Jxck)
発表資料はありませんが、用意されたホワイトボード2つを使ってCookieに関わる話をいくつかのトピックを取り上げて全体像がわかるように説明して頂けました。@flano_yukiさんが池上彰だとしたら、Jxckさんは林修です。説明がわかりやすいし、聞いている人の質問にも周辺情報とともにさらっと答えてもはや有名予備校の講師です。（私の勝手なイメージですが🙏）
とりあげていた話題は、質問された内容も含めてざっと以下のような感じです（順不同）。
- Same origin policy
- Webの広告の仕組み
- サードパーティクッキーの廃止による問題 (シングルサインオンなど)
- Cookieの今後の話や現在の取り組み
- Cookieの属性の話 - Secure属性、Domain, Path, HttpOnlyなど
- なぜはてなブログはjavascriptを置けるのか
- 現在はトラッキングにも使われている)は別の仕組み
- サードパーティクッキーとCSRFだけ解決すればいいという話ではないこと
- HTTPSを使う現在の流れ
- httpでSecure属性を剥がす攻撃 (Cookieの範囲がゆるふわだから)
- SameSiteの話 (Strict, Lax)
- Prefixという仕様について
- Sec-Http-State
- セッション維持目的のCookieがどうあるべきか
- ReadのクッキーWriteのクッキー
- Cookeiは認証も認可もする。(Getでログアウトはfetch metadataでやればいい(ゆきさん補足))
- GitHubのクッキーはお手本になる話
- 仕様はブラウザが正しく実装されているという前提で決められている。(ブラウザを改造してつかってもセキュリティが下がるだけなど)
単純に仕様の説明ではなく経緯や具体例を出しつつ、聴者の質問にその場ですぐホワイトボードを使って答えたりしていました。そのため、Cookieに関して割と広範囲なトピックを扱ったのですが、とてもわかりやすい発表となっていました。
おわりに
技術の話をわかりやすく説明するというのは難しく割とおざなりにされてしまう印象があります。なので今回のようなわかりやすい発表はとても良いと思いました。今回の勉強会の企画者のあらいさん、発表者の@flano_yukiさん、@Jxckさん、会場提供のトレタさんありがとうございました。
発表に出てきたGitHubのCookieの使い方ですが、ググったところ下記の記事を見つけました。
私は1年半くらい前まではWebサービスを作っていたのにも関わらずSameSite属性はこないだ知りました。GitHubのエンジニアの方は3年も前にPrefixまでつけて実装していたんですね。見習いたいです。
質問できなかった気になる話
- すごく気になるのはAuthorizationヘッダーはどういう経緯でできて現在はどういう扱いなのか？（もはや要らない？JSから触れるのはどうなんだろう）
- Same origin policyではSame originじゃないリクエストはエラーで返すけど、サーバで処理は実行されてしまうみたいな感じだったような気がするのだが、どうなってたっけ...。そこらへんの歪みについてもっと知りたい。(というかSame origin policyちゃんと理解していない...調べます)
