- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 18 Nov 2009 23:42:15 -0800
- 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 system. Adam
Received on Thursday, 19 November 2009 07:49:31 UTC