W3C home > Mailing lists > Public > public-privacy@w3.org > July to September 2010

RE: Cookies - Raising Awareness

From: SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com>
Date: Wed, 21 Jul 2010 09:03:48 -0700
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD12EF16CC@BD01MSXMB015.US.Cingular.Net>
To: <ifette@google.com>
Cc: "Karl Dubost" <karl+w3c@la-grange.net>, <public-privacy@w3.org>
Thanks, Ian. 

Clearly the analysis would need to consider tokenization as a key feature to limit the impact on data usage, as well as other side effects e.g. upon app server configuration, load balancing, and all other uses of cookies.

Thanks, 
Bryan Sullivan | AT&T

From: Ian Fette (イアンフェッティ) [mailto:ifette@google.com] 
Sent: Wednesday, July 21, 2010 8:58 AM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: Karl Dubost; public-privacy@w3.org
Subject: Re: Cookies - Raising Awareness

Please do keep in mind that people are already concerned about the amount of overhead that gets tacked on by cookies (in terms of bytes), which is why many sites do compress these into a single cryptic value that has some server-side meaning / mapping to a set of meaningful values...
On Wed, Jul 21, 2010 at 8:31 AM, SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com> wrote:
The investigation would be interesting, especially if someone could create a sandbox where we could experiment with any ideas on how to represent the information (hopefully using some cookie-spec compatible way), and to filter for it (probably first implemented in Javascript then moved into the browser chrome). Further, migrating the experiment to a real service would be needed, to ensure this does not "break the web".

While cookies is a broader web privacy issue, it is related to the scope of the workshop (W3C Workshop on Privacy for Advanced Web APIs) in that information once shared with a web site / webapp server can be written back to the device in cookies. As long as the information stays within the confines of the domain (or more restrictive if needed, the specific webapp on the domain), it falls under "primary use".

One type of information that it would be useful to disclose in cookies is under what "use category" (primary, secondary) is the information being set and used as a cookie.

Another is the source of the information (e.g. to disclose if it has been shared, i.e. not directly obtained). That could be useful if the user wants to limit the migration of data between applications (once of the concepts presented at the workshop - limiting how far information can travel). For example, the user could say "I allow the use of my private information obtained from somewhere else, but I don't allow it to be further distributed".

These indicators could be directly used in the filtering per the user's selected privacy ruleset (http://dev.w3.org/2009/dap/privacy-rulesets/#privacy-rulesets).

Thanks,
Bryan Sullivan | AT&T


-----Original Message-----
From: public-privacy-request@w3.org [mailto:public-privacy-request@w3.org] On Behalf Of Karl Dubost
Sent: Wednesday, July 21, 2010 5:56 AM
To: public-privacy@w3.org
Subject: Cookies - Raising Awareness
Among the discussions we had during the London workshop[1],
We mentionned the cookies and the ability to block them.
Basically, almost nobody blocks the cookies because some
Web sites become quickly unusable. There is also the fact
that most cookies are pretty much harmless.

The UX (User Interaction) in browser for cookies if you
have activated the feature "Accept cookies from sites, but
ask me every time".

1. Reaching a pop-up window saying this site wants to set a
  cookie, do you accept?
2. You can block or not.
3. If you blocked and you want to allow it, the access for
  doing so is not obvious and only a knowledgeable geek
  will be able to do it.

Basically it doesn't work in terms of UX.

The names of the cookies are cryptic, like mentioned in this
blog post.

  how would I know the meaning and consequences of
  allowing Yahoo (of flickr, or any site in the Yahoo
  ecosystem) to store a cookie that sets key T to
  ...CAuNRMqKiCOsvekk....
  --- How the Yahoo portal personalises User Experience [2]

In "HTTP State Management Mechanism" RFC 2109 [3], aka the
Cookies specification, there is an option to raise awareness
about the content of cookies, Section 4.2.2 Set Cookie Syntax.

  Comment=comment
     Optional.  Because cookies can contain private
     information about a user, the Cookie attribute
     allows an origin server to document its intended
     use of a cookie.  The user can inspect the
     information to decide whether to initiate or
     continue a session with this cookie.
  --- "HTTP State Management Mechanism" RFC 2109 [3]

I was wondering if the feature was used, I asked on #whatwg
IRC channel because there have been people creating surveys
on how HTML and HTTP are used on the Web.

  <karlcow> I wonder how many sites are sending the
            optional "Comment=comment" with cookies
  <Philip`> karlcow: Very few
  <Philip`> and half of them are Comment=Sun+ONE+
            Application+Server+Session+Tracking+Cookie
            and the other half are
            Comment=1-800-Volunteer.org
  --- IRC discussion [4]

It would be interesting to have real data on how it is used.
Maybe the Brian Wilson's survey, MAMA [5], could be pushed
further into that direction. Something we could ask Opera.

  Other fields like Content-Length, Etag, and Set-Cookie
  produced so many unique random values that there was
  no point in searching for trends.
  --- MAMA: HTTP Headers, The other HTTP Header fields [6]

Why is it interesting?

It connects directly to Alissa Cooper's privacy rulesets [7]
in which the user could decide that cookies which do not
contain enough information will not be accepted. The issue
being then what is "enough information".

There are two states:

1. Is there a "Comment" attribute for this cookie?
2. What is the information inside this Comment attribute?

The information can just be garbage and will not help users
decide if they want to keep the cookie or not. If we want
something more effective, we could propose to have a precise
vocabulary in the Comment section such as:

Comment= geolocation;shared; [etc.]

Then with a precise vocab, we can create validation tools,
we can create UI giving more information about the cookies
usage. It could help on the side of Aza Raskin's privacy
icons [8]. When there is a formal language it is easier to
display or not the right icons.


The drawback of this proposition is enforcing invalid syntax
for the Comment section in the browser and finding the sweet
spot where the providers will indeed set the comment because
it becomes a benefit for them.

Another issue: How many Web frameworks out there, do not have
the optional Comment feature in their cookies libraries?

There is a need for research.


[1]: http://www.w3.org/2010/api-privacy-ws/

[2]: http://lab.pheromone.ca/2010/07/19/yahoo-personalised-ux/

[3]: http://www.ietf.org/rfc/rfc2109.txt

[4]: http://krijnhoetmer.nl/irc-logs/whatwg/20100721#l-842

[5]: http://dev.opera.com/articles/view/mama/

[6]: http://dev.opera.com/articles/view/mama-http-headers/#other

[7]: http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-12.html

[8]: http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-22.txt


--
Karl Dubost
Montréal, QC, Canada
http://www.la-grange.net/karl/




Received on Wednesday, 21 July 2010 16:04:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:23:51 UTC