schunter asks: is shane back? answer seems to be no.

<rvaneijk> Screenshots sent to the mailing list: https://lists.w3.org/Archives/Public/public-tracking/2017Apr/0035.html

schunter: discuss content & tech resolution. next step is texts and (?)
... 30 minutes, quick discussion of what changes and why
... then we discuss accept the change or not
... can go through call for objects process again
... any ?
... hearing none, gets started.

rvaneijk: can be heard :-)
... using screenshots seen dlist
... makes it easier to distringuish resources and legal grounds
... looked at two groups of actors. first, Rubicon, real time with network partners
... central Rubicon in big yellow, surrounded by nodes in the ad exchange
... in disucssion, would they rely on consent or not? come back to.
... the nodes that are still yellow in the center, resources that through referer header are pulled in and lead to analytics data for the ad exchange network
... header relations between resource and where the js is called from, originally a referer header or a location hearder if the request was redirected
... any ? on the rep of the image?

(trying to find it still!)

rvaneijk, same graph but different group of actors

Rubicon is now in grey, the other nodes in green

rvanejik, API call with UID sent to sync unique id in background, which is the rubicon ad exchange in real time

scribe: the cookie synching allows trading of uid’s.
... core of the arguement is here, around legal grounds.
... calling for specific information in the tracking status resource to distinguist different type of actors
... have the controler array to identify itself
... same party array, all resources could be listed if there’s an agreement signed or resources owned by controller itself (if you host on amazon type of resource (?)
... calling for: try to differentiate. out of band consent is important, can call for persmission for all parties as out-of-bad-consent
... but the networks are not listed on the publisher’s network and cannot rely on the out-of-band-consent of the publisher
... propose distinugishing between parties that are needed to make the real time ad exchange work, and parties that are not
... what is the extent of control of the publisher, do they have an agreement. or these resources are themselves (different)
... would help transparency
... will help parties that cannot rely on out of band consent
... proposal: enhance status resource with new, “other party” (name tbd) to enable publisher to list all resources they can identify that they want to ask for consent from user

?: can you explain in a transaction, how to distinguish between site=wide and (?)

rvaneijk: publisher identifies all the resources, all the nodes. Mike’s example of LA Times, 335 resources

<schunter> 3 tiers of parties: same-party, new website-helpers, and everyone else.

Shane: 300 listed in Yahoo’s privacy center, can have contracts with that many parties. i think you’re trying to state a site-wide exception cannot exist, disagree. how does a UA distinguish between your case and site-wide?
... not listed as same party, since they’re 3rd party. does not require all 3rd parties be enumerated.
... would be those domains under publisher’s (?)

rob: in EU need to enumerate. makes it hard to automate.

shane: not a requirement by law. this is only one technical option and could Break The Entire Standard

rob: trying to improve over cookie wall

shane: consent is the same as a cookie wall. not all publishers can identify all actors

(cannot tpe as fast at they can argue)

shane: a publisher *can* know 3rd parties and this proposal breaks that

rob: transparency not control. additional object, why would it break the model

schunter: echo

<wileys> This list can be accomplilshed MANY ways

<wileys> Does not require DNT to support this outcome

schunter: rob is saying, he believes under EU law you have to list everyone who’s collecting data. Shane, saying no, stie-wide exception is enough. Rob is saying we can implement both options.
... everybody who’s not a first party is still getting data should be listed

Shane: saying, how does the browser manage this?
... if a publisher says, i have a site-wide exception, provides in the TSR and does not fill out Rob’s field, what does the UA do? is this an optional field, and if optional, how does a browser handle populated or not? Rob is attempting to push more requirements on the browser and trying to avoid that

schunter: anything the browser should do with this or just record it?

<wileys> But that is for the browser to decide - not Rob

rob: browser discussion leads to ad blocking. one hand, browser not block anything. other hand, block everything except what’s consented. middle ground between ad blocking options is a consent-based middle ground that DNT can address
... browsers handling this info is out of scope for us. providing this info allows browsers to not break (ad networks?)

<wileys> +q

rob: in order to let programatic ads survive rather than be blocked by default, this missing property allows browsers to

schunter: same party gets DNT:1 everyone else blocked, but with additional field those guys not blocked because friends of the publisher, so get special treatment

wileys: confounding two topics. ad blocking would not occur if all parties have consent or valid processing basis, but that’s not true.
... on the issue of allowing a transaction to occur, if a publisher states site-wide exception, they understand the expanse of that permission, browser should do nothing more than register when the exception occurred. can confirm after to make sure contracts and lists in place, but all browser does is send dnt:0 for the same-party domain
... this is how we developed the standard.

schunter: let’s keep ad blocking out now.
... browser can only send dnt:0 for everything listed in same party area and the like

wileys: and all parties under, all domains under xyz.com should get a dnt:0 if registered a site-wide exception. that’s how we built it to date.

schunter: i think rob doesn’t want to change that. if not sub-sites of yahoo, like the rubicon thing, the other nodes would not get a dnt:0

wileys: but my list could be on a web page.
... should be all domains under those registered under the first party domain

schunter: but then who they are is unknown

wileys: no requirement to list, is over-loading the TSR
... could manage in our privacy centers, the well-known location could hold this. attempting to make it machine readable.
... some are www.adnetwork.com or adnetwork2.com, we’d have to list *all* of those on Rob’s proposal. if a domain is not listed, the brwoser should send dnt:1 even though a site-wide exception have been issued for the parent domain
... ask the browser, or the publisher needs to ask the end user, trying to udnerstand the full scope of interactions in Rob’s structure, breaks many of the conventions we agreed upon

rob: site-wide exception only goes as far as the parties can be identified up front, or else it’s a wild card
... for unknown puposes
... legal consent for ePriv (won’t allow that)

<fielding> I thought our goal was to move the specificaton closer to actual implementations. It sounds to me like folks want to start over with a new API and a completely different consent mechanism based on imagined implementations. I won't argue that either is a better way forward, but I will argue that we can't do the latter on this schedule.

rob: if there are restrictions on site-wide limitations, if that could lead to compliance we wouldn’t need this discussion. but most publishers cannot identify all parties up front. and yes, browser needs to decide, can be conversation with user or automatically.
... ability to express consent through browser settings is long established
... dnt can do so much better than current cookie settings of 1st or 3rd party, doesn’t help publisher either

wileys: have ability to manage individual cookies.
... you didn’t rebuke anything i’ve stated.
... pushes the browser into a legal position to arbitrate valid consent or not

schunter: not so clear, Shane you believe site-wide consent is dnt:0 goes to everything on yahoo.com?

wileys: everything underneath gets dnt:0, on purpose, today
... requirement to list all 1st party, so yimg.net would be on our first party list. if user grants, yahoo takes on the legal responsibility that we request and record that exception, any 3rd parties we have relationships. Rob presumes websites are unable to do this so he’s adding a new option, but we’d break how the TPE works today for a presumed problem (that Shane disagrees exists)
... there are many other solutions v programatically - trying to make 3rd party lists machine readable to put browsers in the

schunter: don’t see how it breaks anything when it’s informational. don’t agrree with your argument

shane: but if people populate it, then you put the browser in that position

schunter: don’t think so. let’s do call for objections,

? : annoyed by how this is being chaired

<wileys> Please speak

scribe: ignoring the queue
... shane saying outragous things about EU law

<wileys> Go ahead Walter

Walter: a few things. Shane is right about TPE so far, but that is because TPE so far is (unclear?)
... site-wide exception makes perfect sense if server believes in permission before hand

<wileys> That was why the site-wide exception was built in the first place - 1st parties themselves are not subject to DNT!

Walter: not out-of-band consent but specific permission needs specific consent (eu law)
... fields that Rob proposes are a useful fit.

<wileys> Walter - you are incorrect - 1st parties are not subject to DNT - they do not need consent on their own

Walter: two cases, DNT for active consent, or a server with opt out on dnt:1 and why the server thinks it has an opt out

<wileys> We REALLY need a web browser vendor on the call

Walter: annoyed by the idea that browsers aren’t intermediaries, user chooses the browser. they provide infrastructure but not a part of the — ?

wileys: Walter wasn’t here at the start, DNT is for 3rd parties (aleecia notes: this is not true)

?: first party was always a compliance spec things

wileys: site-wide exceptions were created to cover 1st parties 3rd parties.
... we’ve forgotten the purpose of a site-wide exception
... the responsibility of the 1st party is to have necessary mechanisms in place before they register a site-wide exception

<schunter> I have to leave 5min earlier.

wileys: once we introduce this next level of enumeration, keep your 3rd party list up to date in your TSR, even though you might have another party keeping your list of 3rd parties. yahoo lists an ad exchange lists all of their clients
... to get consent, give a link to the ad exchange, not this new overhead of managed lists that i don’t own

? … when talking about consent for technical means, something specific, by extension you as a publisher want to prove after that there’s a trail

<schunter> Walter: Consent will be required to be specific (=well-defined list of sites).

scribe: can’t see how i can square specific consent with “using this ad exchange” for all the site-wide exceptions
... this is not actual consent

shane: now we disagree on specificity, limits on use, there are other ways to gain that consent. let the court’s decide. can’t presume the outcome and force the standard

schunter: we aren’t going to reach consensus in 5 minutes. call for objections as usual.
... don’t see doing another few calls since we are not converging

shane: gone for 3 weeks, on honeymoon, could get further with conversation but missed calls. i’m the only person on this call representing industry
... only folks on the call are consuemr advocates and regulators

(apple????)

(adobe???)

<fielding> TPE is concerned with tracking, not parties; a first-party that uses tracking data is still subject to the DNT request, though they might ignore or limit the scope of DNT if the service being requested is expected by the user to involve tracking data.

shane: ok, but they’re not ad side for other industry voices (in response to my mention of other cos)
... little nervous where it’s very lopsided, lacks balance, trying to reestablish balance. mean no disrespect
... would rather more discussion, rather than call for objections
... will get other voices to participate

walter: train here, must go
... suggests more on the dlist

<fielding> I am trying to stay editor-neutral, but I do represent Adobe here. I just don't have the background to know how Adobe's various products will implement DNT.

schunter: ok, one more week

rvaneijk: we announced the call on the list, members who are dormant can participate and know
... we have process of announcement, allows everyone to speak if they want to

schunter: see Shane’s point he wasn’t here. if no consenus by one more week, will do call for objections

Roy: prepare text first, then we can discuss the texts

(+1 on that from me)

schunter: good point
... tracking status resource, sites have other parties, optional. don’t want to specify what browsers do.

<wileys> Correct

schunter: Shane’s proposal not to change the spec with additional fields

<wileys> Walter has me nervous to speak up now

<wileys> :-)

