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

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

From: David Rogers <david.rogers@omtp.org>
Date: Thu, 19 Nov 2009 10:49:00 -0000
Message-ID: <4C83800CE03F754ABA6BA928A6D94A0601E5FACC@exch-be14.exchange.local>
To: "Adam Barth" <w3c@adambarth.com>, "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-webapps WG" <public-webapps@w3.org>
My comments:

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Adam Barth
Sent: 19 November 2009 07:42
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

[DAVID] I would hope that we can come up with some clever API design in terms of safe logic. However, this does not solve the whole problem, at some point you need to make a decision / judgement call. What the policy advocates are proposing is to advance the whole discipline here - let's improve this by adding strength in depth and allow the user to defer their decision to someone who they trust, who is willing to take the decision for them.

Received on Thursday, 19 November 2009 10:49:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:13 UTC