W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2011

Re: Proposal for additional deliverables in rechartering DAP

From: Robin Berjon <robin@berjon.com>
Date: Wed, 9 Mar 2011 15:37:29 +0100
Cc: Frederick.Hirsch@nokia.com, Arthur Barstow <art.barstow@nokia.com>, public-device-apis@w3.org
Message-Id: <6D07FAC5-A6B3-4FE1-AA12-61E1CDE37194@berjon.com>
To: Dominique Hazael-Massieux <dom@w3.org>
On Mar 9, 2011, at 14:44 , Dominique Hazael-Massieux wrote:
> 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.

I certainly hear your concerns, but I wonder if we can't have it anyway. To me, scoping problems are largely related to patent policy. If the scope of a deliverable is too fuzzy, lawyers at some companies will be afraid of greenlighting participation because they won't be able to assess the risk to the company's portfolio. We may not all enjoy taking that into account, but it's part of the game.

But is this really a risk for privacy-related deliverables? Or was your concern more that this should go into a group that has that issue as its primary focus? What I like about keeping it in this group is that since our API deliverables are privacy-sensitive, it creates a built-in feedback loop. I've found this quite useful so far, though of course I can appreciate that not everyone might want to be exposed to all the discussions.

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

+1 on that.

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

+1, I think that this could prove useful in a number of contexts, notably the work by various browsers on installable web applications.

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

Yes indeed.

Robin Berjon - http://berjon.com/
Received on Wednesday, 9 March 2011 14:38:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:48 UTC