widgets - WARP default policy

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?
For example, this implies that a UA should actively block widgets using JSONp, CORS, Google's Ajax libraries, CDNs, or even a widget just grabbing its company's icon off their website in an img tag.
Now there may be UAs who have a default policy that is this strict, but requiring this to be the default policy as a conformance requirement for any WARP implementation seems OTT.
S
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? For example, this implies that a UA should actively block widgets using JSONp, CORS,  Google's Ajax libraries, CDNs, or even a widget just grabbing its company's icon off their website in an img tag. Now there may be UAs who have a default policy that is this strict, but requiring this to be the default policy as a conformance requirement for any WARP implementation seems OTT.S

On Tue, May 4, 2010 at 10:29 AM, Scott Wilson <
If these were limited to Uniform Messages, how much of a need would there
still be to disallow them? What would the remaining threats be?

I've just been reading through the WARP spec again, and in particular this stood out:In the

On Tue, May 4, 2010 at 2:37 PM, Mark S. Miller wrote:
Would it allow reading resources behind corporate firewalls using a
browser running on a computer behind said firewall?
/ Jonas

On Tue, May 4, 2010 at 2:45 PM, Jonas Sicking wrote:
Only if the resource responds with an "Access-Control-Allow-Origin: *"
header.
> If these were limited to Uniform Messages, how much of a need would there
> still be to disallow them? What would the remaining threats be?
Would it allow reading resources behind corporate firewalls using a
browser running on a computer behind said firewall?Only if the resource responds with an "Access-Control-Allow-Origin: *" header.

On Tue, May 4, 2010 at 2:56 PM, Mark S. Miller wrote:
Ah, I see what you mean. Yes, it seems to me like as long as the
normal "web cross origin policies" are applied (including things like
UMP, CORS, , ) then it should be fine I would think.
Though I'm not a widget person so please don't rely on my answer.
/ Jonas

On Tue, May 4, 2010 at 7:29 PM, Scott Wilson
I agree, this is unhelpful in the way it is written. This assumes that
the default policy is "about:blank" or "widget:" (and even for those,
the default policy is not defined - that is, HTML5, AFAIK, does not
define about:blank and widget: does not defined a default policy).
That is wrong IMO. Wookie demonstrates that by embedding the widget
within a web page the widget's security model will be the one given by
the browser.
In the case of wookie, CORS makes more sense than WARP. WARP is only
really suitable for when the widget is relying on a restrictive
security context implied by a given origin (i.e., if origin is
"widget://xxx" or other non-Web one, then WARP applies; Else, if
origin is from http/https the web (HTML5) security model applies).
Agree.
Agree.

On May 4, 2010, at 19:29 , Scott Wilson wrote:
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.

On Wed, May 5, 2010 at 11:40 AM, Robin Berjon wrote:
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.
Exactly, it doesn't because you have CORS, UMP, and our inline
friends. But it makes sense in a widget:// context.

On 5 May 2010, at 10:40, Robin Berjon wrote:
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.

On Wed, May 5, 2010 at 3:59 PM, Scott Wilson
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).

On Wed, May 5, 2010 at 4:05 PM, Marcos Caceres wrote:
Maybe we need a note (or as part of the intro) more clearly explaining
the use case for WARP.