– DRAFT –
Tracking Protection Working Group Teleconference

<Brendan> I can't join audio until 30 minutes into the call due to conflict

<Brendan> Should I leave IRC until I am able to join audio?

<Bert> Brendan, no need to leave IRC

<fielding> agenda is at https://‌lists.w3.org/‌Archives/‌Public/‌public-tracking/‌2017Mar/‌0013.html

Discussion 1: Should TSR be extensible?

- Mike: Fields for EU should be there (or extensible to be there).

Mike: Informed consent requires certain information to be available via TSR

Mike: JSON is extensible anyway. We pre-define some fields with a TPE-defined semantics.

Additional fields can be introduced.

Mike: data-controller SHOULD be provided

Roy: Existing implementation is already fully extensible. Compliance regimes can introduce and require new fields.

Roy: TSR is not exposed during consent dialogue - only page is seen by user (note: We require the site to explain to a user what he is consenting to). The page calls the API to store the consent.

+schunter

<aleecia> This is hardly a push to redo P3P

<aleecia> It may or may not be useful, but this is not P3Pesque

Rob: Extensibility useful

Rob: If DNT is used to obtain consent, then additional data is required to make it legally valid.

<aleecia> So I’m hearing: we would be supporting EU compliance, which is why we rechartered. I’d like to understand how important this change would be.

<aleecia> Ok, “I tried to implement and had a hard time” is pretty good information to add, IMHO

Rob: EU compliance regime could define additional fields that are required to be added by the site.

Rob: Browser requirement: Allow user to revoke consent. Should allow users to review the TSR (=source of truth that is independent of the claims of the web-site)

<fielding> It is always worthwhile to discuss implementation experience, but that starts with implementing the protocol as defined (or at least within proximity). I don't want to see the TSR become extremely large just to support a tool that isn't even part of the consent dialog.

Aleecia: URLs can point to specific anchors for specific information pieces.

<rvaneijk> Well phrased by Aleecia. Extensible yes, but additional fields as options. Not required fields.

Aleecia: URL should point to user-readable text; User agent should retain the URL and re-display it on request.

==> Policy URL would be mandatory.

<aleecia> presumably human-readable has more nuance and is designed for users to read. Less P3P-like than the TSR. :-)

<rvaneijk> An advantage of the TSR that it can even be called in pre-flight.

Proposed Decision 1: When a user-granted exception is registered, user agent should retrieve and retain TSR info.

SHOULD

<fielding> right, the TSR is designed for pre-flight checks. Note that the TSV and Compliance array are what matters for that case, not human reading of JSON strings.

<aleecia> Rob’s extension seemed light-weight & reasonable to support better UIs

<aleecia> Leaves full control with the publishers, does not require redoing current privacy policies. Pretty simple. And makes for a cleaner web experience iff UAs want to adopt. If we don’t provide the mechanism, they’re kinda limited to just parsing the TSR without letting any context from publishers go through (unless we imagine users read privpols on their own…)

<fielding> right now, {"tracking":"N"} is a valid TSR. It is meant to be very small, with defaults making use of what the UA already knows.

<aleecia> …which is a great example of why the fields ought to be optional not manditory.

<aleecia> (i’m unpersuaded on the machine readable issues Mike is raising, perhaps I’m not getting full understanding yet, but it’s NLP all the way down no matter what so why bother)

policy-qualifiers contains in JSON with additional attribute-value pairs

<aleecia> sure, a different compliance approach could make them MUSTs beyond our MAY

<fielding> we are talking about https://‌github.com/‌w3c/‌dnt/‌issues/‌23

<aleecia> so here was Mike’s version:

<aleecia> {

<aleecia> "policy": {

compliance is an array already

<aleecia> "cookie_policy": "https://‌webresource.com/‌cookies" ,

<aleecia> "privacy_policy": "https://‌webresource.com/‌privacy",

<aleecia> "responsible_disclosure_policy": "https://‌webresource.com/‌security",

<aleecia> "terms_and_conditions": "https://‌webresource.com/‌terms_and_conditions"

<aleecia> }

<aleecia> }

<fielding> Again, this is sending more information for which there is no actual use case for reading the TSR. This is metadata that can be added to the privacy policy page.

<rvaneijk> E.g., "compliance": [
…
… "http://‌wetten.overheid.nl/‌BWBR0009950#Hoofdstuk11_Paragraaf11.1_Artikel11.7a",
…
… "http://‌wetten.overheid.nl/‌BWBR0011468/‌2016-01-01",
…
… "https://‌www.w3.org/‌TR/‌tracking-dnt/"
… ],

<aleecia> That makes UAs unlikely to implement UIs

<Zakim> fielding, you wanted to comment on why we need to reduce that API anyway

<aleecia> that’s interesting! but not the problem i was trying to solve

Roy: The page that explains the consent and calls the consent API should contain all information. This URL may be recorded to document what has been consented to.

<aleecia> this is much more involved than what i had in mind. i’m not opposed to what Roy suggests, it’s just a much bigger hammer

<aleecia> all i was looking for was a way for the text the lawyers write to be presented to users in a standard way

Roy: The page is known already (no extra retrieval) and is the actual info that was displayed.

<aleecia> if i agree to a thing, what did i agree to. seems basic. now that there’s no standard compliance approach, we should support conveying the information

<fielding> I agree that should be basic.

Roy: All metadata for consent should rather be in the page that registers consent

<aleecia> (& better implementations are great by me, if there’s a way to reduce overhead great, but having some way to know what you agree to seems crucial)

<fielding> and the TSR is extensible, if that does turn out to be needed for a given compliance regime.

<aleecia> Having five ways to do the same thing via different compliance docs is painful

<fielding> which part of this is not painful ;-)

<aleecia> We cannot anticipate everything, but out to have a good start