- From: Marcos Caceres <marcosc@opera.com>
- Date: Thu, 6 May 2010 11:24:49 +0200
- To: Robin Berjon <robin@berjon.com>
- Cc: public-webapps WG <public-webapps@w3.org>
On Wed, May 5, 2010 at 4:05 PM, Marcos Caceres <marcosc@opera.com> wrote: > On Wed, May 5, 2010 at 3:59 PM, Scott Wilson > <scott.bradley.wilson@gmail.com> wrote: >> On 5 May 2010, at 10:40, Robin Berjon 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. >>> >>> 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. >> >> We use it to feed the whitelist our server-side proxy service uses; I've already implemented it for this admittedly limited purpose in Wookie and it seems to work fine. But for the most part access policy is dealt with by the browser security model, which is moving towards making such workarounds unnecessary in the long run. However, right now we still have a limited UC for WARP. >> > > Right: so WARP on the Web is a band-aid solution that requires a > server-side proxy to retrieve content a browser would not normally be > able to access (because of cross-origin restrictions). WARP should not > be used where CORS is available (and WARP through a proxy should be > used with extreme caution on the Web). Maybe we need a note (or as part of the intro) more clearly explaining the use case for WARP. -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
Received on Thursday, 6 May 2010 09:25:40 UTC