RE: Updated Policy Requirements draft

Hi Frederick,

See my comments inline below.

Regards
  Claes

> -----Original Message-----
> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
> Sent: den 24 augusti 2010 15:45
> To: Nilsson, Claes1
> Cc: Frederick.Hirsch@nokia.com; public-device-apis@w3.org
> Subject: Re: Updated Policy Requirements draft
> 
> Claes
> 
> Thanks for the comments, see my remarks below
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> On Aug 23, 2010, at 6:07 AM, ext Nilsson, Claes1 wrote:
> 
> > Hi Frederick and rest of DAP,
> >
> > Thanks for the updates Frederick.
> >
> > I have reviewed the "Web Browser and Untrusted Widget" and the
> "Trusted Widget" use cases.
> 
> Thanks!
> 
> > The first use case makes sense and I have no specific comments on
> this one. For the second use case "Trusted Widget" the list of
> requirements is currently empty and I assume that this is due to the
> need to discuss this use case further.
> 
> Correct
> 
> > My comments follow concerns the case when the trusted widget use case
> is not combined with "delegated authority":
> >
> > * Isn't it to limiting to call this use case "Trusted Widgets"?
> People may have different views on what a widget is but I guess most
> people think of an installed "live" microstate application running at
> the device's home screen. Isn't the important things here that the web
> application in this case is installable and that it trusted by the
> signature? So, wouldn't it be more appropriate to call the use case
> "Trusted Installable Web Applications?
> 
> Yes, the key point is that it is a signed package, essentially treat as
> an installable application.
> 
> How about  naming this  "Trusted Application"? (trying to be pithy).
> This also gets at one of the approaches mentioned in Ian's paper at the
> privacy workshop (section 5, http://www.w3.org/2010/api-privacy-
> ws/papers/privacy-ws-24.pdf )

Yes, Ian addresses how all permissions could be given by the user at the time of installation. However, Ian says nothing about trust by a digital signature that is the main characteristic of this use case in the your document. Ian instead refers to trust by pro-
viding additional data about the application (including reputation data such as the number of other users using the application). So, if we keep the notion of "Trusted Application" then we might have to generalize the description of how trust is achieved. It could be a digital signature or it could be by other means. An alternative would be to instead define the use case as "Installable Application" that can have a weaker or stronger trust level.

Furthermore, we have the issue of embedded content from another domain than the top-level document. Even if we, at installation time, trust an application originating from a domain we trust, this application might download executable content from other domains. Ian addresses this in his paper in section 3. However, which approach should we take to this problem for installable web applications if we want to make it possible for the user to grant all APIs access as a single action at installation time? How much information could we provide to the user without making it too complicated? 

It would be interesting to hear Google's view on this based on their work with Chrome installable applications (http://code.google.com/chrome/apps/docs/index.html).


> 
> 
> >
> > * Should we also consider "Trusted Web Sites", i.e. sites accessed
> through SSL/TLS transport? I am not sure here because the secure
> transport only provides security between the client and the site
> hosting the web application and the application itself is not signed.
> 
> SSL/TLS only provides transient integrity/confidentiality, and only
> when the correct cipher suite is used. In addition the site itself is
> not necessarily secured or trustworthy, etc. What is the benefit of
> calling out "Sites reached with Secured Transport Mechanisms"? Maybe we
> should defer this for later.

Yes, I agree, let us defer this issue for later.

> 
> >
> > * The main issue here is in what way we could make the life easier
> for the user compared to case 1, i.e. in what way could we limit or
> simplify user interaction.
> 
> Correct
> 
> 
> > An immediate thought is of course to have an approach similar to
> installing applications on a desktop computer, i.e. displaying
> certificate information
> > and something like "Do you trust the author ....State Y/N" and have
> option to save the user's decision.
> 
> Users have never known what to do with certificate information, so I'd
> like to suggest we attempt to limit such dialogs.
> 
> > If the user decides to install the trusted application then no
> explicit user interaction would be required to access device APIs
> during the application's work flow. This approach could be used with
> any installing web application, unsigned or signed, but a verified and
> trusted signature will make it safer for user and the amount on
> information about the application provided to the user could be limited.
> 
> Yes, the issue is how without delegated authority to install the
> application. I guess we have to ask the user whether they wish to
> install and like other systems there is a risk here (e.g. with personal
> computers etc)
> 
> >
> > Your thoughts?
> >
> > Regards
> >  Claes
> >
> >
> >
> > -----Original Message-----
> > From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Frederick.Hirsch@nokia.com
> > Sent: den 18 augusti 2010 17:17
> > To: public-device-apis@w3.org
> > Cc: Frederick.Hirsch@nokia.com
> > Subject: Updated Policy Requirements draft
> >
> > Based on the Resolution and discussion on today's call, I have
> updated the policy requirements draft with the proposal I had made
> earlier, removing the phrase "un-managed" from web browser, and making
> some tweaks accordingly.
> >
> > Please review and discuss any suggested changes on the list.
> >
> > http://dev.w3.org/2009/dap/policy-reqs/
> >
> > Can we agree on next week's call to publish an updated WD of this
> document?
> >
> > Thanks
> >
> > regards, Frederick
> >
> > Frederick Hirsch
> > Nokia
> >
> > This should complete ACTION-254
> >
> >

Received on Wednesday, 25 August 2010 11:02:47 UTC