W3C home > Mailing lists > Public > www-tag@w3.org > January 2015

Re: Cookies Settings Observations

From: Mike West <mkwst@google.com>
Date: Wed, 28 Jan 2015 14:57:50 +0100
Message-ID: <CAKXHy=eHACfmCPzGdajfZ47ep6yftJAwpsc1_zwyeQgzJ-r1ng@mail.gmail.com>
To: "Mike O'Neill" <michael.oneill@baycloud.com>
Cc: Yehuda Katz <wycats@gmail.com>, Daniel Appelquist <appelquist@gmail.com>, TAG List <www-tag@w3.org>
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>

> 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


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
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Wednesday, 28 January 2015 13:59:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:09 UTC