Tracking Protection Working Group Teleconference -- 05 Jun 2013

<trackbot> Date: 05 June 2013

i can scribe

<npdoty> scribenick: kulick

schunter: brad is too quick
... main goals to go over all main goals to close them or make progress on them
... end call with associated actions for all issues
... listed issues in agenda which could benefit for discussion
... next item open actions, overdue action

<schunter> http://www.w3.org/2011/tracking-protection/track/actions/overdue

schunter: next item 312... Justin

<npdoty> note we have several quite old actions that I didn't close during cleanup because I wasn't sure about the status

<npdoty> action-312?

<trackbot> ACTION-312 -- Justin Brookman to merge financial logging language -- due 2013-04-01 -- OPEN

<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/312

schunter: due April 1st

<npdoty> I think Justin might have actually done this already :)

justin: superceded by conversation

schunter: closing this action
... adrian on call?
... action 365

<rigo> trackbot, close action-312

<trackbot> Closed ACTION-312 Merge financial logging language.

<justin> Superseded or done, either way it can be closed.

schunter: over

<npdoty> action-368?

<trackbot> ACTION-368 -- Chris Pedigo to work on updated "service provider"/"processor" definition (with vinay) -- due 2013-02-27 -- OPEN

<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/368

adrian: right

<rigo> trackbot, close Action-365 overtaken by events

<trackbot> Sorry, rigo, I don't understand 'trackbot, close Action-365 overtaken by events'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

schunter: <which item?
... will send reminder to associated folks

<Chapell> Shane is only on IRC

<npdoty> skipping 368, 369, 375, 376, 377 for absent

<WileyS> Thank you Alan

<npdoty> rigo, are you on the call?

<rigo> yes

schunter: nick, can you send reminder?
... would like clean up

who is speaking?

<rachel_n_thomas> folks, the DAA Summit is taking place in DC today, so I know that a lot of folks are tied up there at the moment.

scribe: action 405

rigo: 405 is same as <>... susan is getting decision on audience measurement.
... once feedback, need to provide text and see if addresses Jeff's FAQ
... please keep open... i will set date to next week

schunter: next action about AU OBA guidelines

rigo: done
... can be closed

<npdoty> close action-383

<trackbot> Closed ACTION-383 Ask Malcom Crompton about the Australian OBA guidelines.

not OBA guidelines in AU at the moment

schunter: done with overdue action items
... nick can you send reminder

<vinay> Rigo - aren't the ADAA best practice guidelines here: http://www.youronlinechoices.com.au/wp-content/uploads/2011/03/Australian%20Best%20Practice%20Guideline%2014%20March.pdf

npdoty: yes, i sent some and i will continue to send. also for those we dont know if we can close.

schunter: would appreciate delivery dates for associated open action items
... issues in 3 cats

. 1. to be discussed, 2. unclear, 3) need decision

scribe: issue 137, whether need service provider flag

singer: I am in process of finding my previous write ups
... conclusion: can sail without the flag if we need to
... yes, we can express what we want to thru each of the cases

schunter: you want discussion with aleecia and jonathan

singer: yes, let's reopen the discussion

schunter: instead of separate call, you will discuss on the list and then call, if need be

<fielding> dsinger, was that http://www.w3.org/mid/7AC4D9F6-C8AB-417F-A244-0FF5080D898B@apple.com

schunter: next issue... <mnissed>

<npdoty> issue-200?

<trackbot> ISSUE-200 -- Transitive exceptions -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/200

issue 200

scribe: trasitive exception

rigo: is 1st party recv site wide exceptions
... <behind, sorry>
... would have transitory perms for eveyone in the auction, but w/o adding to profile

<Brooks> aacc is Brooks

rigo: shane mentioned that if i have webside exception, i want to be able to add to my profiles
... only on this edge case do we have disagreement
... the text reflects the main thing that with web wide exception allows for adding tp profiles but is not inline with our proposal
... i will work on text
... about some with web wide exception can add to profile

