Re: First-Party-Only cookies

On Fri, Jan 22, 2016 at 12:43 AM, Martin Thomson <[email protected]> wrote:

> Hmm, it's tricky, I agree.  If the goal is to prevent side-effects
> from top-level loads being exploited, then that where things end up.
>

For the developers I've explicitly talked to, POSTs have been the problem
and they're happy to have a GET carveout.


> Unless you want to specially privilege top-level loads.  You might be
> able to do that automatically for URLs that are provided to the
> browser from other applications, or from the URL bar, but that doesn't
> help webmail much.
>

Yeah, I've made that explicit in the current draft: address bar typings are
"same-site".

An option might be to have the 404 page have all the (public) script
> content for the type of page and to fetch() in any privileged content
> (and get 404s on those fetches).  That would result in a round trip
> worth of delay for those loads.  More complicated to implement,
> granted.
>
> The self-redirect in absence of cookies is easier to implement, but
> fairly clunky.  You would have to set a short-term (first-party)
> cookie to avoid looping too.
>
> I'm not enamoured with the idea, but it's not like sites aren't opting
> in to this sort of complexity by tagging their cookies as same-site (I
> should stop saying first-party now, right?)
>

The nice thing about the current definition is that it can easily layer on
top of existing session management systems. That is, folks like GitHub can
add `SameSite` to their session cookie, and basically everything just works
(or, just worked, a year ago when they were experimenting with me).

Excluding GET would make that more difficult, but would certainly improve
security. That's basically why I'm now leaning towards something like
`SameSite=Lax`, which would allow a stepwise improvement in CSRF protection
over time.

-mike