Re: ACTION-925: CT - same origin policy conformance

On Tue, 14 Apr 2009 18:13:07 +0200, Francois Daoust <fd@w3.org> wrote:

> Context
> -----
> During last F2F, I was actioned to research existing tests to assert the  
> existence of conformance tests around the same-origin that we could  
> refer to in the Content Transformation guidelines to allow links  
> re-writing (and other changes of origin). ...

> Note I am talking about the same-origin policy here, and not about HTTPS  
> links re-writing, although that is part of it.
>
> In short
> -----
> There are test suites. None of them pretends to be complete.

So perhaps it behooves us to complete them to our satisfaction.

> No existing browser fully respects the same-origin policy.
> Well, the same-origin policy does not even "exist" on a normative basis.

Which makes it difficult to respect it completely. Once, this was not  
really even considered a problem, but as you noted this is being addressed  
in increasing detail.

> I do not see what we could refer to in the guidelines, especially since  
> the same-origin policy is only defined in the HTML5 draft so far.
>
> Still, does it entail it has to be completely forbidden?

Actually, there are circumstances under which it *should* be permitted to  
access content across different origins. There is work on that  
specifically because there are good reasons to allow it in certain cases.

...
> It shows that no two desktop browsers behave identically, the most  
> prominent difference being that the port number is not part of the  
> definition of an origin (for DOM access) in IE. Mobile browsers are not  
> mentioned, but I'd be very surprised if we find consistence there.

I would be surprised if we *didn't* find convergence as a trend...

> Conclusion
> -----
> a) We can stick to the resolution we adopted:
> RESOLUTION: Since there doesn't appear to be a way in which the URI sent  
> to the User Agent can be manipulated to preserve security related to  
> same origin policies it is permissible for a CT proxy to act on content  
> in so that security is nonetheless preserved as adjudged by conformance  
> tests that are to be researched. If no such security tests can be found  
> then there cannot be conformance associated with link rewriting and it  
> cannot be permissible for CT proxies to do so.

This does not seem to make sense. Among other reasons, because it ignores  
the ability of a proxy that rewrites links to ensure it is getting all the  
content to handle the same-origin security policies at the proxy by not  
providing the resource.

> b) We can stick to the resolution and decide to rely on HTML5 to come up  
> with a conformance test suite on the same-origin policy since they are  
> defining it.

Which is effectively the same thing as a, no?

> c) We can decide to be slightly less strict and allow that to happen  
> provided the result is purely static:
> PROPOSED RESOLUTION: Links re-writing is strongly NOT RECOMMENDED  
> because it jeopardizes the same-origin policy if no appropriate security  
> measures are taken on the proxy. When links are re-written, proxies MUST  
> ensure that the resulting content is purely static, and MUST therefore  
> remove all scripting and cookies from the content served to the client.
>
> d) We can decide to leave security considerations at an informative  
> level:
> PROPOSED RESOLUTION: Links re-writing is strongly NOT RECOMMENDED  
> because it jeopardizes the same-origin policy if no appropriate security  
> measures are taken on the proxy. Areas affected include DOM access,  
> Cookies, and XHR calls.
>
> Both proposed resolutions are written using casual-discussion terms and  
> would need to be more precise, but you get the idea...

These both allow (as I read them) for the idea that it is possible to  
handle the security consideration, although insisting on a model that  
assumes there are no secure cross-site requests (which is not necessarily  
a valid assumption). I think they are further along the right track though.

In particular, a transcoding proxy should respect the policy of the  
browser which is receiving its transcoded content (asking it to do less  
seems a bad idea, asking it to do more seems unreasonable, although asking  
it to check that policy is also an interesting prospect that might lead us  
bakc to having to do the serious work of figuring out how to handle  
same-origin policy and legitimate exceptions to it...)

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Wednesday, 15 April 2009 01:25:52 UTC