20191226 追記
SameSite属性のついたCookie自体を拒否する古いクライアントにご注意ください
https://sites.google.com/a/chromium.org/dev/updates/same-site/incompatible-clients
20190823 追記
suidenOTI さまよりご指摘いただきました
不具合があったためChrome80でのリリースに延期になったようです。
https://www.chromestatus.com/feature/5088147346030592
https://www.chromestatus.com/feature/5633521622188032
20190523 追記
Firefoxでも同様の動きがあります
https://groups.google.com/forum/#!msg/mozilla.dev.platform/nx2uP0CzA9k/BNVPWDHsAQAJ
開催中のGoogle I/O で、SameSite属性のないCookieをSameSite=Laxとして扱うようにしていくという話があったようです
blog.chromium.org
SameSite=Laxになると、img, iframeやxhrなど送信される他サイトへのHTTPリクエストにおいてthird party cookieがつかなくなります。これによって、cookieの露出を控える事ができます。(SameSite = None とすることで引き続きトラッキングは可能)
Googleの調査によると SameSite属性のついたCookieはまだ0.1%以下であり、まだまだ普及できておらず、今回デフォルトでSameSite=Laxとする動きになったのだと思います。
この挙動は、すでにChrome Canaryでchrome://flagsより設定することができます。
提案仕様
また、上記のアナウンスに続いて、IETF側でもGoogleのMike West氏より「Incrementally Better Cookies」という提案仕様が出ております。
同氏がメーリングリスト投げた「Incremental improvements to cookies.」でも書かれている通り、Cookieを段階的に改善しようとしており、この仕様では
- 1. デフォルトで、Cookieを「SameSite = Lax」として扱う
- 2. 開発者が明示的に `SameSite = None`を設定することにより現状の振る舞いのようにできるが、そうするときは` Secure`属性が必要
にするという提案である。
同氏の関連活動
Mike West氏は、Cookieに関わる多くの改善を提案している
SameSite属性の仕様自体は「Same-Site Cookies」で書かれているが、下記の記事の通り、RFC6265bisに統合される流れである
asnokaze.hatenablog.com
また、新しい仕組みも検討中であったが、フィードバックをうけCookieを段階的に改善しようという流れのようだ
asnokaze.hatenablog.com
