Re: First-Party-Only cookies

Wouldn't it be possible to use the first-party cookie in those cases
at the cost of one extra request?

The third-party initiated, top-level load would have no first-party
cookies, but that page could initiate a new request to check
credentials, which would have the first-party cookie.

It's a little extra latency, but it would seem to retain the
properties we're looking for.  For simplicity, a same-origin redirect
might be permitted to gain access to first-party cookies.

On Wed, Jan 20, 2016 at 10:59 PM, Mike West <[email protected]> wrote:
> 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
>