- From: Peter Cranstone <peter.cranstone@gmail.com>
- Date: Sat, 16 Jun 2012 10:24:29 -0600
- To: "Roy T. Fielding" <fielding@gbiv.com>, Jonathan Mayer <jmayer@stanford.edu>
- CC: <public-tracking@w3.org>
One typo in the last responseŠ
Summary
1) WithOUT a clear definition of what constitutes tracking which is agreed
upon by all parties, the spec cannot move forward.
Peter
___________________________________
Peter J. Cranstone
720.663.1752
-----Original Message-----
From: Peter Cranstone <peter.cranstone@gmail.com>
Date: Saturday, June 16, 2012 10:04 AM
To: "Roy T. Fielding" <fielding@gbiv.com>, Jonathan Mayer
<jmayer@stanford.edu>
Cc: W3 Tracking <public-tracking@w3.org>
Subject: Re: Towards a Grand Compromise
>There's so much to comment on this post it would take pages. Instead I
>will limit myself to two CRITICAL sections.
>
>1) The Definition of Tracking
>2) User Agent and server side compliance.
>
>RE: 1 The definition of tracking.
>
>Roy's 100% correct. Until a definition is AGREED upon by ALL parties then
>the spec fails. As I wrote in a previous post
>http://lists.w3.org/Archives/Public/public-tracking/2012Jun/0216.html -
>Alignment of interests and meeting expectations, it is imperative that the
>definition aligns with all parties to the process.
>
>The user ONLY knows and expects one thing - Tell Web Sites to Not Track
>Me. IMO a very unambiguous statement. He/She will simply set it and forget
>it. However because there is no clear definition on what tracking means
>we're now faced with an un-implimentable number of server side exceptions
>with a corresponding number of UI issues to resolve.
>
>We should start with a list on this forum of ALL the ways that current
>tracking is done. That will become the baseline for the definition.
>(Unfortunately I can imagine that this will consume the forum because of
>different agendas.)
>
>
>RE: 2 User Agent and server side compliance
>
>The User Agent is NOT in the spotlight here. All the server should look
>for is the presence of a DNT flag and then it's current setting. We've
>argued the point to death that there is NO WAY for the server to determine
>the "Choice" of the user. For example?
>
>1) I download and install Windows 8 and accept the defaults because it is
>MY choice
>2) I download and install Windows 8 and disable DNT because it's MY choice
>3) After 3 days of using Window 8 I enable DNT because it's MY choice
>
>All of the above are EQUALLY viable under the spec. Because the spec says
>"Therefore, users need a mechanism to express their own preference
>regarding tracking that is both simple to configure and efficient when
>implemented". In the case of Windows 8 Microsoft made the choice for me -
>and I'm ok with that (my choice), AND they gave me a mechanism to change
>it if I want to. The only thing they omitted was a pop-up dialog asking
>the user to accept the defaults for I.E. 10 which includes turning on DNT.
>Think about that for a second. One pop up added by Microsoft and they're
>suddenly in full compliance with the spec and still the server will NOT
>know who set the flag.
>
>Summary
>
>1) With a clear definition of what constitutes tracking which is agreed
>upon by all parties, the spec cannot move forward.
>2) Unless you dramatically expand the scope of the protocol there is
>clearly NO way (other than press releases which servers don't read) to
>know WHO set the DNT flag.
>
>
>
>Peter
>___________________________________
>Peter J. Cranstone
>720.663.1752
>
>
>
>
>
>
>
>
>-----Original Message-----
>From: "Roy T. Fielding" <fielding@gbiv.com>
>Date: Saturday, June 16, 2012 3:53 AM
>To: Jonathan Mayer <jmayer@stanford.edu>
>Cc: W3 Tracking <public-tracking@w3.org>
>Subject: Re: Towards a Grand Compromise
>Resent-From: W3 Tracking <public-tracking@w3.org>
>Resent-Date: Sat, 16 Jun 2012 09:53:40 +0000
>
>>Regarding the "Do Not Track - Compromise Proposal" of 11 June 2012:
>>
>>I am disappointed that this proposal repeats so much of the current
>>compliance document that has been repeatedly rejected by those
>>who are expected to implement it. The key to any consensus process
>>is to make positive steps toward adoption by all members, not by
>>splitting the difference on never-going-to-be-implemented features.
>>
>>Fundamental problems
>>====================
>>
>>0) This is not the collection protection working group -- it is the
>> tracking protection working group and it has a chartered delivery
>> requirement for a document that defines the meaning of a do not
>> track preference.
>>
>> DNT expresses "do not track". We either agree on a definition for
>> tracking or we don't have a protocol. When we have a definition for
>> tracking, all of the constraints on data collection will be a subset
>> of that definition. Adobe will not accept blanket constraints on all
>> data collection based on the theory that a few exceptions will cover
>> our needs: we have no way to anticipate all of the future needs of
>> our customers that might have nothing to do with tracking.
>>
>> The user is asking not to be tracked, to which we can comply if we
>> have a specific definition that includes both the process of tracking
>> and data collection enabled by that tracking. Some regulators are
>> requiring prior consent for collection of personal information,
>> to which we can comply by obtaining that prior consent or by
>> excluding the personal information from retention. We have no
>> interest in requirements for DNT that exceed these two mandates
>> from users and regulators. If additional privacy issues arise,
>> they should be addressed regardless of whether the user has
>> transmitted DNT; thus, they are outside our current scope.
>>
>> Data collection that is not associated with user activity and
>> which does not represent an identified privacy issue should not
>> be constrained by this standard. If privacy violations occur,
>> the responsible parties should be punished regardless of DNT.
>> There is no need for DNT to cover all privacy concerns.
>>
>>
>>1) We have not found a way for a UA to indicate whether a given
>> request is intentional or not, and we cannot design based on
>> meaningless phrases like "infer with a high probability".
>> The distinction between first and third party resource must either
>> be testable via the protocol or determinable independent of
>> specific requests.
>>
>> A server cannot prevent any given first party resource from being
>> reused in what the WG would consider someone else's first party
>> context (making it a third party resource). Hence, we have no way
>> of complying with the definition as stated other than by always
>> adhering to the third-party constraints.
>>
>> There is a simple solution: define the type of resource according
>> to how the resource owner has designed it to be used, consistent
>> with how that party chooses to use the resource on its own sites,
>> and how it has documented the resource for use by others.
>> TPE is already defined in those terms.
>>
>>
>>2) Outsourcing is not an exception -- it is the rule. When we say a
>> third party is acting as a first party, they *are* the first party.
>> Likewise, when a contractor is acting on behalf of a third party,
>> they are that third party.
>>
>> Very few sites on the Web fall into the billionaire's club of large
>> Web providers that can afford to build their own analytics and
>> advertising businesses within the same corporate shell. The ability
>> to contract for services from the likes of Adobe, AWS, and Akamai is
>> what allows the small mom-and-pop web sites to compete and grow their
>> businesses incrementally. Creating an artificial distinction between
>> in-house proprietary services and contractually-provided services is
>> not acceptable because it would create an artificial market advantage
>> for conglomerates, which would in turn invite scrutiny of this group
>> for anti-trust concerns.
>>
>> The privacy issues regarding service provider data collection can be
>> covered by constraints on ownership and sharing of data. Adobe won't
>> accept any requirement that prevents a contractor, acting on behalf
>> of a first party customer, from doing or implementing anything that
>> a conglomerate could have done within the first party constraints.
>>
>> The solution is to define outsourced service providers as the same
>> party if they only act as data processors on behalf of that party,
>> silo the data so that it cannot be accessed by other parties, and
>> have no control over that data except as directed by that party.
>> Hence, requirements on properly outsourced service providers for a
>> party (first or third) should not be any more restrictive or
>> permissive than the requirements on that party's employees.
>>
>>
>>3) We cannot comply with any requirements on "receives".
>>
>> What a server receives is determined by the user agent.
>> Any requirement on what we receive would cause us to be non-compliant
>> as soon as some joker decides to use curl to send us more information
>> than we would expect, or when some lazy developer copies and pastes
>> HTML content from one our own websites within a third party context
>> that we did not expect to receive data.
>>
>> There is no justification for those requirements in the spec.
>>
>>
>>4) How we implement something is none of your business.
>>
>> The proposal contains numerous half-baked ideas on how various
>>services
>> shall be implemented. None of that belongs in a compliance document
>>for
>> a network protocol. Requirements must be on externally observable
>>events
>> that are known to be privacy sensitive, not internal implementations.
>> Otherwise, the spec would inhibit innovation and prevent adequate
>> solutions that might better fit the scale or sensitivity of data for
>> a given context.
>>
>> If you have specific solutions in mind for better ways of advertising,
>> auditing, or analytics, then I encourage you to start your own
>>business
>> (or open source charity) and demonstrate the merits of that
>>implementation
>> in practice.
>>
>> What this WG needs to concern itself with is actual loss of privacy,
>> not theoretical ideas of what might constitute a bulletproof service.
>>
>>
>>5) Unlinkability does not need to be expressed in terms of probability.
>>
>> Data is not personally identifiable if it cannot be associated with
>> an individual. Data that is not personally identifiable should have a
>> blanket exception -- there is no need for additional requirements on
>> validation, and certainly not a magic number like 1024-unlinkable.
>>
>> DNT requirements should only apply to the handling of linkable data.
>> Probability would only estimate the likelihood of failure to comply.
>>
>>
>>6) The requirements should distinguish between communication records
>> (log files) and data collection for operational use. Log files should
>> not be subject to limitations on tracking if they are not used for
>> operations other than what is necessary to support the permitted uses.
>> Log files are still subject to other limitations under data protection
>> laws, but that is independent of whether the user asks for DNT.
>>
>> We only need to require that:
>> a) log files record the DNT status for each request until the
>> records are destroyed or rendered unlinkable; and,
>> b) aside from the permitted uses, processing a logfile is only
>> allowed if all records marked as DNT:1 are excluded from that
>> processing or if the data derived as a result of the
>> processing is entirely unlinkable.
>>
>>
>>Specific comments
>>=================
>>
>>> 2. Parties, First Parties and Third Parties
>>
>> As described above, service providers that are only data processors
>> should be considered within the same party as the contracting party.
>>
>> Differing constraints on third party versus first party services need
>> to be rephrased in terms of the design of each resource rather than
>> the intent of the user.
>>
>> If a resource is designed for direct interaction, is only used by
>> the resource owner on its own sites for direct interaction, and
>> is not documented by the resource owner for use as an embedded API
>> for other sites, then the resource need only comply with first-party
>> requirements. Otherwise, the resource must comply with third-party
>> requirements unless it can dynamically determine that it has been
>> invoked in a first party context.
>>
>>> 3. Information Practices
>>>
>>> 3.1 Reception, Retention, Use, and Sharing
>>>
>>> A party receives data if the data comes within its control.
>>
>>irrelevant
>>
>>> A party retains data if the data remains within the party's control.
>>
>>"... beyond the scope of the current interaction."
>>
>>> A party uses data if the party processes the data for any purpose,
>>> including for storage.
>>
>>"... other than merely forwarding it to another party."
>>
>>> A party shares data if the party enables another party to receive
>>>the
>>> data.
>>
>>"A party shares data if it allows any other party to receive or
>>access that data."
>>
>>> 3.2 First Party
>>>
>>> A first party must not share information with a third party that the
>>>third
>>> party is prohibited from receiving itself.
>>
>>There is no way for a first party to know what a third party is
>>prohibited from receiving, both because we can't prohibit receiving
>>and because the potential for prior consent always exists.
>>
>>> Best Practice 1: Additional Voluntary Measures
>>>
>>> A first party may voluntarily take steps to protect user privacy
>>>when
>>> responding to a Do Not Track request.
>>
>>That text serves no useful purpose.
>>
>>> 3.3 Third Party
>>>
>>> 3.3.1 General Rule
>>>
>>> A third party must not receive, retain, use, or share any
>>>information
>>> related to communication with a user or user agent. There are
>>>exceptions
>>> to this general rule as defined in the following sections. In case
>>>of
>>> ambiguity, an exception must be construed narrowly. Each exception
>>> operates independently; exceptions cannot be combined except where
>>> explicitly noted otherwise.
>>
>>No, exceptions are permissions and they combine just fine.
>>
>>As mentioned a dozen times before, I object to blanket prohibition
>>of things that a third party obviously has to do just to process
>>a request, even if it is followed by a specific list of exceptions
>>that might or might not be enough to actually process that request.
>>If you can't formulate a requirement in terms of actual tracking
>>or the data collected as a result of tracking, then I will not
>>implement that requirement. As such, this entire section 3.3
>>is not suitable for our specification.
>>
>>> 3.3.2.3 Outsourcing
>>
>>Outsourcing is a general aspect of implementation by any party.
>>It should not be buried under third party.
>>
>>> A first party may outsource website functionality to a third party,
>>>in
>>> which case the third party may act as the first party under this
>>>standard
>>> with the following additional restrictions.
>>>
>>> 3.3.2.3.1 Technical Precautions
>>>
>>> 3.3.2.3.1.1 Operative Text
>>>
>>> Throughout all data reception, retention, and use, outsourced
>>>service
>>> providers must use all feasible technical precautions to both
>>>mitigate the
>>> linkability of and prevent the linking of data from different first
>>> parties.
>>
>>Nonsense, that's unimplementable in practice (nobody knows what
>>"all feasible technical precautions" are at any given moment).
>>Furthermore, this requirement is not specific to outsourcing --
>>it would apply to any third party. And in the specific case of
>>outsourcing, we don't have control over the data and thus cannot
>>prevent two different parties from collecting the same identifiable
>>information, thereby making the data sets linkable by accident.
>>
>>> Structural separation ("siloing") of data per first party, including
>>>both
>>> 1. separate data structures and
>>> 2. avoidance of shared unique identifiers
>>> are necessary, but not necessarily sufficient, technical
>>>precautions.
>>
>>Not phrased as a testable requirement. Moreover, shared identifiers
>>are only a tracking concern if they are retained by the server in a
>>form that could be correlated across multiple first parties.
>>
>>> 3.3.2.3.1.2 Non-Normative Discussion
>>
>>Actually, the contents of this section consists of a number of
>>suggested best practices with an occasional mixture of normative
>>"must" and "should" statements. They do not belong here.
>>
>>...
>>
>>> 3.3.2.3.1.2.2 Siloing in the Backend
>>
>>See general note about "none of your business". This section and all
>>subsections are not suitable for our documents.
>>...
>>
>>> 3.3.2.3.1.2.3 Retention in the Backend
>>>
>>> An outsourcing service should retain information only so long as
>>>necessary
>>> to provide necessary functionality to a first party. If a service
>>>creates
>>> periodic reports, for example, it should delete the data used for a
>>>report
>>> once it is generated. An outsourcing service should be particularly
>>> sensitive to retaining protocol logs, since they may allow
>>>correlating
>>> user activity across multiple first parties.
>>
>>There is no chance that Adobe will agree to delete data that belongs
>>to the first party just because we are a contractor. By definition,
>>we do not own that data. And protocol logs are not specific to DNT.
>>
>>...
>>
>>> 3.3.2.3.3 Use Direction
>>>
>>> An outsourced service
>>> 1. must use data retained on behalf of a first party ONLY on behalf
>>>of
>>> that first party, and
>>
>>That belongs in the definition of outsourced service provider.
>>
>>> 2. must not use data retained on behalf of a first party for their
>>>own
>>> business purposes, or for any other reasons.
>>
>>Too broad. Please use the definition of data processor from the EU.
>>
>>Data must be used in order to retain it in the first place;
>>that is the outsourcer's business purpose. The outsourcer might
>>provide continued storage and backups of the data, along with a
>>suite of tools for use by the party for mining their data to
>>produce reports; dissemination of those reports is entirely
>>controlled by the contracting party, not the outsourcer.
>>
>>An outsourcer must be able to do anything that a party can do with
>>that data, so long as the outsourcer is acting at the direction
>>of that party. Furthermore, the data must be usable by the
>>outsourcer as necessary for capacity planning and billing the
>>party for services provided. Likewise, aggregate statistics
>>based on received requests (across all parties) can be used if
>>the statistics do not contain anything linkable to persons.
>>
>>In general, DNT must not apply to outsourced service providers
>>acting as a first party any more than it applies to first
>>parties: no sharing is allowed beyond the contracting party
>>relationship.
>>
>>...
>>
>>> 3.3.2.4 User Permission
>>>
>>> A website my engage in practices otherwise prohibited by this
>>>standard if
>>> a user grants permission. Permission may be attained through the
>>>browser
>>> API defined in the companion Tracking Preference Expression
>>>document. A
>>> website may also rely on "out-of-band" consent attained through a
>>> different technology. An "out-of-band" choice mechanism has the same
>>> effect under this standard as the browser exception API, provided
>>>that it
>>> satisfies the following bright-line requirements:
>>> 1. Actual presentation: The choice mechanism must be actually
>>>presented
>>> to the user. It must not be on a linked page, such as a terms of
>>> service or privacy policy.
>>> 2. Clear terms: The choice mechanism must use clear, non-confusing
>>> terminology.
>>> 3. Independent choice: The choice mechanism must be presented
>>>independent
>>> of other choices. It must not be bundled with other user
>>>preferences.
>>> 4. No default permission: The choice mechanism must not have the
>>>user
>>> permission preference selected by default.
>>
>>Actually, an out of band consent mechanism provides additional
>>permissions, whether or not they fall within the scope of this
>>specification. In all cases, prior consent overrides DNT because
>>it is the only means of enabling the user to selectively allow
>>data collection by specific trusted parties without constantly
>>having to change their browser configuration.
>>
>>There is still no need to define how prior consent is obtained,
>>provided we define it as specific, explicit, and informed.
>>
>>> An "out-of-band" choice mechanism must additionally satisfy the
>>>following
>>> high-level standard:
>>>
>>> An ordinary user would know that the choice overrides his or her
>>>privacy
>>> protections under this standard.
>>
>>No. Most consent actions do not, in any way, harm a user's privacy,
>>and ordinary users don't read standards.
>>
>>> 3.3.2.5 Security
>>>
>>> 3.3.2.5.1 Operative Text
>>>
>>> A third party may receive, retain, and use data about a particular
>>>user or
>>> user agent for the purpose of ensuring its security, provided that
>>>there
>>> are reasonable grounds to believe the user or user agent was
>>>attempting to
>>> breach the party's security at the time the data was received.
>>>
>>> Note: This draft does not address the extent to which technical and
>>> business precautions are required for security data.
>>
>>As already explained, DNT must not have any effect on security or
>>fraud controls, period. That is not negotiable. Data retention for
>>those purposes may be limited to what is necessary for those purposes,
>>but the notion that sending "DNT: 1" has any effect whatsoever on
>>security and fraud controls is a non-starter.
>>
>>
>>Cheers,
>>
>>....Roy T. Fielding, Principal Scientist, Adobe Systems Inc.
>> <http://adobe.com/enterprise>
>>
>>
>>
>
>
>
Received on Saturday, 16 June 2012 16:25:13 UTC