- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 09 Mar 2011 14:44:02 +0100
- To: Frederick.Hirsch@nokia.com, Arthur Barstow <art.barstow@nokia.com>
- Cc: public-device-apis@w3.org
Le vendredi 04 mars 2011 à 17:39 +0000, Frederick.Hirsch@nokia.com a écrit : > To fill this gap we could add two additional deliverables: > > (1) "Privacy Mechanism" recommendation track deliverable. > > To support privacy by design principles we may need to outline > mechanisms across the specifications. This may relate to various "do > not track" efforts going on, rulesets, or other approaches, but the > charter should allow work in this area. I'm torn about this one; I think there is work to be done in the area, there is clearly interest from the industry, but I don't know that we have a clear enough scope of the work to put something in the charter as a Recommendation track deliverable. We had also discussed writing a best practices document on writing privacy-sensitive Web applications; I don't know if this still on the table or not, but could be another item in this field. > (2) We also need to call out an explicit deliverable for permissions, > > "Feature Permissions" recommendation track deliverable [FeaturePermissions] > What do you think? Yes, I think it's worth keeping that deliverable in scope. Regarding Art's question about their relationship of these works to the priority Web APIs: the way I envision it at this time, these works should not block the work on APIs, but rather complement it with an additional layer. My reasoning is that if any of the security/privacy work is to be useful, it needs to apply to already existing APIs (Geo, Accelerometer) and to APIs developed outside of this group. Dom
Received on Wednesday, 9 March 2011 13:44:18 UTC