[WARP] Comments to WARP spec

[SULLIVAN, BRYAN L (ATTCINW)]

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 | AT&T

[Marcos Caceres-3]

2009/11/2 SULLIVAN, BRYAN L (ATTCINW) <BS3131@...>:

> 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

[SULLIVAN, BRYAN L (ATTCINW)]

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@... [mailto:marcosscaceres@...] 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@...>:

> 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

[Marcos Caceres-3]

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

[SULLIVAN, BRYAN L (ATTCINW)]

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 | AT&T
-----Original Message-----
From: Marcos Caceres [mailto:marcosc@...]
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

[Marcos Caceres-3]

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 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.
>

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.

[SULLIVAN, BRYAN L (ATTCINW)]

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 | AT&T
-----Original Message-----
From: Marcos Caceres [mailto:marcosc@...]
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 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.
>

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.

[Marcos Caceres-3]

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 the<access>  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.

[SULLIVAN, BRYAN L (ATTCINW)]

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 | AT&T
-----Original Message-----
From: Marcos Caceres [mailto:marcosc@...]
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 the<access>  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.

[Marcos Caceres-3]

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.

[Marcin Hanclik]

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: [phone]  |  Fax: [phone]
Mobile: [phone]
E-Mail: marcin.hanclik@...

-----Original Message-----
From: public-webapps-request@... [mailto:public-webapps-request@...] 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 the<access>  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.

[Marcos Caceres-3]

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 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?
>

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

[Marcin Hanclik]

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: [phone]  |  Fax: [phone]
Mobile: [phone]
E-Mail: marcin.hanclik@...

-----Original Message-----
From: Marcos Caceres [mailto:marcosc@...]
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 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?
>

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.

[Marcos Caceres-3]

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.

[SULLIVAN, BRYAN L (ATTCINW)]

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();">
        <p>Not 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/>
        <p>Test 1: If the widget engine does not allow external script references, no you will
        see "boohoo!" below:</p>
        <div id=test1></div>
        <hr/>
        <p>Test 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 | AT&T

-----Original Message-----
From: Marcos Caceres [mailto:marcosc@...]
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-3]

On Fri, Nov 13, 2009 at 6:39 AM, SULLIVAN, BRYAN L (ATTCINW)
<BS3131@...> 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();">
>        <p>Not 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/>
>        <p>Test 1: If the widget engine does not allow external script references, no you will
>        see "boohoo!" below:</p>
>        <div id=test1></div>
>        <hr/>
>        <p>Test 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 | AT&T
>
> -----Original Message-----
> From: Marcos Caceres [mailto:marcosc@...]
> 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

[Robin Berjon-2]

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/

[Robin Berjon-2]

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/

[SULLIVAN, BRYAN L (ATTCINW)]

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:robin@...]
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/

[SULLIVAN, BRYAN L (ATTCINW)]

In this case, it is definitely better late than never. And months is really not that long for a feature to undergo initial scrutiny (especially over summer), and further scrutiny for consistency within the broader set of specifications.

I think the statement that "the default is defined by the security policy of the host language" is good, or more specifically "the default security policy is defined by the specifications governing processing of the widget content".

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Robin Berjon [mailto:robin@...]
Sent: Wednesday, November 18, 2009 4:00 AM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: Marcos Caceres; WebApps WG
Subject: 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/