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

Question/comments on Ruleset "Issues"

From: <Frederick.Hirsch@nokia.com>
Date: Mon, 24 Jan 2011 23:14:46 +0100
To: <public-device-apis@w3.org>
CC: <Frederick.Hirsch@nokia.com>
Message-ID: <FA66A9CE-AD87-4A5F-B724-49CE1FB2F1D1@nokia.com>
I have some comment and questions related to the issues noted in the RuleSets draft [1] (not as chair here)

[[ There are a number of open implementability questions about the rulesets. ]]

<fh> "Implementability" is probably not the correct word since it isn't a question of whether privacy mechanisms can be specified or implemented, but whether there is a strong enough requirement or incentive to do so. 

[[  * Granularity of permissions: At the F2F, a simplified and less granular selection of rulesets was discussed that would provide only three ruleset choices: one-time, profile, and personalization. Whether the granularity should be at this lower level or somewhere in between the three simplified rulesets and the rulesets as described in this document is an open question.

 Jurisdiction-based configurations: There may be legal and other jurisdiction-based constraints that require web applications to perform certain operations on user data. With a small static set of rulesets, the result of these constraints may be that certain applications are unable to comply with particular ruleset

<fh> These two are on opposite sides of the same concern, one asking for less complexity for usability, the other suggesting that finer granularity might be needed. My understanding is that the simplified rulesets at the workshop was an attempt to address concerns raised about complexity, yet the initial proposal attempted to find a fairly simple approach that can meet various needs. Are changes in the regulatory and legal environment  giving insight on impact to DAP work without explicit privacy mechanisms? The Ruleset proposal was an attempt by privacy experts to hit the right balance ....

[[	 Variability of user policies: Because there are multiple rulesets, sites could receive different rulesets from different users. Responding to this variability in back-end implementations may be challenging depending on the site functionality and the range of policies that might be received. ]]

<fh> I don't understand this issue. Many items have differences depending on individual user choice and are dealt with. 

 UI complexity:The rulesets proposal envisions that users would have to select the appropriate ruleset for an interaction through the browser UI. With multiple possible rulesets, this may translate into a more complicated UI than browsers currently offer for other user preferences.

<fh> what are the criteria for appropriate user interfaces? History mechanisms  are not that simple, but implemented, isn't that the case?  IE has a set of mechanisms for various security domains and has been used for years.

	 UI promising too much: Because browsers would be displaying the ruleset choices in the UI but they are not in a position to enforce the rulesets, there is concerns that users may lose trust in the browser when their ruleset directives are not followed, even though that would be the fault of the web site that received the rulesets and not the browser.

<fh> Isn't it possible to make a user interface that makes clear to whom the information is being shared with, solving this issue fairly simply?

	 User decision complexity: The results of choosing a particular ruleset may not be evident to users, creating a complex decision that users are not prepared to make. For example, if a particular ruleset choice results in a web application not working properly, it is not clear how to explain to users the causality between the ruleset choice and the application failure.]]

<fh> The choices offered by Rulesets seem fairly obvious. We make many assumptions about "users", e.g. that they know what the lock icon means, what "back" means, how to deal with cookies and pop up windows, proxies, etc.  Are ruleset privacy choices that much more complicated than many of the preferences offered in browsers to users today? I'd argue not, especially given reasonable defaults.

	 Composability of rulesets: When multiple pieces of data are combined in a single service, or when multiple rulesets are chosen for a single piece of data, rulesets may have to be composed. The current proposal does not address composability.

<fh> Why is this necessarily complex? Why not apply a single ruleset choices to all items in an "application" composed of various API uses? Perhaps the complexity here is the question of how the choice is integrated, e.g. an application "install time" could be simpler than queries upon every API invocation...

regards, Frederick

Frederick Hirsch

[1] http://dev.w3.org/2009/dap/privacy-rulesets/

For tracker, completes ACTION-292
Received on Monday, 24 January 2011 22:15:43 UTC

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