schunter: why cant you?
... seems reasonable to do this
... why does it not work in auction

<WileyS> If we equate a WW UGE to equate to OOBC then I don't see an issue here

rigo: b/c if you have user granted exc, if you have real estate on the page, transitory dont apply

<WileyS> WW UGE (Web-Wide User Granted Exception) - OOBC (Out of Band Consent)

rigo: only applies if you dont have direct access to the browser
... question is who is paying for the doubt, user or company
... shane wants user to pay, i want company to pay

schunter: there are multiple issues intermingled here
... 1 issue (missed)
... 2 what extent are you allow to store permissions

<Brooks> yes

schunter: other opionions?

nick: clrifiying question
... this case seems about where user doesnt interact with user directly
... server to server
... I thot <missed>

<npdoty> one relevant email: http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0004.html

rigo: you can indirect
... we want to avoid reprogramming all auction systems to be rewired to work for redirects

<schunter> issue 1: Storage of transaction data (if you get an exception that has been transferred)

rigo: we were trying to provied a kind of container

schunter: propose that we see rigo and shane's proposals

rigo: cant do before june 26

schunter: assigning to shane, then

npdoty: this is for action item 203

schunter: correct, please update accordingly

npdoty: what is the work

schunter: spell out agreements and alternatives accordingly

<dsinger> do we need to remember the 'acting as a service provider to a 3rd party with consent'?

schunter: add a comment and push deadline by a week

singer: tech poss to say i am a site acting as a 3rd party with consent

<npdoty> yes, thanks for clarifying for me

rigo: problem is you need prior aggrement
... auction works on post bid agreement

singer: okay

schunter: btw - i opened issue 200, which was closed
... in an old issue

<npdoty> re-opened action-203, with notes

schunter: should action 396 be associated with this issue

npdoty: yes

schunter: nick, can you report on the progress on this

npdoty: daivd put in text for transitive redirect case, but not server to server case
... C for consent, but need to add new qualifier key

<npdoty> http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0021.html

schunter: david will add to the text

<npdoty> use "C" for consent, and a new qualifier "t" for transferred

thx

schunter: this closes 168 ?

<fielding> why don't you just use a different TSV, like T

siger: yes will cover the 2 cases

no reason to respond with 'C'... <missed>... why not just create a new status of 't'

fielding: they may have consent, but also have trasferred consent
... you want them to be diff signals instead of adding 't' as a qualifier

npdoty: worksforme
... i'll update mailing list with that alt

schunter: anything else on the issues we wanted to discuss?
... moving on to where status is unclear

<rigo> issue-153?

<trackbot> ISSUE-153 -- What are the implications on software that changes requests but does not necessarily initiate them? -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/153

schunter: issue 153

<npdoty> I think fielding is right, that better handles distinguishing between the transferred case and the independently-having-user-granted-exception case

<npdoty> open action-396

schunter: there shouldnt be mods between UA and server
... i would close this issue
... did i overlook something?

<fielding> So, create a new TSV (perhaps "T") to indicate the the third party does not have consent directly from the user but does have transferred permission from the transitive permission.

<schunter> http://www.w3.org/2011/tracking-protection/track/issues/153

schunter: issue 153

<npdoty> action-396: provide an update, as suggested by Fielding, to use a different tracking status value

<trackbot> Notes added to ACTION-396 Provide pending review text for signal of transferred/redirected exception (issue 168).

which one?

rigo: related to open action ???

npdoty: it is in pending review as of October

<npdoty> http://lists.w3.org/Archives/Public/public-tracking/2012Oct/0634.html

npdoty: jonathan has proposed text
... but there are other alts
... <missed>

<npdoty> with David Singer, I suggested that we add a requirement that any software that modifies also follow the consent requirements as defined in Section 3

<fielding> I think this is tied up with the compliance issue?

rigo: as soon as alt nick mentioned is in the spec we can close the issue

