W3C home > Mailing lists > Public > public-tracking-comments@w3.org > June 2014

TPE Last Call Working Draft Comments

From: Chris Mejia <elementslifestylegroup@hotmail.com>
Date: Wed, 18 Jun 2014 13:59:54 -0700
Message-ID: <BLU436-SMTP6A654E5393489C3B17E5ECC100@phx.gbl>
To: <public-tracking-comments@w3.org>
Dear Co-Chairs, W3C Staff and Working Group Colleagues,

Thank you for the opportunity to provide my comments and input on the Last
Call Working Draft of the TPE as an invited expert to the W3C Tracking
Protection Working Group (TPWG). Fundamentally, I believe in providing
Internet users with transparency and informed choice. Iıve had high hopes
that this Working Group would deliver on both fronts. And while the veneer
of this specification may appear to the unsophisticated eye to deliver these
basic tenants, the unfortunate reality is it falls short. I find that there
are fundamental flaws to this specification, which if left as-is, will most
likely lead to itıs failed adoption by the majority of those companies
engaged in the business of online advertising, and thus not reach users to
fulfill itıs charter:
1. Entities receiving the DNT:1 signal cannot rely on its validity.  Because
there is no strict requirement in the TPE on how and when user agents
set/send DNT signals on behalf on properly informed users, the signal itself
cannot be relied on as a consistent message (an expression of individual
user choice) to those who receive it. We have already seen examples of DNT:1
being sent by default, where users did not take an affirmative action to
enable its sending, and where in most cases, the user had no idea it was
being sent‹ this is simply unacceptable for a standard that proposes user
choice as one of itıs core tenants. In order for this specification to be
successfully adopted, entities receiving the signal must have confidence
that the signal received represents an individual userıs properly informed
choice. This requires an educational component‹ users must be informed
(transparency), and that educational component must be validated by the
specification so that those receiving the signal can differentiate when itıs
been set/sent appropriately, vs. the the ³noise² created by user agents that
insist on sending it by default for all of their users. Furthermore, because
there is no real cost for user agents and intermediaries to ³turn-on² DNT:1,
we can see that itıs being insincerely deployed (under the guise of user
protection) as a competitive tort in commercial competition wars, rather
than as a functional tool for individual user choice. By allowing unfettered
flooding of un-checked DNT signals into the wild, the actual user-set/sent
DNT signals will become effectively lost signals in the noise of
machine-generated signals‹ this practice of bastardizing the signal does not
help to advance user privacy controls, and is thus inconsistent with the
TPWG Charter.
2. The definition of ³tracking² and ³context² are policy terms that should
not be included in the TPE‹ a pure technical specification that should only
aim to define how the ³plumbing² (technical protocols) of the specification
works. This TPWG made a clear and sound decision to bifurcate the process of
developing the DNT specification into two parts: the technical specification
(the TPE) and the compliance specification, specifically allowing for the
potential of multiple (jurisdictional) compliance specifications
(approaches). The full DNT specification is thus made up of two separate
parts, combined to create ONE cohesive specification in practice.
Accordingly, it is not necessary to encumber the TPE component with
policy-focused definitions‹ those definitions will be provided in the
compliance specification(s) that marry with this TPE. Defining ³context² and
³tracking² is important, donıt get me wrong‹but itıs equally important that
their definitions fall in line with the rest of a compliance documentıs
policy. The push to define these terms in the TPE feels like a back-door way
to force certain overriding privacy constructs on jurisdictional compliance
policies yet to be developed or chosen. That was not the intent of
bifurcating the spec into two parts. I believe we need to respect
jurisdictional regulation (including self-regulation), codes and laws‹ this
means that it is impossible to have just one compliance specification for
the world (despite the wants by some in this working group)‹ the more
palatable and adoptable solution is that jurisdictions will develop their
own compliance specifications consistent with their own regulations, codes
and laws, which should marry with this TPE. In order to avoid jurisdictional
conflict with the TPE, policy-based terms like ³tracking² and ³context²
should be defined ONLY in the compliance specification(s).
3. This TPE does not require user agents to support the
user-granted-exception (UGE) protocol developed by this TPWG. The decision
to not make UGEs a required technical requirement of user agents that wish
to comply with the DNT specification will create an inconsistent user
experience across the ecosystem, causing confusion, but more importantly,
taking away the choice of an informed user to make granular exceptions to
his/her DNT preference. User choice should be well balanced in this
specification‹ just as we make daily exceptions to our overriding personal
presets, users of DNT will want to make certain exceptions to their
overriding DNT:1 choice. Forcing a user into an ³all or nothing² proposition
to set/send DNT:1 does not help to advance user privacy controls, and is
inconsistent with the TPWG Charter.
I believe we need to fix these fundamental flaws before sending this TPE to
implementation phase. Our failure to do so will surely represent the failure
of this working group to create a specification that will reach wide adopted
and thus find its way to users. If the user is our most important
consideration, we should re-work this specification accordingly.

Respectfully Submitted on June 18th, 2014,

Chris Mejia
Invited Expert, W3C TPWG

--
Chris Mejia's Profile on LinkedIn: http://www.linkedin.com/in/chrismejia
<http://www.linkedin.com/in/chrismejia>

 
Received on Wednesday, 18 June 2014 21:00:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:37:44 UTC