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.hanclik@access-company.com

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

Received on Thursday, 12 November 2009 15:37:23 UTC