<Chapell> agree with roy

<Chapell> there is a key dependency here

schunter: need a volunteer

rigo: add to 285? and open with new due date ?

<Chapell> assuming that the group finds consensus re: the de-identification proposal

<dsinger> I added Nick's text to the notes of the action.

chapell: no opinion on this lang so long as group has some info on de-id... however it that doesnt move forward, we need more on this

<justin> I think it's tied up with *other* compliance issues than deidentification . . .

<justin> But still tied up with other ongoing issues.

<npdoty> my proposal with dsinger was a MUST, rather than a best practice, but Jonathan proposed this alternative

<Chapell> +1 to justin

<npdoty> I agree, I don't see the particular connection to de-identification, except for deidentification being an important issue

chapell: not sure what this adds
... de-id is a recognition that there would be invalid DNT signals... we dont know if we can distinguish btw them and that would be built into the sighanl
... dwhat does it add

rigo: the scenario is related to a transparent proxy
... this is a clear req that software can circumvent
... what are valid toekns
... <missed>
... need to send a header that you are dismissing if you believe invalid

chapell: why is this a must if called as a best practice

<dsinger> …and we add to that the consent requirements must be held to

schunter: should be a must if y7ou modify
... another use case

<npdoty> my proposal from last July: http://lists.w3.org/Archives/Public/public-tracking/2012Aug/0001.html

<npdoty> "> Software outside of the user agent that causes a DNT header to be sent (or modifies existing headers) MUST NOT do so without following the requirements of this section; such software is responsible for assuring the expressed preference reflects the user's intent."

schunter: any intermediatary needs to make sure if support user choice the same as broswer <right?>

chapell: i would move to make must

<npdoty> Chapell, you can see my "MUST" proposal in IRC above, or in link above

singer: it must follow reqs for setting DNT header

schunter: can it delegate to extension
... as a whole it should happen, some could be by UA and some by extensions

<justin> Whatever we decide here, it needs to be mapped to whatever we decide on UA requirements in Compliance: http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#user-agent-compliance

schunter: end product must satisfy reqs

<npdoty> I proposed text in July 2012, pasted above

chapell to provide requirements

chapell: singer's lang better

