Re: My logfile of potential TPE changes and features to be put at risk

Hi Roy,

thanks a lot for the feedback. You are right that I mixed editorial and
non-editorial changes.
As Jeff Jaffe put it: While we should be formally able to push to Rec,
it would help to gain further confidence that the TPE is implementable
and contains the right set of features.

The point that we discussed (that was not properly reflected in my
email) was that besides some editorial changes,
we may need to introduce further changes based on the implementation
experience we try to gather.
The point is that we plan to do some serious evaluation that may lead to
further insight that may then require us to do those non-editorial
changes that I listed as candidates below.

fyi: If we want to introduce larger changes, according to the new 2016
process this means that we need to publish another CR for review before
pushing for Rec.

I hope this makes sense... I can provide more details in our next WG call.

Regards,

matthias

Am 22.09.2016 20:04, schrieb Roy T. Fielding:
>> On Sep 22, 2016, at 4:09 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:
>>
>> (Editorial) Changes to TPE
>> - Change fingerprinting section and extend it to a privacy and security
>> section
> The entire spec is about privacy and security.  We would have to narrow
> that quite a bit, such as "privacy bits specific to the TPE protocol"
> or some such.
>
>> - Allow HTTP Equiv (change to section 5.2; proposed text by Mike ONeil)
>>   Paste from Mikes Document?
> That wouldn't be editorial. While I appreciate the desire to make things easier
> to deploy, the fact is that an organization cannot make any claims to compliance
> (or even knowledge) of tracking if they don't have the ability to control
> standard header fields.  Individuals using a common hosting service that does
> not itself implement TPE are incapable of making any statement about tracking,
> even if they want to, since the hosting service might be tracking for them
> or using software that tracks without their knowledge.
>
> Site owners need to first ensure the hosting service is going to obey whatever
> claim they are going to make. Part of that is making sure that the hosting
> software won't interfere with sending consistent Tk values and providing access
> to the associated well-known URL space.  Note that we are using the well-known
> URL space specifically to allow non-trackable requests to be made before a
> trackable request, so sending meta http-equiv in an already-tracked response
> is not equivalent.
>
>> - No change to "DNT Extensions" - leave it at risk but do nothing for now
> *shrug*
>
>> - Change definition of "enabled" to also include exceptions: Once you
>> recorded an exception, you implicitly enabled the feature.
> That would not be editorial because the term is used in normative requirements.
> In any case, it isn't necessary: read the last two paragraphs of
>
>   https://www.w3.org/TR/tracking-dnt/#determining
>
>> - Check whether all fields in the tracking status object have actual
>> value in real-life
> Again, not editorial.  A useful thing to do, surely, but changes would result
> in a return to WG status.
>
>> - Add question: on call-back mechanism for exception API. Site could be
>> informed whether their request for an exception has been granted or declined or
>> that the user agent chooses to give no indication. Maybe using promises?
> Reopening a closed design issue is not editorial.
>
>> - We should mark the cookie-like wildcards in the exceptions as a
>> feature at risk.
> Too late.
>
>> - We should consider making explicit targets mandatory or else drop the
>> features.
>>    Reason for this feature was that a company may have a list of companies
>>        with contractual relationships and would want to extend a site-wide
>>        exception only to those.
> Reopening a closed design issue is not editorial.
>
>> - Ask Rob whether there are any changes required for GDPR compliance
>> (e.g. terms definitions that are so broken they do not work)
> Even if it were even remotely possible to reopen that issue without
> mass destruction, GDPR compliance has nothing to do with the terms we
> use for the user agent's request. At most, it would define the terms of
> one Compliance spec to which a site could reference in their TSR.
>
>> - An EU compliance document may need define a set of qualifiers that
>> provide transparency for EU users.
> Yes, that would be in scope for such a compliance spec.
>
> Cheers,
>
> ....Roy
>
>

Received on Friday, 23 September 2016 07:41:18 UTC