- From: Francois Daoust <fd@w3.org>
- Date: Wed, 15 Apr 2009 11:41:33 +0200
- To: Charles McCathieNevile <chaals@opera.com>
- CC: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Charles McCathieNevile wrote: [...] >> In short >> ----- >> There are test suites. None of them pretends to be complete. > > So perhaps it behooves us to complete them to our satisfaction. I guess we would need more than just to complete them. We would need to complete them, and then to adapt them so that they can successfully check that a proxy that re-write links does not change the rules. [...] > ... >> 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... Yes, I was looking for existing consistence here. Convergence should be the trend, the problem being that the converging point is not fully defined or testable yet, as the ongoing works on HTML5 and cross-origin resource sharing demonstrate. Having guidelines on a moving target does not seem to be such a good idea, and having guidelines based on existing implementations that are not really consistent does not seem to be such a good idea either. That may be too simplistic a view, though... >> 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? This possibility would allow links rewriting but introduce something along the lines of "proxies that re-write links MUST conform to the same-origin policy defined in HTML5", with the drawback that we would then probably need to wait for HTML5 to move forward on the Rec track. > >> 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...) Yes, that sounds reasonable to me, and not actionable in practice at a normative level, which is why I propose the possibilities mentioned above. Francois. > > cheers > > Chaals >
Received on Wednesday, 15 April 2009 09:42:08 UTC