Re: F2F: Open Issues for the TPE Discussion on Tuesday

On May 5, 2013, at 2:36 AM, Matthias Schunter (Intel Corporation) wrote:

> Hi Team,
> 
> I re-scanned the open issues on the TPE and had a look at Roy's TPE diff:
>        http://www.w3.org/2011/tracking-protection/track/products/2
> 
> We have made substantial progress since our last Working Draft and
> we have addressed almost all open issues wrt the TPE!
> 
> Enclosed are the open issues that I would like to discuss during our F2F.
> As indicated earlier, I had a conflict and can only participate remotely.
> Thanks to David Singer who will help me moderating these sessions.
> 
> 
> ---------------------------------  SESSION 09.00-10.30 -------------------------
> 
> For the first session on TPE, I have two goals:
> - Quick Summary of Major changes since our last WD
> - Discuss the preference collection, transmission,
>   and acceptance/disregarding of preferences:
>    ISSUE-194: How should we ensure consent of users for DNT inputs?
>    ISSUE-161 Do we need a tracking status value for partial compliance or rejecting DNT?
> 
> I believe that these two issues are intertwined:

I don't.  Yes, ISSUE-194 exists because senders violate ISSUE-4,
but it is useless do anything within the protocol to change that
other than to keep clarifying the text describing our decision
on ISSUE-4.

ISSUE-194 is about minimum UI for consent.  I don't believe we
need a minimum UI for consent -- we just need to require that
consent be explicit and informed, as already discussed.

ISSUE-161 is about sending responses when there is not yet a
statement of conformance or when the server is disregarding
the signal.  Sites do not need either option (for the same
reason that sites don't have a need to send any response),
but it was requested as a means of providing more transparency.

ISSUE-161 is orthogonal to how many additional requirements
we add (or not) to the consent granting process, since "!" has
nothing to do with consent and "D" is not limited to invalid
consent.

> We can either try to find minimal common ground
> where we all believe that a defined way of preference collection is acceptable (and must
> not usually be disregarded), or else we allow flexibility wrt preference collection and management
> and allow sites to disregard certain signals (in a transparent way) that they deem unacceptable.

That is ISSUE-4, and as far as I am concerned it is carved in
stone until it is reopened by the chairs based on new information.

The protocol is defined to be carrying a user preference.
If the user has not set that preference, then the protocol is
violated.  There is no wiggle room either way -- any setting
of the preference must be a statement that the USER (not the
installer, not the sysadmin, not some dude at the ISP who wants PR,
and not some vendor engaged in a proxy battle) has performed
some action that deliberately set that preference.


> OPTION A: A first proposal along the first line is to keep the current spec that requires that preferences
>     must be expressed by actual users (while not saying how exactly; and then mandate that sites accept this preferences).

No, the former is already decided by ISSUE-4, and no protocol
can mandate adherence to a lie.

> OPTION B: A second proposal along the first line (as suggested by the DAA) is to constrain the preference setting
>   to be part of the browser settings (and then mandate that sites accept this preferences).

There will be no mandate that sites accept a lie.  Sites
will be bound by compliance to valid protocol.  Sites can do
whatever they want in the absence of valid protocol because
the protocol no longer applies.

Naturally, sites would still be bound by whatever
policies they have advertised outside of the protocol.

> OPTION C: A third proposal with enhanced flexibility (as discussed on the list) is to provide qualifiers to the preference
>   (even a "vendor preference" qualifier may be considered) and then allow sites to choose and disregard some of those
>   preferences.

It doesn't make any sense to design a protocol wherein signals
containing deliberate lies are somehow okay if they include
additional information explaining how badly they lie.  Obviously,
the folks sending the lie are going to lie about its source
as well.

> Note that technically, we need to introduce a new signal for Options A+B, too, to distinguish existing non-compliant
> user agents that sent DNT;1 from newly designed and compliant user agents that need to be distinghuisable
> (sending DNT;8, DNT;1+, .... or anything else that is different from DNT;1).

*sigh*

....Roy

Received on Sunday, 5 May 2013 22:43:56 UTC