Re: Cookies Settings Observations

Hi, Mike (this won't get confusing at all! :) )!

On Wed, Jan 28, 2015 at 2:34 PM, Mike O'Neill <michael.oneill@baycloud.com>
wrote:

> The browser cannot tell it is “really” a third-party and the user may have
> no indication they were going to be redirected through the third-party.
>

What does "really" a third-party mean? In the case you outline, the browser
did a full-page navigation to origin X. For that request, origin X is, in
fact, the first-party.

The first-party attribute would have to stop cookies being sent in these
> kind of redirected requests.
>

1. Why? I think we're dealing with distinct threat models, so I'd like to
understand the threat you're trying to defend against. The spec I posted is
focused on two:

    * It attempts to defend against CSRF attacks that use a user's ambient
authority on `https://bank.com/` to do bad things.
    * It allows a site that doesn't _want_ to track users cross-origin to
set cookies without the risk of receiving them in unexpected circumstances.

2. What kind of heuristics would you suggest? The issue, as you probably
understand, is that the browser doesn't know how origin X is going to
respond to a request. It may deliver a 200 response with a lovely HTML
page. It may deliver a 302 to `https://evil.com/`. It may explode with a
500. It's not clear to me that it's possible to make such an a priori
distinction.

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)