Re: Proposed privacy requirements document changes - to address issues in document

Back in March, I had brainstormed about the space of possible  
requirements for each of the privacy elements, including notice.  
Looking back at  http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0027.html 
, here is the notice piece:

> Notice
> (i) whether the UA needs to notify users before their data is sent  
> to a requestor; how that notification happens; what that notice  
> should contain; whether the UA needs to notify users as their data  
> is sent to requestors (see, e.g., the discussion that started at  
> [Geolocation2])
> (ii) whether requestors need to provide notice of the fact that they  
> are collecting user data and the primary purpose for which it is  
> being collected; how that notification happens; what that notice  
> should contain
>


In your notice discussion below, you are highlighting an additional  
aspect of notice, which is the aspect about the privacy rulesets being  
conveyed. I think that's a fine idea, but I don't think it obviates  
the need for a requirement about simply notifying users that their  
data is being collected by an API. The simple notification is  
important and could be expressed in a requirement such as:

APIs MUST make it possible for user agents to notify users that their  
data is being collected via the API.

More inline...

On Apr 20, 2010, at 4:01 PM, Frederick Hirsch wrote:

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

Actually I thought this issue was about *applications* conveying their  
intended use of data to users, not *users* conveying their preferences  
to applications. Only the latter is covered by the rulesets.

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

Are you assuming that the indicator would be used to express both what  
the ruleset is and the fact that the user's data is being conveyed?


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

I'm not sure that I agree. The rulesets only cover what happens to the  
data after it's been shared with the app. If users consent to have an  
app access their contacts, and they later decide they don't want the  
app to be able to do that anymore, there should be a way for them to  
revoke that consent. This isn't covered by the rulesets as they stand  
now.

Alissa

>
> (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 Wednesday, 21 April 2010 13:53:12 UTC