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 )


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

> 
> * 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 Tuesday, 24 August 2010 13:45:38 UTC