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

Re: new Privacy Best Practices draft

From: <Frederick.Hirsch@nokia.com>
Date: Thu, 14 Jul 2011 18:05:39 +0000
To: <dom@w3.org>
CC: <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>
Message-ID: <3ED5F9B9-3768-472F-8646-002E88F58106@nokia.com>
Dom

I've updated the Privacy Best Practices draft, including adding a new section to summarize the Best Practices. I also restructured it a bit.

Thanks for your comments, I updated the document based on them as well, see details below.

Any additional review should be on the revised document.

http://dev.w3.org/2009/dap/privacy-practices/

regards, Frederick

Frederick Hirsch
Nokia



On Jul 8, 2011, at 8:50 AM, ext Dominique Hazael-Massieux wrote:

> Hi,
> 
> Le mardi 05 juillet 2011 à 21:15 +0000, Frederick.Hirsch@nokia.com a
> écrit :
>> I have created an initial draft of  a Privacy Best Practices document for service providers.
>> see http://dev.w3.org/2009/dap/privacy-practices/
> 
> Thanks for getting this started!
> 
> Some early comments (I'd probably have much more after a more thorough
> reading, but I thought I would send what already appeared to me):
> * the document's title refer to device APIs; I think the current content
> doesn't match this scoping:
> - it seems to apply more broadly than when using APIs
> - it applies more broadly than just "device" APIs (assuming this has a
> clear definition)
> Fixing this could mean either broadening the title, or reducing the
> actual scope, or a combination of both


changed to "Privacy Best Practices for Service Providers"


> 
> * I think the document should strive to use as little privacy-jargon as
> possible and instead use language that will make sense to services
> providers and developers; I would probably argue e.g. against having a
> section called "minimizing data" since it only makes sense to people who
> have been exposed to the concept of data minimization; in this case, it
> could be as simple as rewording it in "minimize collection and
> transmission of personal data"
> 

I don't see much jargon but perhaps I'm too close to it. Made the change above, thanks

> * the best practices mix imperative language ("do this"), affirmative
> language ("A is B", or "A requires B"), and RFC2119 language ("X should
> do Y"); I think we should align on a single form as much as we can 
> 

I made it uniform, e.g. "Follow "Privacy By Design" principles"

I added a "Best Practice Summary" section that lists all of them:

http://dev.w3.org/2009/dap/privacy-practices/#bp-summary

> * I think giving plenty of examples would be terrific

If anyone can help that would be very good, but I'll work on this

> 
> * there should be something about using HTTPs to transmit
> personal/sensitive data over the network

added confidentiality section. Possibly too strong on need for confidentiality of storage, but I think we've seen too many cases of servers being hacked on to provide complete lists of personal data to the perpetrators.

> 
> * while referencing privacy by design is good, I don't think that most
> of our readers would actually bother; it would probably be better
> documenting how these principles apply concretely to the development of
> Web apps using sensitive APIs.

listed the principles explicitly without repeating the detail which is referenced, revised language of best practice

> 
> * the bits on "minimal consent dialogs" don't seem to apply to services
> providers but more to UA? at least it's not clear to me how it would
> apply to services provider
> ; likewise for the discussion on "making
> decision in context".
> 

Revised this to reflect possible use by service providers.

> Some links to previous discussions on these BP that may be worth
> exploring:
> http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/att-0154/minutes-2010-03-16.html#item01
> http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-21.pdf

I already looked at these before creating the first draft, but may have missed something. Thanks for the reminder

> 
> Dom
> 
Received on Thursday, 14 July 2011 18:06:24 UTC

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