schunter: nick, p[ls mod existing action and assign to alan?

npdoty: yes

schunter: thx

<aleecia> listen only mode

schunter: welcome aleecia

<aleecia> (Zakim dropped me multiple times this morning already)

schunter: issue 195

<npdoty> ACTION: chapell to propose new text regarding other software (perhaps building off of npdoty, dsinger) [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action01]

<trackbot> Created ACTION-414 - Propose new text regarding other software (perhaps building off of npdoty, dsinger) [on Alan Chapell - due 2013-06-12].

schunter: proposal from ronan
... handling OOB consent

<npdoty> action-414: issue-153

<trackbot> Notes added to ACTION-414 Propose new text regarding other software (perhaps building off of npdoty, dsinger).

schunter: 'p' potential consent
... accpt, reject, oither?
... not clear if people are convinced

singer: leaky hole

<aleecia> I'm 408

<rigo> agrees with dsinger that this is a leaky hole

<aleecia> Or rather, was, until joining via work phone

singer: dont think any users will do this... it seems dangerous

schunter: site needs more than 2 secs to get consent
... so w/o delaying we need another way

singer: user should be able to find from control link

schunter: I would support this lang

<hefferjr> the information does not necessarily exist at that point in time (as discussed previously)

schunter: we should not go into details of timing for retrieval

singer: yea

schunter: at control link user can retrienve this but no speak to timing

ronan: did discuss timing

<justin> Where is this language?

ronan: 24-48 hrs?

<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#TSV-P

ronan: data may not be collected in time

schunter: exact hours creates debate

<aleecia> (this sounds exactly like what a SHOULD is for)

schunter: therefore we should leave it out and explain why you need more time at the link

<dsinger> ….I fear that any 'come-back-later' is a gaping hole that the nefarious will drive trucks of bad behavior through

<justin> I had proposed two amendments: can't be used for personalization and can't subsequently reject consent as invalid. I don't think those are adequately reflected in that text.

<rigo> absolutely

singer: i dont think it is a gapping hole

<fielding> There was a question about short term data retention permission being sufficient to make this TSV no longer needed. Did we confirm that or not?

singer: bad sites will abuse this

<npdoty> justin, if you can remind us with a text proposal, that would be great

coorrect: singer: I think IS a gapping hole

npdoty: understand the concern, would be bad if 'p' was over used

<justin> I can take an action to update this. hefferjr had agreed in concept with the amendments, but not sure it was ever put into text.

npdoty: meant for exceptional cases
... we could update to say "in this exceptional case..." and see if over used and come back to this

rigo: service could send 'p' to evybody
... and then say we find out later who we have for

<npdoty> yes, rigo is right, the "P" would be used by any such service in all of its responses

<schunter> no

<schunter> I disagree.

rigo: brtowser is unable to determine if data collection is propotionate

<npdoty> ACTION: brookman to provide text proposal regarding limitations on using a Potential Consent signal [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action02]

<trackbot> Created ACTION-415 - Provide text proposal regarding limitations on using a Potential Consent signal [on Justin Brookman - due 2013-06-12].

rigo: <gist is will be abused>

<schunter> The "P" does not give any extra permissions. It just is a relaxation of the information requirement.

rigo: "p" opens too much

<npdoty> rigo: "P" signal would be sent for everyone

schunter: our understanding might be diff then
... "p" doesnt give extra perms
... it just says i cannot tell you at this point
... it doesnt allow you to do anything with the data
... you must be on safe side

<dsinger> I really fear 'P' is an invitation for sites to be lazy. If it's any amount of work to do the check that 'C' requires to work at the control link, sites will say 'P' to everyone all the time.

<npdoty> I think schunter is right that this does not create a new permitted use or new retention possibility, it's just a different signal back to the user

<dsinger> There *is* a short-term storage permitted use already.

schunter: doesnt give extra perms, but delays cheking for consent
... alt discussed is just declare '1' or '3'. as '3' you still have perms to say if I have consent to use the data
... if find out that I can consent then I can keep your data

fielding: same point as schunter
... other alt

<aleecia> DNT fails.

fielding: to the dangerous loophole concern:

no danger implied by holding danger for time to identify consent, here we are making it more explicit

scribe: danger notion doesnt match

<npdoty> I think the danger might be that signals will stop losing their meaning if "P" is always returned and the user never knows if they are being tracked with consent

schunter: if add under '3', people dont understand if stored long term

<dsinger> …agree with Roy that the short-term raw data retention is there and OK. The question is whether the use will know whether there is retention and tracking beyond that. P makes it effectively impossible for the user to know, and it's too attractive for sites to say P all the time.

ronan: echo matthias
... no permited use... it is permitted retention
... text also has should determine in real time
... 'p' prtovides more transparency
... '3' works but is less transparent to users

singer: i dont agree

<fielding> dsinger, but that is still better than receiving 3 (and actually keeping data if there is consent) or not being able to send any response because we forbid these systems from complying with DNT

<rigo> Roy, I think you assume that the browser is not reacting while I assume that the browser reacts, thus my different opinion. Under your assumption, Roy, I would agree with you...

singer: alot of sites will read this as i dont need to create ctonrol link <?>

<justin> This only applies to market research companies, not OBA companies (assuming my amendment goes through).

singer: 3 times to check for consent
... 1. as user interaction
... 2. user visits control link
... you hav minutes at this point

<npdoty> justin, but users have an interest in knowing what's going on whether the business practice is OBA or market research, yeah?

singer: 3. 24-48 hours later after data agg

<schunter> Suggested way forward: "say that the control link provides information "as soon as technically possible"" and try to add the extensions of Justin

singer: okay with 1 and 2, but feel 3 is too big a hole

schunter: control link should provide as technically possible

<fielding> justin, yes -- I am assuming this excludes personalization

<justin> npdoty, Yes, I have concerns either way. I don't love this rule, just trying to make it as palatable as possible.

singer: but you cannot find out sometimes
... need to say that control link will tell you whether you have consent or not

<npdoty> fielding, justin, as this doesn't add new permitted uses, I think it necessarily excludes using the data for personalization before consent is determined

schunter: justin mention some reaonable constraints
... i suggest moving forward with control link text w/o time

<npdoty> action-414?

<trackbot> ACTION-414 -- Alan Chapell to propose new text regarding other software (perhaps building off of npdoty, dsinger) -- due 2013-06-12 -- OPEN

<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/414

<justin> singer, I have an action to provide text, will circulate to list.

<npdoty> action-415?

<trackbot> ACTION-415 -- Justin Brookman to provide text proposal regarding limitations on using a Potential Consent signal -- due 2013-06-12 -- OPEN

<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/415

schunter: then wew ill review revised text

<npdoty> action-415: dsinger can add this new text to the spec, and allow group review

<trackbot> Notes added to ACTION-415 Provide text proposal regarding limitations on using a Potential Consent signal.

schunter: should add explict that 'p' does not provide usage of the data

<dsinger> action-415?

<trackbot> ACTION-415 -- Justin Brookman to provide text proposal regarding limitations on using a Potential Consent signal -- due 2013-06-12 -- OPEN

<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/415

ronan: find with no time
... still gives us 72 hours

<justin> npdoty, You might be right about that. Still want to make clear that you can't reject DNT:1 signal later.

ronan: how about outer bound

schunter: outer bound means you have to delete data if regardless if you know if you have consent or not

ronan: outer bound is privacy enhancing

<npdoty> is the outer bound implied as an outer bound for retention? or outer bound for returning a signal back to the user?

rigo: 1 question, 1 remark
... when have 72 hours outer bound... should say up to 72 hours
... question
... roy's remark made me rethink my pos
... do browser intend to have reaction on response

<schunter> The outer bound for retention is the maximum time you may need to determine consent. If you need longer, you may be forced to answer "I was unable to find out whether I had consent from you in a timely fashion, therefore I did not keep your data."

<missed.... sorry rigo, you are hard to scribe>

<aleecia> Rigo - there is more to life than browsers

<npdoty> I don't think there is any scenario where after an amount of time a service will have a definite answer on consent because it's always possible that for new requests the consent may have received in the meantime

npdoty: 1 concern

<WileyS> As with other items, I believe we should avoid arbitrary timeframes in normative text but could offer thoughts in non-normative

schunter: wait and look at text then move forward

<rigo> NP: if p would be predominant the browser couldn't inform the user anymore in time

<fielding> well, the sender of P still needs to obtain that consent -- I have a hard time understanding what the problem would be that browsers can't mess up the UI.

npdoty: david to work with ronan

schunter: 137
... in david's hands
... <what number>

<npdoty> ACTION: singer to review potential consent proposal (including updates from justin), may provide alternative regarding control link [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action03]

<trackbot> Created ACTION-416 - Review potential consent proposal (including updates from justin), may provide alternative regarding control link [on David Singer - due 2013-06-12].

schunter: 416

<npdoty> issue-151?

<trackbot> ISSUE-151 -- User Agent Requirement: Be able to handle an exception request -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/151

schunter: on 151...

<rigo> RW: only concerned if the browser reacts on DNT signals by e.g. sending less chatter or personal data, then p is dangerous as it mainly requires the browser to open up as a reaction. So the browser would have to block things in p as the state is unclear

schunter: not a must, but a should... some say it doesnt matter

<fielding> rigo, no more than it would have to do so for sites that don't support DNT at all.

npdoty: the must req is just having a section in the spec
... do we have alt text for proposal

<rigo> fielding: right, but then P won't by Ronan anything anyway

schunter: do we need alt text?

singer: spoke about this in camb
... would be redundant to add
... want to see must inserted to avoiud abuse

<fielding> well, that effectively means we should remove UGE from the spec.

<npdoty> might have missed that last point, dsinger -- you want to add an explicit "MUST" here

chapell: how is this significanntly diff from discussion 30 mins ago

<npdoty> ... or you want to *not* say "MUST"?

chapell: software altering/sending signal
... why is this diff?

<npdoty> action-151?

<trackbot> ACTION-151 -- JC Cannon to write up personalization-without-tracking on loggedinness (with David and Shane) -- due 2012-03-28 -- CLOSED

<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/151

<npdoty> issue-151?

<trackbot> ISSUE-151 -- User Agent Requirement: Be able to handle an exception request -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/151

<fielding> no

chapell: isnt this just an exaqmple of software changing signal

npdoty: this is related to browser,

schunter: all UA must have exception APIs

<dsinger> the other practical point is that there is no functional difference between a UA that doesn't implement and a UA that always says 'no'.

<dsinger> I am completely opposed to a MUST

schunter: convergin to a must

<adrianba> does the spec say that the api is optional?

<npdoty> the current text in the spec does not include a MUST or indication that it's optional

singer: if will be abuse, i am against must

chapell: not sure how we address that

<npdoty> singer: if sites will use this as a reason to ignore the user's signal, then I am against adding a MUST

rigo: biggest dang for DNT are people not here just imp to spawn dnt headers
... kills our ecosystem

<Chapell> WileyS may want to weigh in on this

rigo: my aim was to protect the eco system

<dsinger> Also, we heard in Cambridge that sites would make no practical difference to the users, whether DNT is set or not; under those circumstances, why would sites ask, and why would users grant, an exception?

rigo: by those investing and have exception, you cannot ignore them
... and claim compliance

<dsinger> The issue of equipment/software that randomly injects DNT signals is real, and will exist whether or not we write this into the spec. We need a serious discussion on how to handle this.

<adrianba> in the end everything is optional for implementers but unless the spec says the feature is optional you can't claim to comply with 100% of the requirements in the spec if you do not implement all the non-optional pieces

rigo: if other better way to exclude bad routers and killers of ecosystem, i can drop issue 151

singer: i dont have intermediate evildoer problem

<npdoty> rigo, I think our text responses to issue-153 are likely to prohibit the invalid spawning of signals without user consent; adding an additional emphasis that the JavaScript API must be implemented may not help us

<Chapell> I propose we table this discussion

singer: needs seriously discussion... must in text doesnt matter

<fielding> bah

<npdoty> I believe we have already rejected the idea of orphaning legacy agents by changing DNT: 1 to a different value later

singer: changing from dnt:1 to dnt:something might be good idea

scribe: suggest not tying with extra musts

<Chapell> +1 to Roy

<adrianba> writing MUST in spec doesn't change if it gets implemented

<rigo> IMHO this is why I raised the issue, so we have to ponder and noodle on it

fielding: sites have to imp OOB consent mech

<justin> Two browsers have said they don't want it, and I know other advocates (and Ed Felten) have expressed concerns about putting a MUST in here. Not sure there is consensus.

<npdoty> dsinger: adrian has indicated that he is working on implementing it; other companies are unable to comment

fielding: only reason to justify in the spec and this everyone <missed> ... if in spec should be must, if not remove from spec altogher

<npdoty> we could mark it as risk, but I agree with adrian that adding more MUSTs doesn't seem to make it *more* likely to be implemented

singer: if adding musts on UA, we need more musts on sites

<fielding> MUST implement the WKL is a huge requirement on sites

schunter: i believe sites already have quite a few musts
... how to move forward
... must or not must... that is the question

<justin> Chair's decision seems to be right approach here.

<npdoty> we can postpone this discussion, I was just asking whether we need alternatives from the current text

<dsinger> yes, I am saying that

rigo: compromise?

<schunter> "to MUST or not to MUST" ;-)

