Re: Batch closing of TPE-related issues (response by April 16)

Hi Mike,


thanks for pointing out this valid concern.

I agree with your concern that if sites frequently register exceptions 
(web-wide or site-wide) invisibly, then this would weaken our standard.

However, I believe that this discussion is currently "hosted" in another 
issue:
- ISSUE-194: How do we ensure consent for exceptions
My reading is that "invisible" exceptions should not meet our consent 
requirements that we will define in ISSUE-194.

Another (market-driven) mitigation that I expect is that once bogus 
sites get common, then user agents will start
second-guessing the exceptions (i.e., reconfirming consent or providing 
feedback with baloons).

SUGGESTION: Is it OK for you to continue this discussion within 
ISSUE-194 and close ISSUE-185?


Regards,
matthias


On 12/04/2013 15:21, Mike O'Neill wrote:
>
> Hi Matthias,
>
> The reason for issue-185 was to address the danger of web-wide consent 
> being registered invisibly (bad actors or accidentally). This was not 
> a problem with the old API because the UA could intervene and notify 
> the user, and is not a problem with the new site-specific API because 
> of the limited scope.
>
> We should still keep it open to discuss ways to mitigate this, for 
> example requiring web-wide exceptions to be executed in user click 
> context or requiring  a data-controller string to be present in the TR.
>
> If illicitly registered web-wide exceptions are too easy and become 
> common it could weaken the authority of the standard.
>
> Mike
>
> *From:*Matthias Schunter (Intel Corporation) 
> [mailto:mts-std@schunter.org]
> *Sent:* 12 April 2013 14:00
> *To:* public-tracking@w3.org (public-tracking@w3.org)
> *Cc:* public-tracking-announce@w3.org
> *Subject:* Batch closing of TPE-related issues (response by April 16)
>
> Hi Folks,
>
> as part of our final cleanup in preparation of our next working draft, 
> I suggest to close the issues listed below.
>
> Please respond by April 16 if you cannot live with the proposed 
> resolution of those issues.
> If you do so, please include a justification and describe what concern 
> of yours is not addressed in
> the currently documented draft of the TPE.
>
> Regards,
>  matthias
>
> --------------
>
> ISSUE-112 
> <http://www.w3.org/2011/tracking-protection/track/issues/112>(edit) 
> <http://www.w3.org/2011/tracking-protection/track/issues/112/edit>
>
> 	
>
> OPEN
>
> 	
>
> How are sub-domains handled for site-specific exceptions? 
> <http://www.w3.org/2011/tracking-protection/track/issues/112>
>
> 	
>
> http://www.w3.org/2011/tracking-protection/track/issues/112
>
> REASON:
> - We agreed to use cookie-matching-like wildcards and rules to allow
>   for code-reuse in user agents
> - This is reflected in the spec
>
> ISSUE-144 
> <http://www.w3.org/2011/tracking-protection/track/issues/144>(edit) 
> <http://www.w3.org/2011/tracking-protection/track/issues/144/edit>
>
> 	
> 	
>
> User-granted Exceptions: Constraints on user agent behavior while 
> granting and for future requests? 
> <http://www.w3.org/2011/tracking-protection/track/issues/144>
>
> http://www.w3.org/2011/tracking-protection/track/issues/144
>
> REASON: In the new exception model, user agents are required to 
> communicate the status of an exception.
>  The status may be changed by end users and no further requirements 
> are needed. This is reflected in the spec.
>
> NOTE: We still have an open issue whether user agents are required to 
> implement the exception API.
>
> ISSUE-161 
> <http://www.w3.org/2011/tracking-protection/track/issues/161>(edit) 
> <http://www.w3.org/2011/tracking-protection/track/issues/161/edit>
>
> 	
> 	
>
> o we need a tracking status value for partial compliance or rejecting 
> DNT? <http://www.w3.org/2011/tracking-protection/track/issues/161>
>
> http://www.w3.org/2011/tracking-protection/track/issues/161
>
> RESOLUTION:
> - We defined a "!" indicator that says that the site is not claiming 
> to comply (e.g., maintenance / under construction)
>
> ISSUE-185 
> <http://www.w3.org/2011/tracking-protection/track/issues/185>(edit) 
> <http://www.w3.org/2011/tracking-protection/track/issues/185/edit>
> WebWide Not
>
> 	
> 	
>
> There should not be an API for web-wide exceptions 
> <http://www.w3.org/2011/tracking-protection/track/issues/185>
>
> http://www.w3.org/2011/tracking-protection/track/issues/185
>
> RESOLUTION:
> - We reached agreement that there will be an API for web-side exceptions
>
> ISSUE-143 
> <http://www.w3.org/2011/tracking-protection/track/issues/143>(edit) 
> <http://www.w3.org/2011/tracking-protection/track/issues/143/edit>
> Reciprocal Consent
>
> 	
> 	
>
> Activating a Tracking Preference must require explicit, informed 
> consent from a user 
> <http://www.w3.org/2011/tracking-protection/track/issues/143>
>
> http://www.w3.org/2011/tracking-protection/track/issues/143
>
> REASON:
> - We will have this discussion as part of ISSUE-194.
>
>