Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31, ISSUE-34, ISSUE-49)

Jonathan ­ thanks for a thoughtful analysis on where things stand from your
perspective. While I disagree with some of your narrative, I think that may
have to do more with the fact that we just see the world a bit differently.

So rather than focus on those, I'll merely point out that no one on this
thread has even entertained the concept of having invited experts from the
long tail of industry. Regardless of the requirements imposed on first
parties, when 60 pages of documents appear on the desks of the technology
leads who are not Adobe or MSFT ­ it will create pretty significant
indigestion. While publisher are part of that equation, there are also a
number of small to mid sized technology platforms out there that do not have
the resources of a big company. And while you are one of the smarter people
that I've come across in recent memory, the idea that you (or anyone) can
serve as a proxy for how an entire marketplace works smacks of hubris.

I would hope that advocating a multi-stakeholder approach is a relatively
uncontroversial idea on this thread - as that seems to be a core philosophy
of the W3C. It just seems that we have a few holes in terms of perspective
when it comes to our talented TP group. And I'm sort of curious why I'm the
only person who feels that wayŠ.(?)


Cheers,

Alan Chapell
Chapell & Associates
917 318 8440


From:  Jonathan Mayer <jmayer@stanford.edu>
Date:  Mon, 6 Feb 2012 17:56:13 -0800
To:  "public-tracking@w3.org (public-tracking@w3.org)"
<public-tracking@w3.org>
Subject:  Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31,
ISSUE-34, ISSUE-49)
Resent-From:  <public-tracking@w3.org>
Resent-Date:  Tue, 07 Feb 2012 01:58:34 +0000

In the interest of keeping things readable, here's a consolidation of issues
on the thread and my responses.

1) Without broad exceptions, Do Not Track will be difficult for millions of
small publishers to implement.

Shane:
> [W]e have ~1 million web sites around the globe that will need to implement
> DNT, ranting from the very large . . . to the very small (small bloggers who
> are reliant on ad revenue to pay their mortgage and will feel the impact of
> revenue loss more acutely) . . . .

Mike Zaneis:
> [W]e cannot ask millions of websites (certainly well over the conservative
> estimate Shane gave of approximately 1 million) to reconfigure their servers
> to meet the W3C standard.

I see very little implementation burden on publishers, large or small.  The
group has already agreed that first parties (including publishers) will only
be prohibited from circumventing the standard through deliberate data
sharing.  Backend data sharing is uncommon, and frontend data sharing can be
easily prevented by third parties.  In fact, at least two large advertising
data providers already stop their frontend data sharing when they receive a
Do Not Track header‹and they found implementation trivial.  I do not believe
there is substantiation for the technical claim that current proposals would
require "millions of websites . . . to reconfigure their servers."


2) If we call for complex privacy-preserving technologies, Do Not Track will
be a flop like P3P.

Shane:
> As part of the community attempting to implement P3P, it failed due to
> difficultly to implement (no flexibility, no response structure, etc.).

Alan:
> Given that one of the chief criticisms of the P3P standard was that its
> complexity made it difficult to implement correctly, I think its worth asking
> the question whether or not we are at risk of repeating those mistakes.

I'm certainly sensitive to complexity of all kinds, but I don't think the
P3P analogy holds up.  P3P was "complex" in that it required significant
legal, business, and technology customization for each website.
Privacy-preserving technologies, on the other hand, are "complex" in that
they require carefully designed algorithms and carefully engineered
software.  But, once built, a privacy-preserving technology can be deployed
on many sites.  There are great JavaScript libraries for DOM manipulation
(e.g. JQuery), browser support (e.g. Modernizr), and many other common
purposes.  Do Not Track should encourage similar initiatives for
privacy-preserving advertising, whether from an open source community, a
self-regulatory group, or a trust provider.

Moreover, unlike P3P's technology mandates, Do Not Track would not require a
third-party website to deploy a privacy-preserving technology.  If it finds
the implementation onerous, it can simply forego the benefit of that
technology.  Whatever the challenge of the privacy-preserving technology,
stopping data collection is quite straightforward.

A final point: while P3P was a failure for first-party websites, the
relevant population for Do Not Track is third-party websites‹where P3P is
widely implemented.  See Leon et al.'s paper "Token Attempt: The
Misrepresentation of Website Privacy Policies Through the Misuse of P3P
Compact Policy Tokens."


3) P3P did/did not adequately protect user privacy.

Jeff:
> None of the leading privacy groups at the time, with a few exceptions, saw P3P
> as an effective way to address data tracking, targeting.

Shane:
>  [P3P] absolutely protected privacy when implemented correctly.

Whatever the merits of the technical design, I think all agree that P3P as
currently deployed does not provide users with adequate privacy controls.


4) We should not include technology-specific exceptions.

Sean:
> I would say that my more general point (which is perhaps more useful) is that
> we should not be prescribing technologies that have not been tested at scale
> in the context of the compliance doc.

Instead of calling for a specific technology, an exception could delineate a
set of design guidelines.  That would be completely fine by me.


5) Let's start with blanket use-based exceptions and work our way towards
privacy-preserving technologies.

Shane:
> Hopefully the conversation will continue from here and we'll figure out a way
> to start at use-based exceptions and develop a process by which technology
> solutions become the best practice as soon as they're available at scale.

I'm very skeptical that third-party websites will develop new
privacy-preserving technologies.  As an empirical matter, I am unaware of a
single privacy-preserving technology that has been deployed by the
third-party display advertising industry (writ large) in its fifteen or so
years of existence.  The general trend has been, on the contrary, towards
more collection and use of personal information.  It doesn't take much
imagination to see why; there's perceived value in personalization and
market understanding, while privacy-preserving technologies require valuable
R&D resources and don't contribute to the bottom line.  I don't mean this as
a slight against online advertising businesses; they're in a competitive and
growing industry, with countless other priorities.

Even if the incentives were there, I don't believe there are fundamental
discoveries in privacy-preserving technology waiting around the corner.
Researchers have identified a fairly small and stable set of building blocks
for privacy-preserving technologies (including client-side storage, dropping
data, crypto, and query-response APIs).  While the permutations of the
building blocks can vary substantially between proposals, current objections
are targeted at the building blocks‹and therefore go to all possible
designs.

Taking the objections that have been raised at face value‹I would reiterate
that I don't believe there are nearly so significant implementation
challenges as some have claimed‹I see two paths forward for "operational
purpose" exceptions.  First, we can nix the exceptions altogether, as I
discussed in an earlier email.  That seems an unnecessarily bad outcome.
Second, for certain "operational purposes" we can give privacy-preserving
design parameters and establish a path to adoption for privacy-preserving
technology.  That path could involve a grandfathering period or other
creative policies.  But it has to include incentives for developing
privacy-preserving technologies, and it has to account for the very likely
eventuality that better alternatives will not be found.


6) Privacy advocates are arguing that local storage is a non-starter.

Shane:
> There are many privacy advocates that have argued leveraging local stores . .
> . are NOT consumer privacy protective.

I'm unsure whom this refers to.  I have heard the claim from advertising
companies before (Google in particular), but not privacy advocates, let
alone many privacy advocates.  Could you provide some pointers Shane?


7) Where's the privacy problem if we prevent profiling?

Shane:
> [W]hat are the counter arguments . . . for allowing the already stated
> exceptions?  Especially since none of these allow the profiling (tracking) of
> a user's activities into a profile for use to alter the user's experience.

Roy:
> I am not following the part where it is assumed server-side frequency capping
> cannot be done while preserving privacy. If we are assuming that the server is
> a good actor, then there should be ways to store the data such that it is no
> more of a privacy concern than using the network.

I believe a third party's collection of a user's browsing history across
unrelated websites poses serious privacy risks to users.  From the group's
conversations, it's clear that I'm far from alone in that assessment.


8) I'm refusing to compromise.

Shane:
> If Jonathan's approach is the end of the compromise process, I'm afraid W3C's
> DNT is DOA.

Nonsense.  My focus on privacy-preserving technologies has had the very
purpose of achieving compromise.  I greatly appreciate that Sean recognized
as much.