schunter: two options, Rob, please send text for your proposal

<rvaneijk> ok

schunter: no change is easy to write up :-)

<walter> wileys: Heh, I wish I had that power. But no, it wasn't about you.

Shane — CONGRATULATIONS!

<walter> oh, yes, that too!

I hope you had a great honeymoon!

<schunter> Issue 35: Summary by Aleecia

<walter> To give users the ability to see what they agree to

<walter> One is to give the delta of what changes between dnt:0 and dnt:1

<schunter> Suggest a way to find a user-readable description of what users consent to.

<walter> The other is to explain both dnt:0 and dnt:1

<walter> The idea is to have some hook in the text

<wileys> DNT:0 = Privacy Policy — DNT:1 = Statement of what stops

<wileys> I’m fine with this proposal on “what changes” under DNT:1 as a human readable (not machine) element

<fielding> My understanding of the (Adobe) legal perspective is that we can only have one set of instructions that describes what we do in each case. Showing different text to different users is NOT an option.

<walter> I'm in favour of treating DNT:0 rather differently from DNT:1

<walter> they are too different

<walter> Matthias would like to push this out to the next release

<walter> aleecia thinks it makes more sense to deal with this now

<walter> Because we don't have a baseline

<walter> People need to know what they are agreeing to

<walter> This is the fallout of not having a compliance spec