<fielding> we could make it conditional : browsers that block on the basis of TSV responses MUST implement the UGE?

<schunter> Way forward: "SHOULD" and wait for last call

rigo: if leave open in lastr call and have in cr exit criteria, then make exception api a should and how it works how bad the ambient header noise is

singer: seeing experience is good

schunter: add as should and evaluate at last call

<fielding> SHOULD is fine

<Chapell> I'm not sure we have the right folks on the call --- we should leave open for now

rigo: SHOULD now

<npdoty> we would mark it in the ISSUE, and then include text in our last call/cr announcements

<dsinger> we should insert the 'UAs should implement the exception API" and we add a NOTE saying "under consideration, for last call, to be a MUST"

<Chapell> If memory serves, WileyS had a strong opinion on this issue - and he is not on the call

<schunter> /should/SHOULD/

rigo: and issue 151, resolved or postponed with comment we have this resolution we want to test and if need be, this can become a MUST

<npdoty> Chapell, I don't think we're closing the issue right now (matthias would send around email about it), just a possible way forward

<Chapell> npdoty sounds good. thanks

schunter: we have a way forward... action in singer to add a should
... SHOULD

<hefferjr> sorry about that, this technology is beyond me

<npdoty> ACTION: singer to provide proposal regarding SHOULD and last call / CR notes regarding implementing exceptions API [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action04]

