- From: Marcos Caceres <marcosc@opera.com>
- Date: Wed, 5 May 2010 15:57:21 +0200
- To: Robin Berjon <robin@berjon.com>
- Cc: Scott Wilson <scott.bradley.wilson@gmail.com>, public-webapps WG <public-webapps@w3.org>
On Wed, May 5, 2010 at 11:40 AM, Robin Berjon <robin@berjon.com> wrote: > On May 4, 2010, at 19:29 , Scott Wilson wrote: >> I've just been reading through the WARP spec again, and in particular this stood out: >> >> In the default policy, a user agent must deny access to network resources external to the widget by default, whether this access is requested through APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, img). >> >> I'm not sure if this statement is actually helpful here. While it makes sense that WARP defines policies that widen access beyond whatever the UA's default policy may be, is it strictly necessary to define the default policy? > > Well, if you think about it a little bit further, is it really necessary to have a way of defining a network access policy, and if so is the content you're distributing the best place to do so? I personally have a somewhat reserved judgement about whether WARP is useful at all. A rather large number of people expressed this requirement, so it was delivered, and it's quite possible that they were right. But it's also possible that they're not which is why I'm happy that it's not part of P+C. > No, we added it because the HTML-WG refused to define what happens when you run a web page locally. We (the WG) needs this. HTML5 defines a security model, and so should widgets in the absence of the same origin policy. I don't see anyway around this. > > If you noticed this because you're working on it for Wookie, I'm not sure that's it's worth the (minimal) effort. WARP makes no sense in a Web context. > Exactly, it doesn't because you have CORS, UMP, and our inline friends. But it makes sense in a widget:// context. -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
Received on Wednesday, 5 May 2010 13:58:14 UTC