W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: From-Origin FPWD

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Mon, 01 Aug 2011 02:52:34 +0200
To: "Anne van Kesteren" <annevk@opera.com>
Cc: "WebApps WG" <public-webapps@w3.org>
Message-ID: <p0sb375en0c676ei73uo4djq9pimf2begq@hive.bjoern.hoehrmann.de>
* Anne van Kesteren wrote:
>   http://www.w3.org/TR/from-origin/

The proposed `From-Origin` header conveys a subset of the information
that is already available through the Referer header. As it is, it is
very rare for the Referer header, or coressponding interfaces that are
available to scripts, to be absent and the draft does not even attempt
to argue how the reasons for the Referer header's abscence don't apply
to `From-Origin`. It also lacks a description of the problem domain.

As an example, it is unclear that there are important use cases that
require telling a.example.com apart from b.example.com (assuming that
example.com is a "public suffix" while the subdomains are not). That's
important if one were to design the mechanism where it's easy for a
site to verify if the "from-origin" is acceptable, but hard to learn
the actual "from-origin" when it is not.

(Consider as a trivial example you send the MD5 of the "from-origin"
instead of the actual value: verification would be easy, but learning
the actual value would require to go through a possibly long list of
possible origins; of course, brute force against MD5 is trivial, and
if you use the "whole origin" you couldn't check for "*.example.com",
without trying all possibilities for the wildcard, but cryptography
offers other options, and knowing constraints is important to find and
evaluate them.)

Similarily, it is unclear whether there is actually an important need
to know more than "same 'public suffix'" if "Referer" is there anyway
most of the time (you can obviously make up examples to illustrate a
difference, but there are usually design alternatives that render such
examples unimportant).

Clearly "Referer" information would be available more often if there
had always been a policy to only strip path and query information in-
stead of stripping it entirely, and the only difference between such
a policy and the proposed header -- assuming the idea is that it'd be
available 'always' -- that there wasn't such a policy. But that is
about all there is to this proposal at the moment, and I don't find
that very convincing.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Monday, 1 August 2011 00:52:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:07:39 UTC