<walter> Roy feels no difference between having a compliance spec or not

<walter> Aleecia wants to prevent a billion pop-ups

<walter> Consensus on a very low burden to do this

<walter> Matthias: so what you're suggesting is a best practice?

<walter> aleecia: not even related to multiple compliance specs, it is that the user should understand what changes

<fielding> I meant that we have a Compliance array to provide a reference to how the site will comply to DNT. And we have a policy member that points to the text-for-all-cases.

<wileys> Pop-ups are going to occur no matter what now - and will likely be more of a burden for users under ePR

<walter> will do so, then

<walter> bye!

<fielding> scribe: aleecia

<fielding> trackbot, status

<fielding> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/ teh / the /
Succeeded: s/stie/site/
Default Present: Bert, fielding, schunter, dsinger, wseltzer, walter, adrianba, hadleybeeman, mkwst, wileys

WARNING: Replacing previous Present list. (Old list: Bert, fielding, schunter, dsinger, wseltzer, walter, adrianba, hadleybeeman, mkwst, swiley, moneill, rvaneijk, aleecia, wileys)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Bert, fielding, schunter, dsinger, wseltzer, walter, adrianba, hadleybeeman, mkwst, wileys

Present: Bert fielding schunter dsinger wseltzer walter adrianba hadleybeeman mkwst wileys
Regrets: David Singer
Found Scribe: aleecia

WARNING: No "Topic:" lines found.

Found Date: 24 Apr 2017
Guessing minutes URL: http://www.w3.org/2017/04/24-dnt-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report