Re: First-Party-Only cookies

Thanks for starting this thread, Mark. I'll reply to some of the questions
inline, but I'll first note that I'm working on an -05 draft which might be
helpful in terms of clarifying the mechanism under consideration at
https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-05.html.
That should make the Fetch story clearer, and hopefully address Anne's
question about workers (it also renames the feature to "SameSite", for
reasons that aren't worth getting into here).

Broadly, the "safe" top-level navigation carveout is meant to deal with the
confusion that might otherwise result from an auth cookie not being present
for a request. Since GitHub is the only implementation I know of, let's use
them as an example: it would be confusing if I clicked on a link to a
private repository in an email, navigated to GitHub.com, and got a 403
error telling me I wasn't logged in. Likewise, it would be strange if I
popped up a window as part of a "Sign in with GitHub" OAuth dance and had
to sign in every time.

They certainly _could_ rewrite their session management system to deal with
multiple cookies granting different levels of access (just as Amazon
requires reauth to actually buy things), but based on some conversations,
they're more likely to simply not use the feature than to undertake that
rewrite.

At the moment, I'm thinking that it might be reasonable to have the
carveout as an option; `SameSite=Lax` or something. I've been reluctant to
do so, as I'm not sure the extra complexity is worth it, but if folks like
GitHub wouldn't use the strict form of the feature, then such an option
starts sounding more reasonable.

On Wed, Jan 20, 2016 at 2:53 AM, Tanvi Vyas <[email protected]> wrote:

> I believe the intention here is to prevent sites that use safe methods for
> state changing actions from depending on the First-Party-Only flag for CSRF
> protection.


For clarity, this isn't the intention of the carveout. The spec plainly
states that this feature constitutes defense in depth, on top of a already
robust CSRF protection. If we decide, however, that the carveout should be
removed (optionally), then I certainly wouldn't block that decision based
on the fact that some developers might mistakenly rely on it too heavily.
We should give developers sharp tools. *shrug*

-mike