Re: TPE Handling Out-of-Band Consent (including ISSUE-152)

That might be possible, but I have a hard time thinking that it would be
acceptable from a privacy perspective to have our software insert
exceptions into User Agents' exception repositories.  That sounds like a
very dangerous practice for a DNT spec to permit.  If we want to implement
a part of the spec that requires User Agents to reach out to a common
repository in the machine into which third-party software can insert
exceptions, that would work, but I really think that that is a cure much
worse (from a privacy perspective) than the disease.

--ronan


On Sat, Mar 23, 2013 at 11:05 AM, Grimmelmann, James <
James.Grimmelmann@nyls.edu> wrote:

> A naive question:
>
> Would it help if user-agents could send, with the initial request, a
> header that contains a short list of explicit named out-of-band exceptions?
>  E.g, DNT-OOB: NIELSEN.  The expectation would be that these exceptions
> would be used for cases that involve (1) out-of-band consent, to (2)
> third-party tracking across a wide variety of sites, by (3) a specific
> party, that (4) has consent from a relatively small fraction of users, and
> that (5) is difficult to confirm in real-time.  That is, since real-time
> lookup is hard to do on the server side, perhaps it makes more sense to
> have user-agents send a simple, unambiguous signal that is easy to
> implement.  The names would be much easier, indeed trivial to check than
> figuring out whether a specific user is in the panel who have consented.
>  The header is added to every request, yes, but presumably by a relatively
> small number of users.  And user agents wouldn't need to have a more
> complicated real-time interactive UI, since the preference to send an
> exception via this header could be set-and-forget.  It also seems easier to
> investigate and audit than other suggestions on the table.
>
> In this model, Nielsen would be responsible for making sure that users in
> the panel configure their user-agents to send this exception header; if
> they don't, they can't be tracked.  Other unaffiliated servers would be
> prohibited from relying on this exception.  It would be prohibited to set
> such an exception header without explicit, specific user consent.  And
> there would need to be some kind of namespace control to determine who gets
> to use which tokens as named exceptions.
>
> Much of this is far from ideal, but it seems like some approach along
> these lines could provide users with immediate feedback on their tracking
> status while enabling the desired form tracking by a party who has explicit
> out-of-band consent against a general DNT:1 backdrop.
>
> I am happy to have explained the multiple ways in which this suggestion
> violates other core commitments of the protocol, fails to satisfy the
> expressed tracking goal, is unimplementable by user-agents, will lead to
> horrific privacy violations, and is otherwise contrary to common sense,
> public order and decency, and the laws of physics.  But please be gentle.
>
> James
>