Re: Transferring File* to WebApps - redux

On 6/16/10 12:59 PM, David Rogers wrote:
>
> [DAVID] I was actually referring to:
> http://dev.w3.org/2009/dap/privacy-reqs/

(As mentioned in previous correspondence, I think securing an API and 
privacy can be decoupled, but both are very relevant topics).

I've read that document and think that much of it is reasonable (the 
first section matches the section in the licensing document, which I 
thought was reasonable), but I strongly disagree with the explicit vs. 
implicit reasoning here.  You say:

"D evice APIs may also be defined such that consent must be explicit, 
not implicit. Examples are a camera API that takes a photograph without 
user involvement, or a messaging API that sends a message without the 
user pressing "send." In these cases dialogs may be required."

A Camera API that takes a photograph without user involvement seems like 
something that is risky to build into web content, and I'm not sure I 
totally understand the use case behind it.  Earlier email threads have 
raised the issue of the policy-file based security model.  While you say 
dialogs 'may' be required, you also make a case for not overwhelming the 
use with dialogs.  This isn't as clear as it could be.

Bryan's email -- 
http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1050.html 
-- gives a good explanation of points where it may make sense to specify 
additions to the API.  Robin's email -- 
http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1055.html 
-- proposes a layered approach in the File* context which makes sense, 
namely layering into the existing File model additional features that 
cross the current sandbox.



> and yes I don't want to
> pre-judge the outcome of the workshop but we all pretty much acknowledge
> that there are privacy issues we need to deal with and that the design
> of any the work we're doing here should take it into account (in the
> same way as security). The whole basis of establishing the DAP working
> group was to protect the consumer and improve on the current status quo.
> Like you, I'm not precious about where things live, but I just want to
> make sure that if the file related APIs go into webapps that we can
> continue in that spirit, not just forget all that - otherwise there is
> no point and you won't see take-up of the API in the long-term because
> it would be too risky. As I said before, there is no value in creating a
> schism here, it would create more problems for W3C as a community and is
> absolutely needless.
>    

I think privacy is important.  I think security is important.  I think 
wherever work is done, both should be respected.

>    
>> 2) Also, please can you outline the security model that you will
>>      
> propose
>    
>> if it does transfer to WebApps - would it allow for management of
>>      
> access
>    
>> to the file system by policy (in the BONDI manner or by Google
>>      
> Powerbox
>    
>> or Mozilla's separate policy scheme)?
>>
>>      
>
>    


>   If so, the security model (which needs
> more work and shouldn't be considered final by any means) probably
> shouldn't be based on policy schemes like BONDI's policy language.  I'm
> not sure yet what to make of PowerBox, but I'm personally not
> considering it in this regard.  There isn't a separate Mozilla policy
> scheme, but the same-origin scheme for scripts and the separation of
> chrome content and web content is applicable here.
>
> [DAVID] So I'll take that as an agreement that we need to address the
> security model properly before we can progress. Can we work together to
> achieve this?
>    

Certainly.  If you have concerns about security (or privacy) in any 
WebApps API, you should share these on the listserv.
>    
>> 3) Would your proposed API require prompts to the user and explicit
>>      
> user
>    
>> acceptance of some sort?
>>
>>      
> *Which* proposed API?  The File API (covering FileReader) already uses
> the existing selection mechanism via input elements, and is shipping in
> Firefox 3.6.3.  This does have explicit user acceptance, but this model
> has already been around in the web for interacting with file systems.
> We should secure this model further in lieu of proposing a new one.  So,
>
> earlier proposals for spawning a script-only FileDialog were abandoned.
>
> [DAVID] Yes agreed, so this is where OMTP and Google are coming from -
> we need to deal with this issue head-on. How would you propose to deal
> with file writing if you need explicit user acceptance - bombard the
> user with prompts? It doesn't and can't work and is an out-of-date
> mechanism that has been abused for years via social engineering and
> technical means. Users end up having to download applications to do this
> sort of stuff now for picture uploading etc. Let's try and tackle it
> together and come up with a decent solution, but first we need to agree
> that these issues will be properly taken into consideration if file
> writing moves over from DAP.
>    

The user shouldn't be bombarded with prompts, nor should user 
notification be bypassed.  You've identified an important issue, which 
is also an issue in Eric's specification:

http://dev.w3.org/2009/dap/file-system/file-writer.html#obtaining-file-writers

The existing mechanisms ("Save As" or "input selection" along with 
additional "saveas" semantics) are considered here.  I'd consider this 
work in progress, and there is more than enough room for constructive 
discussions on how to secure the experience.

-- A*