Robin, I think you captured the essence. The WARP spec should not inhibit widget access to the same types of content that a browser has, under the same conditions. The <access> element is useful as a disclosure of intent, but as it stands it conflicts with the implementation of the "web security model" since it defines a significantly different behavior as compared to a browser-based web application (at least those not packaged as widgets).
Best regards, Bryan Sullivan | AT&T -----Original Message----- From: Robin Berjon [mailto:[email protected]] Sent: Wednesday, November 18, 2009 3:57 AM To: Marcin Hanclik Cc: Marcos Caceres; SULLIVAN, BRYAN L (ATTCINW); WebApps WG Subject: Re: [WARP] Comments to WARP spec On Nov 12, 2009, at 16:36 , Marcin Hanclik wrote: > I understand that too many details may not work or be an obstacle in the > adoption. > However, I derive that from the security point of view we still would like to > distinguish at least between executable and non-executable content. That doesn't work. Not only could some script just manipulate canvas stuff, but some images can execute script. It would be trivial to create lossless bitmaps that could encode script. One could also use XHR to evaluate content returned as text/plain (or as a bunch of other things). One could request an image that is redirected to http://address/of/image?put+a+complete+script+here and then evaluate the query. I think there are two threads in this discussion, one seems to concern the default behaviour of widget UAs as defined by WARP - I think that's a valuable discussion to have (is the request simply that WARP be open by default for the same things that are allowed in a browser?) that is being drowned in the other discussion, which is about a semi-sentient local filtering proxy firewall built using pieces of flint and some string. Can we focus on the first one? -- Robin Berjon - http://berjon.com/
