RE: [WARP] Comments to WARP spec

Hi Marcos,

To be clear, your answer addresses point (2) only, and while I realize that the idea proposed may not apply to all valid start files, it nonetheless did address the point of the comment. It may not be the best solution but it is just a start on one, I hope.

I still think we should recognize and somehow address the significant limitations of blanket handling of all external references ala "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 think this will have a significant impact on the functionality of web applications that should be able to access wide sources of media content, but want to be more selective on sources of scripts.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
Sent: Friday, November 06, 2009 8:20 AM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: WebApps WG
Subject: Re: [WARP] Comments to WARP spec

2009/11/2 SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com>:
> Here are the comments I had to the WARP spec in the Webapps/DAP joint
> meeting:
>
> 1) Does "*" grant/require either HTTP or HTTPS as schemes? It would be
> better to allow "https://*/" or "http://*/" distinctly since some
> applications may not be allowed by policy to access specific sources
> using non-secure HTTP, e.g. an e-commerce-enabled application. It would
> thus not be possible to include both "http://*/" (for generic content)
> and also limit access to the e-commerce sensitive sites via HTTPS.
>
> 2) Re "A user agent enforces an access request policy. 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).".
> Note that content that is typically not executable, e.g. img sources,
> this limitation on access to linked resources is significant, and will
> require e.g. for mashup applications that all content and references are
> pre-retrieved (or reference URI's re-written at least, to be proxied
> upon request) by the web application server (or set of servers as
> represented by the access list). It would be good to consider a way for
> the webapp to allow for certain types of content reference methods to be
> allowed from a wider set of sources, while preserving restrictions on
> others, e.g.:
>
> <access origin="http://trustedsite.com" "tag=script"/>
> <access origin="*" "tag=img"/>

The "tag" attribute assumes HTML is the language being used. But there
is no relationship between packaging and the content type of the start
file. Cute idea thought :)

-- 
Marcos Caceres
http://datadriven.com.au

Received on Saturday, 7 November 2009 00:57:02 UTC