See also: IRC log
<trackbot> Meeting: Tracking Protection Working Group Teleconference
<trackbot> Date: 26 January 2012
<npdoty> scribenick: npdoty
Nota bene: Because of inconsistent Internet access during this day's meeting and separation into breakout sessions, the minutes may be incomplete in some areas. If you took offline notes that should be merged into these minutes, please contact npdoty@w3.org.
schunter: thanks for coming back
... some changes to the agenda
... do some breakout sessions in smaller groups and then come back to the main group
... first with the TPE and then again with Compliance later
... going through community group comments
... discussion of timeline, planning and closing remarks
... three breakout sessions for TPE, simplified response header, response header changes and technical mechanism for sites belonging to a party
tlr: need a discussion on the javascript api?
schunter: by show of hands, not a lot of interest in the simplified response header at the moment
tlr: need a group including people who understand browser/javascript apis and those who understand communication between advertisers and publishers
jmayer: maybe the sites-belong-to-a-party is a full group discussion, rather than a breakout
could use some of the discussion time in 11:30 block to discuss the sites-belong-to-a-party as a full group
scribing: Shane for the half-hour plenary block this morning; JC to scribe compliance block; Karl to scribe compliance plenary this afternoon; Bryan for the CG responses; npdoty to scribe wrap-up
schunter's slides: http://www.w3.org/2011/tracking-protection/brussels/W3C-DNT-ProcessRefinement-v03.pdf
schunter: challenges to keeping up with the timeline
... slow progress in generating text, we need to produce more text
... sometimes text is not delivered as promised
... slow progress in actually closing issues
... yesterday we did a much better job, closed more issues yesterday than we ever had
... some issues where the group is divided and we need to find a middle ground
... need to find solutions that everyone can live with
... refine the process a bit
... Goal 1: Text-centric
... "if it's not written as text, it does not exist"
... just criticizing doesn't work, need a counter-proposal as text
... time-boxed discussions, then assign text for proposals
... Goal 2: Project management
... track issues along a timeline more rigidly
... calls for text, reviews and decisions
... if we set a deadline where we need text, if we don't get proposals then we as chairs will close issues as no one is interested
... open issues, getting text proposals, counterproposals
... if we have unanimity in the group, or if the chairs can identify solutions that fit an 80/20 solution, we can close the issue
... then W3C process continues on re-opening issues or objecting as usual
... benefits: keeping to our promised deadlines, focusing on concrete and specific proposals
... npdoty and chairs need to work on tracking issues and deadlines this way
... and want the group to agree that we can push harder on deadlines
shane: I agree with the general process, I share the urgency, but having the co-chairs decide, is that part of the W3C process?
aleecia: it is, we've seen it in HTML5 for example
... they have a survey to get opinions
... and objections and then chairs can choose the least objection
... one thing it implies is that it's useful to put text they can get a majority on rather than on the edges
... trying to persuade each other to support your text
... our alternative would be to take these things down to a vote; nobody is thrilled with that idea
... rather than get an arbitrary level from a vote
tlr: important element from the HTML5 chairs, not who screams loudest or gets the most me-too's, but weigh the rationales given and the information before the group
... here is the impact this has on this group of people and that group of people, documented in writing
... beats a pure headcount approach
jc: still calls for a suggested decision; leanings of the chairs
dsinger: just puts more pressure on us to reach consensus
aleecia: not about my or matthias' previous knowledge, but about the text that's in front of us
schunter: there's always a level of subjectivity, but try for objectivity based on what's presented in front of us
tlr: in formal objections, argue in front of the group or in front of the director; if the chairs are not being objective in their analysis, that would be a reason for the director to overturn
... "least reasoned objective"
... best process we've seen so far in groups that are massively split
... based on proposals and counter-proposals before the chairs
jimk: I can see advantages as a process, but need some pretty clear shared goals even if those goals are in tension with each other
... need those goals/objectives to be a bit clearer
karl: in html5, when the chairs make a decision, they publish a text report where they explain for each argument exactly why and what was most important
sean: this all sounds reasonable
... how does this connect to the mini-groups we're looking at today?
... everything you've described in this process sounds fair
schunter: the mini-groups are about generating the text proposals
<johnsimpson> test
sean: trying to get to text1, so that people can generate counterproposals
<johnsimpson> thanks
schunter: ideally the mini-group would generate a text that the group as a whole would agree to, but if it doesn't, it can start the generation of more counter-proposals
amyc: thanks for looking at new alternatives to move us forward
... from law school, important to get text-based definitions
... changing definitions could then change something we thought we had agreed on
aleecia: can re-open in some cases
jmayer: there will be some cases when the further discussion reveals that we didn't actually have consensus
alan: I'm concerned about silence acting as consent, particularly given how quickly we've started moving
... might be hard for me to tell you whether I have a counter-proposal when I'm uncertain about definitions
<phone ringing; thanks to vincent for handling those calls>
tlr: that might be a classic case of new information being a reason for chairs to re-open an issue
aleecia: Matthias uses the term "earthquake" for the series of changes that an issue affects including potentially several other issues
schunter: the difference is that if we talked about something a long time ago and someone didn't raise any concerns until months later, that won't fly
... very counterproductive if we build a lot on an issue and then have to re-open them later
ted: I'm happy to hear that we're going to move more quickly, because that will help me understand whether I can agree or disagree, because I currently don't know how they interact
schunter: our primary goal is to have a complete document end-to-end
... I feel we have agreement and we're now allowed to get on your nerves a bit more
amyc: how would the end user actually see this?
<scribe> scribenick: npdoty
fielding: could have the value in the file, rather than a redirect
... and what if the site lied about who it's owner was?
npdoty: +1 on presence in a file
... but what are we actually going to do with this? if it's just about signaling data sharing, then lying won't matter much
... but if we are thinking about safety messages to the user, then deception is a problem
bryan: what about maintaining a list on the master site? a list in XML/JSON, and then a redirect to the master's list on the child sites
shane: I agree that the security problem is an issue
... and even if my operational team wouldn't like this, I could support the list and you only need to do this if you want a 1st-party exception
kevin: how does that validation actually occur?
... i imagine there are sites where this list is changing hourly
... would your UA regularly fetch this well-known URI automatically?
bryan: if the user wants to know the owner, your user agent could fetch it automatically
karl: the protocol seems simple, but the management seems very difficult
<karl> karl: is the cost of implementation higher than the benefits for... who? users? companies? Adding sites to the list, removing the list and then managing the short lifetime of web sites bought by spammers
shane: the goal here is to be less arbitrary than some of the alternatives for determining how the party is sharing data
john: can we get a terse definition of the problem?
shane: began with trying to determine a first party affiliation in a programmatic way
jmayer: this doesn't solve that problem
<rvaneijk> jmayer: what we are doing is specifying a protocol for assertion for a party which it belongs to
jmayer: this would only help with understanding the assertion by a site
shane: agree that this is just about the assertion, not about the actual distinction between 1st/3rd
jmayer: I think it's mostly just useful for an enforcement hook, and in that case it's over-engineered
kevin: struggling to understand what we're going to do with that thing
<rvaneijk> kevin: struggeling to understand what we are doing with this. It is a way to convey pary relations
<rvaneijk> ... now puslishing and maintaining in real time
<scribe> scribenick: rvaneijk
kevin: question: who is going to use this
dsinger: eg user agent
... or type in url manual
kevin: why would a user do this
bryan: is also for sites that have not implemented DNT fuly
amy: we have compliance doc and track expression doc
wileys: is a TPE discussion
... removing the subjectivity for whatever the compliance rules come up with
... rather than 200 differerent urls's for a site with site specific exceptions having a master
kevin: so if you have an exception it can hit a master ulr?
<karl> http://www.w3.org/TR/2009/NOTE-powder-primer-20090901/
<karl> POWDER — the Protocol for Web Description Resources — provides a mechanism to describe and discover Web resources and helps the users to make a decision whether a given resource is of interest. There are a variety of use cases: from providing a better means to describing Web resources and creating trustmarks to aiding content discovery, child protection and Semantic Web searches.
shane: yes could be a vehicle to do it that way
<npdoty> see also http://www.w3.org/P3P/2004/03-domain-relationships.html
john: why the assetion?
dsinger: could be used to check an op-in status
wileys: is pure technical, all about site specific exceptions. It simplifies the amounth of data stored on a client's site
karl: references powder working group
bryan: on of the forms of assertions instead of a re-direct could be that
... this is what powder is
<amyc> could powder be another may reference?
kevin: when you are surfing and hit a site and want to ask for a site specific exception
... answer is 'these 40 domains'
npdoty: particialar request for a user. The user should not have to allow every site
kevin; depends on how we define parties. Not chopping up
wileys: what is the key to all the other sites the user might interact with?
<amyc> thinks answer to Nick's question is the language used in user override, rather than machine readable
ninja: risk of confusing 1st and 3rd parties
dsinger: it is about where data flows, eg in an advertising use cse
<karl> it would be cool if shane could draw what he just explained.
rvaneijk: problem in NL is domains not resolving and just using ip adresses
jmayer: new proposal: a party must through reasonable means to make known the relations somehow
robsheval: example of peoplefinder.com
... the lists of affeliations should be open. incentives for independent parties to build these lists themselves. Not just central.
shane: if user experience, every user will turn off DNT
sean: the experience on site specific exceptions method may result in pop-ups. Otherwise you will not be able to see the sports
shane: we are trying to solve the transparancy
dsinger: question: when a user grans an exception to a 3rd party A on 1st party B, they are implicitly granting an exception to all sites inthe party that B is a member off?
shane: first party specific exception, do not narrow in on sites
dsinger: we are not sure why we want the list
jmayer: are we putting out 1st/3rd party?
shane: we are not trying to solve the compliance document (1st/3rd party)
jamayer: domain pair do not need mapping, do not solve the problem entirely
resolution: we're not trying to define the breadth of a party using this mechanism
jmayer: are we trying to solve discoverability fo law enforcers, researchers, users?
... 3 thing, what are we trying to solve?
dsinger: it is not about 1st 3rd party distinctions.
... assertion of party relationships that are claimed
jmayer: browser could use some of the info within site specific exceptions but is different problem
<karl> I still do not see what the browser is supposed to actually do when having cross checked the domains.
nick: automated discoverabliilty of assertion of party relationships (goal1) and master list (goal2) proposal is to write 2 texts first
<karl> And what is happening when a site has 15 site-specific exceptions, how does it empower the user? How the user understands the meaning of these relations
dsinger: defining actions first
... dave/nick to refine/write this
... amy to write up (2)
... bryan assists
<npdoty> ACTION: singer to write up automated discoverability of party relationships proposal (Nick and Bryan to help) [recorded in http://www.w3.org/2012/01/26-dnt-irc]
<trackbot> Created ACTION-99 - Write up automated discoverability of party relationships proposal (Nick and Bryan to help) [on David Singer - due 2012-02-02].
<npdoty> ACTION: amy to write up use of machine-readable party relationships for site-specific exceptions (Joanne and Kevin to help) [recorded in http://www.w3.org/2012/01/26-dnt-irc]
<trackbot> Created ACTION-100 - Write up use of machine-readable party relationships for site-specific exceptions (Joanne and Kevin to help) [on Amy Colando - due 2012-02-02].
<amyc> scribenick: amyc
Matthias: what header format should look like
... TL proposal for input, mixed with other input
tl: came up with proposal as simple as possible, talked with Roy, Shane
... TK is name of header
... field 1
... plus two optional field
... field 1: does not track beyond what is permitted in spec OR is first party OR service provider/processor
... where last item is under outsourcing requirements spec, when operating under separate domain
nick: what about separating out why you are tracking
jonathan: asserting 1st or 3rd party?
... asserting will do no more than what 3rd party will do
tl: right
efelten: so user agent will be able to know
jonathan: 2 distinct things, one is what you are and what is what you are doing
tl: most queries don't care what your status is, just what you are doing
kevin: on service provider, following 1st party rules?
... exemption to first party rules?
tl: service provider has more use restrictions than 1st party
kevin: automated resources will treat them identiically
efelten: what if someone thinks first party, but is mistaken. helpful to know
bryan: intended for use?
matthias: site cannot always tell whether it is first party or 3rd party, as in embedded case where might not be able to detect
bryan: context dependent
matthias: anything except 1 means that you may be tracked
tl: can only tell what tracking is occurring here and now
david: being tracked in all cases
jonathan: in compliance with spec
matthias: field 2 +3 is opt-in
... site specific exceptions, meaning explicit opt-in
... browser may know or may be other schemes for override
... may retrieve more information about override opt-in in field 3
tl: not specifying what in that field yet
bryan: purpose?
matthias: well known URI to maintain information
tl: not by convention
bryan: URL is not included, concerns about data size
... how often used
tl: server can choose to what to include
bryan: significant bandwidth
nick: shorter the better
matthias: discussion as to whether header is mandatory or not, did not happen
<npdoty> we could specifically recommend that the response explanation field be as short as possible, or that it be a 1 character
<npdoty> with a SHOULD, say
matthias: disagreement on mandatory
... but format of header is required
... need to generate text then can propose close
... on format of header
bryan: exceptions need to be disclosed on regular basis now moot
ninja: disagree
... that exceptions are tracking
david: suggests that scenarios and purposes be part of text
<npdoty> bryan suggests that activities for which there is an exception are not tracking; ninja disagrees
matthias: good for preamble text to declare goals
tl: field 3 can be there without field 2
bryan: include a 0?
matthias: field 2 is optional sometimes
<npdoty> we still need to clarify the actual encoding mechanism (for optional fields, for example) but we're not doing that in this session
matthias: if want to do more, then must have field 2
kevin: does functionality match tl original proposal?
tl: every state in previous one matches
... merged some because following 3rd party definition
jonathan: what is dependency if response header required?
tl: if header not required, may prefer more states
jonathan: may be dependencies based on how that is resolved
<bryan> My understanding is that field 2 (Opt-in status) is optional, but something has to be there if field 3 is provided, since field 3 can't take the place of field 2.
matthias: lets not discuss here
<npdoty> ACTION: schunter to confirm that we have an open issue on whether the response header is mandatory [recorded in http://www.w3.org/2012/01/26-dnt-irc]
<trackbot> Created ACTION-102 - Confirm that we have an open issue on whether the response header is mandatory [on Matthias Schunter - due 2012-02-02].
ninja: simple and elegant, but does this answer do I track
<bryan> There seemed to be disagreement on the assumptions that exceptions do not need to be conveyed because they are not considered as "tracking".
ninja: what about a response that says I don't track you anyway
kevin: user asked please follow DNT rules
<npdoty> bryan, that's a question we should look at once we have a particular encoding detail
ninja: don't get a definite answer, but OK with this
kevin: would have to define tracking and not tracking
<bryan> My understanding of Field 3 is that the well-known URL is not part of the field, and the "string" is a generic value (and does not assumed to be user-specific).
tl: not trackable could be optional as super heightened level of privacy
matthias: switch to david working group
david: backed up into what problems trying to solve
<npdoty> I share what I think is Ninja's concern that the user wants to know whether they're being tracked, rather than the legal status of whether the server will comply with the Compliance spec
david: automated discoverabulity by assertion
... also use to manage user overrides
<ninjamarnau> I think if we find an agreement on ehat tracking is, we can reopen this
david: simplify request noise
jonathan: automated way of listing
david: not about 1st/3rd party distinctions
... action to educate on POWDER
nick: we agreed that this was assertion, not sufficient
jonathan: about party assertion
david: sites may maintain redirection pointer to master site that may resolve to text file of domain names
... if file does not exist, may not be able to verify assertion
... goes through use cases
... reviews action items with Nick
... did not agree to anything, even definition of problem
<npdoty> action-100?
<trackbot> ACTION-100 -- Amy Colando to write up use of machine-readable party relationships for site-specific exceptions (Joanne and Kevin to help) -- due 2012-02-02 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/100
efelten: in scores example, user opts into list of properties may change
<npdoty> action-99?
<trackbot> ACTION-99 -- David Singer to write up automated discoverability of party relationships proposal (Nick and Bryan to help) -- due 2012-02-02 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/99
efelten: should be clear to user whether override applies to list of sites or ownership
... distinction should be made clear to user so that he or she understands
karl: must make sure this is implementable
... both on server and client side
jonathan: my view
... salient issues are tools for researchers and regulators, not really for users
... OK with text that this should generally be reasonably discoverable as in prviacy policy, without need to technical format
... for 3rd party content, OK with name pair
... 3rd party should ask for permission for new domains, because 3rd party domains are stable
nick: goes through action items for Amy and for Jonathan (reasonably discoverable)
jonathan: talking about assertion to be reasonably discoverable, not the definition
bryan: what would be good example, what about mobile devices
<npdoty> ACTION: mayer to write-up "reasonably discoverable assertions" standard for party-membership for purposes of researcher/enforcement only [recorded in http://www.w3.org/2012/01/26-dnt-irc]
<trackbot> Created ACTION-105 - Write-up "reasonably discoverable assertions" standard for party-membership for purposes of researcher/enforcement only [on Jonathan Mayer - due 2012-02-02].
david: creating a redirect when you register new domain name not much work, maintaining list is more work
tl: great possible functionality to have able to read by user agents
matthias: close discussion until text
... feedback on process?
nick: problem because breakout group was large
<bryan> I believe discoverability of site relationships by user (and user-agent, if that is the way the user discovers this, but is not an essential requirement) are very important and need to be described in Jonathan's non-normative description of "reasonable access" to this information.
matthias: lunch break, back at 1330
<npdoty> thanks to amyc for scribing!
<karl> scribenick: karl
shane: (introducing the summary of what they came up with Do Not Profile + Do not Cross Site track)
1st party may collect and profile
shane: 1st party may collect and profile
... 3rd parties MUST NOT collect data across multiple, non-affiliated or branded websites
jmayer: about 3rd parties, what does that mean "collecting across"
shane: it is a general rule.
... if you collect data segregated by parties.
... You can profile into a silo
npdoty: 3rd party can't collect across sites ?
shane: Correct, they can collect only into the context of the site your are visiting.
... only siloed
kevinsmith: What happens in vegas stays in vegas
(laughter)
scribe: all data and interactions have to stay on that Web sites. Data have to be siloed.
... they can't be combined with data from other 1st parties
... There is a minimum threshold. Everyone in the room wants to avoid cross-sites tracking.
... The idea is very straightforward. I can explain it to someone else.
... the more I interact with a precise site will not impact other sites.
... It has high chances to be implemented.
... It is easy to understand from a consumer perspective.
... It removes the creepiness factor.
... It doesn't remove the deep level of creepiness.
... There are companies out there which knows things about me.
aleecia: What about shane solution?
kevinsmith: no. Because ours is more straightforward
aleecia: what about you shane?
shane: no.
john: what's in Shane's proposal that's not in yours? missed the question
kevinsmith: don't need to define a "third party", have to define the boundaries of a party but not when you become first or third
sean: You will have to monitor agencies, if they are running cross-site tracking.
... it will be difficult to implement.
aleecia: all summaries will be send to the list.
xyz: Do not create profile.
... There are people who do not want to have a profile at all.
npdoty: the two concerns. Targetting from unexpected sources and retention from unexpected sources.
... do not use data to modify the user experience.
... do not contribute data from this user experience to a profile.
... we had a few exceptions.
... but we will send details.
vincent: Do Not Remember
... or remember to forget me
... DNT=1 should be kept in the logs to taint them to remember to erase them later.
... In case with a lot of logs, we do not keep the data in the aggregated logs.
... Do not modify the client state (no cookies change)
... no personalization by third parties. No memory at the application level.
Sean: Reason in between for deidentification instead of anonymizing.
vincent: You may need http logs.
Ninja: We are the hard liners.
... we have collection limit, retention limit, correlation limit,
... every handshake contains a huge amount of information
... the party doesn't need to receive that data
... the party must not retain the data, except according to the compliance documents.
... There are issues with IP address and navigation.
... We want to keep these but separate and strictly for the purpose.
... We are not sure how to address yet the first party itself.
... It may address first parties.
Shane: How would you address digital fingerprinting?
ninja: would apply not at the time of collection of data, but rather the correlation restriction
Shane: it can happen in real time.
ninja: The fingerprint would not happen.
jmayer: passing fingerprint useragent, IP, etc. we need to put collection limits.
... but that it is different from actively collecting.
shane: how do you honor the stated exceptions at the same time than this proposal.
sean: it would take a longer conversation.
shane: I consider it to be a weakness.
karl: I think the proposal on do not remember is very similar with the one from Ninja group. We could consolidate
aleecia: (going through some of the issues to consolidate some of them)
... no objections to consolidation?
Agreement from the group
issue-16
issue-36?
<trackbot> ISSUE-36 -- Should DNT opt-outs distinguish between behavioral targeting and other personalization? -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/36
aleecia: we could close that as no
... we do not have any proposals for it.
issue-36, close
jmayer: this is an issue about personnalization.
aleecia: we can tag it as raised
<scribe> UNKNOWN: to what extent DNT signals you can not deliver content based on the user interaction
aleecia: The issue-36 is changed from OPEN to RAISED
issue-71?
<trackbot> ISSUE-71 -- Does DNT also affect past collection or use of past collection of info? -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/71
aleecia: interesting issue in terms of Europe.
efelten: it will be handled on case by case.
<scribe> ACTION: ninja working with Ninja to draft a response on issue-71 [recorded in http://www.w3.org/2012/01/26-dnt-irc]
<trackbot> Could not create new action (failed to parse response from server) - please contact sysreq with the details of what happened.
<trackbot> Could not create new action (unparseable data in server response: local variable 'd' referenced before assignment) - please contact sysreq with the details of what happened.
<scribe> ACTION: amy to work with Ninja to draft a response on issue-71 [recorded in http://www.w3.org/2012/01/26-dnt-irc]
<trackbot> Could not create new action (failed to parse response from server) - please contact sysreq with the details of what happened.
<trackbot> Could not create new action (unparseable data in server response: local variable 'd' referenced before assignment) - please contact sysreq with the details of what happened.
issue-72
issue-72?
<trackbot> ISSUE-72 -- Basic principle: independent use as an agent of a first party -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/72
aleecia: I think I should close it.
shane: we are addressing it elsewhere
issue-72, close
tl: when we were talking about the response headers, there is no room for signaling "no tracking at all".
aleecia: some people will not implement DNT, because they go a lot further than it.
... there is a use case for it.
tl: we need text on this to describe the issue.
issue-55?
<trackbot> Getting info on ISSUE-55 failed - alert sysreq of a possible bug
jmayer: it seems a sub-species of what is tracking
aleecia: I think it should be closed.
vincent: is it about targeted ads without tracking.
jmayer: it depends on how people undertsand tracking
aleecia: let's leave it as raised.
... then collect text and eventually close
issue-69?
<trackbot> Getting info on ISSUE-69 failed - alert sysreq of a possible bug
johnsimpsons: I thought we had already language about it
aleecia: we will take half an hour break.
<npdoty> apologies, we're aware of trackbot and tracker problems and the team is working on it
--- BREAK ---
<npdoty> thank you for scribing, karl!
<npdoty> issue-69?
<trackbot> ISSUE-69 -- Should the spec say anything about minimal notice? (ie. don't bury in a privacy policy) -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/69
<bryan> scribenick: bryan
matthias: thanks to community group for comments improving the quality of the proposal
<tlr> ACTION: roessler to follow up on JavaScript API and report hallway conversation with Shane [recorded in http://www.w3.org/2012/01/26-dnt-irc]
<trackbot> Created ACTION-111 - Follow up on JavaScript API and report hallway conversation with Shane [on Thomas Roessler - due 2012-02-02].
<aleecia> http://www.w3.org/community/dntrack/2012/01/14/community-group-comments-on-w3c-dnt/
<npdoty> schunter: comment on "Advertising revenue is the single largest source...."
<npdoty> ... agree that we should substantiate
<npdoty> ... and should acknowledge the privacy goals as well
matthias: concerns expressed re statements about "ad revenue as largest single source of funding...
dsinger: statements such as objected to do not belong in a technical spec
matthias: re UA shipping with DNT:0
... we have not specified a default, that is up to the UA
<karl> The issue with revenues is that it doesn't create more interoperability. So it can be dropped.
<npdoty> dsinger is suggesting potentially a separate introductory document outside the spec
<npdoty> fielding: I disagree, you're wrong, the audience (for the spec?) is not in the room
matthias: UA configuration and related DNT settings may be updated as the user customizes their device
... re entities constituting a 1st party
... (the responses being presented will be circulated to the group)
tlr: re entities, we will respond that we are thinking about this and will come back later
matthias: re issue 43, we will leave it to sites to decide the options they will provide under DNT
shanew: other options e.g. paywalls, etc will be explored in the market
matthias: issue 71, we need more info on what "it should" means, e.g. erasing old traces, stop using old data, etc
<npdoty> alan: should have a general caveat that even where we have a consensus now we may re-open issues
<npdoty> tlr: +1
<npdoty> schunter: will send out a doc with my proposed responses and get more feedback
<bryan_> jmayer: re defaults, its actually that we are not taking a position on UA defaults
<bryan_> ... (no objections)
<bryan_> matthias: is this procedure OK?
<bryan_> johnsimpson: timeline?
<bryan_> aleecia: longer than 2 weeks
<npdoty> scribenick: bryan_
johnsimpson: we may have more substantive comments at last call time, it may be better for the group to continue working on issues
tlr: input is most useful while work is going on. last call input may be turned down unless there is new information on the issue.
shanew: I heard John say that rather than respond to each, we should say thanks and we will work on these points in the context of open issue resolution
<npdoty> jimk: maybe it would be useful to split these up to particular issues in the Tracker
<npdoty> aleecia: yes, Nick can help with that
sorry for the instability of scribing
<npdoty> jeffc: I think it's helpful to get specific responses back, so that we can take that back to the international Community Group and continue to get their feedback
<npdoty> scribenick: npdoty
aleecia: finally starting to close bunches of issues
... fantastic!
... only opened one new issue (thank you, tl)
... hearing some issues with the call time (including from editors/chairs), will try to find a better time with doodle
... but will fall back on the existing time if we can't find a better time
... thinking about another face-to-face meeting since it's clear we still have a lot of work
... looking at 2-4 April, 11-13 April
... probably in DC
shane: Ad Tech may be the second week of April, and would be in SF
straw poll -- at least a few affected by Ad Tech
Ad Tech is April 3-4
potential conflict with a Brussels behavioral targeting event
aleecia: we've been invited back here at some point, which is nice
... potential events in June to connect with
<karl> http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83
"will they have Internet by then?"
aleecia: we're thinking April around DC
... how do we do our next publication?
<karl> IETF 83: March 25-30, 2012, Paris, France
aleecia: clear not at last call, but should publish another working draft
... can have multiple proposals and open text in the documents
... much easier if we can look at the document as a big picture
... get text inputs during the next two weeks
<tl> New plan: instead of posting working drafts, we just move to a git repo, and if anyone wants to see where we are, they can checkout the head.
aleecia: freeze on new input Feb 8, editors to have a full draft by Feb 15, which we can discuss quickly on a call
dsinger: no time to write/edit in the next two weeks due to other standards meetings
tlr: no new proposals for this Working Draft after Feb 8
aleecia: review as a group on the Feb 22nd call, then publish immediately after that
<tl> Also: if we use git, then everyone can propose patches easily, and the editors can just pull in changes as desired.
aleecia: thanks to the European Commission for hosting
<tl> Just saying...
aleecia: thanks to the editors <applause>
... thanks to the W3C folks
... thanks to everyone for your sustained efforts
thanks to the chairs!
yay aleecia, yay schunter