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

Re: [cors] Two minor processing issues

From: Thomas Roessler <tlr@w3.org>
Date: Thu, 4 Aug 2011 14:55:48 +0200
Cc: Thomas Roessler <tlr@w3.org>, public-webapps@w3.org, "Philippe De Ryck" <philippe.deryck@cs.kuleuven.be>
Message-Id: <45328664-7ECC-497D-9C02-D97A0D4331DD@w3.org>
To: Anne van Kesteren <annevk@opera.com>
On Aug 4, 2011, at 00:12 , Anne van Kesteren wrote:

> On Wed, 03 Aug 2011 19:43:28 +0200, Philippe De Ryck <philippe.deryck@cs.kuleuven.be> wrote:
>> CORS-ISOLATION-1.Unique Origins: When run in a document with a globally
>> unique identifier for an origin, the Origin header specification
>> requires that null should be sent as the value of the Origin header. The
>> algorithms listed in the CORS specification do not explicitly take the
>> null value into account, leading to some unlogical scenarios. It is for
>> instance valid that a request sends origin null and the server responds
>> with an Allow-Origin header with the value null.
> 
> Is that problematic? This is a feature.

The other observation would be that this approach permits any web site to serve as a communication channel between arbitrary unique origin contexts, in arbitrary browser instances.  That effect seems contrary to the goal of unique origins to me, which is exactly to limit the communication paths available. This strikes me as a feature that's more likely to show up in obscure attacks (or bugs) than in legitimate code.

I'd find it more intuitive if a unique origin (at least as currently defined) would lead to a hard failure for now.  There might be more sophisticated things one can do about unique (or perhaps public-key based?) origins in the future, but just using "null" isn't one of them.
Received on Thursday, 4 August 2011 12:55:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT