Re: Frequency Capping

Roy,

On 7/12/2012 4:44 PM, Roy T. Fielding wrote:
> On Jul 12, 2012, at 12:56 PM, Tamir Israel wrote:
>
>> On 7/12/2012 3:12 PM, Roy T. Fielding wrote:
>>> Yes, and it has been rejected many times because the ID cookies are
>>> used by other features that won't be turned off by DNT.
>> Not so. I have never interacted and have no relationship with third party server X.
> Regardless of Shane's first-party perspective, your browser sent
> an HTTP request to the third party server. That is interacting with it.
Yes. But as a third party. If we really want to be sticklers about this:
<http://tools.ietf.org/html/rfc2965>

	When it makes an unverifiable transaction, a user agent MUST disable
    all cookie processing (i.e., MUST NOT send cookies, and MUST NOT
    accept any received cookies) if the transaction is to a third-party
    host.

    This restriction prevents a malicious service author from using
    unverifiable transactions to induce a user agent to start or continue
    a session with a server in a different domain.  The starting or
    continuation of such sessions could be contrary to the privacy
    expectations of the user, and could also be a security problem.

    User agents MAY offer configurable options that allow the user agent,
    or any autonomous programs that the user agent executes, to ignore
    the above rule, so long as these override options default to "off".

    (N.B.  Mechanisms may be proposed that will automate overriding the
    third-party restrictions under controlled conditions.)

    Many current user agents already provide a review option that would
    render many links verifiable.  For instance, some user agents display
    the URL that would be referenced for a particular link when the mouse
    pointer is placed over that link.  The user can therefore determine
    whether to visit that site before causing the browser to do so.
    (Though not implemented on current user agents, a similar technique
    could be used for a button used to submit a form -- the user agent
    could display the action to be taken if the user were to select that
    button.)  However, even this would not make all links verifiable; for
    example, links to automatically loaded images would not normally be
    subject to "mouse pointer" verification.

    Many user agents also provide the option for a user to view the HTML
    source of a document, or to save the source to an external file where
    it can be viewed by another application.  While such an option does
    provide a crude review mechanism, some users might not consider it
    acceptable for this purpose.

[...]

An origin server could create a Set-Cookie2 header to track the path
    of a user through the server.  Users may object to this behavior as
    an intrusive accumulation of information, even if their identity is
    not evident.  (Identity might become evident, for example, if a user
    subsequently fills out a form that contains identifying information.)
    This state management specification therefore requires that a user
    agent give the user control over such a possible intrusion, although
    the interface through which the user is given this control is left
    unspecified.  However, the control mechanisms provided SHALL at least
    allow the user

       *  to completely disable the sending and saving of cookies.

       *  to determine whether a stateful session is in progress.

       *  to control the saving of a cookie on the basis of the cookie's
          Domain attribute.


> Why does it need to be able to identify me in any way?
> Some clients don't interact in a friendly way.  It requires effort
> for a service to separate bad clients from good clients.  Cookies
> are one of the main ways to reduce that effort (and not just in the
> obvious way of identifying a specific UA, which is easy to forge).

If there are limited security justifications for tracking, it may be 
useful to discuss these. I would still want some parameters on this (for 
example, servers should not be permitted, in my view, to place ID 
cookies on any and all users they randomly with, without any trigger to 
suggest a particular user has done anything to warrant suspicion). You 
don't get the blanket right to track everyone on the web just because a 
few of the users you interact with are acting badly.

> ID cookies are not a significant privacy concern if data retention
> is constrained in the ways already outlined for frequency capping.

It is a significant privacy concern if users are not able to say: I 
don't trust server X. I've expressed my intention not to be tracked 
[DNT-1] (so I assume server X is no longer tracking me for /any 
/reason), and I do not wish to grant server X any type of exception. 
Because I don't trust them.

>
> ....Roy