Hi David,
Thanks for your questions.
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.
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? 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.
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.
-- A*
