RE: [WARP] Last Call comments (1)

Hi Robin,

Herewith I reply to both your recent answers [1] and [2].

It is good for me to see that the intentions and scope of the WARP spec get clarified upon discussion.

>> Schemes such as sms and tel are definitely out of scope for
>>this simple approach.
If so, then please add clear rules to the spec which schemes are in scope.
These are the hints:

a)
"A network resource is a retrievable resource of any type that is identified by a URI that has a DNS or IP as its authority."
So here sms: and tel: seem out of scope. What about E164 and DNS [3]?
Another edge case:
sms:+41796431851;pid=smtp:ietf@dret.net from [4]

b)
"This special value provides a means for an author to request from the user agent unrestricted access to resources through any and all schemes and protocols supported by the user agent."
Here the set of schemes is infinite. So I suggest adding the relevant text, e.g.
"This special value provides a means for an author to request from the user agent unrestricted access to network resources through any and all schemes and protocols that have DNS or IP as its authority and that are supported by the user agent.

>>Schemes such as sms and tel are definitely out of scope for this
>>simple approach. Even if they weren't they would *still* be out of
>>scope for <access> because they aren't network resources. You can't
>>make an XHR request to sms:, it is meaningless to have <img
>>src='tel:...'/>. These are therefore rejected immediately - just
>>because it has a scheme doesn't mean it's a network resource, those
>>are two completely separate things.
Can you do XHR to mailto:? Or <img src='mailto:...'>?
But mailto: is explicitly mentioned in WARP.

>>There is a major distinction here. When you use mailto: or tel:, it
>>triggers an external application (email client, phone dialer)
Not necessarily. My mail client may be another widget/webapp.
Similarly to tel: (depends on DAP).

>> and you
>>can decide from within that application whether to enact those. If you
>>have access to a messaging or calling API, then you can do those
>>stealthily - but that's not WARP's problem, it's DAP's problem.
>From the security point of view it does not matter whether a message or a call was accomplished by a programmatic call to device API or by an external application that was triggered by the URI embedded in a widget. If restricted, it should simply not happen. I understand that this is a DAP issue, therefore I suggest to leave it all to DAP.

In general, if the text of WARP specifies that WARP is only about http, https, and XHR I could live with it.


Thanks,
Marcin

[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1113.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1114.html
[3] http://www.ietf.org/rfc/rfc2916.txt
[4] http://tools.ietf.org/html/draft-wilde-sms-uri-00#section-2.4

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: Robin Berjon [mailto:robin@berjon.com]
Sent: Thursday, September 17, 2009 4:27 PM
To: Marcin Hanclik
Cc: Marcos Caceres; public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)

On Sep 7, 2009, at 15:11 , Marcin Hanclik wrote:
>>> is pretty simple, logical, and gets the job done for most use cases.
>
> The above is not the case e.g. for mailto: or tel:, specifically if
> you want to be more specific/selective with the additional arguments
> (a la subdomains).

There is a major distinction here. When you use mailto: or tel:, it
triggers an external application (email client, phone dialer) and you
can decide from within that application whether to enact those. If you
have access to a messaging or calling API, then you can do those
stealthily - but that's not WARP's problem, it's DAP's problem.

What WARP is concerned with is whatever access can be made without
user interaction (an img/@src, or an XHR request) that is possible
today in a WRT. Anything else is out of scope, and is DAP's job.

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

Received on Thursday, 17 September 2009 15:12:38 UTC