Tracking Protection Working Group Brussels f2f

26 Jan 2012


See also: IRC log


Participants list
Aleecia (aleecia) and Matthias (schunter)
npdoty, rvaneijk, amyc, karl, bryan, bryan_


<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

small-group on file of 1st-party assertions

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].

Simplified header proposal

<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

Overview of dnt-sites file discussion

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!

What is TRacking

<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


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

Going through WG issues

aleecia: (going through some of the issues to consolidate some of them)
... no objections to consolidation?

Agreement from the group



<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


<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.



<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.


<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


<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

Community Group Comments and Responses

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

Summary of Action Items

[NEW] ACTION: amy to work with Ninja to draft a response on issue-71 [recorded in http://www.w3.org/2012/01/26-dnt-irc]
[NEW] 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]
[NEW] 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]
[NEW] ACTION: ninja working with Ninja to draft a response on issue-71 [recorded in http://www.w3.org/2012/01/26-dnt-irc]
[NEW] 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]
[NEW] 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]
[NEW] 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]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2012/02/15 09:00:02 $