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

Hi Maciej,

I think we should separate the policy definition from its application.
We could have a single policy abstraction for browsers/OS vendors and all others.
At the risk of oversimplification we could summarize that such abstraction is just a list of applicable security concerns.
In some environments some third parties could be responsible for policy application (corporate, walled garden etc) within a configurable runtime/OS/etc and in the others the policy could be hard-coded and not modifiable (e.g. in a freely downloaded browser the browser vendor applies the policy once and forever).
Still we could have the same security concerns.

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: Maciej Stachowiak [mailto:mjs@apple.com]
Sent: Thursday, November 19, 2009 2:20 AM
To: Frederick Hirsch
Cc: ext Jonas Sicking; David Rogers; 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 Nov 18, 2009, at 5:13 PM, Frederick Hirsch wrote:

> This is a good point, and an argument for "policy" rather than
> implicit user consent, if I'm not mistaken. It highlights that
> usability might also be an issue with the non-modal interaction
> model,  as well as not always be very meaningful (since I the user
> might have no idea what most directories are for or where to
> navigate). Arbitrary directory navigation for writing files is not a
> good idea.

"policy" is not a solution to the scenario Jonas posted either. Who is
going to define a home PC or Mac user's browser policy? The user
doesn't have the expertise to do it. There's no sysadmin to do it for
them. And browser/OS vendors should not be in the game of whitelisting
a specific set of sites for extra access.

Regards,
Maciej

>
> More importantly we have to be careful with analogies.
>
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Nov 18, 2009, at 3:14 PM, ext Jonas Sicking wrote:
>
>> 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:16:20 UTC