RE: [WARP] Comments to WARP spec
Hi Robin,
Great thanks for the descriptive example!
At first I thought that it all depends on the trust model.
The security issue in your example results from the eval that is contained in
the html within a widget. So we could assume that if the widget is signed we
could somehow rely on its content. Then the evil eval would maybe not be used
(at least not in the context you quote).
So we could have the simple distinction between executable content (js, html)
and non-executable content (img, css [until scripts come there] ).
However, since some images can also be executed, the distinction is de-facto
void.
Therefore it seems the use case is not doable, because we probably do not want
to overload the implementations with [SNIFF] algorithms.
Thanks,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
-Original Message-
From: Robin Berjon [mailto:ro...@berjon.com]
Sent: Wednesday, November 18, 2009 6:37 PM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [WARP] Comments to WARP spec
Hi Marcin,
On Nov 18, 2009, at 14:37 , Marcin Hanclik wrote:
One could request an
image that is redirected to
http://address/of/image?put+a+complete+script+here
and then evaluate the query.
Ok, but then it will still be processed as image and will result in an
invalid image, I think.
Not so. Consider the following piece of Perl:
#!/usr/bin/perl
print Location: img.png?alert('I am evil!')\n\n;
And the following HTML:
!DOCTYPE html
iframe src='img.pl' id='pl'/iframe
script
window.onload = function () {
eval(unescape(document.getElementById(pl).contentDocument.location.search.substring(1)));
}
/script
This produces the expected alert. No script was ever exchanged, and I get the
image to display perfectly fine.
--
Robin Berjon - http://berjon.com/
Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
www.access-company.com
CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or
distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by
responding to this e-mail. Thank you.
Re: [WARP] Comments to WARP spec
Hi Marcin,
On Nov 19, 2009, at 09:44 , Marcin Hanclik wrote:
Great thanks for the descriptive example!
A pleasure :)
The security issue in your example results from the eval that is contained in
the html within a widget. So we could assume that if the widget is signed we
could somehow rely on its content. Then the evil eval would maybe not be used
(at least not in the context you quote).
Perhaps, but the example I used was very straightforward and easy to review —
it would be possible for the original HTML to be a trojan with a less obvious
attack path.
For instance consider a createElement(name, parent, content) method; you could
obtain script and alert('I am evil!') using the same trick, and call
createElement(script, document.body, alert('I am evil!')) — it would work
just the same as eval().
However, since some images can also be executed, the distinction is de-facto
void.
Right, it's one of those things that people would've done differently if we'd
had a chance to think about the consequences while the web was being
organically grown, but that's water under the bridge now.
--
Robin Berjon - http://berjon.com/
RE: [WARP] Comments to WARP spec
Hi Robin,
For instance consider a createElement(name, parent, content) method; you
could obtain
script and alert('I am evil!') using the same trick, and call
createElement(script, document.body, alert('I am evil!')) - it would work
just
the same as eval().
Yes, it seems the architecture is simply vulnerable per current design (e.g. in
ECMA allowing non-strict eval etc.) and we cannot do too much.
Right, it's one of those things that people would've done differently if we'd
had a
chance to think about the consequences while the web was being organically
grown, but
that's water under the bridge now.
Keeping the context of having a chance: what about event naming in [1]?
Thanks,
Marcin
[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0795.html
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
-Original Message-
From: Robin Berjon [mailto:ro...@berjon.com]
Sent: Thursday, November 19, 2009 11:15 AM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [WARP] Comments to WARP spec
Hi Marcin,
On Nov 19, 2009, at 09:44 , Marcin Hanclik wrote:
Great thanks for the descriptive example!
A pleasure :)
The security issue in your example results from the eval that is contained in
the html within a widget. So we could assume that if the widget is signed we
could somehow rely on its content. Then the evil eval would maybe not be used
(at least not in the context you quote).
Perhaps, but the example I used was very straightforward and easy to review -
it would be possible for the original HTML to be a trojan with a less obvious
attack path.
For instance consider a createElement(name, parent, content) method; you could
obtain script and alert('I am evil!') using the same trick, and call
createElement(script, document.body, alert('I am evil!')) - it would work
just the same as eval().
However, since some images can also be executed, the distinction is de-facto
void.
Right, it's one of those things that people would've done differently if we'd
had a chance to think about the consequences while the web was being
organically grown, but that's water under the bridge now.
--
Robin Berjon - http://berjon.com/
Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
www.access-company.com
CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or
distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by
responding to this e-mail. Thank you.
Re: [WARP] Comments to WARP spec
Hi, On Nov 19, 2009, at 11:38 , Marcin Hanclik wrote: Right, it's one of those things that people would've done differently if we'd had a chance to think about the consequences while the web was being organically grown, but that's water under the bridge now. Keeping the context of having a chance: what about event naming in [1]? Honestly I think that naming is far less important than architecture, and generally a bike shed topic :) -- Robin Berjon - http://berjon.com/
RE: [WARP] Comments to WARP spec
Hi Robin, It seems in I am a naming purist :) Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Robin Berjon [mailto:ro...@berjon.com] Sent: Thursday, November 19, 2009 11:58 AM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [WARP] Comments to WARP spec Hi, On Nov 19, 2009, at 11:38 , Marcin Hanclik wrote: Right, it's one of those things that people would've done differently if we'd had a chance to think about the consequences while the web was being organically grown, but that's water under the bridge now. Keeping the context of having a chance: what about event naming in [1]? Honestly I think that naming is far less important than architecture, and generally a bike shed topic :) -- Robin Berjon - http://berjon.com/ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
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/
Re: [WARP] Comments to WARP spec
On Nov 9, 2009, at 20:22 , SULLIVAN, BRYAN L (ATTCINW) wrote: (1) we need to be specific about which API's / resource types are affected by inclusion (or exclusion) of domains in access (and keep this equivalent to HTML5) We're very specific: it's a blanket exclusion. Now I can be sensitive to an argument indicating that the default is defined by the security policy of the host language, in which case we need to also clarify which default to pick when there are several (HTML for instance has different origin rules for file:// and http://). My primary objection is that it's pretty late to have this discussion, the restriction has been there for months. -- Robin Berjon - http://berjon.com/
Re: [WARP] Comments to WARP spec
Hi Marcin,
On Nov 18, 2009, at 14:37 , Marcin Hanclik wrote:
One could request an
image that is redirected to
http://address/of/image?put+a+complete+script+here
and then evaluate the query.
Ok, but then it will still be processed as image and will result in an
invalid image, I think.
Not so. Consider the following piece of Perl:
#!/usr/bin/perl
print Location: img.png?alert('I am evil!')\n\n;
And the following HTML:
!DOCTYPE html
iframe src='img.pl' id='pl'/iframe
script
window.onload = function () {
eval(unescape(document.getElementById(pl).contentDocument.location.search.substring(1)));
}
/script
This produces the expected alert. No script was ever exchanged, and I get the
image to display perfectly fine.
--
Robin Berjon - http://berjon.com/
Re: [WARP] Comments to WARP spec
On Fri, Nov 13, 2009 at 6:39 AM, SULLIVAN, BRYAN L (ATTCINW)
bs3...@att.com wrote:
Hi Marcos,
Opera 9.5 running on Windows Mobile 6.1 and Opera 10 running on PC both allow
access to scripts and images from different domains than a widget was
obtained from. I have tested this and can provide a working example (see
below for the index.html - package it yourself and see).
Touché :)
Thus the same-origin restriction does not apply in current Opera
implementations for externally referenced scripts and images. The processing
of the access element as defined in WARP is not consistent with the current
Opera implementation.
So what do you mean by We've had a similar model in place for a long time in
our proprietary implementation?
!DOCTYPE html
html
head
meta charset=utf-8 /
link rel=stylesheet type=text/css href=style.css /
script src=http://www.json.org/json2.js;/script
script
function bodyLoad() {
var str = boohoo!;
try { str = JSON.stringify(['e', {pluribus: 'unum'}]);
str = hooray!;}
catch (e) { }
document.getElementById(test1).innerHTML = str;
}
/script
/head
body onload=javascript:bodyLoad();
pNot Same-Origin Resource Access Test: a test of the same-origin
rule for resources
accessed from domains other than where the widget was obtained./p
hr/
pTest 1: If the widget engine does not allow external script
references, no you will
see boohoo! below:/p
div id=test1/div
hr/
pTest 2: If the widget engine does not allow external image
references, no image will
be shown below:/p
img src=http://dev.opera.com/img/logo-beta.gif/
/body
/html
Best regards,
Bryan Sullivan | ATT
-Original Message-
From: Marcos Caceres [mailto:marc...@opera.com]
Sent: Tuesday, November 10, 2009 1:02 PM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: WebApps WG
Subject: Re: [WARP] Comments to WARP spec
SULLIVAN, BRYAN L (ATTCINW) wrote:
Placing broad restrictions on widget-context webapp access to network
resources (substantially different from browser-context webapps) is not an
effective approach to creating a useful widget-context webapp platform. That
would create a significant barrier to market acceptance of the W3C widget
standards.
Opera does not agree. We've had a similar model in place for a long time
in our proprietary implementation and we have not faced any issues in
the marketplace.
The WARP spec solves many problems that arise from not actually having a
network established origin, and may even avoid the confused deputy
problem CORS is currently facing (which locally running widgets won't be
able to use anyway).
I think that technically we are in agreement; but we are just in
disagreement about the level of granularity that the WARP spec affords
to authors. For the record, I like the way WARP is currently specified:
it's easy to use, and essentially works in much the same way as the same
origin policy does for Web documents... but with the added bonus of
being able to do cross origin - but with the restriction of not being
unrestricted, like it's the case for web documents.
--
Marcos Caceres
http://datadriven.com.au
RE: [WARP] Comments to WARP spec
Hi, What about semantic distinctions? tag as proposed till now seems to be too detailed and does not scale. For HTML/XHR: script means an executable content retrieved from the remote host. img, video etc means a displayable content retrieved from the remote host. iframe means a container (possibly for executable and displayable content) retrieved from the remote host. form means form submission, i.e. data is sent and not retrieved (topic discussed at TPAC. This also relates to the notion of retrievable content that is currently defined in WARP). API means that the network resource is to be requested by some API and not markup. We could have similar model to @rel on link from HTML, i.e. some meta information. We probably would like to distinguish between executable/non-executable (e.g. displayable or styling) contents and a kind of containers into which we have/not have insights. Keeping WARP on an abstract level, we could specify that the semantics of the particular content in the WARP model is out of scope for WARP. Then e.g. for HTML we could adopt the above distinctions in some other spec. It should work for HTML+SVG. The proposal is: add type attribute on access element that must have a value that is a set of space-separated tokens: exec - any retrievable content that is executed within the user agent (i.e. something that - when retrieved - will be executed), display - any retrievable content that is (only) displayed by the user agent, form - any data submitted by the user agent, container - any (markup) container that could be used to load executable, displayable or any other type of content by the user agent (i.e. e.g. some html page. This touches upon a being clicked in a widget: should the browser be opened? ), api - any retrievable and displayable content that is to be processed by the executable content within the user agent (e.g. by XHR. But what to do with the submissions based on XHR...? It seems API blurs this model a bit, since it is undefined what would happened to the retrieved data. Also e.g. the retrieved XML may be executed by some processor developed in script.), any - all/any of the above. Missing value equals to any (the default). This attribute specifies the origin of the access request and purpose for the submitted/retrieved data. Any views on this? Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: Tuesday, November 10, 2009 4:30 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: WebApps WG Subject: Re: [WARP] Comments to WARP spec SULLIVAN, BRYAN L (ATTCINW) wrote: Marcos, I agree there is an assumption behind the approach I proposed, which I also believe will be valid for the vast majority of widgets which will actually have index.html or something like that as the start page. Further, the statements in the config.xml apply to all resources in the widget, not just the start page, i.e. I can start with a non-HTML which references an HTML file in the package, to which the tag attribute applies. So we are clear, the tag attribute does not work in the following situation. I want to disable x:script, but allow v:script... unless you know what the things different namespaces will not be added dynamically to the DOM: x:html xmlns:x=http://www.w3.org/1999/xhtml; ... x:script ... /x:script v:svg v:width=6cm v:height=5cm v:viewBox=0 0 600 500 xmlns:v=http://www.w3.org/2000/svg; version=1.1 v:script src=../v:script /v:svg /x:html If the proposed solution is inadequate, I welcome other suggestions. I don't have a suggestion because I don't believe this part of WARP is broken or is necessary. But as it stands, the WARP spec is not consistent with the web security model, so we need to fix theaccess element definition somehow. Well, the whole point of WARP is to put these boundaries around the behavior of widgets because they run locally. How a browsing context should behave when run locally is not really defined by HTML5. This leaves a gap for us to fill. Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [WARP] Comments to WARP spec
Marcin Hanclik wrote: Hi, What about semantic distinctions? tag as proposed till now seems to be too detailed and does not scale. For HTML/XHR: script means an executable content retrieved from the remote host. img,video etc means a displayable content retrieved from the remote host. iframe means a container (possibly for executable and displayable content) retrieved from the remote host. form means form submission, i.e. data is sent and not retrieved (topic discussed at TPAC. This also relates to the notion of retrievable content that is currently defined in WARP). API means that the network resource is to be requested by some API and not markup. We could have similar model to @rel onlink from HTML, i.e. some meta information. We probably would like to distinguish between executable/non-executable (e.g. displayable or styling) contents and a kind of containers into which we have/not have insights. Keeping WARP on an abstract level, we could specify that the semantics of the particular content in the WARP model is out of scope for WARP. Then e.g. for HTML we could adopt the above distinctions in some other spec. It should work for HTML+SVG. The proposal is: add type attribute on access element that must have a value that is a set of space-separated tokens: exec - any retrievable content that is executed within the user agent (i.e. something that - when retrieved - will be executed), display - any retrievable content that is (only) displayed by the user agent, form - any data submitted by the user agent, container - any (markup) container that could be used to load executable, displayable or any other type of content by the user agent (i.e. e.g. some html page. This touches upona being clicked in a widget: should the browser be opened? ), api - any retrievable and displayable content that is to be processed by the executable content within the user agent (e.g. by XHR. But what to do with the submissions based on XHR...? It seems API blurs this model a bit, since it is undefined what would happened to the retrieved data. Also e.g. the retrieved XML may be executed by some processor developed in script.), any - all/any of the above. Missing value equals to any (the default). This attribute specifies the origin of the access request and purpose for the submitted/retrieved data. Any views on this? My view is that all this is overkill. I would prefer to keep things simple. To add the above would mean that a UA would have to flag every single element and every future supported element, as well as every feature, into a particular class (or into multiple classes or worst, do this dynamically (e.g., script style=display: block; background-color:red;.../script)). This proposal does not scale either. Kind regards, Marcos
RE: [WARP] Comments to WARP spec
Hi Marcos, 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. The distinction between retrievable and submissible touches upon the privacy (at present the users do not complain when they submit any data), but seems to be out of concerns at present. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Marcos Caceres [mailto:marc...@opera.com] Sent: Thursday, November 12, 2009 3:04 PM To: Marcin Hanclik Cc: SULLIVAN, BRYAN L (ATTCINW); WebApps WG Subject: Re: [WARP] Comments to WARP spec Marcin Hanclik wrote: Hi, What about semantic distinctions? tag as proposed till now seems to be too detailed and does not scale. For HTML/XHR: script means an executable content retrieved from the remote host. img,video etc means a displayable content retrieved from the remote host. iframe means a container (possibly for executable and displayable content) retrieved from the remote host. form means form submission, i.e. data is sent and not retrieved (topic discussed at TPAC. This also relates to the notion of retrievable content that is currently defined in WARP). API means that the network resource is to be requested by some API and not markup. We could have similar model to @rel onlink from HTML, i.e. some meta information. We probably would like to distinguish between executable/non-executable (e.g. displayable or styling) contents and a kind of containers into which we have/not have insights. Keeping WARP on an abstract level, we could specify that the semantics of the particular content in the WARP model is out of scope for WARP. Then e.g. for HTML we could adopt the above distinctions in some other spec. It should work for HTML+SVG. The proposal is: add type attribute on access element that must have a value that is a set of space-separated tokens: exec - any retrievable content that is executed within the user agent (i.e. something that - when retrieved - will be executed), display - any retrievable content that is (only) displayed by the user agent, form - any data submitted by the user agent, container - any (markup) container that could be used to load executable, displayable or any other type of content by the user agent (i.e. e.g. some html page. This touches upona being clicked in a widget: should the browser be opened? ), api - any retrievable and displayable content that is to be processed by the executable content within the user agent (e.g. by XHR. But what to do with the submissions based on XHR...? It seems API blurs this model a bit, since it is undefined what would happened to the retrieved data. Also e.g. the retrieved XML may be executed by some processor developed in script.), any - all/any of the above. Missing value equals to any (the default). This attribute specifies the origin of the access request and purpose for the submitted/retrieved data. Any views on this? My view is that all this is overkill. I would prefer to keep things simple. To add the above would mean that a UA would have to flag every single element and every future supported element, as well as every feature, into a particular class (or into multiple classes or worst, do this dynamically (e.g., script style=display: block; background-color:red;.../script)). This proposal does not scale either. Kind regards, Marcos Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [WARP] Comments to WARP spec
Marcin Hanclik wrote: Hi Marcos, 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. I think this is established by the content type, see the SNIFF spec. If that is not what you mean, then can you please elaborate. The distinction between retrievable and submissible touches upon the privacy (at present the users do not complain when they submit any data), but seems to be out of concerns at present. I don't understand the above.
RE: [WARP] Comments to WARP spec
Hi Marcos,
Opera 9.5 running on Windows Mobile 6.1 and Opera 10 running on PC both allow
access to scripts and images from different domains than a widget was obtained
from. I have tested this and can provide a working example (see below for the
index.html - package it yourself and see).
Thus the same-origin restriction does not apply in current Opera
implementations for externally referenced scripts and images. The processing of
the access element as defined in WARP is not consistent with the current
Opera implementation.
So what do you mean by We've had a similar model in place for a long time in
our proprietary implementation?
!DOCTYPE html
html
head
meta charset=utf-8 /
link rel=stylesheet type=text/css href=style.css /
script src=http://www.json.org/json2.js;/script
script
function bodyLoad() {
var str = boohoo!;
try { str = JSON.stringify(['e', {pluribus: 'unum'}]);
str = hooray!;}
catch (e) { }
document.getElementById(test1).innerHTML = str;
}
/script
/head
body onload=javascript:bodyLoad();
pNot Same-Origin Resource Access Test: a test of the same-origin rule
for resources
accessed from domains other than where the widget was obtained./p
hr/
pTest 1: If the widget engine does not allow external script
references, no you will
see boohoo! below:/p
div id=test1/div
hr/
pTest 2: If the widget engine does not allow external image
references, no image will
be shown below:/p
img src=http://dev.opera.com/img/logo-beta.gif/
/body
/html
Best regards,
Bryan Sullivan | ATT
-Original Message-
From: Marcos Caceres [mailto:marc...@opera.com]
Sent: Tuesday, November 10, 2009 1:02 PM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: WebApps WG
Subject: Re: [WARP] Comments to WARP spec
SULLIVAN, BRYAN L (ATTCINW) wrote:
Placing broad restrictions on widget-context webapp access to network
resources (substantially different from browser-context webapps) is not an
effective approach to creating a useful widget-context webapp platform. That
would create a significant barrier to market acceptance of the W3C widget
standards.
Opera does not agree. We've had a similar model in place for a long time
in our proprietary implementation and we have not faced any issues in
the marketplace.
The WARP spec solves many problems that arise from not actually having a
network established origin, and may even avoid the confused deputy
problem CORS is currently facing (which locally running widgets won't be
able to use anyway).
I think that technically we are in agreement; but we are just in
disagreement about the level of granularity that the WARP spec affords
to authors. For the record, I like the way WARP is currently specified:
it's easy to use, and essentially works in much the same way as the same
origin policy does for Web documents... but with the added bonus of
being able to do cross origin - but with the restriction of not being
unrestricted, like it's the case for web documents.
Re: [WARP] Comments to WARP spec
SULLIVAN, BRYAN L (ATTCINW) wrote: Marcos, Re I'm personally not in favor of trying to deviate too much from the Web security model.: I agree with you, and that is the point of the comments. The web security model (I think you mean the same-origin restriction) does not restrict access to image content from anywhere, like theaccess element would. Theaccess element as currently in the WARP spec goes beyond the web security model. My point is that the statement below in the WARP spec needs to change, because this is not compatible with the web security model, and also makes more work for implementers because the security model for widget-context webapps would not be the same as for browser-context webapps: 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). So either: (1) we need to be specific about which API's / resource types are affected by inclusion (or exclusion) of domains inaccess (and keep this equivalent to HTML5) (2) we must add a way for the developer to indicate which types of references should be allowed for the domain My preference would be (1), but I proposed the use of tag= to illustrate how (2) might work. Again, @tag= assumes HTML. There could be many different variant start files in a widget. Consider the case where you have a compound XML document as the start file (HTML + SVG + Custom XML)... how would you say which element this applies to and in which namespace? Also tag makes no sense in the context of CSS, XHR, etc.
RE: [WARP] Comments to WARP spec
Marcos, I agree there is an assumption behind the approach I proposed, which I also believe will be valid for the vast majority of widgets which will actually have index.html or something like that as the start page. Further, the statements in the config.xml apply to all resources in the widget, not just the start page, i.e. I can start with a non-HTML which references an HTML file in the package, to which the tag attribute applies. If the proposed solution is inadequate, I welcome other suggestions. But as it stands, the WARP spec is not consistent with the web security model, so we need to fix the access element definition somehow. Best regards, Bryan Sullivan | ATT -Original Message- From: Marcos Caceres [mailto:marc...@opera.com] Sent: Tuesday, November 10, 2009 1:36 AM To: SULLIVAN, BRYAN L (ATTCINW) Cc: WebApps WG Subject: Re: [WARP] Comments to WARP spec SULLIVAN, BRYAN L (ATTCINW) wrote: Marcos, Re I'm personally not in favor of trying to deviate too much from the Web security model.: I agree with you, and that is the point of the comments. The web security model (I think you mean the same-origin restriction) does not restrict access to image content from anywhere, like theaccess element would. Theaccess element as currently in the WARP spec goes beyond the web security model. My point is that the statement below in the WARP spec needs to change, because this is not compatible with the web security model, and also makes more work for implementers because the security model for widget-context webapps would not be the same as for browser-context webapps: 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). So either: (1) we need to be specific about which API's / resource types are affected by inclusion (or exclusion) of domains inaccess (and keep this equivalent to HTML5) (2) we must add a way for the developer to indicate which types of references should be allowed for the domain My preference would be (1), but I proposed the use of tag= to illustrate how (2) might work. Again, @tag= assumes HTML. There could be many different variant start files in a widget. Consider the case where you have a compound XML document as the start file (HTML + SVG + Custom XML)... how would you say which element this applies to and in which namespace? Also tag makes no sense in the context of CSS, XHR, etc.
Re: [WARP] Comments to WARP spec
SULLIVAN, BRYAN L (ATTCINW) wrote: Marcos, I agree there is an assumption behind the approach I proposed, which I also believe will be valid for the vast majority of widgets which will actually have index.html or something like that as the start page. Further, the statements in the config.xml apply to all resources in the widget, not just the start page, i.e. I can start with a non-HTML which references an HTML file in the package, to which the tag attribute applies. So we are clear, the tag attribute does not work in the following situation. I want to disable x:script, but allow v:script... unless you know what the things different namespaces will not be added dynamically to the DOM: x:html xmlns:x=http://www.w3.org/1999/xhtml; ... x:script ... /x:script v:svg v:width=6cm v:height=5cm v:viewBox=0 0 600 500 xmlns:v=http://www.w3.org/2000/svg; version=1.1 v:script src=../v:script /v:svg /x:html If the proposed solution is inadequate, I welcome other suggestions. I don't have a suggestion because I don't believe this part of WARP is broken or is necessary. But as it stands, the WARP spec is not consistent with the web security model, so we need to fix theaccess element definition somehow. Well, the whole point of WARP is to put these boundaries around the behavior of widgets because they run locally. How a browsing context should behave when run locally is not really defined by HTML5. This leaves a gap for us to fill.
RE: [WARP] Comments to WARP spec
Marcos, Re the whole point of WARP is to put these boundaries around the behavior of widgets because they run locally., there is really no difference between browser-context and widget-context webapps in that sense. Both run on the device, and both can access device resources and network resources. The only essential difference is that widgets are downloaded and installed as a package which can define some extra information that is useful in the install phase of the application lifecycle (e.g. compatibility checks via the the feature and access elements). I don’t believe it is correct to say that How a browsing context should behave when run locally is not really defined by HTML5.. I believe that regardless of where a web page originates, the security model must be consistent. For the part of HTML5 (e.g. access to DOM elements) that depends upon same-origin restrictions, the source of the stored content is important (and should anyway be known by the browser in most cases), but for the other parts (e.g. img tag and referenced scripts) it is irrelevant. Placing broad restrictions on widget-context webapp access to network resources (substantially different from browser-context webapps) is not an effective approach to creating a useful widget-context webapp platform. That would create a significant barrier to market acceptance of the W3C widget standards. Best regards, Bryan Sullivan | ATT -Original Message- From: Marcos Caceres [mailto:marc...@opera.com] Sent: Tuesday, November 10, 2009 7:30 AM To: SULLIVAN, BRYAN L (ATTCINW) Cc: WebApps WG Subject: Re: [WARP] Comments to WARP spec SULLIVAN, BRYAN L (ATTCINW) wrote: Marcos, I agree there is an assumption behind the approach I proposed, which I also believe will be valid for the vast majority of widgets which will actually have index.html or something like that as the start page. Further, the statements in the config.xml apply to all resources in the widget, not just the start page, i.e. I can start with a non-HTML which references an HTML file in the package, to which the tag attribute applies. So we are clear, the tag attribute does not work in the following situation. I want to disable x:script, but allow v:script... unless you know what the things different namespaces will not be added dynamically to the DOM: x:html xmlns:x=http://www.w3.org/1999/xhtml; ... x:script ... /x:script v:svg v:width=6cm v:height=5cm v:viewBox=0 0 600 500 xmlns:v=http://www.w3.org/2000/svg; version=1.1 v:script src=../v:script /v:svg /x:html If the proposed solution is inadequate, I welcome other suggestions. I don't have a suggestion because I don't believe this part of WARP is broken or is necessary. But as it stands, the WARP spec is not consistent with the web security model, so we need to fix theaccess element definition somehow. Well, the whole point of WARP is to put these boundaries around the behavior of widgets because they run locally. How a browsing context should behave when run locally is not really defined by HTML5. This leaves a gap for us to fill.
Re: [WARP] Comments to WARP spec
SULLIVAN, BRYAN L (ATTCINW) wrote: 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. Although I understand the rationale, I'm personally not in favor of trying to deviate too much from the Web security model. This proposal seems to make more work for authors rather than providing security enhancements. It also makes more work for implementers in that they need to change the security model of the browsers on which widget engines run. Kind regards, Marcos
RE: [WARP] Comments to WARP spec
Marcos, Re I'm personally not in favor of trying to deviate too much from the Web security model.: I agree with you, and that is the point of the comments. The web security model (I think you mean the same-origin restriction) does not restrict access to image content from anywhere, like the access element would. The access element as currently in the WARP spec goes beyond the web security model. My point is that the statement below in the WARP spec needs to change, because this is not compatible with the web security model, and also makes more work for implementers because the security model for widget-context webapps would not be the same as for browser-context webapps: 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). So either: (1) we need to be specific about which API's / resource types are affected by inclusion (or exclusion) of domains in access (and keep this equivalent to HTML5) (2) we must add a way for the developer to indicate which types of references should be allowed for the domain My preference would be (1), but I proposed the use of tag= to illustrate how (2) might work. Best regards, Bryan Sullivan | ATT -Original Message- From: Marcos Caceres [mailto:marc...@opera.com] Sent: Monday, November 09, 2009 2:01 AM To: SULLIVAN, BRYAN L (ATTCINW) Cc: WebApps WG Subject: Re: [WARP] Comments to WARP spec SULLIVAN, BRYAN L (ATTCINW) wrote: 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. Although I understand the rationale, I'm personally not in favor of trying to deviate too much from the Web security model. This proposal seems to make more work for authors rather than providing security enhancements. It also makes more work for implementers in that they need to change the security model of the browsers on which widget engines run. Kind regards, Marcos
[WARP] Comments to WARP spec
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/ Best regards, Bryan Sullivan | ATT