<trackbot> Created ACTION-417 - Provide proposal regarding SHOULD and last call / CR notes regarding implementing exceptions API [on David Singer - due 2013-06-12].

rigo: progress. yah

<npdoty> action-417 due 06-19

<trackbot> Set ACTION-417 Provide proposal regarding SHOULD and last call / CR notes regarding implementing exceptions API due date to 06-19.

schunter: issue 164

<npdoty> issue-164?

<trackbot> ISSUE-164 -- To what extent should the "same-party" attribute of tracking status resource be required -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/164

schunter: 3 alts
... 1. completely optional
... 2. mulitple domains should declare

3. UA may assume you are diff parties if you dont declare

scribe: 3. UA may assume you are diff parties if you dont declare
... my fav is 3

<npdoty> do we have text proposals for the alternatives?

<moneill2> +1 for C

<rigo> npdoty, see end of my email

scribe: any other points

<fielding> I said above (missed) that sites already have to implement OOB consent. The premise for having UGE in the spec is that sites will eventually be able to use it when all browsers implement UGE -- otherwise, sites have to keep using OOB consent forever. That is why the spec needs to require implementation of UGE, or remove the functionality from the spec because it is redundant.

<dsinger> yes, UAs may question why you claim '1' status when you appear unrelated to the first party

