- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Wed, 28 Jan 2015 14:14:27 -0000
- To: "'Mike West'" <mkwst@google.com>
- Cc: "'Yehuda Katz'" <wycats@gmail.com>, "'Daniel Appelquist'" <appelquist@gmail.com>, "'TAG List'" <www-tag@w3.org>
- Message-ID: <3b9101d03b04$be168800$3a439800$@baycloud.com>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mike Yes, well I was thinking of the third-party who wants to get round (say Safari) third-party cookie blocks to do cross-origin tracking, which isn’t your threat model but is happening and sites may like to avoid it using a CSP type mechanism. I thought it was worth pointing out that the problem was not just embedded third-party subrequests. MikeO From: Mike West [mailto:mkwst@google.com] Sent: 28 January 2015 13:58 To: Mike O'Neill Cc: Yehuda Katz; Daniel Appelquist; TAG List Subject: 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.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) Comment: Using gpg4o v3.4.19.5391 - http://www.gpg4o.com/ Charset: utf-8 iQEcBAEBAgAGBQJUyO7CAAoJEHMxUy4uXm2JvTYIAK73rXBMHrKFLQuSW8ideSL2 pRbOjFUrtbF+RveyRAgzT6IxuyVEO6iMBxYwgkZYpHLC7abjOJYMpsod9DyZ29xi tLYoroST8GerA9hrc0hiGP88XrN/cZuoSND7TkOw2nl3H4Kq8PKD+y6NNo1/jI4P jqVEFcvgps2TIjXeDxF0G3oOZUcNCwKSyTHrKFamI93TVcrXnc1KEmysA7IqO+ow 8MYLYYaqpNQm9HWFv5fwXYw+2ogxmHoKD94eN/7sKZALhQsWCKcNuw3LiJGBvriR FRT1LMhG8jprdQe/pxiAxgsxmqBBKNRr096OJVcOMQ9zsUu+QEfF9nsz+VILKyA= =Zvok -----END PGP SIGNATURE-----
Attachments
- text/html attachment: PGPexch.htm
- application/octet-stream attachment: PGPexch.htm.sig
Received on Wednesday, 28 January 2015 14:16:23 UTC