- From: Mike West <mkwst@google.com>
- Date: Fri, 24 Oct 2014 21:42:03 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAKXHy=ekENDs+JKaWMsDCv0LyNPXmc5U3AstVvEtx6w=gizaQQ@mail.gmail.com>
On Fri, Oct 24, 2014 at 9:29 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > Oh, I have a very different threat model in mind. That threat model > is the one that Secure addresses, namely that an origin can request > that cookies it gives out are not distributed by the client to other > hosts. Ok. Origin cookies address this concern by locking the cookies to the origin that set them. An origin cookie set by `example.com` would not be sent to `subdomain.example.com` and vice versa. I think we're on the same page here. > And when you send cookies, you don't necessarily know that > they support origin cookies, so you are taking a risk. > One way of mitigating this risk is to force the user agent to _always_ send an `Origin-Cookie` header as a feature detection mechanism. You seem to be more concerned with the converse aspect: that other > domains (subdomains or parent domains, HTTP or JavaScript) can alter > the cookies that you see in requests. > I'm certainly concerned about `subdomain.example.com`'s ability to set cookies for `example.com`. And even more about `http://example.com:1999` setting cookies for `https://example.com:443`. Those are both use cases I think origin cookies can help with. -- Mike West <mkwst@google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 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.)
Received on Friday, 24 October 2014 19:42:52 UTC