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

Re: HTTPbis and the Same Origin Policy

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 30 Nov 2009 12:17:38 -0800
Cc: Adam Barth <w3c@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <AD72FEE3-8DC0-4DE5-B861-4AF5A0091095@apple.com>
To: Tyler Close <tyler.close@gmail.com>

On Nov 30, 2009, at 11:25 AM, Tyler Close wrote:

> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Wed, Nov 25, 2009 at 2:34 PM, Tyler Close  
>> <tyler.close@gmail.com> wrote:
>>> On Wed, Nov 25, 2009 at 1:54 PM, Adam Barth <w3c@adambarth.com>  
>>> wrote:
>>>> Indeed.  Security in the application layer is quite complex.   
>>>> That's
>>>> what makes life interesting.  :)
>>> So are you agreeing that there do exist SOP rules that the  
>>> application
>>> layer must obey? If so, should we document those rules?
>> Yes.  At the application layer.
> Perhaps we're just talking past each other here. I'll try again...
> When creating a new application layer API, the designers must take
> into account the SOP protection expected by resources. Currently,
> these expectations aren't documented anywhere. In the status-quo, the
> application layer API is expected to magically know all the SOP
> restrictions and then document how it enforces them. I'm just
> suggesting that it would be a good thing to remove some of the magic
> here by writing down the SOP restrictions, leaving the application API
> with only the task of documenting its enforcement mechanism.

It's important to understand that the same-origin policy is a concept  
specific to a certain kind of client, not to a particular network  
protocol. It's more of an HTML-level concept than an HTTP-level  
concept. In particular, a browser loading a document over FTP or  
Gopher would still enforce the same-origin policy in the same way. But  
a low-level HTTP client library would not enforce the same-origin  
policy at all.

>> I'm not even sure you can articulate the policy coherently without
>> referring to application-layer concepts.  How would you explain the
>> restrictions on images in the HTML Canvas element in terms of HTTP
>> protocol messages?
> The response to a GET request must not be made accessible to content
> from another origin, unless the target resource has explicitly
> indicated otherwise. The HTML <script> tag is a notable violation of
> this restriction for content matching a particular syntax. Otherwise,
> this rule seems widely enforced.

That's a bit of an oversimplification. How much of the response you  
can get depends on the embedding context:

cross-origin <script> --> contents executed as JavaScript, which may  
let you read some of the contents depending on the nature of what is  
cross-origin <link rel="stylesheet"> --> contents applied as a  
stylesheet, all of the rules in the stylesheet can be read via CSS
cross-origin <img> --> if a valid image in some known format, height  
and width can be determined; also, can be drawn to <canvas>, but then  
reading the pixels of that canvas is disallowed
cross-origin <video> --> same as <img> plus you can get the duration.
cross-origin <iframe> --> the only way to communicate is via  
cross-origin XMLHttpRequest --> nothing about the response is  
available (unless the server opts in)

Same-origin policy differences are primarily about the embedding  
context, not the networking-level details. All of these examples would  
behave the same for FTP or Gopher or whatever other network protocol  
is supported. In fact, classically the same-origin policy was all  
about scripting access to the DOM, in that scripting access to the DOM  
contents cross-origin frames is denied. It only started to affect  
networking as such with the advent of XMLHttpRequest.

It would be good to gather the distributed knowledge about the same- 
origin policy and make recommendations for new embedding or networking  
facilities. But it's not really about HTTP, and would not make sense  
as part of the HTTPbis effort.

Received on Monday, 30 November 2009 20:18:13 UTC

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