- 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