W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2010

Proposed privacy requirements document changes - to address issues in document

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Tue, 20 Apr 2010 16:01:16 -0400
Message-Id: <141AF549-F407-4BD9-9237-0E63A0277E1A@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
It seems that some of the issues noted in the privacy requirements  
document can be  addressed if we accept the ruleset approach.

In general it seems that choice of a specific ruleset should apply to  
all APIs uniformly, impacting them where appropriate. This simplifies  
the notice aspect since the user simply needs an indication of whether  
a privacy ruleset is in force and be able to display the text  
associated with it. However the URI for the ruleset should be passed  
in all primary API calls as an optional parameter so that it can be  
conveyed to recipients of the information as needed.

In order to progress this document I propose the following changes  
along these lines to the privacy requirements document:

(1). Remove (close) the two issues in section 1.2 "Privacy Principles  
relevant to APIs" and add the following text to the end of the section:

[[

User expectations beyond the default privacy elements supported by the  
individual device APIs may be expressed and shared using privacy  
rulesets [[PrivacyRulesets]], identified by URI.
The user may select a privacy ruleset and this ruleset URI MUST be  
conveyed using an optional parameter to all primary API methods that  
invoke a service. An  example is the <code>captureImage</code> in the  
Capture API [[CAPTUREAPI]]. This approach is to be general across the  
various API definitions.

The details of the definition and management of privacy rulesets are  
out of scope of the API definitions and this document. The Privacy  
Ruleset document provides information and guidelines but will not  
proscribe the detailed rulesets to be used.

User agents MUST enable users to select and change a privacy ruleset  
preference at any time.

]]

(2) In section 2.1 Notice, remove first issue addressed by ruleset  
proposal.

(3) In section 2.1 Notice, second issue,

"Is it possible to provide an indicator that user data is being used,  
and enable follow up action from the user to determine how it is being  
used? (e.g. visual indicator and means to access log)"

address by adding requirement

User Agent MUST provide means for user to determine the default  
privacy ruleset in force at any time, and SHOULD provide a visual  
indicator that a privacy ruleset is in force. If an indicator is  
displayed an approach could be to allow selecting this indicator to  
see the text associated with the ruleset in force, and to be able to  
change rulesets (or have none).

(4) Section 2.4

I believe we can handle revocation of consent by changing or removing  
the default ruleset, and not needing any additional mechanism (not  
going back into the past). Details of meaning are based on the ruleset  
definition. UA control aspect suggested in my comment above.

(5) I suggest we add a reference to the ruleset document, and plan to  
publish FPWD of these two at the same time.

thoughts?

regards, Frederick

Frederick Hirsch
Nokia
Received on Tuesday, 20 April 2010 20:01:52 UTC

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