- From: David Rogers <david.rogers@omtp.org>
- Date: Thu, 19 Nov 2009 10:49:00 -0000
- 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 system. [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. Adam
Received on Thursday, 19 November 2009 10:49:56 UTC