RE: Action-157: Update logged-in consent proposal

Lee,

You are making the assumption that:

1. DNT will be implemented in the consumer's UA.
2. The consumer knows what DNT means.
3. Current services that permit personalization are invalid.
4. Consumers are not safe if DNT is disabled. You use the expression "best protection" as if the consumer is not safe unless DNT is enabled. I certainly want to dispel the myth that consumers are in danger if DNT is not enabled. Consumers should always be protected when using any online service. 

I don't think we have reached middle ground here.

JC

-----Original Message-----
From: Lee Tien [mailto:tien@eff.org] 
Sent: Monday, May 07, 2012 6:42 PM
To: public-tracking@w3.org
Subject: Re: Action-157: Update logged-in consent proposal

My two cents.  

I'm less convinced than others about obviousness via context.  We're only talking about users who send DNT:1, correct?  To me, that makes DNT:1 part of the context, and thus a strong default that requires a clear reversal.

So I'd want in every case during signup flow a clear statement like: 

"Even though I set DNT to prevent tracking, I allow Example Social to treat me as a person who did not set DNT to prevent tracking, which means that Example Social will identify me on other websites in order to [personalize social content, etc.] while I am logged in."   

And that the user must choose "yes" or "no" to move on.  

My example wording is probably crap, but my point is that the user is entitled to a clear presentation of the fact that signing up would override her DNT setting at the time that choice is being made.  It might even be the best protection for Example Social to be clear in this way.  

Lee

On May 7, 2012, at 6:03 PM, Justin Brookman wrote:

