W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

Re: The HTTP Origin Header (draft-abarth-origin)

From: Robert Sayre <sayrer@gmail.com>
Date: Sat, 24 Jan 2009 16:38:54 -0500
Message-ID: <68fba5c50901241338i61edbd98n16aae3b24b26de9@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>

On Sat, Jan 24, 2009 at 1:02 PM, Adam Barth <w3c@adambarth.com> wrote:
> Without even anecdotal evidence that this occurs, this privacy leak
> seems theoretical.  (Of course, I'd prefer hard data to anecdotes.)

It no doubt occurs, since the web makes it easy to do. Do you
disagree? I agree the quantity is hard to guess at, and the nature of
the problem makes it hard to get data for, if you think about it.
Again, I don't think the quantity argument is a good one, since the
problem is that people can install a new browser and leak data in new
ways, by default. In my project, it's unusual to dismiss security or
privacy bugs by saying "well, it only happened to a few people".

Asking people to provide data is often a good thing, especially when
they're proposing features, but in this case it seems like you're
using it to squash a pretty valid concern when the burden of proof is
on you. Where would such a rhetorical tactic fly?

It's your piece of http space junk. :)

>> Information on the quantity would be nice to have, but I don't think a
>> new CSRF mitigation technique should introduce a privacy leak,
>> especially when it looks like there might be a way to avoid it that
>> you haven't explored.
> I welcome suggestions for a solution that address the same use cases
> with further privacy protections.

Didn't I just give one, or do you want me to design a full URL
comparison for you? I guess I can throw something together if you
insist. I'm sure it could cover the facebook example you gave. It
wouldn't cover the case where you actually want to allow some
syntactically unrelated host to submit POST requests via a whitelist.
That seems like a reasonable trade off to me.

Ian Hickson wrote:
> This solution would fail to satisfy the original use case of Origin,
> namely to let the server in an XHR2 scenario know who the origin was so it
> could make educated decisions about letting information out.

This could change things, since this seems to /require/ leaking the
host name. But "educated decisions" is a pretty vague term.

That said, cross site XHR2 as proposed in the W3C is pretty bloated
and complex. Having to mint a different header for that use seems like
a drop in the bucket.


Robert Sayre

"I would have written a shorter letter, but I did not have the time."
Received on Saturday, 24 January 2009 21:39:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:48 UTC