Re: DAP and security (was: Rename “File API” to “FileReader API”?)

OK, I will take your word for it that security is an important  
consideration for DAP. But while at the TPAC, I heard more than one  
DAP participant say, when faced with a potential security concern,  
something like "can't we just leave that up to the policy?" In one  
case when I enquired further, at least one DAP member mentioned to me  
the idea of using some sort of "policy file" that would take care of  
all security issues. He suggested this might come from a corporate  
administrator, and that the format would be XML, but otherwise details  
were light.

To me that seems like a plausible model for something like widgets or  
browser extensions or walled garden content, but not for sites on the  
public Web.

My apologies if I misinterpreted these remarks or got the wrong  
impression.

One more comment below:

On Nov 18, 2009, at 4:18 AM, Marcin Hanclik wrote:

> +1
> APIs - specifically their design - shall be specified tightly with  
> the security model in mind to make them both easy to use and  
> effective.
> This is what makes the whole task that difficult.
>
> 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: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org 
> ] On Behalf Of Dominique Hazael-Massieux
> Sent: Thursday, November 12, 2009 10:30 AM
> To: Maciej Stachowiak
> Cc: Robin Berjon; public-device-apis@w3.org; public-webapps WG
> Subject: DAP and security (was: Rename “File API” to “FileReader  
> API”?)
>
> Le mardi 10 novembre 2009 ŕ 17:47 -0800, Maciej Stachowiak a écrit :
>> I would be concerned with leaving file writing to DAP, because a
>> widely held view in DAP seems to be that security can be ignored  
>> while
>> designing APIs and added back later with an external "policy file"
>> mechanism.
>
> Frederick already mentioned this isn’t the case at all, and I want to
> strongly reject the notion that DAP is considering security as an
> after-the-fact or out-of-band aspect in the design of its APIs.
>
> Our charter clearly stipulates that our policy model “must be  
> consistent
> with the existing same origin policies (as documented in the HTML5
> specification), in the sense that a deployment of the policy model in
> Web browsers must be possible”.

It seems to me that for most of DAP's likely deliverables, there are  
serious security considerations, but the same-origin policy is  
irrelevant to addressing them. The same-origin policy is designed to  
protect Web sites from attacks by other Web sites. It does not really  
apply to access to system resources. Doing that in a Web-safe way will  
require new inventions or might not even be possible in some cases.

>
> In fact, most of models that have been discussed in this thread to
> reduce the risks exposed by new APIs (sandbox for writing, user
> interaction or markup-based element for sharing data) were already
> mentioned as options by DAP WG participants during our F2F last week.
>
> More generally, I don’t think assuming that DAP would create worse/ 
> less
> secure APIs than WebApps or any other group would is either right nor
> useful to ensure a good collaboration between our groups. And clearly,
> we will actively be seeking feedback and input from the WebApps  
> Working
> Group when we produce new APIs, which should also contribute to reduce
> the fears that we would get it all wrong :)
>
> Regards,
>
> Dom
>
>
>
>
> ________________________________________
>
> 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 Wednesday, 18 November 2009 12:36:12 UTC