See also: IRC log
<trackbot> Date: 30 November 2011
<tl> i think this building must be made from nothing but faraday cages
<npdoty> agenda should be in email, I don't have a working link at the moment
<npdoty> volunteers for scribe?
<npdoty> scribenick: bryan
<npdoty> http://www.w3.org/2011/11/23-dnt-minutes
<johnsimpson> having trouble getting into phone bridge. will keep dialing
RESOLUTION: minutes are approved http://www.w3.org/2011/11/23-dnt-minutes
Next meeting details presented
<npdoty> http://lists.w3.org/Archives/Public/public-tracking/2011Nov/0298.html
<johnsimpson> call bridge repeatedly won't let me complete call in..
<npdoty> meeting will be Tuesday 24 January until Thursday 26 January
<aleecia> Email re: f2f went out this morning
<npdoty> the concurrent meeting is http://www.cpdpconferences.org/
Discussion of conference
justin: large European conference on privacy
<npdoty> we could have a potential outreach session on Friday at the cpdp conference
<npdoty> http://www.w3.org/2011/tracking-protection/track/issues/pendingreview
<npdoty> ISSUE-4?
<trackbot> ISSUE-4 -- What is the default for DNT in client configuration (opt-in or opt-out)? -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/4
Matthias: to close issues asap
(matthias dropped off)
<npdoty> issue-13?
<trackbot> ISSUE-13 -- What are the requirements for DNT on apps/native software in addition to browsers? -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/13
<npdoty> issue-78?
<trackbot> ISSUE-78 -- What is the difference between absence of DNT header and DNT = 0? -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/78
Issue 4: Default for DNT
Issue 13...
matthias: text proposals already
<npdoty> bryan: would prefer to have some time to review issues before they're closed
bryan: would prefer to have a few days to review
matthias: to send an email on closure pending review
john: language is related to FPWD
npdoty: notes on the issues will clarify the background
<tl> agreed. saying which issues will be closed in an agenda at 2am the night before the call is a little late
<fielding> http://www.w3.org/2011/tracking-protection/track/issues
<fielding> http://www.w3.org/2011/tracking-protection/track/issues/open
matthias: look at left over issues and plan for the rest
<npdoty> issue-27?
<trackbot> ISSUE-27 -- How should the "opt back in" mechanism be designed? -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/27
<npdoty> issue-51?
<trackbot> ISSUE-51 -- Should 1st party have any response to DNT signal -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/51
<npdoty> issue-95?
<trackbot> ISSUE-95 -- May an institution or network provider set a tracking preference for a user? -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/95
<npdoty> issue-87?
<trackbot> ISSUE-87 -- Should there be an option for the server to respond with "I don't know what my policy is" -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/87
matthias: Issue 27, 51, 95, 87
<tl> can we end with issue 27?
shane: Issue 27 may be too meaty, put at the end
<bryan_> +1
matthias: Issue 51
..ISSUE-51: Should 1st party have any response to DNT signal
<fielding> http://www.w3.org/2011/tracking-protection/track/issues/51
tl: impression that the consensus was "yes" as per the draft sent to the list
WileyS: agree, we had come to consensus that 1st party must ack the user that the signal was received and response etc
<johnsimpson> +1 on consensus on 51
roy: disagree on consensus - see no reason for 1st party to respond
tl: actively blocking or just think it's not a good idea?
roy: expressing disapproval - would prefer some justification for this rather extensive change to HTTP, not yet deployed
tl: impression that consensus is to move forward, no sustained objections.
matthias: need text proposal with justifications, with details e.g. restrictions
<npdoty> if roy is looking for justifications, I think there are some that have been expressed, right?
<aleecia> Nick, I do believe so, yes
tl: proposal sent three weeks ago, not much discussion but no one suggested blocking it
<npdoty> fielding, did you not see any justifications? or did you not agree with the thinking?
tl: use cases have been proposed on the list, with discussion but no blocking objections
roy: repeat unless there is a substantial reason for the header, it won't be there
<WileyS> Please honor the queue :-)
tl: believe a substantial need has been demonstrated in F2F and on the list
<rvaneijk> I have read the VARY usecase Roy has put forward several times and agree that caching is something into account
matthias: propose to postpone discussion, and review emails with Roy
<tl> the current proposal takes caching into account
matthias: and whether header is needed on all responses
<WileyS> Agreed - not all responses - just those not subject to caching - that'll be more than enough
<Frank_> Small websites are unlikely to respond to a DNT header. What are the implications of that?
matthias: read Issue 51 as whether 1st party should send any response at all
<schunter> bq?
<fielding> I also don't believe it has any functional value in accomplishing the task of the protocol (telling the server what the client's expressed preference is)
WileyS: agree that it should only be responses not subject to caching
<aleecia> Actually I'm not convinced that there should be caching off the table,
<aleecia> since fingerprinting etc. are still an issue.
<npdoty> isn't another task of the protocol to enable transparency for the user?
WileyS: Roy had advised a way to meet that objective - we do want the server to respond, but not break caches
<aleecia> agree with Nick
<tl> this is actually accounted for in the proposal
tl: proposal did account for caching, including a 5-character header on cacheable objects.
... need to move forward unless there is an alternative
<npdoty> tom's proposal is here: http://lists.w3.org/Archives/Public/public-tracking/2011Nov/0067.html
roy: agree on the need for an alternative to meet the objective, but have objected to this approach several times
<johnsimpson> Tom, where is the language? In the email exchange on issue 51 on the trscker?
<aleecia> Also, issue-21 is "enable external audit of DNT" -- this is an implicit issue here too
<tl> johnsimpson, see http://lists.w3.org/Archives/Public/public-tracking/2011Nov/0067.html
ksmith: wondering what the debate is about... should 1st party return a header, and what should the header look like?
bryan: I agree we should break this into smaller problems
<tl> the current response header includes 1p responses
<tl> this issue has been discussed, and a solution proposed
<carmenb> user transparency is crucial and 1st party response is important part of that, especially w/the reality that users will have different expectations of DNT
<schunter> - Should 1st parties send responses at all (or be exempted)
<schunter> - What should a header look like?
<schunter> - Should the header be sent on all elements or just the non-cacheable subset.
bryan: benefit from addressing just whether there should be a header
<bryan_> +1
matthias: good suggestion, narrow 51 re whether 1st party is exempt from sending the header
<aleecia> One of the few things we clearly agreed to was Yes, first parties must receive a header.
<fielding> 51 is only about 1st party
matthias: (a) exemption (b) what should the header look like (c) what is effect on caches
<aleecia> If we're echoing what we get, then first parties would also send a response
matthias: impression that we have agreement on the need for a header to be sent
roy: keep in mind that 99% of the web does not use tracking and this impacts them
<Frankie> Hi there no chance to dial in, conference is full
<npdoty> non-compliant servers can continue to ignore the recommendation, right?
<tl> yes, yes they can
<aleecia> Nick: exactly my point
matthias: did not think we wanted all sites to send the header, only if DNT was received and the server is mandated to respond
<schunter> - Response headers should only be sent if you received a request with DNT
matthias: will refresh the issues and make a proposal
<schunter> - if you do not intend to comply with DNT, no need to send a DNT response header
...ISSUE-87: Should there be an option for the server to respond with "I don't know what my policy is"
<fielding> http://www.w3.org/2011/tracking-protection/track/issues/87
tl: the answer should be no, there is no option to respond in that way
WileyS: it should be a definitive response
<Frankie> Thx nick
dwainberg: should allow for "don't know" option
... there is a difference between not responding because its not subject to DNT, or subject but not compliant
... we should plan for where the server does not know the answer
<aleecia> they could not reply
<tl> tl, WileyS : no, either you give a specific response or you're not compliant
dwainberg: if they have to respond otherwise they may be wrong
<WileyS> David - please give an example where a company won't know? Wouldn't it be better to not respond at all if there is a certain perspective?
ksmith: had the same question
... difference between I don't know, blank response, no response
<aleecia> to me "I don't know" means "please start an enforcement action against my company"
<tl> aleecia, +1
<WileyS> :-)
dwainberg: if servers not subject send no response, or not compliant sends no response, there is ambiguity
<aleecia> So if that's what you all really want...
<efelten> Is there a use case where a user agent would behave differently in the two cases (no-response vs. don't-know)?
<schunter> ackn ksmith
dwainberg: giving the server a don't know option makes resolves the ambiguity
<fielding> to clarify, all servers are "subject to DNT" in the current drafts
<tl> efelten, not as far as i can see. either case means "i can't promise that i'm in compliance"
ksmith: think the end result is that dont know will be interpreted as no response, and don't see the value yet
schunter: if we don't have agreement, this may be a "not urgently required" aspect, and may be dropped
<johnsimpson> +1 no reason to have don't know.
schunter: David, could take an action to explain how a browser would treat both cases differently, and what the value is to the end user
WileyS: if the assumption is that there is no response, the party is saying I don't need to be in compliance. but it the company is responsible, it should respond. thus no response should mean DNT is not implemented
tl: any lack of response should be "not in compliance" for whatever reason
<tl> act tl
<fielding> tl, that's called a formal objection (if it were in the spec), not a block
schunter: have enough input, propose to close the issue after David's input
...ISSUE-95: May an institution or network provider set a tracking preference for a user?
<tl> fielding, formal objection is only once it's in a published spec
...ISSUE-95: is this issue a compliance or expression question?
<fielding> tl, right that's what the parens are for ;-)
WileyS: already wrote a draft and sent it
tl: comfortable with the draft
schunter: so the list will review the text and respond
...ISSUE-27: How should the "opt back in" mechanism be designed?
<fielding> http://www.w3.org/2011/tracking-protection/track/issues/27
WileyS: technically discussed several options on site-specific exception
... the opt-in / site exception list, ...
(having a hard time hearing, drop outs maybe in my connection, please drop notes in the IRC)
<dwainberg> same here
<dsriedel> confirm drop outs
<ksmith> same
<Lia> same
<johnsimpson> shane you are breaking up...
<bryan_> (hooray for mobile networks)
schunter: any other opinions in the interim...
<WileyS> I can not call in via cell - "the call is full"
ksmith: expressed concern that standards are good, but opt-in will need to be customized to the user experience
<sidstamm> WileyS, I'll drop off to make a slot for you (need to drop off in 5 min anyway)
<amyc> +1 I don't believe we should dictate technological mechanism, could have best practices?
ksmith: there will be a need to do things differently so standardization may not support all the ways that interaction may need
<WileyS> Argh - that's a horrible solution - don't want anyone to leave for me
<aleecia> yay
<ksmith> cannot hear shane still
<tedleung> even worse now.
<aleecia> Shane, can you type?
<sidstamm> WileyS, I have a standing conflict anyway, the slot is all yours
tl: any current language on this?
<ksmith> What I think Shane said is that we can have a policy definition, without a technical definition. If so, or even if not, I can think I can get behind that
schunter: no
tl: need proposals first for discussion. there were some discussions in the F2F. but unless proposals are made, we should defer this
<WileyS> I will write a proposal - extension of our original submission to the W3C
<WileyS> I'll take the assignment
schunter: will send a call for proposals, and if there are no clear ideas we will wait for later proposals
<hwest> O
<kimon> I'm not ok
schunter: if no significant proposals this may slip to a later release
<hwest> I don't like that approach
<hwest> I think it's a big problem not to have an opt back in in order to get sites to implement
<tl> hwest, can you write a proposal?
<hwest> I can write up a short and non technical proposal
kimon: websites need to know what the current status is, whether they can leverage user data or not (please correct if needed)
... can discuss with publishers on proposals
schunter: what mechanisms to use e.g. out of band, what objective is being sought, e.g. informal description is ok - it does not need to be technical
hwest: will help with that
schunter: any more on issue 27?
... next item is for Roy to make proposals
fielding: no progress yet, plan is for progress in the next two weeks
schunter: that's all for today, next call next week will be chaired by aleecia
... focusing on compliance doc