RE: Issue-207

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

But the need for clarity means that the user should be informed why the D signal has been sent. Just putting a list in a privacy policy of possible reasons a valid DNT might be rejected leaves the door open for arbitrariness and possible discrimination (on the grounds of a user's technology choice as Rob points out), and may lead to the D response becoming a more common occurrence.

Although it needs another transaction we can use the qualifiers property in the TSR (you were right Jack - I had missed that the status-id was indeed designed for that purpose) to report one of a small set of D reasons, say L for legal constraints, P for permitted purpose etc. We should agree an appropriate small set and specify the codes them (in the TCS if not in the TPE), for transparency and because UA's may want to parse them in order to indicate to the user. 


> -----Original Message-----
> From: David Singer [mailto:singer@apple.com]
> Sent: 18 April 2014 22:29
> To: Mike O'Neill
> Cc: Roy T. Fielding; Walter van Holst; public-tracking@w3.org
> Subject: Re: Issue-207
> 
> 
> On Apr 18, 2014, at 12:15 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > If that is the only reason to send a D ("we have reason to believe this DNT
> signal does not reflect the user's intention") then we do not need a qualifier, just
> specify that as the only justification for it in the TCS. If there are other possible
> reasons then, for transparency, there has to be a way of signalling the relevant
> one to the user.
> 
> I think people pointed out that there may be other possible reasons:
> 
> * your site was caught serving inappropriate content, and part of the court order
> was to track all requests for a period of time and keep full logs.  You are under a
> legal obligation to track all visitors
> 
> * As Roy points out, you have reason to believe you are under attack and need
> to track some or all visitors as part of the diagnosis
> 
> I really don’t want to re-open the discussion with Shane and others on this.  We
> have reached an uneasy middle ground, and if some servers stretch the use of
> ‘D’ too far, then the consequences will be outside the protocol (user and
> regulatory complaint, for example, or business relationships).  All we can ask for
> in the protocol is clarity, and to make sure that the two ends communicate to
> each other what they think and are asking.  More than that is not possible.
> 
> > The UA may indicate the response in some way, and the user is able draw
> conclusions from it.
> 
> Yes, exactly, the UA can tell the user ‘You are asking SkankyCommerce not to
> track you, and they say they are Disregarding your request. Do you want to close
> the connection, view their Privacy Policy to see why they might be doing this, or
> go straight to Yikes! and write a vitriolic review?’
> 
> 
> >
> > mike
> >
> >
> >> -----Original Message-----
> >> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> >> Sent: 18 April 2014 19:23
> >> To: Walter van Holst
> >> Cc: public-tracking@w3.org
> >> Subject: Re: Issue-207
> >>
> >> On Apr 18, 2014, at 10:41 AM, Walter van Holst wrote:
> >>
> >>> Rob already as argued for this better than I can. It only stands to
> >>> reason that syntactically well-formed DNT requests are honoured without
> >>> second guessing the user.
> >>
> >> No, that doesn't stand to reason, anywhere.  We don't honor requests
> >> from clients that match the pattern of a denial of service attack.
> >> We don't honor purchases made with a stolen credit card.  We don't
> >> honor requests that appear to be gatewayed through a phishing site.
> >> We frequently don't honor requests that pass through an export-controlled
> >> location. And we sure don't honor HTTP protocol fields from user agents
> >> that lie about their capabilities or semantics.
> >>
> >> I will never support a standard that allows a user agent to lie about
> >> its semantics to a server without any corresponding power of the server
> >> to recognize that lie and work around the bug.  That would only
> >> encourage unscrupulous actors to manipulate standard protocols for
> >> their own personal gain.
> >>
> >> If a user agent does not adhere to the semantics of the protocol,
> >> the signal will be ignored.  This is not subject to the WG's opinion.
> >> Whether or not a "D" is sent after a signal is ignored is what
> >> is subject to the WG's opinion.
> >>
> >> ....Roy
> >>
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.13 (MingW32)
> > Comment: Using gpg4o v3.2.42.4591 - http://www.gpg4o.de/
> > Charset: utf-8
> >
> >
> iQEcBAEBAgAGBQJTUXm6AAoJEHMxUy4uXm2JA54IAMGloJfE7P4c3tk4ENqyeqB
> S
> > Vke/7moiNUZ+/l32Q8KwxOatt3WrdmLafUIJBX5L5rXmn+PK4dyJJnu+grFXMKoz
> >
> +SDdwIAv4xoPM/9hw7D5loYZ5BAaWG1SLogDcLePIoRsBaf7bCP1NY0x8jzHDznz
> >
> 4J3ScoVzhFv7i592MVOKwXpC3nLCUIUh8UmaCdplXGekTel+9ORQNKbz7Y5XVPs7
> >
> sul9+vsIuZf4W9JYShWwTRaxeZkiD9KDCG8uvCN5lke+DoGpr6gfuRz92M+E7xmX
> > ykldJtgYfCfd7p7Abg9SKukhOH6CAKsnfilT5gw2XWyCNJyoqGF36nGd4v6ukkI=
> > =Cu9j
> > -----END PGP SIGNATURE-----
> >
> >
> 
> David Singer
> Manager, Software Standards, Apple Inc.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.2.42.4591 - http://www.gpg4o.de/
Charset: utf-8

iQEcBAEBAgAGBQJTUj6tAAoJEHMxUy4uXm2JpewH/RuK8AFGMoReakljbN5jRQAY
Ebk01aGSmxzbv8DoDZRufLylHQGwPKTaV7cHmoAi5KpKoywPsDfUVc7i5Jm+XLwV
JpTME/MGWEa/cnqpq4LwvNvdlJ7/hacwJzZXqDJxsqd5ISDkbIgDIsQuppBGcIS5
SQaNeqwS5oOTWhCr39YAsUK/HeKI5YPn41KLjqdE3d0oUeoBUIH4dmGa2SnUqQMS
zg9fnOYdTVADovvKPTKPm17sYLIk2Hrnb/jdFWktYDN/paQRSeT8H/0LmIK5HtUR
a4vo8MpzfB1m3QO+xukb9C8veUmZH1uP7OxMaTyZuw1k7MGjw2Itt+Sc7e6R+VQ=
=ZDls
-----END PGP SIGNATURE-----

Received on Saturday, 19 April 2014 09:16:24 UTC