RE: Transferring File* to WebApps - redux

Hi Arun,

-----Original Message-----
From: Arun Ranganathan [mailto:arun@mozilla.com] 
Sent: 16 June 2010 19:48

On 6/16/10 2:16 AM, David Rogers wrote:
>    
>> The question of where you are represented and your ability to
>> participate cuts both ways - the same is true for us. I think if the
>> browser vendors want their products really to be seen as compatible
>>      
> with
>    
>> the Web application space (as compared to just dynamic Web pages),
>>      
> they
>    
>> will support the work in DAP as its there that non-obtrusive and
>> inherently secure models for Web application access to device
>>      
> resources
>    
>> will be defined as APIs.
>>
>>      
> At present time, I think that the paragraph above accurately
summarizes
> a technical rift between certain members of both working groups (DAP
and
>
> WebApps).  It may not be worthwhile to resolve this rift, and we
should
> allow disparate families of specifications to bloom, taking care not
to
> cause developer confusion with naming (a hard problem).  Where
> specifications worked on in the DAP WG lend themselves to
implementation
>
> plans, I think Mozilla participants interested in these can comment on
> them (e.g. Contacts API, at least for now).
>
> [DAVID] I don't think it is worth creating a schism. The file API
hadn't
> been touched since 2006 when we started looking at this work so it is
> good that we have managed to help motivate some further work on it. A
> number of browser vendors are involved in DAP and are starting to
build
> DAP APIs so I think this might be an incorrect assumption too. We're
all
> in this together, so let's try and get it right for the user.
>
> The key question remains around security model. OMTP members believe
in
> separating policy for good security reasons and to advance the general
> discipline away from the natural answer which would be 'provide a
prompt
> or explicit user interaction'. If we slip back into this old way of
> thinking, we are destined for failure. Yes, at some point you need
user
> interaction but let's try to minimise that in an intelligent manner
> which means that the user is not bombarded with prompts, making the
> system less secure. So, some questions from me:
>
> 1) I want to make sure that we can continue the good privacy work that
> has been started in DAP - please can you clarify if you would propose
> adopting those requirements if transferred to WebApps?
>    

I think you are referring to: 
http://dev.w3.org/2009/dap/docs/privacy-license.html .  Is that correct?

If so, that's a document that seems like a really good start.  There's 
an upcoming workshop on this subject for which Aza Raskin has submitted 
a paper which also posits a "license" style model, but couples it with 
easy user-readable icons.  I don't mind where general privacy guidelines

live.  I think what's wise is to allow for maximum browser vendor 
review, but additional charter items on WebApps is hard.  I think we can

review sensible privacy guidelines wherever they live; they don't have 
to be transferred, but widespread review is desirable.

It might be useful to decouple privacy from a secure model for APIs.

[DAVID] I was actually referring to:
http://dev.w3.org/2009/dap/privacy-reqs/ 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.

> 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)?
>    

Are you talking about the email Robin sent about transferring FileWriter

and FileSystem over to WebApps? 

[DAVID] Yes, that is what this whole message thread is about.

 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?

> 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.

Thanks,


David.

Received on Wednesday, 16 June 2010 19:59:47 UTC