scribe: unless objection... option C (3 in scribe notes... doh!)

<rigo> schunter: accept that text and put in the spec: http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0016.html

<fielding> okay, not sure I am happy with exact wording

<schunter> we can fine-tune the wording.

<npdoty> I think rigo is proposing no new requirements, but the recommendation, with Roy clarifying wording

schunter: actio to Roy to put in spec
... 1 more item

<rigo> npdoty, yep no new requirements, just non-normtive text

schunter: issue 161

<dsinger> issue-161?

<trackbot> ISSUE-161 -- Do we need a tracking status value for partial compliance or rejecting DNT? -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/161

<npdoty> ACTION: fielding to add text to spec regarding conditions where it would be useful to indicate same-party member [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action05]

<trackbot> Created ACTION-418 - Add text to spec regarding conditions where it would be useful to indicate same-party member [on Roy Fielding - due 2013-06-12].

schunter: jonathan is okay with '!' but has concerns with 'd'
... '!' is accepted

<npdoty> action-418: can work off of http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0016.html, but Rigo certainly accepts any improvements in language

<trackbot> Notes added to ACTION-418 Add text to spec regarding conditions where it would be useful to indicate same-party member.

schunter: 'D' means i disregard your signal

<dsinger> The point is that IF they are going to disregard you, at least tell the user

singer: concern is more suttle... disregard is compliant... need add to text that compliance is indetermine in this case
... if 'D' at least tell why

rigo: from legal, '!' and 'D' is the same

<dsinger> so, I want to add to 5.2.8 "The compliance of the Disregard signal is indeterminate; it may be compliant or not compliant, depending on the reasons or circumstances."

<schunter> + explain why somewhere

<Zakim> npdoty, you wanted to ask indeterminate or non-compliant

rigo: i understand concern, but abuse would be highlighted soon

npdoty: i thot '!' doesnt mean compliance... <???missed>

<dsinger> I also want a required "why" somewhere in the WKR

schunter: might need to postpone due to time.

<npdoty> npdoty: I thought "!" indicated non-compliance and must not be used in compliance; we could do the same with "D", to say that it's never compatible with complying with a user's preference

singer: want to see why is disregarded and user can act upon that

adrian: agreed with david

<npdoty> dsinger, current text requires explanation in the privacy policy

adrian: i think signal should be 'D' disregard the signal b/c upon reason I dont think i should follow it b/c it is believe the source is not compliant or not readable

<rigo> because I'm not able to honor, so +1 to adrianba

<dsinger> …maybe I am under a court order to keep complete records of my visitors because I did something bad in the past. Under those circumstances, I have to disregard you...

schunter: action item to update text?

speaker? fielding?

<schunter> ye

<schunter> s

<schunter> "D should be used in exceptional cases and policy should explain when it is used"

fielding: should add info as to non-compliance in policy
... i dont want in spearate field

<dsinger> totally fine if the policy has to explain when 'D' may be used. As long as we require the explanation somewhere, that's fine.

<npdoty> might be hard to get agreement on "in exceptional cases" if implementers believe they will use it predominantly

<fielding> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#TSV-D

schunter: 'D' in exceptional cases, but policy says why/when not respected

<fielding> "An origin server that sends this tracking status value MUST detail within the server's corresponding privacy policy the conditions under which a tracking preference might be disregarded."

<npdoty> dsinger, adrian, if you're happy with the existing text which requires "privacy policy", then we don't need a new action

<dsinger> so, summary: (1) say it should be 'rarely' used; (2) say that the compliance is indeterminate; (3) say that the privacy policy must explain

schunter: update text and see if jonathan's concern is mitigated
... roy is taking action item

<npdoty> ACTION: fielding to update Disregard signal with conditions (rarely and indeterminate) [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action06]

<trackbot> Created ACTION-419 - Update Disregard signal with conditions (rarely and indeterminate) [on Roy Fielding - due 2013-06-12].

schunter: for 1 and 2 of singer's comment above

<npdoty> action-419: dsinger: so, summary: (1) say it should be 'rarely' used; (2) say that the compliance is indeterminate; (3) say that the privacy policy must explain

<trackbot> Notes added to ACTION-419 Update Disregard signal with conditions (rarely and indeterminate).

<dsinger> yes, Rigo, that's the point of 'rarely' used

rigo: concern is where you claim something you do not do

schunter: give rigo action for text

<npdoty> ACTION: rigo to propose non-normative text on use of Disregard signal [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action07]

<trackbot> Created ACTION-420 - Propose non-normative text on use of Disregard signal [on Rigo Wenning - due 2013-06-12].

schunter: 137 is big concern

<fielding> actually, one problem with "rarely" is what that means: MSIE 10 will be disregarded whether it is rare or not

schunter: bye

<scribe needs to leave> bye

<npdoty> thanks to kulick for scribing!

- DRAFT -

Tracking Protection Working Group Teleconference

05 Jun 2013

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output