– DRAFT –
Tracking Protection Working Group Teleconference

schunter: I presented to Future of Privacy Forum

shane: matthias did an awesome job

timeline

schunter: We have to find a procedure. my proposal is in agenda.
… open issues addressed.
… spec freeze in April, spec in May
… probably need weekly telcons
… because we have some 20 issues.
… May need to do another version later.
… But I want to stick to the charter.

moneill2: CR in May? end of May? and after that?

<rvaneijk> Timeline is fine with me. Issues may pop up as ePriv Regulation proposal becomes solid

schunter: CR freezes the spec, maybe with features "at risk"
… once we have implems we may remove the "at risk" features

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

schunter: but apart from that, it will be the final Rec.

moneill2: Would we need a new charter if not?

<wileys> Use will be driven by what features we’re able to get into this version

<wileys> And if web browsers build user granted exceptions support

moneill2: My propsosal for site-specific consent, would that be a version-2 project?

schunter: We would have to decide at the end of the charter.
… If there is enough traction, enough adoption.

dsinger: We can also publish the omitted "at risk" feats as a Note
… and if they start getting traction, W3C could recharter a WG.

schunter: Everything is possible in W3C with sufficient traction.

rvaneijk: The negotiations on privacy directive sitill ongoing.
… May lead to us having to add new features.
… We should not exclude that.
… Inform & Consent important topics.
… Article 29 opinion and ENISA work on guidelines on DNT.

<wileys> Rob - informed consent will be based on the statements the publisher makes to the user outside of DNT. The publisher then executes the user granted exception API to record the user’s consent.

<wileys> +q

rvaneijk: There is also a more generic opinion of Art 29 in thw works.
… I want to make sure that whatever new attributes come out of this are known in this group.
… And that we have anought hooks to deal with those.

schunter: What should we do?

rvaneijk: Should keep the strict timeline.
… More concrete means people can more easily give feedback.
… There will be a small groups which is not known beforehand and which may need features such as the JS API.
… If the API becomes at risk before we know it will be a requirement, our timelines will be out of sync.

<wileys> Disagree on the DNT “Lite” - no value for the marketplace

rvaneijk: But a DNT-light would already be good.
… As long as the limitations are clear to everybody.
… Already clear se need more metadata in the well-known resource.
… *Free, informed and specific*

<wileys> How should the well known resource be structured? We had not defined a formal structure at this point.

rvaneijk: (I've been ill a bit, but will make an issue on github)

<wileys> Human readable vs. machine readable?

moneill2: Can we move this timeline by a week or so?

schunter: Not set in stone, a week is OK

<fielding> well, we defined it to be a JSON object, so that's a bit of structure ;-)

schunter: I wouldn't want to wait on Art 29 or ENISA, but if you alreadyhave input, raise the issue.

<walter> moneill2: ENISA is the EU-wide NCSC

moneill2: DNT extensions. Would like to specify in the API, maybe with dnt:1

<wileys> We need baseline browser support before we go too far on considering extension libraries for 3rd party tools

moneill2: E.g., for Qualified consent, or site-specirfic consent.

<rvaneijk> wileys, machine readable as in browsers being able to retrieve the information and present it to the user, if needed. UI is out of scope.

schunter: So if we push my timeline by one week, everybody is OK?

<wileys> Rob - great - just meaning they can display a text page, correct?

fielding: Don't close the issue list, maybe just cloise it for a specific draft.

<rvaneijk> yes, and/or provide links to deeper layers of information.

fielding: Keep opportunity for people to tell us we screwed up.

schunter: Issues can continue to come it, we just say they will be off our list for this release.

shane: disagree with DNT-light.
… Main driver is EU priv regulation.
… So if we mobilize DNT as a consent mechanism […]

<rvaneijk> wileys, slightly disagree, because profiling is ruled by the GDPR

shane: We can discuss more the concept of expiry now.
… draft regulation has sort of reminder, up to 6 months before user is reminded of their consent.
… Hoping we can integrate that.

<rvaneijk> wileys, on user granted exceptions, the concept of expiry and the ability to revoke consent are two important elements.

<wileys> Rob - agreed on expiry and revocation

walter: Support Mike's issue for a more interesting set of features for dnt:0

<moneill2> walter, thanks

dsinger: Back to what Roy was saying: Every CR & PR should have a link to where to report issues and a link to reports.

<rvaneijk> wileys, great :)

dsinger: Mailing lists no longer adequete.
… Maybe Bert can help with github or bugzilla.

<fielding> we could add a link to the issues list, sure.

<walter> +!

<walter> eh, +1

dsinger: Something that says report bugs here and see other bugs here.

<wileys> UGE revocation was always expected to managed by the browser UX - other than saying that this should be a browser feature is there anything else the standard should say here to meet the “as easy to remove as it is to set”?

<moneill2> great

fielding: I can move drafts to github and then open it up for the issues.

moneill2: About first using cookies:

<wileys> Cookies would be messy

<wileys> DNT UGEs are superior

<wileys> There are ways to do it but they are complex (see industry opt-out pages for example)

moneill2: In terms of generalized system that would be verificable anbd extensibel, you'd need to escape the same-origine. That's where API come sin.

schunter: Want to counter Shane's argument:
… I want to get the doc out, follow our charter.

<wileys> I’m not against pushing a CR now

<wileys> Just don’t want us to stop at that point

