Re: Logged-In Exception (ISSUE-65)

The scenario you describe is at the core of ISSUE-65.  I would not override DNT, for the reasons I gave in my initial email.

I would note that nothing stops the social network from:

1) presenting unpersonalized widgets,

2) tracking if the user interacts with a widget, and 

3) tracking if the user gives consent (i.e. a web-wide exception, using the browser API or out-of-band).

Jonathan

On Mar 15, 2012, at 2:33 AM, Rigo Wenning wrote:

> Jonathan, 
> 
> thanks for starting to address this. I wonder if, according to you, the 
> following scenario falls within the scope of ISSUE-65:
> 
> A user logs into her favorite social networking site and clicks on "remember 
> me". The site sets a cookie that sets the state to "logged-in" (until 2018, 
> for the fun of it). Now the user closes the browser and goes on holidays, 
> comes back 2 weeks later and browses to her favorite news site where there are 
> a gazillion buttons from social networks on the bottom of every page. She 
> switches on DNT because she is looking for some information about race and 
> religion. Because she still has the "logged-in" cookie, she is considered 
> logged in to one of the networks and will be tracked in an _identified_ way. 
> But the probability that she is aware of this going on in the background are 
> very low. 
> 
> This raises the question of what "logged-in" really means. I agree with Shane 
> that an interactive logged-in session can be considered an out-of-band 
> agreement. You logged in, registered while accepting conditions etc. 
> Overriding DNT would create a legal mess. But without blinking prompt, I feel 
> there is something fishy in saying that this "logged-in". But this may be just 
> a browser interface issue. 
> 
> So is this part of ISSUE-65 according to you?
> 
> Rigo
> 
> 
> On Tuesday 13 March 2012 19:07:19 Jonathan Mayer wrote:
>> 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
>

Received on Thursday, 15 March 2012 21:08:38 UTC