Re: Logged-In Exception (ISSUE-65)

(I'm addressing here only the logged-in exception component of Ted's question.  The rest of my response is in another thread.)

To clarify: the user *does not* have to log into the first party for each widget interaction.  You can see how Do Not Track might affect widgets by trying out the ShareMeNot extension, available at: http://sharemenot.cs.washington.edu/

On Mar 13, 2012, at 7:56 PM, Leung, Ted wrote:

> Jonathan,
> 
> Can you outline what you feel are acceptable out-of-band consent experiences.   As I understand you right now, it sounds like you want consent to be obtained after the user logs in, each time the user logs in.  Is that what you are looking for?
> 
> Ted
> 
> From: Jonathan Mayer <jmayer@stanford.edu>
> Date: Tue, 13 Mar 2012 19:42:39 -0700
> To: Shane Wiley <wileys@yahoo-inc.com>
> Cc: Tracking Protection Working Group WG <public-tracking@w3.org>
> Subject: Re: Logged-In Exception (ISSUE-65)
> 
> For purposes of this issue, let's assume the user has not provided out-of-band consent.
> 
> While I seriously doubt that we would allow a first party to achieve out-of-band consent by burying it in signup terms or a privacy policy (ISSUE-69), even if we did, some responsible third parties would not take advantage of the loophole.
> 
> On Mar 13, 2012, at 7:29 PM, Shane Wiley wrote:
> 
>> Jonathan,
>>  
>> If “logged-in” equates to “out of band” consent from a user, then I believe this is moot discussion and would equate more likely to #3 – depends on the terms of registration with that party.  I would suggest we treat “logged-in” on the merits of registration with each party and therefore the W3C makes no statement with regard to DNT and a logged-in state.
>>  
>> - Shane
>>  
>> From: Jonathan Mayer [mailto:jmayer@stanford.edu] 
>> Sent: Tuesday, March 13, 2012 7:07 PM
>> To: Tracking Protection Working Group WG
>> Subject: Logged-In Exception (ISSUE-65)
>>  
>> I see three possible policy options here.
>>  
>> 1) No logged-in exception: login state does not affect DNT obligations.
>>  
>> 2) A logged-in exception: if the user is logged into a website, it is treated as a first party.
>>  
>> 3) In between: if the user is logged into a website under certain conditions (e.g. a recent login, or a login in the same window), it is treated as a first party.
>>  
>> The ISSUE is PENDING REVIEW, with two text proposals for #1.  (One proposal would be explicit about it, the other would be implicit.)
>>  
>> #1 seems to me the right outcome.  A first party is under greater market pressure to get privacy and security right - a privacy plus relative to pure third parties.  On the other hand, a first party can link browsing activity to account information - a privacy minus.  Given the risks at issue, it seems to me users should still be provided control.
>>  
>> I would note that #1 does *not* prevent social widgets and single sign-on from functioning.  Rather, they will initially appear unpersonalized.  After user interaction they can function as normal in a specific scenario, and after user consent they can always function as normal.  Arvind Narayanan and I mocked up an example of Facebook's like button under DNT at: http://donottrack.us/cookbook
>>  
>> I am concerned that #2 and #3 would privilege specific advertising business models.  Those advertising companies that also operate a large first-party website would be greatly advantaged relative to pure third-party advertising companies.
>>  
>> Finally, I think #2 and #3 impose an unrealistic burden on users by compelling them to learn about the logged-in exception and then choose between the convenience (and in some cases security) of a saved login and carefully monitoring their login status to exercise choice.
>>  
>> For those participants who persist in viewing DNT as a limit on content personalization, I think all of the same arguments apply (save the first paragraph about collection).
>>  
>> In group discussions I *think* there has been a consensus or near-consensus for #1.  If anyone disagrees, I'd very much like to hear about it.  Otherwise, this issue seems ripe for closing in next week's call.
>>  
>> Best,
>> Jonathan
>