RE: status of Tracking Preference Expression (DNT) Editor's Draft

Thanks Roy for this impressive amount of work. I will read it carefully. For
now I like the API name change which is certainly better than "exceptions",
though it might upset some webappsec folk who are already working on a
Permissions API. We (David Singer I think it was) suggested the term way
back anyway.

There might be mileage in merging these APIs sometime in the future (after
we finish this obviously).

Here is the current draft of the Permissions API
https://w3c.github.io/permissions/

BTW it is also a bit stingy on explaining Promises, though they do have a
reference to the guide.

Mike


-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: 02 July 2017 15:24
To: tracking protection wg <public-tracking@w3.org>
Subject: status of Tracking Preference Expression (DNT) Editor's Draft

I spent the week trying to ensure that all of the changes the WG has
made or resolved since CR have been correctly added to the draft and
that the overall spec is readable and consistent.  I also revisited
some of the old last call input to see what we could improve now that
we decided to change the API.  This resulted in a significant number
of editorial changes (mostly terminology fixes) and a few normative
changes (API names and adjustments to the text of a couple of the
resolved issue that were committed while I was in Europe).

The current ED is at

  https://w3c.github.io/dnt/drafts/tracking-dnt.html#rep.controller

a complete side-by-side diff of the changes since CR is at

  https://w3c.github.io/dnt/diffs/diff_tpe_CR_to_ED_20170702.html

and the blow-by-blow history can be seen at

  https://github.com/w3c/dnt/commits/master/drafts/tracking-dnt.html


The following are significant changes worth reviewing first:

0) I updated the SOTD section and removed DNT-extension from the formal
   "at risk" category (since the new W3C process doesn't seem to care
   about removing things after CR).

1) I did a global replace of "user-granted exception" with
   "user-granted permission" (and assorted other variants)
   and adjusted the descriptions accordingly.

2) I replaced the target and top-level origin terminology of the API
   descriptions with terms that are defined by HTML5 or new terms
   defined using the terms in HTML5. This was necessary because we depend
   on the domain model for some defaults and the matching algorithm.

3) I added a Note to 5.1 to describe why no signal is the default
   and why mandating a preconfigured DNT:1 is a bad idea.  Given the
   number of misunderstandings from the prior last call comments,
   I think it is worth the attempt. YMMV.

4) I explicitly defined how the TSV and TSR properties are extended by
   compliance regimes and required that the compliance array contain
   identifiers for each such extension used. See 6.2.11, 6.5.3, and 6.5.10.

5) I clarified the policy property in accordance with issue #35 but
   removed the examples because they used real names and assumed the
   policy link referenced only a tracking policy and not the site's
   entire privacy policy. See 6.5.8.

6) I reverted part of the "WG consensus" decision on issue #21 which
   added a requirement to the JavaScript API section that redefined
   what is a valid TSR and required the presence of controller and policy
   properties be present, in spite of the fact that both are defined
   as having a default when not present (which accomplishes exactly
   the same thing without sending any extra bytes).

7) After updating the terminology in section 7.* (User Granted Permissions),
   I found so many severe problems with the description that I decided
   to rearrange the order in which it is presented and rewrite some of the
   introductory paragraphs. It is still terrible, but at least now we can
   see some of the glaring omissions. All prior requirements and useful text
   should still be present (but in different sections and using different
   terms to describe the domains). You can compare them in the diff, but
   it is probably more useful at this point to just give a careful read of
   the entire section and suggest the additional text that it needs to
   help people implement the thing.

8) I added some notes in section 7 where I think the API still has some
   serious shortcomings.  I would like to remove those notes before CR.

Unfortunately, my personal conclusion remains that the API and the API
descriptions are not ready for a push to CR.  They need serious work,
actual implementation experience, and review by the Web Platform folks.
If we want to publish something right now, publish it as a WD instead
so that we don't bother the team with premature process.

I have already overspent the time I had available.  I won't be able
to work on it again until July 10th at the earliest, and will go on
sabbatical on July 24th through September 5.  I will be happy to resign
as editor of TPE if the WG can find anyone with experience specifying
Web Platform promise APIs to carry it the rest of the way.

My suggestion is that folks in the WG who aren't on vacation this week
should do a thorough read-through of the ED and raise new issues on github
for anything you think should be changed, even if it is just a request to
revert something I described above (after you have reviewed the ED).
That will make it far easier for us to track things that need to be
addressed or brought to a formal CfC.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <https://www.adobe.com/>

Received on Sunday, 2 July 2017 16:05:46 UTC