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

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.hanclik@access-company.com

-----Original Message-----
From: Jonas Sicking [mailto:jonas@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-apis@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.rogers@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.

Received on Thursday, 19 November 2009 09:09:28 UTC