> I am not at all sure there is any clear divide here.  I think we can find common ground on the ideas that consent can be presumed by the fundamental nature of the service and that the choice could be presented clearly and prominently during the signup flow.  I think the question is how prescriptive we want to be in the language of the normative text.
> 
> Shane, when you say "these changes are overly prescriptive," were you referring to Jonathan's questions or the non-normative text I suggested.  If the latter, please let me know what you specific concerns are --- it was merely my intention to spell out with more clarity what I thought we were agreed upon.  Just as it's important for you to have non-normative language making clear that consent can be contextually presumed, it is *very* important for advocates to have the language making clear that privacy policy/TOS language won't be sufficient for express, informed consent for products where there are not contextual clues.  Again, I have not heard a single person advocate that this would be an appropriate or desirable result, and you have argued against such a result yourself.  I do not see how what I drafted could be deemed prescriptive or controversial (though perhaps I am just misreading your email, in which case, I apologize!).
> 
> From: Shane Wiley [mailto:wileys@yahoo-inc.com]
> To: Jonathan Mayer [mailto:jmayer@stanford.edu]
> Cc: Justin Brookman [mailto:justin@cdt.org], public-tracking@w3.org 
> [mailto:public-tracking@w3.org]
> Sent: Mon, 07 May 2012 20:38:56 -0400
> Subject: RE: Action-157: Update logged-in consent proposal
> 
> In some cases, #1 would be fine (Example Social is primarily based on sharing of “Social Me” buttons across web-sites and that’s the core value it provides to users – everything about the product is centered around this).
>  
> #2 is fine if the information is explicit and informed (“Welcome to 
> Social Example!  Among the many features we offer, we’ll also collect 
> your interaction with our “Social Me” buttons across the Internet 
> [Learn More].”)
>  
> It’s at #2 that the original proposed text was developed and the non-normative was attempting to allow for #1 where the service is obviously centered on multi-site data collection and use.
>  
> Since you appear to believe only approaches #5 or above are acceptable I suggest we punt on this conversation as I believe this will be another area of a clear divide.  Rather than attempting to override local laws with this provision perhaps our efforts would be better suited addressing more central issues and we can circle back to this one at the end if we have enough time.
>  
> - Shane
>  
> From: Jonathan Mayer [mailto:jmayer@stanford.edu]
> Sent: Monday, May 07, 2012 5:13 PM
> To: Shane Wiley
> Cc: Justin Brookman; public-tracking@w3.org
> Subject: Re: Action-157: Update logged-in consent proposal
>  
> This conversation has been in a roundabout for months.  Perhaps some straightforward examples would cut through talking points and clarify our substantive disagreements.  What do participants think of the following use cases?
>  
> 1) Example Social is a social network.  It includes this provision in its privacy policy: "In order to personalize our social content, we may identify you on other websites while you are logged in."
>  
> 2) The same statement is in Example Social's signup flow.
>  
> 3) The same statement is in Example Social's login flow.
>  
> 4) Example Social's signup flow includes an option: "I allow Example Social to identify me on other websites in order to personalize social content while I am logged in."  The option is marked "yes" by default.
>  
> 5) The same signup option is offered, but is is not marked "yes" or "no" by default.  The user must choose "yes" or "no" to move on.
>  
> 6) The same signup option is offered, but it is not marked "yes" or "no" by default.  The user does not need to give a response, and the lack of a response is functionally a "no."
>  
> 7) TrackMyBrowsing is a web service that exists for the sole purpose of collecting a user's browsing history.  A user signs up and logs in.
>  
> I think 1-4 are not sufficient consent and 5-7 are sufficient consent.
> On Monday, May 7, 2012 at 4:41 PM, Shane Wiley wrote:
> 
> These changes are overly prescriptive in my opinion and are narrowing valid consent paradigms.  If we go this route it would be easier to side-step this conversation altogether and move to a legal bar determination (probably where we should have started/ended).   
>  
> I would simply include the re-enforcement mechanism provided by a response/well-known URI approach in the non-normative.  Parking this off-weights the conversation as in this context a user is CONSTANTLY remind of previous choices.  This “constant reminder” model far surpasses most online transparency structures in place today and provides the balance against the “as determined by local law” approach.
>  
> <Normative>
> Sites MAY override a user's DNT preference if they have received user consent to do so - as determined by local law.
>  
> <Non-Normative>
> Out-of-band consent will be further reinforced in user interactions through either the Header Response or Well-Known URI approaches to replying to user Tracking Preferences.  This will provide a constant reminder of prior consent on each interaction and provide a resource (link) to allow the user to understand how this consent was achieved and ideally options to alter that consent if the user chooses to do so.
>  
> - Shane
>  
> From: Jonathan Mayer [mailto:jmayer@stanford.edu]
> Sent: Monday, May 07, 2012 3:54 PM
> To: Justin Brookman
> Cc: public-tracking@w3.org
> Subject: Re: Action-157: Update logged-in consent proposal
>  
> I find Justin's language a great improvement.  We all agree that websites obviously dedicated to tracking will by rare; why should we let such exceptions dictate the general rule?
>  
> That said, there still seem to be a few open design points.
>  
> 1) Should this text be normative?  In my view, we're operating in the realm of MUSTs, not best practices.  Here's a stab at normative text: "A provision in a website policy document (e.g. terms of service or privacy policy) never constitutes explicit, informed consent.  In rare cases a website may be unambiguously dedicated to tracking users.  Signing into such a website would constitute explicit, informed consent."
>  
> 2) Can a website have an exception selected by default?  See, for 
> example, the Google account signup page: 
> https://dl.dropbox.com/u/37533397/tracking_the_trackers/safari_study/g

