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.

The analogy that comes to mind is this is like telling folks not to use third party library code for dependencies because of the risks. It’s 2020 and nearly nobody writes/runs every bit of software associated with running their business. This should be doable.

What would be helpful here? Would opting into `__Host-` behavior for a whole site in some way be helpful? (I have terrible ideas about how to do this with a specially-named configuration cookie set from the site’s apex domain (with host-specific overrides) that I should write up)