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

Re: Question/comments on Ruleset "Issues"

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 01 Feb 2011 10:40:05 +0100
To: Frederick.Hirsch@nokia.com
Cc: public-device-apis@w3.org
Message-ID: <1296553205.13755.110.camel@altostratustier>
Hi Frederick,

Thanks for taking the ball on this.

Le lundi 24 janvier 2011 à 23:14 +0100, Frederick.Hirsch@nokia.com a
écrit :
> [[ 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. 

I think some of the issues below are actually a matter of
implementability; of course, provided with enough time and money, most
problems of implementability go away, but in practice, Web technologies
that are too hard to implement correctly don't get implemented.

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

I would characterize that as two concerns pushing in opposite
directions, actually.

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

If I may recast the issue in terms of scoping, it would be "is there a
sweet spot between simple-enough policies for users to understand and
rich enough to comply with regulation?".

I don't know if anyone can answer that question now, so I think it would
be fine for us to assume that this will be part of the exploration made
while working on the document; in other words, that particular issue
shouldn't block publication as FPWD.

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

Let me try to clarify it since at least to me, this seems like one of
the biggest issue with the proposal.

We currently assume that the rulesets are bound to the collected data on
an API-per-API basis. 

This means that any data resulting from the manipulation of the
collected data on the client side must also be bound with a ruleset, for
instance the average speed of the user as measured by collecting her
positions regularly. It's among other things not clear what policy needs
to be bound to the resulting data when the policy differs from one call
to another, but more generally, ensuring that data remains "tainted"
across any program that has a minimum level of complexity is extremely
difficult, and most likely well beyond most Web developers reach.

This also means that each individual data set collected from each of
these APIs must be recorded on the server side with a sharing policy;
for anyone who has had to design a database (let alone upgrade one to a
new schema), this is bound to be nightmarish.

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

I think the best way to reduce concerns about that issue would be to
propose a couple of prototypes of how rule sets would be presented to
the user with a couple of APIs (e.g. geolocation and contacts?).

> [[
> 	• 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?

The question is not about whom the info is shared with, but how to
communicate accurately to the user the actual impact of setting a
policy; in other words, the current proposal makes the policy setting
part of the browser chrome, which browser vendors want (reasonably, in
my opinion) to keep for unambiguous transactions with the user. Setting
a policy that may or may not be followed by the server-side falls in the
ambiguous side.

Also, if the rulesets are attached only to API calls, they would leave
entirely unaddressed data collected by other means (e.g. traditional
forms), making the overall impact of these policies un-understandable to

But again, I think the best way to progress on the UI considerations is
to propose simple prototypes.

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

Note that they need to be obvious to everybody, not only to privacy
advocates :)

More importantly, they need to be obvious enough in a form that can be
integrated in a UI that users would be exposed to on a regular basis (so
among other things, in a very short form, e.g. for mobile devices), and
also obvious enough that the user can now how to fix a problem caused by
her decision of a given policy (without compromising her privacy).

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

Well, in practice, the complexity of the choices to which users are or
have been exposed (e.g. cookies settings) has been one of the sources of
privacy problems.

Typically, while disallowing 3rd-party cookies would reduce drastically
tracking on the Web today, it has proved very difficult to deploy
because it's quite hard to explain what a cookie is, what a 3rd-party
cookie is, why it's disabled by default but need to be re-enabled for a
particular Web site to work. I personally wouldn't want to try to
explain this to my mother even though she's quite Web-savvy in many
other ways.

> [[
> 	• 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?

Well, in the current propoosal, a ruleset is bound per API-call, at the
user’s discretion; so if the user decides to set a given policy for one
call and another policy for a later call, it's not clear what's the
policy that needs to be attached to e.g. the average of the data
gathered on the two calls.

Having rulesets bound at the application level would certainly solve a
lot of the problems discussed above, but is not in line with what has
been proposed so far (and would likely change quite a few of the
expected advantages of the proposal). But this would also be more
in-line with the current proposals from Microsoft [1] and Mozilla [2].



[2] http://www.open-mike.org/entry/thoughts-on-do-not-track
Received on Tuesday, 1 February 2011 09:40:24 UTC

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