RE: DAP and security (was: Rename "File API" to "FileReader API"?)

Hi Adam,

>>Abstracting the problem doesn't make the security challenges
>>any easier.
I agree.
The implementations still need to properly code the abstractions, and additionally have to properly capture the application of the policy. So the work virtually doubles.
The only difference / advantage of having the abstraction is that the way of operation is configurable.
That's what the policy is in the nutshell.

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: Adam Barth [mailto:w3c@adambarth.com]
Sent: Thursday, November 19, 2009 8:42 AM
To: Marcin Hanclik
Cc: Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; public-device-apis@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename "File API" to "FileReader API"?)

On Wed, Nov 18, 2009 at 6:16 AM, Marcin Hanclik
<Marcin.Hanclik@access-company.com> wrote:
> The first step is to have the security concerns.
> The widget environment, BONDI etc. then encode them somehow (e.g. as device capability, feature etc.) creating an abstraction.
> In case of the browser, those concerns seem to be simply coded in the browser.
> Still the concerns remain and are handled.
> The widgets spec try to abstract them in order to give the freedom either to the end user, administrator, operator or any other party. Alternatively they could be simply hard-coded in the webruntime.  So the issue is only who is able to specify whether the policy is applied, the concerns are still there.

I'm skeptical that this approach will lead to a secure API for file
access.  Abstracting the problem doesn't make the security challenges
any easier.  The reason the HTML file upload control has been such a
successful secure API for reading files is because the security issues
are specifically *not* abstracted.  The entire API is designed around
the security considerations and eliciting user consent in a
easy-to-understand way.

I suspect we'll need a similarly clever API design to address the
security challenges of letting web content write to the user's file
system.

Adam

________________________________________

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, 19 November 2009 09:24:10 UTC