Re: Call for proposals for ISSUE-194

On a past call I described one possible proposal to address this issue. I don't think any of the proposals of this form are likely in practice to help the problem so I would prefer silence (combined with legal and social measures). Nevertheless, it may still be worth describing the proposal, which I think would be less bad than some alternatives.

We could define two flags that would fit in the "extension" part of the protocol as currently defined, "u" and "d":

DNT: 1u
DNT: 0u

"u" is a redundant flag, but may be used by user agents to clarify that a user affirmatively chose this DNT setting. DNT: 1u has the same meaning as DNT: 1.

DNT: 1d
DNT: 0d

"d" indicates that the DNT setting was made by default. User agents and other software MUST NOT use this setting. [DNT: 1d indicates non-compliance with this standard, just as Tk: ! indicates non-compliance with the Compliance spec.]

If user agents that currently plan to send a DNT signal by default could be persuaded to use these flags (while not being persuaded to comply with the spec), it could facilitate services that want to disregard only signals set by default.

If the goal is just to break all current (or "legacy" as Matthias used it below) implementations, we could more efficiently do that by changing the name of the header ("DNU" or "DNV" instead of "DNT"). I think such a change would be a mistake; that goal is antagonistic to our goal of creating interoperability.

Thanks,
Nick

On May 3, 2013, at 9:58 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:

> Hi Team,
> 
> thanks for your input!
> 
> One challenge that I heard is to distinguish legacy signals (tools spraying DNT;1) from newly designed
> user agents that comply with our spec.
> 
> My understanding of the proposal by Rob:
> - Use authentication to ensure valid transmission of signals
> - Replace unauthenticated signals by DNT1
> 
> Another proposal was to introduce a new flag/value to distinguish
> legacy signals from signals from newly designed user agents:
> - DNT;1 - Legacy signals
> - DNT;1i - User preference collected at install-time
> - DNT;1p - User preference entered by the user as part of the run-time preference settings
> - DNT;0 - Permission to track (by preference or exception)
> 
> Note that for all approaches, there is always the User agent string that gives some indication of the user agent sending the requests.
> 
> I am still eager to hear more proposals. Overall, the goal to reliably identify "sound" user preferences is a common objective of this group.
> IMHO we just have not found the best approach to achieve this goal.
> 
> Further comments, clarifications, and inputs are appreciated. I would also like to discuss this topic at our F2F next week.
> 
> Regards,
> matthias
> 
> On 30/04/2013 09:38, Matthias Schunter (Intel Corporation) wrote:
>> 
>> Hi Team,
>> 
>> during the last TPE call, we discussed ISSUE-194. One goal of ISSUE-194 is to ensure that sites reliably receive valid DNT signals.
>> Without such a mechanism, there is a risk that a multitude of things spray DNT;1 signals (antivirus, network devices, operating systems, ...; often without user interaction).
>> As a consequence, sites can no longer reasonably by required to listen to those signals.
>> 
>> We agreed that separating noise from signals is a valid concern and there were concerns
>> whether there exists any solution that satisfies our goals.
>> 
>> If we could reliably distinguish between valid user preferences/choice and noise from other entities on the net,
>> then this allows sites to actually reliably act on user preferences while "D"isregarding the noise.
>> 
>> As part of discussing this further, I would like to issue a call for proposals. The question is
>> what mechanisms are envisioned that allow sites to (more) reliably separate noise from preferences.
>> 
>> Any proposals (as responses) are welcome. My goal is to then discuss and compare thes proposals
>> to understand whether they help sites with this concern.
>> 
>> 
>> Regards,
>> matthias
>> 
>> 
> 
>

Received on Sunday, 5 May 2013 23:18:54 UTC