Re: First-Party-Only cookies

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.
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.

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?)



On Thu, Jan 21, 2016 at 8:14 PM, Mike West <[email protected]> wrote:
> On Wed, Jan 20, 2016 at 11:30 PM, Martin Thomson <[email protected]> wrote:
>>
>> Wouldn't it be possible to use the first-party cookie in those cases
>> at the cost of one extra request?
>
>
> Sure. That seems like a large cost, but it's certainly one we could ask
> folks to pay.
>
>>
>> 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.
>
>
> How would you know when to do this? You'd have to do it for basically every
> incoming request, right?
>
>>
>> It's a little extra latency, but it would seem to retain the
>> properties we're looking for.
>
>
> For some value of "little" that might not actually be little.
>
>>
>> For simplicity, a same-origin redirect
>> might be permitted to gain access to first-party cookies.
>
>
> My suspicion is that the general flow would be something like this:
>
> * User gets an email with a link to `github.com/sekrit/project/pull/1`
> * User clicks on the link.
> * GitHub returns a 404 because it doesn't want to leak the fact that the
> project exists to folks who shouldn't be able to see it.
> * User is sad.
>
> Your suggestion is that the 404 page could be a 302 instead? To itself?
>
> -mike