Hi Jonas, I think that it all depends on the user or the abstraction that we seem to have about the user.
We can take the analogy to the operating system. OS may e.g. not be writable for the user, may have pre-defined active firewalls etc. The user then may not access some sites, may not install any native app etc. The OS or PC is a kind of a toy or a kiosk. Later, the user switches off firewalls, gets admin rights, installs apps that have access to the file system etc. I think that the same principle is being applied to the browser world. Policy is to make it all easier and more comprehensible. The default settings within a browser could e.g. disable directory walking and file writing. But if the user changes the settings (and is warned about the potential security risks when switching some protection off), then it is up to the user and she/he takes over the responsibility. The abstraction of the security concerns within a policy may allow delegation of the security to some third parties. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -----Original Message----- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Wednesday, November 18, 2009 9:15 PM To: David Rogers Cc: Maciej Stachowiak; Marcin Hanclik; Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename "File API" to "FileReader API"?) On Wed, Nov 18, 2009 at 5:27 AM, David Rogers <david.rog...@omtp.org> wrote: > Hi Maciej, > > >From my side I'd like to understand what your thoughts and proposals for > >file writing security / policy would entail - would you defer the decision > >responsibility to the user via a prompt? >From my point of view the answer is unfortunately "there are no simple answers, it's always a judgement call". For example for the geolocation the security model is basically: 1. Page asks for user position 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answers "yes" then the position is returned to the page. In this case I think this was an acceptable solution. If we added a directory API which gave access to a requested path on the users hard drive we could use a similar security model: 1. Page asks user for permission to read/write to a specific directory, say "C:\" 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answeres "yes" a reference to the directory is returned which the page can read from/write to. This would *not* be an acceptable solution to me, despite being basically identical to the geolocation case. The reason is two-fold. I think it's easier to explain to the user what the user is authorizing ("your location"), and if a user doesn't understand and still clicks "yes", it has less catastrophic results. For the directory API though, it's much harder to explain the decision to the user. What's the "C:\" directory? What's the difference between that and "C:\Documents and Settings\Jonas Sicking\My Images"? What's a directory? Also, if a user clicks "yes" without understanding the risks, that has catastrophic results if the directory in question is "C:\" and read/write access is granted. When it comes to security dialogs, the basic rule to keep in mind is "Lots of people are not going to understand it and just click whatever button they think will get stuff to work, or a random button". / Jonas ________________________________________ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
