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

> 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 Thursday, 22 September 2016 19:04:53 UTC