RE: Batch closing of TPE related issues

Rigo,

I believe by pairing the OOBC with the control link, we've removed the likelihood of false options for users.  If a company were to really want to make it hard to reverse an OOBC, they would attempt to hide it from the user and use other persistent means of storing the user's consent.  I believe places OOBC and UGE in a central location for users is a far better outcome in all cases.

- Shane

-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: Tuesday, June 18, 2013 1:43 PM
To: David Singer
Cc: Shane Wiley; public-tracking@w3.org; Matthias Schunter (Intel Corporation); Rob van Eijk
Subject: Re: Batch closing of TPE related issues

On Tuesday 18 June 2013 11:35:15 David Singer wrote:
> > Could you please opine on the proposal to allow OOBC to be recorded 
> > in the UGE registry with a pointer to the control mechanism?
> That's almost the definition of in-band exceptions, isn't it?

OOBC was seen as legacy. My goal was to make getting an exception easier 
and also getting rid of the exception. If we store OOBC with its heavier 
procedures and other problems into the store, we create another parallel 
DNT exception mechanism that you can customize at will. And 
customization means I can make it arbitrarily harder to opt out. (Do you 
really really really want to opt out?)
So storing the OOBC in the UGE store is taking advantage of the user 
tradeoff (persistent store) but doesn't pay for it by allowing easy opt-
out. That's why I have a feeling that it is kind of cheating. 

On the other hand, the more Shane stores in the UGE with links to opt 
out, the better compared to the current situation. 

But my ultimate fear is that someone takes an UGE, mentally transforms 
and re-lables the UGE into OOBC that trumps everything and refuses any 
opt out or makes it arbitrarily difficult. Would this be compliant? If 
yes, Houston has a problem.... If not, how can we prevent that?

 --Rigo

Received on Wednesday, 19 June 2013 02:59:38 UTC