W3C home > Mailing lists > Public > public-tracking@w3.org > October 2012

Re: ISSUE-45 ACTION-246 Clarified proposal on compliance statements

From: David Wainberg <david@networkadvertising.org>
Date: Thu, 11 Oct 2012 10:26:20 -0400
Message-ID: <5076D70C.3030205@networkadvertising.org>
To: Ed Felten <ed@felten.com>
CC: Shane Wiley <wileys@yahoo-inc.com>, "public-tracking@w3.org" <public-tracking@w3.org>
It is not realistic to have a single universal standard that everyone 
everywhere adheres to in the same way. So I am assuming there will 
necessarily be variations. The question then becomes how many variations 
are there and how do companies communicate which they honor. This token 
proposal addresses that. Instead of leaving it to companies to define 
their own variations and communicate them in privacy policies, it 
facilitates having a relatively small number of variations that are 
communicated in a standard way.

On 10/11/12 10:05 AM, Ed Felten wrote:
> I'm unclear on how changing the standard to allow more entities to 
> write compliance definitions would have the effect of reducing the 
> number of compliance definitions in use.   How would that happen?
> On Thu, Oct 11, 2012 at 9:31 AM, David Wainberg 
> <david@networkadvertising.org <mailto:david@networkadvertising.org>> 
> wrote:
>     Ed,
>     Technically, there is nothing to prevent this. But there is
>     nothing to prevent it in any case. Today, a group of companies
>     could go out and create a new self-reg program. Even under a
>     single DNT spec released by the W3C, companies could create their
>     own variations of compliance. In fact, this is exactly the problem
>     this proposal solves for. Because there will necessarily be
>     variation in the way companies honor DNT, this proposal helps us
>     limit that variation to a relatively small set of widely accepted,
>     identifiable options. If companies depart from that set, they will
>     be easy to find and investigate. And, frankly, such outliers may
>     have a hard time doing business, as potential business partners
>     will shy away.
>     -David
>     On 10/9/12 7:55 PM, Ed Felten wrote:
>>     I was definitely thinking about all of the entities affected by
>>     the standard, and not just U.S.-based third party ad networks,
>>     which I agree are a small subset of the affected entities.
>>     I'm still not clear on what would prevent anyone from creating a
>>     new compliance regime under David's proposal.   You say that
>>     regulators and advocates would prevent this.   How exactly would
>>     that work?  Who would you have deciding which compliance regimes
>>     were allowed and which were not?
>>     And how is the user interface supposed to work?  Does the user
>>     have to make a separate decision to accept or reject each
>>     compliance regime?  That seems impractical if there are more than
>>     a very few regimes.  Or would you let the browser help in the
>>     decisionmaking?
>>     On Tue, Oct 9, 2012 at 11:52 PM, Shane Wiley
>>     <wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com>> wrote:
>>         Ed,
>>         When you look at this through the lens of 3^rd parties /
>>         service providers I don’t believe the universe is as large as
>>         your mental model assumes.  If you further narrow this to
>>         3^rd party ad networks (initial FTC focus in this area),
>>         you’ll find the number is very small and at least in the US
>>         context, the number of “valid compliance standards” available
>>         to provide a representation are very small (primarily two:
>>         DAA or NAI).  When you expand this to other regions you’ll
>>         likely find small numbers of valid compliance standard
>>         options for 3^rd parties.  So while theoretically you could
>>         have a world where 5 companies get together to develop their
>>         own standard, the real-world provides for a very different,
>>         pragmatic outcome.  I would suggest we shy away from
>>         contemplating edge-cases that don’t represent reality. 
>>         Consumer advocates and regulators will still be expected to
>>         contain these types of scenarios from ever coming to pass (as
>>         well as industry as good actors will not want bad actors to
>>         undermine their good practices).
>>         - Shane
>>         *From:*Ed Felten [mailto:ed@felten.com <mailto:ed@felten.com>]
>>         *Sent:* Tuesday, October 09, 2012 2:31 PM
>>         *To:* David Wainberg
>>         *Cc:* public-tracking@w3.org <mailto:public-tracking@w3.org>
>>         *Subject:* Re: ISSUE-45 ACTION-246 Clarified proposal on
>>         compliance statements
>>         On Tue, Oct 9, 2012 at 8:41 PM, David Wainberg
>>         <david@networkadvertising.org
>>         <mailto:david@networkadvertising.org>> wrote:
>>             On 10/9/12 11:19 AM, Ed Felten wrote:
>>                  A company that collected only minimal information
>>                 would presumably be in compliance with all, or almost
>>                 all, of the compliance regimes in existence.  If I
>>                 were that company, I wouldn't want to miss out on the
>>                 benefits of claiming any compliance regime that a
>>                 particular user or browser might be looking for.
>>                 In general, there would a number of regimes, and a
>>                 server might be in compliance with various subsets of
>>                 them.  Again, servers won't want to miss out on the
>>                 benefits of claiming any compliance regime that a
>>                 particular user or browser might be looking for.
>>             I find it hard to imagine it happening in practice that
>>             companies would try to claim multiple tokens at the same
>>             time. Perhaps they would adhere to different regimes
>>             depending on context, e.g. the geo of the user, but it
>>             would only be one per request.
>>             Also, there is contemplated in the tech spec a "N" signal
>>             for this purpose, yes? Although I've opposed including
>>             that, doesn't it address the case you're describing?
>>         It would be possible for a company to comply with more than
>>         one compliance regime at the same time.  Even if we consider
>>         just two of the regimes that have been discussed, DAA and
>>         Nick's proposal ("NP"), a company could comply with neither,
>>         or just with DAA, or just with NP, or with both DAA and NP.  
>>         If a company complied with both, it would presumably want to
>>         say so--if it named just one, users who insisted on the other
>>         might conclude that the site did not meet their needs.
>>         If you consider more than two regimes, then the possibilities
>>         get even more complicated.  Suppose a company complies with
>>         "absolutely not tracking" (ANT) and also with DAA and NP.  If
>>         it just says it complies with ANT, the user or browser might
>>         not know about ANT, or might not know that ANT compliance
>>         implies NP compliance, or might mistakenly think that ANT
>>         compliance implies DAA compliance.  The company would
>>         presumably want to claim compliance with all three.
>>         If you postulate that some users will ignore tokens they
>>         don't recognize, as you seem to be doing below, then the
>>         desire of companies to claim multiple regimes gets even stronger.
>>                         Second, do you envision some body that
>>                         decides which compliance tokens are valid?  
>>                         If so, who might that be?   If not, how do
>>                         you prevent people from making up their own
>>                         new compliance tokens?
>>                     I would expect it to be unusual to do this, and
>>                     it might be a self-correcting problem in the
>>                     small number of cases. Given that the tokens
>>                     companies use will be transparent, advocates and
>>                     regulators will be able to investigate
>>                     non-standard tokens. A non-standard token will be
>>                     a red flag that says, "hey, we're doing something
>>                     unusual."
>>                 If there is no body or procedure deciding which
>>                 tokens are allowed, then there cannot be
>>                 "non-standard" tokens.  There can only be unusual
>>                 tokens.  I still don't see what would stop a company,
>>                 or small group of companies, from just creating their
>>                 own compliance rules and sending the resulting token.
>>                  Either there is somebody or something deciding which
>>                 tokens are valid; or all tokens are valid.
>>             What's to stop companies now from writing whatever they
>>             want in their privacy policies? This token idea would
>>             generate a small set of widely accepted tokens. Unlike
>>             with privacy policies, anyone doing something outside
>>             that small set would be machine-discoverable.
>>         This gets to my initial question: why would this scheme not
>>         lead to a proliferation of tokens?  Or to put it another way,
>>         why would these tokens not be like privacy policies, where
>>         many companies seem to want to create their own?
>>             But, even though I think it would work that way, I'm open
>>             to discussing ideas to standardize the set of tokens, if
>>             others are interested in that. I think I left that open
>>             in the proposal.
>>                     On Tue, Oct 9, 2012 at 3:22 PM, David Wainberg
>>                     <david@networkadvertising.org
>>                     <mailto:david@networkadvertising.org>> wrote:
>>                     ACTION-246
>>                     (http://www.w3.org/2011/tracking-protection/track/actions/246),
>>                     which relates to ISSUE-45
>>                     (http://www.w3.org/2011/tracking-protection/track/issues/45).
>>                     Hello all,
>>                     This is a clarification of my previous proposal
>>                     (http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0012.html).
>>                     I'm launching it on a fresh thread, because the
>>                     previous one got a bit wild and off-topic.
>>                     Recall that this arose out of the problem of how
>>                     or where parties may or must make statements
>>                     regarding their DNT compliance. One proposal,
>>                     which many of us strongly objected to, was to
>>                     make provision of the tracking status resource in
>>                     and of itself an assertion of compliance with the
>>                     DNT spec. That proposal was a replacement for an
>>                     initial proposal to require a public statement of
>>                     compliance, but without specifying where or how
>>                     that statement must be made.
>>                     The problems with these proposals are that the
>>                     one is overly strict, does not provide any
>>                     flexibility, and sets up a legal landmine that
>>                     companies will avoid by not providing the WKL,
>>                     and the other is too loose; it allows for
>>                     potentially unlimited variation in how companies
>>                     honor DNT and where and how they make their
>>                     commitments to do so.
>>                     This proposal solves these problems by requiring
>>                     a statement in the status resource regarding
>>                     compliance with /one of a limited set of DNT
>>                     variations/. Although I understand the desire for
>>                     and attractiveness of a single universal
>>                     specification for DNT compliance, the reality is
>>                     that we will have to accommodate some variation
>>                     based on, e.g., business model, geography, etc.
>>                     Examples of this problem arose during the
>>                     Amsterdam meeting. If we want to ensure wide
>>                     adoption and enforceability of DNT, this is the
>>                     way to do it.
>>                     The proposal is the following:
>>                     Add a required "compliance" field to the tracking
>>                     status resource in the TPE, where the value
>>                     indicates the compliance regime under which the
>>                     server is honoring the DNT signal. In 5.5.3 of
>>                     the TPE:
>>                     /    A status-object MUST have a member named
>>                     _compliance_ that contains a single compliance
>>                     mode token./
>>                     From here, I look to the group for discussion
>>                     regarding how and where to define compliance mode
>>                     tokens. My initial version of this proposal
>>                     suggested looking to IANA to manage a limited set
>>                     of tokens to prevent collisions. I think there
>>                     was some misunderstanding and concern about how
>>                     this would work. No -- companies should not just
>>                     create their own arbitrary values. My view is
>>                     that each token must have a well-defined and
>>                     widely-accepted meaning. How's this:
>>                     /Compliance mode tokens must be associated with a
>>                     legislative or regulatory regime in a relevant
>>                     jurisdiction, or with a relevant and established
>>                     self-regulatory regime./
>>                     I'm open to other ideas for this.
>>                     Cheers,
>>                     David
Received on Thursday, 11 October 2012 14:26:55 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:36 UTC