- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 2 Mar 2015 17:37:51 -0800
- To: Tracking Protection Working Group <public-tracking@w3.org>
Hi all,
Here are my long-delayed comments on the whole TCS ED (as quoted).
In general, I still prefer the alternative I proposed in October.
http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance-i203b.html
though I think the specific problems around issue-203 have been solved
by the current draft (aside from a few bits described below).
> W3C
> Tracking Compliance and Scope
> W3C Editor's Draft 17 February 2015
>
> http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html
>
> Editors:
> Nick Doty, W3C
> Heather West, Google
> Justin Brookman, CDT (until September 2013)
> Sean Harvey, Google (until June 2012)
> Erica Newland, CDT (until May 2012)
>
> Copyright (c) 2015 W3C(R) (MIT, ERCIM, Keio, Beihang). W3C liability,
> trademark and document use rules apply.
>
> ----------------------------------------------------------------------
>
> Abstract
>
> This recommendation defines a set of practices for compliance with a
> user's Do Not Track (DNT) tracking preference to which a server may claim
> adherence.
>
> Status of This Document
>
> This section describes the status of this document at the time of its
> publication. Other documents may supersede this document. A list of
> current W3C publications and the latest revision of this technical report
> can be found in the W3C technical reports index at http://www.w3.org/TR/.
>
> This editor's draft does not constitute consensus and may change
> frequently. Reviewers are advised to consult the list of issues tracked in
> the Compliance Current product and the wiki list of change proposals
> developed by participants in the Working Group. The Working Group has
> published a Last Call Working Draft of the companion Tracking Preference
> Expression document; a more stable snapshot of this document has been
> published as a Working Draft.
>
> This document was published by the Tracking Protection Working Group as an
> Editor's Draft. If you wish to make comments regarding this document,
> please send them to public-tracking@w3.org (subscribe, archives). All
> comments are welcome.
>
> Publication as an Editor's Draft does not imply endorsement by the W3C
> Membership. This is a draft document and may be updated, replaced or
> obsoleted by other documents at any time. It is inappropriate to cite this
> document as other than work in progress.
>
> This document was produced by a group operating under the 5 February 2004
> W3C Patent Policy. W3C maintains a public list of any patent disclosures
> made in connection with the deliverables of the group; that page also
> includes instructions for disclosing a patent. An individual who has
> actual knowledge of a patent which the individual believes contains
> Essential Claim(s) must disclose the information in accordance with
> section 6 of the W3C Patent Policy.
>
> This document is governed by the 1 August 2014 W3C Process Document.
>
> 1. Scope
>
> Do Not Track is designed to provide users with a simple mechanism to
> express a preference to allow or limit online tracking. Complying with the
> user's preference as described in this document includes limits on the
> collection, retention and use of data collected as a third party to user
> actions.
It also limits sharing of data collected as a first party.
> This recommendation is intended for compliance with expressed user
> preferences via user agents that (1) can access the general browsable Web;
> (2) have a user interface that satisfies the requirements in Determining
> User Preference in the [TRACKING-DNT] specification; (3) and can implement
> all of the [TRACKING-DNT] specification, including the mechanisms for
> communicating a tracking status, and the user-granted exception mechanism.
s/; (3) and can /; and, (3) can /
> Issue 209: Description of scope of specification
>
> 2. Definitions
>
> 2.1 User
>
> A user is an individual human. When user agent software accesses online
> resources, whether or not the user understands or has specific knowledge
> of a particular request, that request is "made by the user."
Note that this differs from the definition in TPE.
> 2.2 User Agent
>
> The term user agent refers to any of the various client programs capable
> of initiating HTTP requests, including but not limited to browsers,
> spiders (web-based robots), command-line tools, native applications, and
> mobile apps [RFC7230].
>
> Issue 227: User Agent requirements in UA Compliance vs. Scope section
>
> There is a proposal to move a sentence about user agents from the
> Introduction/Scope section to this section. We might also include a
> reference here to the conformance requirements on user agents in the
> companion TPE recommendation.
Is that why there is an extra sentence in section 2.1? The issue comment
doesn't seem to apply.
> 2.3 Network Interaction
>
> A network interaction is a single HTTP request and its corresponding
> response(s): zero or more interim (1xx) responses and a single final
> (2xx-5xx) response.
>
> 2.4 User Action
>
> A user action is a deliberate action by the user, via configuration,
> invocation, or selection, to initiate a network interaction. Selection of
> a link, submission of a form, and reloading a page are examples of user
> actions.
>
> 2.5 Subrequest
>
> A subrequest is any network interaction that is not directly initiated by
> user action. For example, an initial response in a hypermedia format that
> contains embedded references to stylesheets, images, frame sources, and
> onload actions will cause a browser, depending on its capabilities and
> configuration, to perform a corresponding set of automated subrequests to
> fetch those references using additional network interactions.
The term subrequest was removed from TPE because we didn't need it.
It is only used in this specification once -- in 2.8, where it can be
deleted without any change of meaning (see below).
> 2.6 Party
>
> A party is a natural person, a legal entity, or a set of legal entities
> that share common owner(s), common controller(s), and a group identity
> that is easily discoverable by a user. Common branding or providing a list
> of affiliates that is available via a link from a resource where a party
> describes DNT practices are examples of ways to provide this
> discoverability.
>
> 2.7 Service Provider
>
> Access to Web resources often involves multiple parties that might process
> the data received in a network interaction. For example, domain name
> services, network access points, content distribution networks, load
> balancing services, security filters, cloud platforms, and
> software-as-a-service providers might be a party to a given network
> interaction because they are contracted by either the user or the resource
> owner to provide the mechanisms for communication. Likewise, additional
> parties might be engaged after a network interaction, such as when
> services or contractors are used to perform specialized data analysis or
> records retention.
>
> For the data received in a given network interaction, a service provider
> is considered to be the same party as its contractee if the service
> provider:
>
> 1. processes the data on behalf of the contractee;
> 2. ensures that the data is only retained, accessed, and used as directed
> by the contractee;
> 3. has no independent right to use the data other than in a permanently
> deidentified form (e.g., for monitoring service integrity, load
> balancing, capacity planning, or billing); and,
> 4. has a contract in place with the contractee which is consistent with
> the above limitations.
>
> 2.8 First Party
>
> With respect to a given user action, a first party is a party with which
> the user intends to interact, via one or more network interactions, as a
> result of making that action. Merely hovering over, muting, pausing, or
> closing a given piece of content does not constitute a user's intent to
> interact with another party.
>
> In some cases, a resource on the Web will be jointly controlled by two or
> more distinct parties. Each of those parties is considered a first party
> to a given user action if a user would reasonably expect to communicate
> with all of them when accessing that resource. For example, prominent
> co-branding on the resource might lead a user to expect that multiple
> parties are responsible for the content or functionality.
>
> Network interactions and subrequests related to a given user action may
> not constitute intentional interaction when, for example, the user is
> unaware or only transiently informed of redirection or framed content.
s/Network interactions and subrequests related/Network interactions related/
[because subrequests are a subset of those related network interactions]
> 2.9 Third Party
>
> For any data collected as a result of one or more network interactions
> resulting from a user's action, a third party is any party other than that
> user, a first party for that user action, or a service provider acting on
> behalf of either that user or that first party.
>
> 2.10 Deidentification
All my spell-checkers and the abundance of existing external references
say this should be hyphenated as De-identification, de-identified, etc.
I don't think that is editorial preference (neither is spelling).
> Data is permanently deidentified when there exists a high level of
> confidence that no human subject of the data can be identified, directly
> or indirectly (e.g., via association with an identifier, user agent, or
> device), by that data alone or in combination with other retained or
> available information.
>
> 2.10.1 Deidentification Considerations
>
> In this specification the term permanently deidentified is used for data
> that has passed out of the scope of this specification and can not, and
> will never, come back into scope. The organization that performs the
> deidentification needs to be confident that the data can never again
> identify the human subjects whose activity contributed to the data. That
> confidence may result from ensuring or demonstrating that it is no longer
> possible to:
>
> * isolate some or all records which correspond to a device or user;
> * link two or more records (either from the same database or different
> databases), concerning the same device or user;
> * deduce, with significant probability, information about a device or
> user.
>
> Regardless of the deidentification approach, unique keys can be used to
> correlate records within the deidentified dataset, provided the keys do
> not exist and cannot be derived outside the deidentified dataset and have
> no meaning outside the deidentified dataset (i.e. no mapping table can
> exist that links the original identifiers to the keys in the deidentified
> dataset).
>
> In the case of records in such data that relate to a single user or a
> small number of users, usage and/or distribution restrictions are
> advisable; experience has shown that such records can, in fact, sometimes
> be used to identify the user or users despite technical measures taken to
> prevent reidentification. It is also a good practice to disclose (e.g. in
> the privacy policy) the process by which deidentification of these records
> is done, as this can both raise the level of confidence in the process,
> and allow for for feedback on the process. The restrictions might include,
> for example:
>
> * technical safeguards that prohibit reidentification of deidentified
> data and/or merging of the original tracking data and deidentified
> data;
> * business processes that specifically prohibit reidentification of
> deidentified data and/or merging of the original tracking data and
> deidentified data;
> * business processes that prevent inadvertent release of either the
> original tracking data or deidentified data;
> * administrative controls that limit access to both the original
> tracking data and deidentified data.
>
> Geolocation data (of a certain precision or over a period of time) may
> itself identify otherwise deidentified data.
>
> 2.11 Tracking
>
> Tracking is the collection of data regarding a particular user's activity
> across multiple distinct contexts and the retention, use, or sharing of
> data derived from that activity outside the context in which it occurred.
> A context is a set of resources that are controlled by the same party or
> jointly controlled by a set of parties.
>
> Tracking data is any data that could be combined with other data to engage
> in tracking a user across different contexts.
Wait, that's new. Tracking data is already implicitly defined by the
first paragraph, above, to be the data collected when tracking. I am pretty
sure that is how we use it, as well, so we don't need another definition.
The above definition changes it to mean the data used to enable tracking,
which isn't at all like we are using it.
In any case, the definition is incorrect because any data
"could be combined with other" (tracking) data to make more tracking data,
which implies that all data is tracking data.
If we need an explicit definition, it could be something like
"Tracking data is any data collected or derived as a result of tracking
that would not have been known without tracking."
> 2.12 Collect, Use, Share, Facilitate
>
> A party collects data received in a network interaction if that data
> remains within the party's control after the network interaction is
> complete.
>
> A party uses data if the party processes the data for any purpose other
> than storage or merely forwarding it to another party.
>
> A party shares data if it transfers or provides a copy of data to any
> other party.
>
> A party facilitates any other party's collection of data if it enables
> such party to collect data and engage in tracking.
We don't use facilitate, so its definition should now be removed.
> 3. Server Compliance
>
> It is outside the scope of this specification to control short-term,
> transient collection and use of data, so long as the data is not shared
> with a third party and is not used to build a profile about a user or
> otherwise alter an individual user's user experience outside the current
> network interaction. For example, the contextual customization of ads
> shown as part of the same network interaction is not restricted by a DNT:1
> signal.
>
> Issue 134: Would we additionally permit logs that are retained for a short
> enough period?
The above paragraph seems to be disconnected. I think it belongs in
section 1 (Scope).
> 3.1 Indicating Compliance and Non-Compliance
>
> In order to communicate compliance with a user's expressed tracking
> preference as described in this recommendation, a party MUST indicate
> compliance using the tracking status resource defined in the
> [TRACKING-DNT] recommendation. A party MUST use the following URI (in the
> compliance property array) to indicate compliance with this version of the
> recommendation:
The above is far too ambiguous for me, particularly since it assumes
that a party's compliance will be the same for all resources and that
there is only one tracking status resource.
Contrast the above to what I proposed:
To indicate compliance with this specification for a given
designated resource, an origin server MUST do all of the following:
• conform to the origin server requirements of [TRACKING-DNT];
• send a value other than ! (under construction) or D (disregarding)
for a tracking status value (TSV) applicable to that designated
resource; and
• send, in a tracking status representation applicable to that
designated resource, a compliance property that contains
at least one reference to the following URI:
> http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html
>
> Note
> The editor's draft URI points to content that will change. Versions of
> this document that are published as Working Drafts or later maturity
> levels will use permanent URIs in this section, pointing to content that
> does not change.
>
> When a user sends a DNT:0 signal, the user is expressing a preference to
> allow tracking. This recommendation places no restrictions on collection
> or use of data from network interactions with DNT:0 signals. Note,
> however, that a party might be limited by its own statements to the user
> regarding the DNT:0 setting. For more information, see Section .
>
> A party to a given user action which receives a DNT:1 signal and is
> tracking that action MUST indicate so to the user agent. A party that is
> tracking a user with that user's consent to override an expressed DNT:1
> preference MUST indicate so with the corresponding C or P tracking status
> values. A party that is tracking a user for reasons allowable under this
> recommendation (for example, for one of the permitted uses described
> below) MUST use the T value. A party to a given user action that is not
> engaged in tracking SHOULD use the N value (a T value is also conformant
> but not as informative).
Why does this paragraph use "a party to a given user action" here?
Shouldn't this apply to any recipient of a network interaction?
Also, I don't think it is accurate to combine "C or P" in one sentence,
since P does not presume the user's consent.
Also, we need to add the "G" value here.
> A party to a given user action that disregards a DNT:1 signal MUST
> indicate that non-compliance to the user agent, using the response
> mechanism defined in the [TRACKING-DNT] recommendation. The party MUST
> provide information in its privacy policy listing the specific reasons for
> not honoring the user's expressed preference. The party's representation
> MUST be clear and easily discoverable.
The above seems to arbitrarily differ from the requirements in TPE for
the "D" response.
> In the interest of transparency, especially where multiple reasons are
> listed, a server might use the [TRACKING-DNT] qualifiers or config
> properties to indicate a particular reason for disregarding or steps to
> address the issue. A user agent can parse this response to communicate the
> reason to the user or direct the user to the relevant section of a privacy
> policy. This document does not define specific qualifiers for different
> reasons servers might have for disregarding signals.
>
> 3.2 First Party Compliance
>
> With respect to a given user action, a first party to that action which
> receives a DNT:1 signal MAY collect, retain and use data received from
> those network interactions. This includes customizing content, services
> and advertising with respect to those user actions.
>
> Example 1
>
> A site that collects and uses data about users only when those users visit
> the site itself can comply with the a user's expressed DNT preference
> without changing the site's practices of data collection and use. Such a
> site can create a static site-wide tracking status resource with a
> tracking status value of N.
>
> A first party to a given user action MUST NOT share data about those
> network interactions with third parties to that action who are prohibited
> from collecting data from those network interactions under this
> recommendation. Data about the interaction MAY be shared with service
> providers acting on behalf of that first party.
>
> Compliance rules in this section apply where a party determines that it is
> a first party to a given user action - either because network resources
> are intended only for use as a first party to a user action or because the
> status is dynamically discerned. For cases where a party later determines
> that data was unknowingly collected as a third party to a user action, see
> Section .
>
> A first party to a given user action MAY elect to follow the rules defined
> under this recommendation for third parties.
>
> Note
> Given WG decision on ISSUE-241, how should a first party to an action
> indicate to the user that it is electing to follow third-party rules?
> Should we suggest using "N" or some other tracking status code?
>
> 3.3 Third Party Compliance
>
> Issue 203: Use of 'tracking' in third-party compliance
>
> When a third party to a given user action receives a DNT:1 signal in a
> related network interaction:
>
> 1. that party MUST NOT collect, share, or use tracking data related to
> that interaction;
> 2. that party MUST NOT use data about network interactions with that user
> in a different context.
>
> A third party to a given user action MAY nevertheless collect and use such
> data when:
>
> 1. a user has explicitly-granted an exception, as described below;
> 2. data is collected for the set of permitted uses described below;
> 3. or, the data is permanently deidentified as defined in this
> specification.
I dislike this contradiction of a MUST NOT and MAY nevertheless.
I'd rather reverse the order and say MAY when 1, 2, 3; otherwise,
MUST NOT (a) and MUST NOT (b).
> Example 2
> An embedded widget provider (a third party to users' interactions with
> various sites) counts visitors' country of origin and device type but
> removes identifiers in order to permanently deidentify collected data. For
> the purposes of this recommendation, the party is not tracking the user
> and can create a static site-wide tracking status resource with a tracking
> status value of N to indicate that status.
>
> Outside the permitted uses and explicitly-granted exceptions listed below,
> a third party to a given user action MUST NOT collect, share, or associate
> with related network interactions any identifiers that identify a specific
> user, user agent, or device. For example, a third party that does not
> require unique user identifiers for one of the permitted uses MUST NOT
> place a unique identifier in cookies or other browser-based local storage
> mechanisms.
>
> 3.3.1 General Requirements for Permitted Uses
>
> Some collection and use of data by third parties to a given user action is
> permitted, notwithstanding receipt of DNT:1 in a network interaction, as
> enumerated below. Different permitted uses may differ in their permitted
> items of data collection, retention times, and consequences. In all cases,
> collection and use of data must be reasonably necessary and proportionate
> to achieve the purpose for which it is specifically permitted;
> unreasonable or disproportionate collection, retention, or use are not
> "permitted uses".
>
> Note
> The requirements in the following sub-sections apply to a party that
> collects data for a permitted use and that would otherwise be prohibited
> from collecting, retaining or using that data under the third-party
> compliance requirements above. Where a first party to a given user action,
> for example, collects some data for a purpose listed among the permitted
> uses (e.g. security of network services), these requirements do not apply.
>
> 3.3.1.1 No Secondary Uses
>
> A party MUST NOT use data collected for permitted uses for purposes other
> than the permitted uses for which each datum was permitted to be
> collected.
Yikes. How about:
A party MUST NOT use data collected for permitted uses for purposes
other than those permitted uses.
> 3.3.1.2 Data Minimization, Retention and Transparency
>
> Data collected by a party for permitted uses MUST be minimized to the data
> reasonably necessary for such permitted uses. Such data MUST NOT be
> retained any longer than is proportionate to, and reasonably necessary
> for, such permitted uses. A party MUST NOT rely on unique identifiers if
> alternative solutions are reasonably available.
I know we have discussed this before, but "is proportionate to" does not
mean whatever it is that folks want this to mean. I think
"longer than is reasonably necessary for" is the correct phrase.
Proportionate only makes sense for the amount of data retained;
however, that too is meaningless when combined with "reasonably necessary".
> A party MUST provide public transparency of the time periods for which
> data collected for permitted uses are retained. The party MAY enumerate
> different retention periods for different permitted uses. Data MUST NOT be
> used for a permitted use once the data retention period for that permitted
> use has expired. After there are no remaining permitted uses for given
> data, the data MUST be deleted or permanently deidentified.
>
> Issue 199: Limitations on the use of unique identifiers
>
> 3.3.1.3 No Personalization
>
> A party that collects data for a permitted use MUST NOT use that data to
> alter a specific user's online experience based on tracking data, except
> as specifically permitted below.
>
> 3.3.1.4 Reasonable Security
>
> A party that collects data for a permitted use MUST use reasonable
> technical and organizational safeguards to prevent further processing of
> data retained for permitted uses. While physical separation of data
> maintained for permitted uses is not required, best practices SHOULD be in
> place to ensure technical controls ensure access limitations and
> information security.
>
> 3.3.2 Permitted Uses
>
> Issue 211: Should we specify retention periods (extended with
> transparency) for permitted uses?
[move issue marker to 3.3.1.2]
> 3.3.2.1 Frequency Capping
>
> Regardless of the tracking preference expressed, data MAY be collected,
> retained and used to limit the number of times that a user sees a
> particular advertisement, often called frequency capping, as long as the
> data retained do not reveal the user's browsing history.
>
> 3.3.2.2 Financial Logging
>
> Regardless of the tracking preference expressed, data MAY be collected and
> used for billing and auditing related to the current network interaction
> and concurrent transactions. This may include counting ad impressions to
> unique visitors, verifying positioning and quality of ad impressions and
> auditing compliance with this and other standards.
>
> 3.3.2.3 Security
>
> Regardless of the tracking preference expressed, data MAY be collected and
> used to the extent reasonably necessary to detect security incidents,
> protect the service against malicious, deceptive, fraudulent, or illegal
> activity, and prosecute those responsible for such activity, provided that
> such data is not used for operational behavior beyond what is reasonably
> necessary to protect the service or institute a graduated response.
>
> When feasible, a graduated response to a detected security incident is
> preferred over widespread data collection. In this recommendation, a
> graduated response is a data minimization methodology where actions taken
> are proportional to the problem or risk being mitigated.
>
> Example 3
>
> Examples of using a graduated response for data minimization in security
> and fraud prevention include:
>
> * recording all use from a given IP address range, regardless of DNT
> signal, when the party believes it is seeing a coordinated click fraud
> attack on its service from that IP address range.
> * collecting all data matching an identifiable fingerprint (a
> combination of User Agent and other protocol information, say) and
> retaining logs until it can be determined that they are not associated
> with such an attack or such retention is no longer necessary to
> support prosecution
>
> 3.3.2.4 Debugging
>
> Regardless of the tracking preference expressed, data MAY be collected,
> retained and used for debugging purposes to identify and repair errors
> that impair existing intended functionality.
>
> 3.3.3 Qualifiers for Permitted Uses
>
> A party MAY indicate which of the listed permitted uses apply to tracking
> of a user with the qualifiers mechanism defined in the [TRACKING-DNT]
> document. While providing qualifiers is OPTIONAL, a party that wishes to
> indicate particular permitted uses MUST use the corresponding characters
> as indicated in the table below.
>
> qualifier permitted use
> c frequency capping
> f financial logging
> s security
> d debugging
>
> A party MAY use multiple qualifiers to indicate that multiple permitted
> uses of tracking might be ongoing and that each such use conforms to any
> corresponding requirements. Where qualifiers are present, a party MUST
> indicate all claimed permitted uses.
>
> Note
> The qualifiers in this table correspond directly to the permitted uses
> described in the previous section. This list, the characters and the names
> may change depending on the resolution of open issues regarding the
> permitted uses.
>
> Example 4
> A site that tracks user activity across several unrelated sites (through a
> tracking pixel or embedded script, for example) but collects and uses
> tracking data only as necessary for security and debugging purposes might
> create a tracking status resource with a tracking status value of T (to
> indicate tracking) and a qualifiers value of sd (to indicate the
> particular permitted uses).
>
> 4. User-Granted Exceptions
>
> A party MAY engage in practices otherwise proscribed by this
> recommendation if the user has given explicit and informed consent. After
> consent is received, it MAY be subsequently registered through the
> User-Granted Exceptions API defined in the companion [TRACKING-DNT]
> document, or a party MAY obtain and record out of band consent to
> disregard a Do Not Track preference using a different technology. If a
> party is relying on out of band consent to disregard a Do Not Track
> preference, the party MUST indicate this consent to the user agent as
> described in the companion [TRACKING-DNT] document.
s/recommendation/specification/ [the former assumes a given status]
I find this confusing. Out-of-band consent is, by definition, not
something registered through UGE. Also, "out of band consent to
disregard a Do Not Track preference" is too specific. The out of band
consent may have had no mention of DNT, but still imply overriding
some or all of the DNT requirements. It is better to rewrite this as:
A party MAY engage in practices otherwise proscribed by this
recommendation when the user has given explicit and informed consent.
A party MUST indicate when it is relying on out of band consent to
override a Do Not Track preference, as described in the companion
[TRACKING-DNT] document.
> Example 5
> A site may provide a settings page to its logged-in users with an
> explanation of a feature that involves collecting data on that user's
> activity on other sites in order to provide more relevant content on the
> home site. To implement the feature and record that consent, the site
> places a cookie on the user's machine. In subsequent requests where the
> consent cookie is recognized and a DNT: 1 header is present, the site
> responds with a Tk response header of C, to indicate that consent to the
> user.
>
> 5. Interaction with Existing User Privacy Controls
>
> Multiple systems may be setting, sending, and receiving DNT and/or opt-out
> signals at the same time. As a result, it will be important to ensure
> industry and web browser vendors are on the same page with respect to
> honoring user choices in circumstances where "mixed signals" may be
> received.
>
> As a general principle, more specific settings override less specific
> settings, as where the specific consent in user-granted exceptions
> overrides a general preference. If a party perceives a conflict between
> settings, a party MAY seek clarification from the user or MAY honor the
> more restrictive setting.
>
> 6. Unknowing Collection
>
> If a party learns that it possesses data in violation of this
> recommendation, it MUST, where reasonably feasible, delete or de-identify
> that data at the earliest practical opportunity, even if it was previously
> unaware of such information practices despite reasonable efforts to
> understand its information practices.
>
> 7. Legal Compliance
>
> Notwithstanding anything in this recommendation, a party MAY collect, use,
> and share data required to comply with applicable laws, regulations, and
> judicial processes.
I still think this section is silly, but *shrug* ... Normally, I would
expect such a party to be non-compliant due to powers that be, rather
than compliant by escape clause.
> A. Acknowledgements
>
> This specification consists of input from many discussions within and
> around the W3C Tracking Protection Working Group, along with written
> contributions from Haakon Flage Bratsberg (Opera Software), Amy Colando
> (Microsoft Corporation), Nick Doty (W3C), Roy T. Fielding (Adobe), Yianni
> Lagos (Future of Privacy Forum), Tom Lowenthal (Mozilla), Ted Leung (The
> Walt Disney Company), Jonathan Mayer (Stanford University), Ninja Marnau
> (Invited Expert), Thomas Roessler (W3C), Matthias Schunter (IBM), Wendy
> Seltzer (W3C), John M. Simpson (Invited Expert), Kevin G. Smith (Adobe),
> Peter Swire (Invited Expert), Rob van Eijk (Invited Expert), David
> Wainberg (Network Advertising Initiative), Rigo Wenning (W3C), and Shane
> Wiley (Yahoo!).
>
> The DNT header field is based on the original Do Not Track submission by
> Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm
> (Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web
> Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Eliot
> Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js.
Cheers,
Roy T. Fielding <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe <http://www.adobe.com/>
Received on Tuesday, 3 March 2015 01:38:17 UTC