W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

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

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 18 Nov 2009 23:42:15 -0800
Message-ID: <7789133a0911182342l1a610af7pfc31a942ffd786da@mail.gmail.com>
To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Dominique Hazael-Massieux <dom@w3.org>, Robin Berjon <robin@berjon.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, public-webapps WG <public-webapps@w3.org>
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

Received on Thursday, 19 November 2009 07:49:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:40 UTC