<aleecia> thanks, Shane!

<wileys> np

<wileys> I always wonder the same thing

<aleecia> while we’re waiting, do we have a scribe?

<schunter> 1 Goals / Procedures

<schunter> 2. Should we allow transmission of TK headers within http-equiv.

<schunter> 3. Implementation/Validation Strategy

<scribe> scribenick: npdoty

Goals / Procedures

schunter: sent email recommending that we try to minimize changes, based on what's necessary for implementers

<schunter> 5. Other issues from our tracker:

moneill2: agree, concentrate on getting something to Recommendation
... issue (with site exceptions) that will come up in EU compliance

<schunter> nick: could you sribe?

<schunter> (thanks a lot for being proactive! I thought so.

aleecia: repeat from email; agree with approach; can capture issues even if not all changed, agree with goal of getting this done

<aleecia> (suggested time boxing issues and getting to what we can before a deadline, holding off on non-critical issues until the end)

<wileys> +q

schunter: if we have well-documented issue from someone in the group, should consider it. otherwise can wait until implementation experience

<wileys> -q

schunter: agreement to stay on time, focus on the essential, can capture the list of issues for later
... using github, can add labels/milestones to issues
... have started marking them per milestone based on the status of the issue

npdoty: usually labels for this purpose rather than milestones

http-equiv

https://github.com/w3c/dnt/issues/10

schunter: we require participation from the server owner, so /.well-known/dnt is server-wide
... site can send Tk headers to point to different versions of a tracking status resource
... could the site owner put that in http-equiv
... pros: it could be convenient, simpler for the site owner

<wileys> Strong “NO” from a publisher who actually owns a publishing platform and is concerned that low tech skilled users will not understand the complexity of overriding the core domain’s DNT position by posting their own.

schunter: cons: there could be ambiguities, is tracking a non-content property?

fielding: the primary response is the well-known resource, so the site owner / server still has to set that up
... the Tk header could give a resource specific response

<aleecia> My concern is that a platform will report on behalf of one of their publishers, and get it wrong.

<aleecia> Since that’s what happened on P3P

fielding: could be easier to add as http-equiv, but if the site has inconsistent tracking policy, the server would have to parse/change HTML content

<aleecia> …so what can we do to resolve that concern? I am not wed to any particular approach, just to solving the problem.

fielding: tradeoffs
... for me, it seems like I can control header fields just as easily
... if we allow servers that flexibility, then the client has to handle that flexibility

<aleecia> We could put a MUST requirement on platforms, but I’m hesitent there.

fielding: don't see the advantage in clients having to read the HTML, or later address in JavaScript

<wileys> If a publishing platform allows its publishers to post 3rd party tracking tech then they will either have to a) disallow their publishers from supporting DNT or b) build a configuration option for publishers to implement their desired position on DNT. Attempting to allow publishers to state their DNT stance outside of the publishing platfrom will cause confusion and will most likely just be wrong - meaning they are lying to users.

fielding: can understand the interest, but don't see the value to us

<aleecia> it’s that last part that captures my conern!

schunter: issue for mike was hosted site where the host doesn't provide a lot of functionality

<wileys> If publishers feel this is critical they can select a publishing platform that supports DNT configuration for their posts.

<aleecia> One option is to add text calling this out in the spec, with a SHOULD on a UI as you described.

<aleecia> Well, no: if all publishers are basically lazy, there’s no choice and no incentive for any of them to change.

moneill2: for example, as a first party site with very basic publishing tool, might want to declare that consent has been received, using Tk: C

<wileys> DNT is completely optional - should not be a SHOULD. Publishers can select the platform they feel best meets their needs.

<aleecia> “The market will solve it” doesn’t work for me.

<aleecia> Then we’re at MUST.

<wileys> Aleecia - unfortunately that’s how the real world works

<aleecia> Because writing a spec where we know platforms will wind up effectively lying to users sounds like poor design, no?

moneill2: if for some reason you can't put the header there (loads of people, including companies, don't know how to do that on their sites)

<wileys> The platform would not be lying if we allow http-equiv and publishers attempt to overwrite the platforms position it is them that are lying

<fielding> I think only the publisher has the motivation to tell the truth here. Authors don't know, so they will sell sugar.

<wileys> http-equiv is a bad idea

moneill2: how are third-party advertisers going to gain consent?

