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

On Thu, Jan 22, 2009 at 7:14 PM, Adrien de Croy <adrien@qbik.com> wrote:
> was there any trend you were able to recognise from the 3% of stripped
> requests?  e.g were any investigated to see if there was a common theme
> regards which model of proxy they may have been going through?

Due to ethical restrictions, we were unable to collect
user-identifiable information (such as IP addresses) during this
study.  We did observe a number of times that the Referer header was
replaced with an advertisement for a privacy firewall (one of whose
advertised features was stripping the Referer header).  I also have
worked for companies (and hear about similar deployments) whose
corporate firewall/proxy strips the Referer header to protect the
confidentiality of intranet URLs.

> I would have thought that if a system admin decided to strip referer for
> privacy reasons, then they may also decide (whether in ignorance or not) to
> strip the Origin header as well.

Unlike the Referer header, the Origin header is not set for GET or
HEAD requests.  In practice, this immensely reduces how often the
header is sent.  For example, imagine a corporate wiki page at
http://wiki/Main/PlansToBuildAnIPhoneKiller has a hyperlink to Apple's
iPhone marketing materials.  An employee who follows this link will
leak sensitive information to Apple in the Referer header, but the
employee will not leak any information in the Origin header because it
is not sent for GET requests.

> Also I presume this scenario is coupled with a requirement for browsers to
> make it impossible for a script to touch the Origin header?

This is already the case for cross-site requests in browsers today.
The XMLHttpRequest specification in the W3C already forbids overriding
the Origin header for same-site requests.  This change has already
been implemented by several major browser vendors.

Thanks for your feedback,
Adam

Received on Friday, 23 January 2009 04:04:11 UTC