Totally….this was parlty what came up in our internal discussion. __Host seems like the much more powerful means of constraining things.

I guess the end point being..I'm not sure SameSite should really be mentioned in the context of a CSRF solution (even with ubiquitous browser support), since lots and lots of sites have subdomains of lesser trust.

Which begs the question...why can’t we have SameOrigin cookies 😀. Get to work @mikewest 😛.

That is part of the HTTP state tokens proposal, fwiw. speakerdeck.com/mikewest/coo… and mikewest.github.io/http-stat…

Glancing at it I’m not sure it does. I basically want the ability for foo.bar.com and bar.com to be able to opt out of all the cookie setting/sharing shenanigans without requiring separate TLD+1s.

You can kinda get part way there if you ensure every single cookie is __host prefixed. That is doable but slightly annoying. Leaking cookies to some subdomains but not all subdomains is not really doable at all today.

The fundamental tension is that cookies and domains/subdomains have this “unfortunate history” that is best resolved by picking separate TLD+1s....but brand/product/everyone but security really hates that solution.

Related, white-labeled domains (eg support.brand.tld pointing to ZenDesk) could mean auth cookies flowing to the partner site. The secure solve for cookie bleeding is to put the partner site behind a reverse proxy and strip off all cookies except those needed by the site.

Alternatively, don't do that.