<wileys> Agree with Roy!!!

<aleecia> i’m surprised you’d want platforms to take on liability for publishers on their platform. sounds very european :-)

moneill2: would prefer well-known named cookie

<wileys> Its a mix of liability based on what features your directly provide as the platform. If publishers go outside of their guardrails the liability is on them.

<aleecia> As a design approach, I’m good with platforms report what they do and their publishers report what they do, and each is responsible for what they actually know about.

moneill2: dynamic tracking status resources -- is it possible to do a preflight on embedded third party resources?

<aleecia> That’s what we’re doing with multiple parties in other contexts.

<aleecia> From the persepctive of use cases:

fielding: wouldn't check preflights because of performance or other reasons?
... preflight policies would be set in advance and be done in the fetch library
... preflight not required

<aleecia> Platform collects & uses for de-ideintified analytics, security; publisher on platform does same but does not retain for security. There should be some way to convey this to users.

moneill2: could be dynamic based on a cookie, but first-party sites aren't likely to need that dynamism

<aleecia> In particular, a publisher that collects & uses more data than the platform REALLY ought to have a way to convey that, or else the publisher claims something untrue.

<aleecia> Building a system that’s likely to report incorrect results — as Shane puts it, lying to users — is a failing on our part, especially when it’s foreseeable

moneill2: if we didn't allow http-equiv, would make it more difficult

<fielding> It is actually VASTLY easier for all sites that do not track whatsoever.

<Bert> (I didn't know w3.org returned Tk 1, but will investigate.)

<wileys> They should either a) use a platform that coordinates DNT responses with them or b) don’t support DNT or c) invest a bit of money and build their own website

schunter: there are other fields that could be in http-equiv -- but is that happening automatically?

<aleecia> I’m focused on what the platform should do.

fielding: http-equiv goes back to 1993, with the idea that servers would extract it and turn it into headers on the server-side

<aleecia> As you point out, the platform can simply not offer DNT. Or, they can do something where they’re not lying. Seems reasonable.

fielding: but implementations didn't do that, so it's just delivered to the client and defined by an HTTP spec

<aleecia> Another way the platform could handle things is to tell their publishers “here is what we do for DNT and you must match it,” which is a rather less technical way we get things to work, and that would be ok by me.

fielding: here the primary role is to provide the tracking response before we get the content back, and sending http-equiv in content doesn't match that tpwg design

<aleecia> Limiting on the publishers. But at least reality matches the DNT signal.

fielding: most sites aren't tracking, and a site-wide resource will be easier

aleecia: use case that might be relevant: don't want to replicate p3p situation where a platform reports on behalf of all of its publishers, which actually isn't accurate for all of those publishers

<wileys> If a publishing platform is falsing stating a position for its publishers that’s on them - they either need to add configuration or contracts that prohibit activities that are against their DNT response.

<wileys> +q

aleecia: whatever the platform is reporting, there has to be some way to distinguish the publishers on that platform

schunter: this use case is meant to be addressed by the status-id that distinguishes different tracking status resources

aleecia: +1. what do we put in the spec to make sure that that happens? do we just need to explain?

<fielding> To be clear, I don't mind adding a defined link relation that says its own thing, such as an override of "my privacy policies"

moneill2: e.g. P3P pasting of policyref headers?

aleecia: publisher reporting compact policies for p3p without realizing because it was platform-wide

<schunter> TODO: Double check spec for clarity

schunter: the goal is not to mitigate against malicious misrepresentation, but to help publishers/platforms not make policy statements for other people

<wileys> P3P - today this won’t be an issue as silence is not punished. If we go to the P3P / IE world of punishing silence then we could get back to the world of false representation.

schunter: can you look at TPE for possible improved text?

<aleecia> action for aleecia to review text

<trackbot> Error finding 'for'. You can review and register nicknames at <http://www.w3.org/2011/tracking-protection/track/users>.

npdoty: do we have to say anything?

<Zakim> npdoty, you wanted to ask whether we need to decide this in spec

npdoty: client parsing of it is optional already, if servers think it's easy and clients do it, then what do we care?

fielding: don't want to make it so that it could be in lots of different places, where clients end up looking inconsistently

<wileys> header / wkl should always be the default

fielding: if you want to communicate the whole status, could just include the full tsr json in the HTML

