W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 18 Nov 2009 17:20:27 -0800
Cc: ext Jonas Sicking <jonas@sicking.cc>, David Rogers <david.rogers@omtp.org>, Marcin Hanclik <Marcin.Hanclik@access-company.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>
Message-id: <1D42AF7F-0094-425A-819D-DA5D0C9F9803@apple.com>
To: Frederick Hirsch <frederick.hirsch@nokia.com>

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
>>
>
Received on Thursday, 19 November 2009 01:21:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT