Re: Issue-207

Rob

you are right.  Generally, when someone finds a non-confirming implementation, they work with the company in question (not the end-user) and get the situation fixed.  In the meantime, they try to handle the users, um, gracefully.

In this case, we don’t seem to be in this state.  The best we have managed to get is IF you are going to disregard the signal THEN you must tell the user (and give the user the means to find out the possible reasons why).

You’ll note that we are carefully silent on whether such server behavior is considered conforming (a question for the compliance spec.), reasonable (a question for society as a whole), permitted by regulation (a question for regulators), and so on.  So yes, technically, you can write in your policy “I disregard all users on all days whose names end in Y”, and send the matching Disregard. Whether people outside the W3C would see that as reasonable, acceptable, or permissible, is (happily) outside our remit.

Clearly Shane and I (and others) have had rather sharp discussions on this before, and I both like him too much to want to repeat myself, and also feel that in the current environment we are unlikely to do better.  Which is why I would rather leave this where it is, and fry fish that are much further from being even vaguely cooked.


On Apr 21, 2014, at 13:01 , Rob van Eijk <rob@blaeu.com> wrote:

> 
> A user's and regulators expectation is that DNT "should opt out  of  collection  of  behavioral  data  for  all  purposes  other  than  those  that  would  be consistent  with  the  context  of  the interaction; DNT should  be  comprehensive, effective,  and  enforceable.  It  should (...) not  permit technical  loopholes." (cf. FTC)
> 
> The D-response with an standard explenation in the privacy policy is a techical loophole in the standard. It reduces user transparancy and damages user control. Moreover, it allows for discrimition based on the judgement of a server of the correctness of the implementation in the user agent. That judgement should not be made on the back of the user while he is using the Web.
> 
> Pleae correct me if I am wrong, but isn't it fair to say that the company making such a judgement should not have the user pay for this judgement, but instead engage with the company who is resonsible for the user agent, and/or file a complaint with the regulator or competent authority?
> 
> Rob
> 
> Roy T. Fielding schreef op 2014-04-21 20:11:
>> On Apr 21, 2014, at 7:12 AM, Rob van Eijk wrote:
>>> Burying the explenation in a large text would not suffice in my view.
>> Then don't bury it.
>>> You can not expect the user to keep track of which company accepts his user agent of choice, and which companies do not. Especially since there can be more than just one reason why a syntactically valid user expression of choice was disregarded.
>> I don't expect them to.  I don't expect a user to ever look at this
>> field, or anything else in the protocol for that matter.  I expect
>> regulators to look at them, and the occasional automated spider or
>> extension driven by someone with advocacy in mind.
>> Remember that the user expression part is already accomplished with
>> the request header field.  If a recipient doesn't want to adhere to
>> that expression, they would be foolish to respond at all to the DNT
>> signal.  "D" is only useful for servers that want to adhere to a
>> user's preference but are disregarding the DNT signal.  "T" is for
>> servers that track in spite of the preference (e.g., permitted uses).
>>> Roy, you take away the ability of a user to excercise choice with his user agent of choice.
>> No, the user agent takes away choice when it fails to implement the
>> protocol correctly.  That is easily correctable by the user agent.
>> There is nothing the server can do about it other than disregard.
>>> Although AB370 does not require companies to honor DNT, I am curious to hear what alternative(s) you give the user.
>> The same alternatives we already give, I presume, though I have not
>> been referring to any specific service.
>>> The output I think is acceptable, is adding granularity to the D-signal in the TPE in combination with new normative text to the TCS prohibiting technological discrimination.
>> I will not implement such a compliance document, nor will anyone
>> else in industry.  Creating compliance documents that none of the
>> servers implement is not a good use of our time.
>> ....Roy
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Monday, 21 April 2014 23:37:59 UTC