RE: ISSUE-161: Discussion of semantics and alternatives to "!"

Hi Matthias,

 

OK, but for clarity:

 

<p>

A tracking status value of 3 means that the origin server claims that the designated resource conforms to the requirements on a third party. The resource may have been designed for use within third-party or first-party contexts.

</p>

 

Mike

 

 

From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
Sent: 22 April 2013 13:36
To: public-tracking@w3.org
Subject: Re: ISSUE-161: Discussion of semantics and alternatives to "!"

 

Hi Mike,

you are right. The current language does not work in this case.

How about this modified language for the "3" signal:
<p> A tracking status value of 3 indicates that the origin server claims that the designated resource conforms to the requirements on a third party. These resources can safely be used in 1st and 3rd party contexts. </p> 
(IMHO the "1" language does not need changing).

Note that my goal is to minimise signals and reduce complexity ...


Regards,
matthias
On 22/04/2013 11:59, Mike O'Neill wrote:

Hi Matthias,
 
You are right, it is sufficient. But the spec says:
 
<p>
A tracking status value of 3 means that the origin server claims that the designated resource <em>is designed for use within a third-party context</em> and conforms to the requirements on a third party. 
</p>
 
The EU server needs to say it is complying with DNT even if the resource is designed to be in a first-party context e.g. its home page or something. My text is for clarity and just says that replying with A or 3 or even 1 is OK and they are equivalent responses, but a response of 1 could be taken as an indication they were complying with lower restrictions than is in fact the case. The new A response means they comply as if they were a third-party but in fact the resource may be designed to be accessed either as a first-party or a third-party.
 
BTW the script at line 25 of the JS in http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html has a comma that should not be there. It makes IE10 throw its toys out of the pram and not apply the respec formatting.
 
 
Mike
 
 
 
 
-----Original Message-----
From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
Sent: 22 April 2013 09:22
To: public-tracking@w3.org
Subject: Re: ISSUE-161: Discussion of semantics and alternatives to "!"
 
Hi Mike,
 
thanks for the proposed language.
 
Why is it insufficient to respond with "3" (I am following third party rules and this content can be safely used in a 3rd party context)?
 
Regards,
Matthias
 
On 21/04/2013 21:19, Mike O'Neill wrote:

On the last call Roy asked for text to clarify how EU servers should respond with a 1 or 3 tracking status.
 
Given that a server under an EU jurisdiction has no need to differentiate between resources designed for use in first-party or third-party contexts the current requirement for a 1 or 3 response (unless no tracking whatsoever is used) is redundant and potentially confusing for implementers. Last October I posted issue-183 which called for an "E" response in this situation. Perhaps an "A" (for "Any") might be more generally applicable.
 
I suggest the following text (5.2.4.1):
 
<h4>Any Party (A)</h4>
<p>A tracking status of A means that the origin server makes no claim 
about the context the designated resource was designed for and that it 
conforms to at least the requirements, under this standard, of a 
third-party. In jurisdictions that require that all resources conform 
to at least the requirements of a third-party a tracking status value 
of 1,3 or A are equivalent.</p>
 
Mike
 
 
-----Original Message-----
From: Rob van Eijk [mailto:rob@blaeu.com]
Sent: 21 April 2013 17:31
To: David Singer; Jonathan Mayer; Matthias Schunter (Intel 
Corporation); public-tracking@w3.org
Subject: Re: ISSUE-161: Discussion of semantics and alternatives to "!"
 
 
Also, on a more fundamental level, my position is that ALL permitted uses in the TCS section 6.2.2.7 MUST have a qualifying equivalent in the TPE section 5.4.2.
 
Rob
 
Rob van Eijk schreef op 2013-04-21 18:15:

David wrote:

I think we have heard from very few people here.

The discussion about a tracking status value of ! is useful in the 
sense that it allows to rethink if the granular dialogue that has 
been crafted is fit for purpose. In my opinion it is not. It makes no 
sense to me that a company can make representations to honor DNT in e.g.
it's DNT statement on the website and then ignore DNT by responding 
with !. It contradicts with transparency.
 
If a party representations is such that is honors DNT, the best way 
IMHO to signal testing or debugging is not in the tracking status 
value, but in the qualifier (TPE section 5.4.3).
 
So I suggest to remove "!" in TPE section 5.2.1 and adjust the table 
in TPE section 5.4.2 such that it links to the permitted use for 
debugging (TCS section 6.2.2.7).
 
Rob
 
 
David Singer schreef op 2013-04-21 03:56:

On Apr 21, 2013, at 2:42 , Jonathan Mayer  <mailto:jmayer@stanford.edu> <jmayer@stanford.edu>
wrote:
 

On Saturday, April 20, 2013 at 1:43 AM, David Singer wrote:
 

On Apr 19, 2013, at 13:02 , Jonathan Mayer  <mailto:jmayer@stanford.edu> <jmayer@stanford.edu>
wrote:
 

David,
I disfavor having any selective noncompliance flag. I'm open to 
the idea of a debugging/testing/phasing-in flag, but it would 
have to be narrowly scoped (e.g. specific uses and limited 
duration) and explicitly disallowed as a basis for claiming Do 
Not Track protocol or policy compliance.

well, the specific use is for when a site is not yet ready to 
claim compliance; why would the duration need a formal limit?

A website might repurpose an indefinite 
debugging/testing/phasing-in flag as a de facto selective 
non-compliance flag. I'd like to mitigate that possibility.

I don't understand the "selective" in your sentence.
 

yes, agreed, the documentation needs to state that the use of this 
flag is a declaration that compliance is not claimed.
* * * *
On 'I am Disregarding you', I am trying to work out your 
alternative in my mind. It seems that if there are going to be 
sites that will ignore DNT signals, you would prefer a state in 
which they could say nothing, and signal nothing, unless someone 
finds out (and how would they)? The site could, if challenged, say 
"we decided to ignore signals we deemed non-compliant". The user, 
unable to see that their data is being added to a database, is 
none the wiser, the privacy researcher is unaware, and so on. Is this really better?

If a website claimed to support Do Not Track but surreptitiously 
ignored certain DNT: 1 signals, it could face grave legal, 
business, and media consequences.

"…if it is found out, and they don't successfully argue that they 
can be non-compliant in response to what they believe are 
non-compliant signals"
As for detection, there are a number of technical options that I'd 
be glad to discuss.
For what it's worth, note the lineup of stakeholders on this issue:
it's not the advocates, regulators, and researchers clamoring for a 
selective noncompliance signal. It's the websites that want to 
practice selective noncompliance.
I think we have heard from very few people here. I suggested it, 
since I like transparency. Shane accepted it, and almost no-one else 
has said
 

For what it's worth, I don't think it's OK to practice selective 
non-compliance, unless forced. But I do support transparency. Yes, 
they may be trying to 'soften the blow' by not being accused of 
lying to users as well as not always complying. "Yes, it's true we 
don't always observe DNT signals, but we're up front about it".

0, 0, 0); font-family: Helvetica; font-size: medium; font-style:
normal; font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2; text-align: auto;
text-indent: 0px; text-transform: none; white-space: normal; widows:
2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust:
auto; -webkit-text-stroke-width: 0px; "> David Singer Multimedia and 
Software Standards, Apple Inc.

 
 

 
 
 
 

 

Received on Monday, 22 April 2013 15:12:15 UTC