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

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

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 21 Apr 2010 09:53:47 +0200
To: Frederick Hirsch <frederick.hirsch@nokia.com>
Cc: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Message-ID: <1271836427.3825.7.camel@localhost>
Le mardi 20 avril 2010 à 16:01 -0400, Frederick Hirsch a écrit :
> 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:

I would close the second issue, but keep the first one — we don't know
yet if privacy rulesets will indeed address the difficulties that the
first issue raises.

I think it's worth adding a reference to privacy rulesets from that
section, but I wouldn't present it as a solution quite yet (and
solutions probably aren't needed in a *requirements* document anyway :)

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

Again, let's not presume that privacy rulesets is a workable solution
quite yet.

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

Hmm... I don't think this document is the right place to put
requirements on user agents — we're talking about requirements for our
specifications, not for the products that implement it.

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

I'm fine with publishing privacy-reqs as FPWD; I'm not sure about
privacy-rulesets yet.

Received on Wednesday, 21 April 2010 07:53:56 UTC

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