> oogle_plusone_signup_highlighted.png
>  
> 3) Can a website bundle the exception with other preferences, or must it be presented independently?
> On Monday, May 7, 2012 at 3:01 PM, Justin Brookman wrote:
> 
> On 5/5/2012 8:59 PM, Nicholas Doty wrote:
> Also, Shane and Justin, does this sentence "Companies ... should not 
> seek to obtain explicit, informed consent from users in non-obvious ways such as placing these details in their Terms of Service or deeply placed within their Privacy Center"
> imply that a service *can* obtain explicit, informed consent to override a user's DNT preference via a Terms of Service document and be in compliance with this standard?
>  
> If not, then we could make this clearer by updating the normative text:
> Sites MAY override a user's DNT preference if they have received explicit, informed consent to do so. Sites MUST NOT obtain explicit, informed consent via Terms of Service or other non-obvious means.
> I think we are all in agreement that the operator of a site cannot obtain explicit, informed consent via a Terms of Service, privacy policy, or other non-obvious means.  Either the tracking is obvious by the nature of the product, or you have to go out of your way to explain clearly and conspicuously and get permission.  I am open to putting language in the normative section making that clear, but I thought that Shane and others were strongly opposed to that.  I do agree that the proposed non-normative text could make clearer that ToS by itself cannot work.  Here is revised language:
> Non-Normative Text:
> 
> Even when a user has turned on a "Do Not Track" setting, the operator of a site may seek to obtain the user's permission to ignore that setting and track the user as a third party on other sites.  In seeking user consent, the tracking functionality has to be clearly communicated to the user such that the user is positioned to make a voluntary and informed decision about whether to allow the operator to collect and use cross-site data about the user in ways that would otherwise be prevented by the DNT setting.
> 
> Interactions with users to obtain consent can in many cases be contextual.  If a service has an obvious cross-site tracking function that the user deliberately signs up for then this could be deemed to have achieved explicit and informed consent from a user without directly addressing its reaction to an external Tracking Preference (which may not have been contemplated at the time the consent experience was designed).  For example, if a user signs up for a social reader service that clearly indicates that information about activity on other sites will be collected and published to a user's social networking page, the service would not need to get separate permission to ignore the DNT signal.  Even in these cases, however, organizations should provide Tracking Preference references in associated product or service materials such as a privacy policy, help center, and/or in separate notice to users.
> 
> Most services that a user signs up for do not have cross-site tracking functionality that would be obvious to a user.  For these services, operators who wish to comply with this spec and track despite the presence of a DNT signal should clearly and conspicuously ask users for permission to track despite the Do Not Track setting.  Simply agreeing to a long boilerplate legal agreement that includes mention of a right to track despite a DNT settings would not constitute express and informed consent.  For example, if the operator of an instant messaging client (who also owned an advertising network) asserted permission to track for behavioral advertising purposes only in a linked license agreement, a user's agreeing to the license agreement would not constitute express, informed consent to override the user's DNT preference for the purposes of this spec.
>  
> Out-of-band consent will be further reinforced in user interactions 
> through [let's park this paragraph until the response header/well 
> known URI are fully fleshed out.]
>  
> Or if the group believes there are some cases where non-obvious means would be acceptable, that would be a SHOULD NOT rather than MUST NOT. Or this could be phrased definitionally instead: "Consent via a Terms of Service or other non-obvious means is not explicit and informed."
>  
> Also, per the question on "ideally", is that a SHOULD requirement? e.g. "Sites SHOULD provide options to alter this consent via the tracking status resource."
>  
> Thanks,
> Nick
>  
> On Apr 25, 2012, at 12:23 PM, Shane Wiley wrote:
>  
> I’m fine with “ideally”:
>  
> <Normative>
>  
> Sites MAY override a user's DNT preference if they have received explicit, informed consent to do so.
>  
> <Non-Normative>
>  
> In the absence of a Tracking Preference standard, many organizations have developed direct consent mechanisms for web-wide tracking.  Interactions with users to obtain consent are often contextual.  For example, If a service has an obvious cross-site tracking function that the user deliberately signs up for then this could be deemed to have achieved “explicit and informed” consent from a user without directly addressing its reaction to an external Tracking Preference (which wasn’t contemplated at the time the consent experience was designed).  Even in these cases, organizations should consider providing Tracking Preference references in associated product or service materials such as a privacy policy, help center, or separate notice to users.
>  
> Companies claiming public compliance with the W3C Tracking Protection standard, should not seek to obtain explicit, informed consent from users in non-obvious ways such as placing these details in their Terms of Service or deeply placed within their Privacy Center if it will not be obvious to users that the nature of the service will lead them to ignore a user’s Tracking Preference based on the nature of the consent the user is granting. 
>  
> Out-of-band consent will be further reinforced in user interactions through either the Header Response or Well-Known URI approaches to replying to user Tracking Preferences.  This will provide a constant reminder of prior consent on each interaction and provide a resource (link) to allow the user to understand how this consent was achieved and ideally options to alter that consent if the user chooses to do so.
>  
>

Received on Tuesday, 8 May 2012 02:49:41 UTC