See also: IRC log
<sidstamm> hm, Zakim didn't notice me dial in... is he slow today?
<trackbot> Date: 01 February 2012
kind of light attendance so far? maybe everyone's recovering from Brussels travel?
<andyzei> i've been waking up at 5am every day :)
<scribe> scribenick: npdoty
agenda is here: http://lists.w3.org/Archives/Public/public-tracking/2012Jan/att-0429/00-part
schunter: thanks for a very productive meeting in Brussels
... closed more issues than ever before as aleecia noted
... changed from just discussing to now closing issues, getting more text
... confident that in a very short time we'll have more complete documents for wider review
<aleecia> thank you, Nick
npdoty: no minutes from Brussels yet, I'll be compiling them
if you have any notes, minutes or slides from Brussels, please send them to npdoty@w3 who will put them all together
<trackbot> ACTION-45 -- Aleecia McDonald to clean up issue-49, issue-22, create new issue on refer -- due 2012-01-18 -- OPEN
aleecia plans to have this complete before the end of the current call!
<trackbot> ACTION-56 -- Kevin Trilli to propose text on enabling auditing compliance -- due 2012-02-01 -- OPEN
<trackbot> ACTION-58 -- Amy Colando to draft text for issue-28 -- due 2012-02-01 -- OPEN
action-56 pending review
<trackbot> ACTION-65 -- Thomas Lowenthal to propose clarification on ISSUE-39 -- due 2012-02-03 -- OPEN
<trackbot> ACTION-64 -- Jonathan Mayer to propose new text for ISSUE-16 -- due 2012-02-01 -- CLOSED
<aleecia> [Nick, I sent my slides to you; let me know if there are any issues.]
justin: will send out text on two action items by the end of the day
<trackbot> ACTION-69 -- Sean Harvey to propose renaming issue-54 -- due 2012-02-01 -- OPEN
schunter: I'll send reminders out today, if no responses, I'll close actions if we can just do without
<aleecia> correction -- not my draft :-)
<aleecia> they're just doing updates
alex: we'll have this on Monday
<trackbot> ACTION-73 -- Ninja Marnau to write-up Do Not Collect Identifiable Information -- due 2012-02-01 -- OPEN
<trackbot> ACTION-74 -- Jeffrey Chester to write-up Do Not Create A Profile -- due 2012-02-01 -- OPEN
jchester2: confused about deadline, will send tomorrow
action-74 due 2/2
<trackbot> ACTION-74 Write-up Do Not Create A Profile due date now 2/2
<trackbot> ACTION-76 -- Kevin Smith to write up Do Not Cross-Site Track -- due 2012-02-01 -- OPEN
<trackbot> ACTION-77 -- David Singer to write up Do Not Cross-Site Track -- due 2012-02-01 -- OPEN
action-77 pending review
<trackbot> ACTION-78 -- Karl Dubost to write up Forget Me/ Do Not Cross Time Track -- due 2012-02-01 -- OPEN
vincent_ volunteers to follow up on action-78 today
<trackbot> ACTION-79 -- Karl Dubost to dubost to validate whether TPE lists can be use to store opt-back-in features or not -- due 2012-02-01 -- OPEN
<trackbot> ACTION-80 -- David Singer to singer and shane wiley to determine whether dave singer's paradigm on parties would be a solution for Issue 27 -- due 2012-02-01 -- OPEN
action 82 is already due Friday, not today
<trackbot> Sorry, couldn't find user - 82
<tl> unmute me
<JC> Amy will join at 9:30
<aleecia> thanks, JC!
<justin> I had thought all these action items were assigned last Wednesday with a "due in one week" instruction.
<johnsimpson> apologies for being late, unexpected bad traffic
most actions were created with a default of one week when we didn't specify (which we commonly didn't)
<fielding> or you can put the correct date in if you can remember what we actually agreed to ... I agree with Tom in that the dates were 2/3 and 2/7
tl: I think a lot of actions were created with incorrect dates, which is creating a lot of confusion now
schunter: so we should give some leeway this time? for this first time, it's okay to just fix the dates
<aleecia> (please mute yourself if you're not Roy)
confusion about action-83, npdoty to follow up with fielding
<aleecia> (I'm using the tracker fine - what are you running into?)
<tl> aleecia: 404 for everything.
<aleecia> ow. send me a specific URL, please, so I can confirm we're seeing different states of the world?
fielding: postponed tracker header name
andyzei: will need to postpone; do have a thread going on with nick and sidstamm
<tl> aleecia: Resolved now, magic!
<sidstamm> agree with andyzei
<aleecia> yay for magic.
action-91 due 2/7
<trackbot> ACTION-91 Write text on fingerprinting risk
<trackbot> ACTION-99 -- David Singer to write up automated discoverability of party relationships proposal (Nick and Bryan to help) -- due 2012-02-02 -- OPEN
npdoty: this is due tomorrow, I'll follow up with dsinger
tl: leaving out the pending-review (and closed) actions
schunter: just trying to make sure the open actions are moving forward and on time
... for pending review we can then discuss that text on a call
<aleecia> In progress!
tl: can we document with clarity on how we're managing action items on calls?
<scribe> ACTION: schunter to document practices for managing action items and share with list [recorded in http://www.w3.org/2012/02/01-dnt-irc]
<trackbot> Created ACTION-112 - Document practices for managing action items and share with list [on Matthias Schunter - due
<trackbot> ACTION-14 -- JC Cannon to write straw man proposal on response from server being optional (related to Issue-81)
issue-14?
<trackbot> ISSUE-14 -- How does what we talk about with
rvaneijk, you mean issue-14, right?
<rvaneijk> no, the one on controller processer, I will look it up.
schunter: associate text proposals by linking in email or pasting into the notes field
<johnsimpson> shane said he was going to be on an airpolane
issue-121?
<trackbot> ISSUE-121 -- Should a user agent advertise its DNT ability by, e.g., sending DNT;NULL -- pending review
tl: happy to respond with an action that the answer is No
<rvaneijk> @nick: issue-14, correct.
<scribe> ACTION: tl to write a proposal on not sending DNT:null [recorded in http://www.w3.org/2012/02/01-dnt-irc]
<trackbot> Sorry, amibiguous username (more than one match) - tl
<trackbot> Try using a different identifier, such as family name or username (eg. tleung2, tlowenth)
<fielding> tl, is your revised proposal at http://www.w3.org/mid/4F2029CB.7080905@mozilla.com
<tl> fielding: i think not
<scribe> ACTION: lowenthal to write a proposal on not sending DNT:null [recorded in http://www.w3.org/2012/02/01-dnt-irc]
<trackbot> Created ACTION-113 - Write a proposal on not sending DNT:null [on Thomas Lowenthal - due 2012-02-08].
<tl> fielding: I have not emailed it. I am planning to pastebin it.
npdoty: per email, I don't think we need this; I don't understand the use case and I think there are affirmative reasons that a user wouldn't want to
<johnsimpson> +1, Tom
<aleecia> +1
npdoty: does anyone on the call have a specific use case? (still following up with Shane)
<adrianba> +1
<andyzei> +1
tl: rather than my taking an action, can we instead wait for a use case?
<jchester2> +1
sidstamm: agree with Tom; I don't think the JavaScript currently allows for checking whether the user agent supports
<sidstamm> er, thanks for the ack npdoty
<sidstamm> aleecia ++
aleecia: there exist browsers that are not dnt compliant for a long time; unless there's a good use case this would be a bad thing to build
... seems like a waste of bytes
<aleecia> +1
npdoty: in JavaScript, could check whether requestSiteSpecificTrackingException exists before calling it, but only relevant if DNT is on
<adrianba> yes
<aleecia> new use cases -> new info
<johnsimpson> +1
<tedleung> +1
<rvaneijk> +1
<fielding> Shane's text http://www.w3.org/mid/63294A1959410048A33AEE161379C8023D0C425862@SP2-EX07VS02.ds.corp.yahoo.com
<sidstamm> npdoty, yeah, and that function may not exist in javascript unless the feature is activated by the user. :)
schunter: no one on the call supports this?
<aleecia> <non-normative>
<aleecia> As many User Agents may fall outside of the large web browser vendors, such as Apps, Toolbars, Custom Web Kits, etc., it will be helpful for publishers to receive a signal that a User Agent supports DNT even when a user has not yet provided a preference.
<aleecia> <normative>
<aleecia> User Agents SHOULD provide a null DNT signal if the user has not yet provided a preference and the User Agent supports DNT.
<aleecia> R
<aleecia> That was text from the link Roy sent
<aleecia> It's at least an interesting argument
<trackbot> ACTION-84 -- Shane Wiley to wiley to describe the reason for setting DNT=null -- due 2012-02-01 -- PENDINGREVIEW
<aleecia> Maybe there's a better way to handle that? Unclear.
<aleecia> Maybe a list of DNT-compliant user agents?
<aleecia> I wonder if there's a more light-weight way to solve the underlying problem
<npdoty_> aleecia, since you can install extensions, the list of user agents won't necessarily be sufficient
tl: can I post a not-yet-complete draft in a paste bin and then share that?
<fielding> I can't think of a need for it other than to trigger the site-specific exception for EU residents, and I don't think that is worth the extra bits on the wire.
<tl> http://pastebin.com/84WBkY1e
tl: the revised proposal has fewer states and fewer required characters, but still has the richness I think we need
... not-tracking indicates that this party complies with the Compliance spec, and satisfies 3rd-party requirements
... first-party indicates that they're a first party and compliant with first-party requirements
<aleecia> I wouldn't mind a way for user agents to assert they support DNT. That could be useful. And Shane's proposal does address that (no Null means no support). It just seems like a list of "if you see this user-agent string, DNT is possible" would be a lot less chatter / faster / better. Downside: someone maintaining the list even after we disband.
tl: service provider, follows those requirements
<npdoty_> aleecia, per above, since you can install an extension, a list of user agent strings isn't a sufficient determinant
tl: reason code, shouldn't need to be more than a letter, but can be as long as a site wants it to be
<aleecia> indeed. Ok. So that fails.
<aleecia> Bah.
tl: at the well-known location the explanation code points to the relevant area
... if the user has opted in, specify how they opted in and a link for a user to revoke the opt-in
... non-normative text on caching (of both resources and the well-known URI)
... summary: whether you're acting as a third, first or service provider, specify an opt-in, and then a reason code for the well-known URI
npdoty: does the response header let the user know whether they've been tracked at all? or just whether they've been tracked in compliance with the spec?
<aleecia> This is issue-119
tl: we have opened an issue for an optional definition of not-tracking-at-all which then might be a fourth state
issue-119?
<trackbot> ISSUE-119 -- Specify "absolutely not tracking"
tl: "for serious" not tracking
<npdoty_> :)
<jchester2> I think such a signal that no tracking is involved is a good one
schunter: first party signal also acts as a warning to the browser if it's embedded in some other page
<tl> jchester2, Agreed, we're working on it now.
schunter: the third party signal is just a sign of compliance with the relevant section of the spec
<aleecia> Ok, so we're handling this elsewhere...
schunter: third party not-tracking signal also signals that it's safe to embed in other pages
fielding: I still don't see a need for the header field, user could just check the well-known URI
... and this proposal still seems oddly complex, only need:
<aleecia> "if it's not text it doesn't exist"
fielding: yes, there's tracking; no, there's not tracking; don't see the need for distinguishing between opt-in tracking and tracking when there's some exception
<aleecia> can we get it on the list?
<adrianba> we are not convinced the response is worth the effort - if there is a response, simpler is better
tl: is there a counter-proposal? on the list?
fielding: yes, but not on the list yet
schunter: we can finish this proposal and send out to the list, and then have time to review before discussing on the next call
<aleecia> is there an open action for Roy to write a counter-proposal?
<fielding> I think so ...
<scribe> ACTION: lowenthal to send revised header proposal to the list by Friday [recorded in http://www.w3.org/2012/02/01-dnt-irc]
<trackbot> Created ACTION-114 - Send revised header proposal to the list by Friday [on Thomas Lowenthal - due 2012-02-08].
action-114 due 2/3
<trackbot> ACTION-114 Send revised header proposal to the list by Friday due date now 2/3
<scribe> ACTION: fielding to write up counter-proposal to header with well-known URI [recorded in http://www.w3.org/2012/02/01-dnt-irc]
<trackbot> Created ACTION-115 - Write up counter-proposal to header with well-known URI [on Roy Fielding - due 2012-02-08].
action-115 due 2/10
<trackbot> ACTION-115 Write up counter-proposal to header with well-known URI due date now 2/10
<trackbot> ACTION-88 -- Rigo Wenning to shane wiley roy fielding sean harvey to draft a simpler version of the spec -- due
<schunter> Tom, Could you attach the issues that are solved by your proposal to ACTION-115? already cover the simpler response header proposal?
<fielding> maybe ;-)
schunter: anything else on the revised response header proposal?
<fielding> I really don't know what Rigo had in mind
<aleecia> q- tl
adrianba: why is this a choice between a MUST and a SHOULD?
<fielding> issue-120?
<trackbot> ISSUE-120 -- Should the response header be mandatory (MUST) or recommended (SHOULD) -- pending review
adrianba: SHOULD is already something that you're supposed to do unless you have a really good reason
... and as an implementer even if it's a MUST, if I have a really good reason I won't do it
... just see a distinction between a MUST and a MAY
<schunter> Adrian: If we have headers, a MAY is too weak. Most favourite option is not having response.
adrianba: don't see a need for a response header at all, but with a MAY you can't really make any inferences, so with a MAY would be my least favorite option
... don't see the need for investing engineering resources in sending the correct response
johnsimpson: if you as a user sends out the request, it's imperative that there's some kind of response so that the user knows the status of their request; ought to be a MUST in order to be compliant
<adrianba> if you're not going to do anything with the response then what's the point of sending it - i don't think you do need a response
tl: issues around regulatory hook and others can't be achieved effectively without a mandatory response header
<aleecia> +1
tl: indistinguishable between a site that respects my preferences and one that doesn't
<jchester2> I agree. User needs mandatory response header.
<aleecia> cannot audit, etc
fielding: if the company as a whole declares that it's compliant with the standard with all of its properties and has a well-known address where it makes a public commitment to it, the user agent just needs to access the well-known address
tl: doesn't meet the user's needs to know
fielding: the user doesn't need to distinguish, for example, between a first and a third party
andyzei: if the goal is just to solve the regulatory hook problem, then a MAY obviously doesn't work
<jchester2> I agree that a user cannot readily understand how site operates, inc. well-known sites. Every site has an array of data collection practices. Users need to know, and regulators will expect they can have this control.
<fielding> note that the browser always knows who the first party domain is
<schunter> A first party collects much more data. Therefore, I believe that a user should know.
<aleecia> Browsers do not always know all the first parties
<fielding> then how did they make the initial request?
<amyc> +1 to Roy, ordinary user won't see response header
amyc: if we want a regulatory hook, we want something that the user sees and relies upon, and this isn't something that the user sees unless it's exposed in the UI which is out of scope
<tl> fielding, There is no technical way to distinguish requests to first and third parties.
<fielding> for the server, yes, but not the browser
<tl> Also for the browser.
<aleecia> (cannot build a plugin for the non-ordinary users if we don't have the data flow, and those with DNT on are not ordinary users...)
<alex> alex
<jchester2> It is a way for auditing, I believe, which will be important for the success of this spec.
schunter: a well-known URI seems to only work if the whole site complies in the same way
<tl> fielding, I cannot technically distinguish the +1 button before and after I've clicked on it.
<fielding> you clicked on it
alex: if the question is "do you comply?", and the answer is just yes or no, then it's easy
<aleecia> better example: non-meaningful interaction
<tl> fielding, You don't know whether it was a branded object.
<fielding> irrelevant, you clicked on it
<aleecia> an ad shows up with music. loud. you click it off.
alex: engineering challenge for the real-time response
<aleecia> that's not considered a meaningful interaction
<aleecia> the browser has no technical way to tell which is what
<tl> fielding, So your answer basically ignores the 1/3 party definition that we've agreed?
<schunter> Requirements I see are:
<schunter> - regulatory hook: Site promises well-behavior/compliance
<fielding> aleecia, that is orthogonal -- we have not said that isn't interaction
alex: if you're in a paranoid mode, you might want to check, but if you're not paranoid, then you don't need a real-time response
<schunter> - fine-grained info for different parts of a complex site he's not keeping up or accurately getting your points
<aleecia> the "meaningful" in "meaningful interaction" is meaningful :-)
<tl> fielding, I just clicked something, how does the browser know whether it was a first party?
<schunter> - Information whether a site is intended for
<schunter> - First party definition from compliance need to be used (not URL-based)
schunter: need to use the terms in the Compliance spec, like the definition of a first party in the Compliance spec
<fielding> tl, the first/third party distinction is manufactured for exemptions ... anything you click on is now first-party for the clicked-on request. I can't imagine any other way of specifying that post-interaction behavior
<tl> fielding, That is false.
<tl> fielding, Clicking on something does not *always* make it a first party.
schunter: our discussion has been about whether we want the header at all, rather than SHOULD vs. MUST
<fielding> tl, then how do you define interaction?
alex: if your answer is that I do not track, then does it matter whether I'm first or third party?
<tl> fielding, Please look at the first vs. third party definition, where we spent a lot of time explaining this point.
schunter: if my page doesn't do any tracking, then I can just send this signal and that's it
alex: if I make that statement, then I'm following that definition of tracking and I'm doing the opposite of it
schunter: following the Compliance spec is the same as 'not tracking'
tl: -1. I don't want to call third party compliance not tracking, because they are doing some sort of tracking
... this is why Ninja and I are working on a separate definition of "not tracking"
<johnsimpson> TL, +!
<fielding> so now we are back to the definition of
alex: I find myself agreeing with you, but
<aleecia> almost: now we're on "not tracking" :-)
alex: does "not tracking" mean that there's absolutely no chance that we're collecting any data at all, or just that there's no chance that any of the information will be about you
tl: concerned about "about you" terminology
... aggregate counts as opposed to any information that could be re-identified
alex: I think I agree with you, happy to help on discussion with Ninja
<fielding> tl, note that IP addresses will be logged ... not sure how you are going to get around that
schunter: the main point of the headers is to explain to the user to what extent you're complying
<tl> fielding, You don't have to log IP addresses. DuckDuckGo doesn't.
<aleecia> don't we have text coming on this?
<tl> I don't.
<tl> aleecia, Yes.
<aleecia> would it make sense to wait for the text proposal?
<tl> aleecia, Yes.
alex: assuming "I do not track." then I don't need to send a response back with an explanation
... if providing the reasoning is a MUST, then it's more confusing
<fielding> if IP address logging is tracking, then Apache httpd will set Tk: 0 on all responsed
<fielding> unless the user modifies the access logging
schunter: anything else?
<johnsimpson> There had been talk about different call times? Anything on that?
<rvaneijk> +1
<johnsimpson> Call method worked for me.
<aleecia> John: yes, we'll be sending out a doodle poll
schunter: metaq-uestion, are people happy with this way of running the calls?
tl: I'm a fan
<dsriedel> \quit
adjourned, meet next week to discuss Compliance
schunter: I'll send homework reminders
<johnsimpson> good bye
thanks
<aleecia> thanks!
<tl> fielding, No, Tk:{1,f,s} all allow IP logs for certain purposes.
<schunter> Tom?