<aleecia> hi Shane, today DNT is mostly a transparency tool (without plugins / in accordance with CA AB 370.) So getting the information right is a major part of DNT. If you want to go back to a market choice framing (sigh) then you’re giving users the ability to choose different content publishers.

<wileys> Pubhlishers already have the ability to choose different platforms - this changes nothing

<aleecia> that’s not what i was saying

schunter: could a mischievous site put an innocuous version in well-known and a more specific, scary version based on http-equiv hoping that most people won't look into it but could use it as an out

wileys: Yahoo! has had platforms with lots of different publishers
... in P3P, there was a punishment for silence (cookie-blocking and security settings for lack of Compact Policy)
... was a mess for GeoCities where increasingly sophisticated publishers used that
... in DNT today, publisher is not punished for silence, for not saying anything about DNT
... good outcome will be for platforms to create configuration options for publishers, which could include DNT settings

<aleecia> (in addition to onboarding config, also need to bring exisiting content publishers through — and have a way to denote “we have no idea” for legacy sites that are basically abandoned)

wileys: make DNT status that's discoverable prior to loading content

<fielding> https://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html

currently headers are optional

<aleecia> for what it’s worth — i don’t object to platforms retaining control of options for their publishers. just against publishers that don’t get it right all the way down the stack, and users should know which party promises which things.

<dsinger> fwiw I currently think I agree with Shane. Allowing hosted sites to bypass the hosting org. seems really dangerous

<aleecia> dsinger - i don’t think we should. i’d like each party responsible only for what they do. asking a publisher to speak for their hosting platform is equally daft.

<aleecia> schunter: would be fine having 5 tracking status resources, default to the one without id

<aleecia> … if manditory that’s a change we should make.

<aleecia> … if there’s no header (id?) it’s the default

<aleecia> mike: if host can’t return a header, defaults to hoster’s?

<schunter> Check: headers should not be mandatory. If the header is absent, then the default TSR is used.

<rvaneijk> Schunter, makes sence to me, this way it is clear what tsr is the default

<schunter> If you have many TSRs with IDs, then a header would be needed to point to one specific ID.

<aleecia> mike: if we have a TSR, fine, if not generate JSON on the fly (missing parts of this)

<scribe> scribenick: npdoty

<aleecia> fielding: if you receive HTML page — not sure what the tech means would be. have an obj in the DOM that the JS would set a value that’s the tracking status response

fielding: could potentially have an object in the DOM, that includes the full content of the tracking status JSON

<wileys> I have an update on Mozilla - not sure if you want that in IRC or verbally...

moneill2: could put text together to consider

fielding: we could, but I'd still prefer to just using site-wide well-known resources

moneill2: I'm trying to make it easier for those server folks to implement

fielding: concerned that making it easier for them in that way may not be better for the user

moneill2: can provide text alternative to be discussed on the list

dsinger: if someone would like to write a short document to enabled hosted sites / publishers, that would be a useful piece of education for industry

<schunter> ls

dsinger: here's a way to configure apache so that different sections of your served site have different TSRs and status-ids

<wileys> It depends on the depth of the publishing platforms openness - this would not work on Tumblr - but may work on several GoDaddy options

fielding: planned once we have a stable spec; either a feature of the server or documentation on how to do it

<wileys> +q

schunter: next time, I'd like to figure out how to close it

wileys: talking with Mozilla about participation

<wileys> I’d leave it out if that’s okay

<wileys> That was good

<wileys> :-)

Implementation Report

schunter: want to get an update from w3c about status, different implementations, etc.
... will discuss next time

<wileys> Need the Exceptions API for us to show value to the ad ecosystem

<aleecia> beautiful

<wileys> Either works for me

<wileys> Okay - March 6th it is

schunter: next call March 6

<aleecia> better to have Nick than me

<wileys> Thank you!

[adjourned]

<fielding> and someone should update the minutes links on https://www.w3.org/2011/tracking-protection/

<Bert> trackbot, end meeting

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: npdoty
Found ScribeNick: npdoty
Inferring Scribes: npdoty
Default Present: npdoty, moneill2, Bert, aleecia, wileys, alantoner, fielding, schunter, dsinger
Present: npdoty moneill2 Bert aleecia wileys alantoner fielding schunter dsinger scribe

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 13 Feb 2017
Guessing minutes URL: http://www.w3.org/2017/02/13-dnt-minutes.html
People with action items: