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

Ruleset issue review

From: <Frederick.Hirsch@nokia.com>
Date: Fri, 19 Aug 2011 21:53:23 +0000
To: <public-device-apis@w3.org>
CC: <Frederick.Hirsch@nokia.com>
Message-ID: <34C9B769-3A7B-4064-B64F-A7E4E152B220@nokia.com>
We have the following issues recorded in tracker related to privacy rulesets and I offer some comment below.

ISSUE-87	Degree of ruleset transmission with API calls, how often, which	2010-07-13	

ISSUE-88	User interaction for ruleset confirmation when multiple APIs are used to provide functionality, usability etc	2010-07-13

ISSUE-95	Different regulatory environments and relationship to privacy and rulesets	2010-07-16

ISSUE-89	Clarify how rulesets interact with pre-existing relationships	2010-07-13

(1) ISSUE-87, ISSUE-88

These two issues are somewhat related in that I would argue the intent of the rulesets proposal is to allow a user to convey intent to a service each time they establish a session with that service to accomplish a task. A service provider may invoke multiple javascript APIs associated with a page (or pages) as part of that session.

Thus we need the concept of a session with a service provider and to convey all ruleset intentions relevant at the start of each session, thus allowing the service provider to know user intents and behave appropriately.

This includes ISSUE-88  since it is the responsibility of the service provider that aggregates use of various APIS in creating a service to evaluate the composition of API uses.

Thus ruleset intents only need to be sent when establishing a browser session, e.g. upon the first page load for an origin (before any cookie is set). We may need a better definition of session and a service provider may need to annotate a page with a manifest of APIs used both for efficiency and as a number of distinct pages might be involved in a session. This could require some definition, but is not an argument against rulesets per se.

(2) ISSUE-95, Different regulatory environments

This is a service provider concern, not API or browser. Conveying user intent is generic, how the service provider deals with the intents is a choice of the service provider. I suggest we close this issue as not directly relevant to the rulesets proposal.

(3) ISSUE-89,  pre-existing relationships

>From the issue description:

[[
John Morris suggested that the rulesets that are sent along with the collected data could be considered as overridden if the interaction is made as part of a pre-existing trust relationship between the site and the user. Conversely, the rulesets would only apply for interactions with site where no trust relationship has been established
]]

Aren't we mixing up "trust" with "user privacy expectations". Even if there is trust it is still useful and important to convey privacy expectations. 

Even with a supposed existing relationship, the details of agreements can change, and user understanding may not match what the service provider expects. Thus conveying intents is a reality check, a "privacy quality" approach of sharing user expectations and is still useful and appropriate.

I propose we close this issue as being of secondary importance to the primary concern of enabling users to be able to express their privacy preferences, since it is exploring an edge case where the mechanism is still useful.

A while ago I reviewed the issues related to rulesets listed in the rulesets draft,  see http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0097.html

regards, Frederick

Frederick Hirsch
Nokia

For tracker, this should complete ACTION-443.
Received on Friday, 19 August 2011 21:54:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:22 GMT