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 <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 <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 08:22:47 UTC