Web Tracking and User Privacy Workshop - Importance of User Intent
One aspect of the W3C "Do Not Track" submission is an HTTP header mechanism for an end-user to request that their activity not be tracked [1]. This is an example of an end-user indicating intent with the expectation that this request be honored, relying on accountability as much as technology to achieve a satisfactory result. The W3C Device API and Policy working group has considered requirements to convey intent related to service provider information retention and reuse, such as "Do not use my information for other purposes" and "Do not retain my information longer than needed for the immediate request" but has had concerns about adoption and ability to implement [2],[3]. The DAP WG is working on incorporating privacy by design into its API work with the most success related to minimization, but difficulty related to being only a part of a larger ecosystem [4], [5], [6].
The "Do Not Track" HTTP header mechanism provides a simple binary indication of intent - "don't do something", as opposed to more nuanced requests like "do not keep my information for more than a month". All are part of a continuum of a user signaling intent to enable accountability of others that use the information. The purpose of this position paper is to suggest that we consider whether an HTTP header "do not track" mechanism could be generalized to support conveying intentions related to data retention and third party re-use without losing the simplicity and elegance of a simple solution. In addition, another goal is to suggest that defining a wire format without requirements on end points could enable interoperability while leaving user interface design and deployment considerations to implementers.
Although a number of definitions of privacy have been proposed, defining privacy as "the ability for a user to understand and control how information about them is used" is appropriate to this case. Relying entirely on technical controls to achieve privacy is probably not feasible, but use of technology to convey intent and then relying on accountability through social, legal and regulatory means probably is. Thus an important minimal step is to allow users to explicitly convey intent. The ability to convey intent to service providers is important, especially as the amount and variety of information collected increases, including new sources such as device information including contacts, calendar, camera, geolocation and sensor information.
Members of the W3C Device API and Policy (DAP) working group have worked to simplify how intent might be conveyed to service providers, proposing Rulesets modeled on creative commons licenses, providing a small set of user choices for categories of concern [7]. The goal of the simplification has been greater usability and implementability, yet issues listed in the document include concerns related to user understanding of even simplified statements, concerns about clarity of roles and responsibilities in the ecosystem (in particular the browser), and composability of intents when a service uses multiple pieces of data that might have different user intentions associated with them. Despite these concerns, the fact remains that without conveying user intent all that remains is notice and consent, which is known to be a flawed model.
The "Do Not Track" proposal submitted to the W3C suggests another approach as presented with the "Do Not Track" HTTP header, namely to define a wire format for conveying intent, leaving the user interface implementation to implementers. Defining a wire format to enable sharing of information has precedent, in Web Services for example. The benefit is to define formats and semantics while giving freedom to implementors to create the detailed interfaces. There are a number of benefits of defining a wire format:
- A variety of endpoint implementations are possible and can evolve,
- Different parties can offer implementations,e.g. browser vendors, plugin authors, service provider web pages etc
- It is simpler to capture and test wire payloads,
- This leaves the user interface open to innovation and competitive advantage,
- Avoid issues of defining the roles and responsibilities of parties which is better left to others
It is a necessary first step to be clear on what intent information should be conveyed and the Rulesets proposal offers a summary of this information. Codifying this as a wire format is a possible next step toward interoperability. An example could be a simple HTTP header corresponding to a Ruleset definition:
The semantics described in the privacy rulesets document are important toward privacy considerations. This approach enables decoupling the expression of that intent from the implementation. As the importance of privacy is recognized by the social, regulatory and implementation communities, incentives will be created to convey such information. Defining a wire format along with the semantics allows this to happen in an interoperable manner.
Notes
- [1] "Web Tracking Protection", W3C Member Submission 24 February 2011. Andy Zeigler, Adrian Bateman, Eliot Graff, Microsoft Corporation.
- http://www.w3.org/Submission/2011/SUBM-web-tracking-protection-20110224/
- [2] DAP Home Page
- http://www.w3.org/2009/dap/
- [3] "Device API Privacy Requirements", W3C Working Group Note 29 June 2010. Alissa Cooper, Frederick Hirsch, John Morris.
- http://www.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/
- [4] "Privacy Workshop Position Paper - the DAP Perspective", Robin Berjon DAP co-chair, Vodafone; Frederick Hirsch, DAP co-chair, Nokia. 4 June 2010
- http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-11.html
- [5] "Position Paper: Privacy and Policy in the DAP WG - a DAP Perspective", Frederick Hirsch, DAP co-chair, Nokia; Robin Berjon, DAP co-chair, Vodafone. 2 September 2010
- http://www.w3.org/2010/policy-ws/papers/14-Hirsch-Berjon-DAP.html
- [6] "Internet Privacy Workshop Position Paper: Privacy and Device APIs", Frederick Hirsch, W3C DAP Co-Chair, Nokia. 5 November 2010
- http://www.iab.org/about/workshops/privacy/papers/frederick_hirsch-revised.pdf
- [7] "Privacy Rulesets", W3C Editor's Draft 06 October 2010. Alissa Cooper, John Morris, Erica Newland, Center for Democracy and Technology.
- http://dev.w3.org/2009/dap/privacy-rulesets/