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

OK Matthias, that's fine. I will start to use issue-194 for this discussion,
so I have no objection to you closing 185.

 

Mike

 

 

From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
Sent: 15 April 2013 11:13
To: Mike O'Neill
Cc: public-tracking@w3.org (public-tracking@w3.org)
Subject: 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>
<http://www.w3.org/2011/tracking-protection/track/issues/112/edit>  (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>
<http://www.w3.org/2011/tracking-protection/track/issues/144/edit>  (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>
<http://www.w3.org/2011/tracking-protection/track/issues/161/edit>  (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>
<http://www.w3.org/2011/tracking-protection/track/issues/185/edit>  (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>
<http://www.w3.org/2011/tracking-protection/track/issues/143/edit>  (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.