schunter: Then if we see after that thet we need more features, we can decide to delay.

shane: Not against a CR now. Just don't want us to stop after that.

schunter: So if there is more info or feedback, otherwise proceed.

<aleecia> +1 agree with Shane — CR now, expect a 1.1 shortly after based on feedback (if no feedback presumably we go home)

<wileys> Agreed - go for CR now - and once new information comes into the group perhaps refresh the CR if needed

<wileys> Time is against us… :-(

schunter: Encourage everyone to bring implementers into the room.

Implementation/validation strategy

schunter: We have three proposals: a) plugins, b) browser implem, c) adapt ourselves to existing IE/Edge
… Question is can we reach REC with just plugins?

moneill2: We need to have a UA

schunter: We are likely to chnage the spec, but MS is not likely to implement the new things.

<aleecia> +1

<aleecia> +q

<aleecia> (sigh)

schunter: So if we want a UA, we need a browser to join, or we need to spec what MS already does.
… Other option is to rely on the plugins.

moneill2: What's happening in Firefox?

shane: FF is meeting internally to see if they should join.

<aleecia> what does yahoo implement for DNT (for FF) — pointer to a doc on that would be great

shane: It's the largest impl, but it's a simple one.

aleecia: Q for W3C staff:

<walter> +1

aleecia: Prefer to go with UAs. Seems they hold off becase we still change spec.

schunter: You mean UA with a plugin?

aleecia: Yes

schunter: I think best option is UAs, 2nd is FF with plugins.

aleecia: I'm supportive of that.

<wileys> Catch-22

aleecia: If MS wants to implement only after the spec is done, we can't blame them.

Action: Bert: work with schunter on requirements for CR exit: UAs, plugins, Edge...?

<trackbot> Created ACTION-473 - Work with schunter on requirements for cr exit: uas, plugins, edge...? [on Bert Bos - due 2017-03-13].

Usability for hosted sites

fielding: We had been discussion whether to include http-equiv in the spec to indicate tracking status.

fielding: We discussed on the call if that was useful in respect to well-known resource.
… We are currently only sending responses udner certain cases, to make caching possible.
… If the UA is parsing the HTML for the tracking status, they need more. Hence the idea to add trk.
… My idea was add in a script attached to document object.
… But it could also be a <meta> element.

moneill2: Issue is with hosting with thousands of sites.
… So http-equiv (or <meta content>) is logictically easier at the moment.
… Not saying it is a better mechanism than well-known resource.

schunter: But the well-known resource will stay as well?

moneill2: Yes.

<walter> Bert: so we're now still using the bugzilla next to the github issue tracker?

moneill2: Include the stringified JSON
… The aim is to make it easier for sites.

schunter: But it removes the transparency.

fielding: If there is a well-known resource, it overrides everything.

<rvaneijk> hmm, I thought the problem was not being able to set the HTTP-headers.

schunter: But if I'm hosted and promise to be nice, and my hosting company doesn't...

<rvaneijk> Posting the .well-know-resource looks the easy bit to me.

<wileys> And the Publishing Platform has no legal requirement to support any DNT disclosures (outside of stating whether they support it or not in CA). Allowing sites sitting on a publishing platform should not be able to speak to DNT outside of collaboration with the publishing platform

dsinger: I don't understand how you can say you are not tracking when you don't even have control ovber the well-known resurce

<wileys> +q

schunter: It's the case when you have comntrol over content, but cannot deal with all the hosting.

<wileys> We must require collaboration between the publishing platform and the publisher

<wileys> MUST

schunter: You may be thinking you are not tracking, but your hoster is.

<fielding> I agree with the concerns and don't have any need for this feature, but given that it only exists when the publisher doesn't support DNT sitewide ... it's okay.

<aleecia> (response to dsinger;: the context was if you are publishing on a hosted platform, like a WordPress publisher. You might know what you’re doing but not have full control)

shane: In this scenario, we should be prescriptive that a platform must cooperate with a publisher.
… As a publisher you need to be informed what your platform supports.
… But example of Unilever, large org with many departments, I think they *can* work together.

schunter: Hosting provider has to have a tracking status resource that allows the content owner to fill in the blanks.

moneill2: Some propertiues in well-known loc and other properties defined in content.

<aleecia> presumably there’s a default that if publishers say nothing, we assume they’re tracking (legacy sites unchanged for a decade or something)

schunter: But that requires trust between content provider and platform.

walter: Two scenarios:
… Platform that just honers what content provider wants.
… Would need some flag the platform does no tracking at all, but content owner may.
… Other scenario is that content provider says he's not tracking more than what the platform does.
… If you dont' have that control, DNT is not a good fit for you anyway.
… But this might be for a version 2.

schunter: Platform can only leave blanks if it is not itself tracking.

<fielding> I think we should focus on what the user needs communicated rather than splitting the communication among hosting and content. After all, none of this is hard for the platform to implement support.

walter: I don;'t want to make this a blocking issue for current spec.

<wileys> Please drop it

<wileys> HTTP Equiv causes more problems than it solves

moneill2: Agree, I think it would help, but let's not block on having the feature.

<aleecia> Yikes.

schunter: Close it? or push to next spec?

<walter> aleecia: ?

moneill2: Just close it.

<wileys> Cleaner implementations

schunter: Conclusions:
… We have a timeline
… We have solved an issue.

<aleecia> noted

schunter: I propose we start weekly telcons now.