Tracking Protection Working Group Teleconference -- 18 Jan 2012

<trackbot> Date: 18 January 2012

<chesterj2> Jeff Chester is on phone

<eb> elise berkower is calling from 646

<Joanne> +1.916.641 is Joanne

<npdoty> karl, can you scribe?

<npdoty> I can take the second half

<npdoty> scribes: dwainberg and tedleung

<npdoty> scribenick: dwainberg

schunter: Any comments on the minutes?

<npdoty> http://www.w3.org/2012/01/11-dnt-minutes

schunter: no comments, so cosidered approved.
... Overdue actions?

<npdoty> action-26?

<trackbot> ACTION-26 -- Karl Dubost to do a review of the Tracking Protection WG deliverables according to http://www.w3.org/TR/qaframe-spec -- due 2011-12-07 -- OPEN

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

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

<schunter> Action--42?

<npdoty> action-42?

<trackbot> ACTION-42 -- Jonathan Mayer to proposes non-normative language to obtain DNT info in Javascript; would replace DOM-API -- due 2012-01-11 -- OPEN

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

<johnsimpson> unmute me

<schunter> Ation-44?

<npdoty> action-44?

<trackbot> ACTION-44 -- Shane Wiley to also write additional examples around branding for first parties by next week -- due 2012-01-11 -- OPEN

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

<schunter> Action-44?

<trackbot> ACTION-44 -- Shane Wiley to also write additional examples around branding for first parties by next week -- due 2012-01-11 -- OPEN

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

WileyS: Action-44 was addressed in the email list.

schunter: that settles item 3 of the agenda, next is discussion of f2f meeting.
... important to register, or you won't get in.

<npdoty> and we need it today!

schunter: dinner arrangements for joint dinner on 1st day in Brussels.
... restaurant wants prior indication of menu. schunter will send a form to the mailing list to get input.

<johnsimpson> +q

<chesterj2> what building are we meeting at first day?

johnsimpson: just 1 joint dinner, and then we're on our own?

schunter: That's unsettled. Any preferences?

<npdoty> Morning meetings in Beaulieu (Avenue de Beaulieu)

<tedleung> Building BU25

schunter: Suggest day 1 is arranged dinner, and then the rest people are on their own.

<schunter> Locals wil propose some restaurants for 2nd and 3rd day.

<johnsimpson> David, only if you have cookies in your pocket

schunter: Any other questions?

<schunter> Issue-105?

<trackbot> ISSUE-105 -- Response header without request header? -- open

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

<npdoty> issue-105?

<trackbot> ISSUE-105 -- Response header without request header? -- open

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

<WileyS> Like your SHOULD respond proposal

<rigo> http://www.w3.org/2011/tracking-protection/track/issues/105

<schunter> Language for review: "If a server has received a http request that does not contain a DNT request header field, then the site MAY include a response header field into the corresponding response."

<WileyS> +q

schunter: does not say what the response should contain, only that if you like can send a response without seeing a request header.

npdoty: easy for companies that don't want to do complex configuration and respond on every time.

WileyS: Supports as well. Also could be a good way to indicate honoring opt out. Only concern is weight or spam if this is coming back in every response header.
... wants to ask Roy that question.

schunter: If a site wants to do stupid things, we should not be the ones to disallow it.

<johnsimpson> makes sense to me.

schunter: Given this language, they decide to only send on particular resources. Gives freedom to respond as they like.

WileyS: Thinks this proposal is non-controversial.

<dsinger> +q

<WileyS> +aaff WileyS

<schunter> Item 8

dsinger: We should discuss response headers and caching. Is the response a cacheable statement?

<WileyS> [WileyS] +aaff

schunter: There's also related Item 8 on the agenda.

<WileyS> Thank you Rigo - can never remember that syntax

schunter: Thinks we can record consensus on that, and close the issue.

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

schunter: Next item: User agent managed site specific exceptions.

npdoty: The idea is an option for sites that want to ask permission for a particular 3rd party to track them on that site.
... Can this particular party track me while I'm on this site.
... JS API for prompting for exceptions. And a JS property with a list of site specific exceptions, so a first party can check.

WileyS: Left open web-wide exceptions, but for site specific they chose to leave this open as a polled property.
... very simple 1st party/3rd party pairing, so the 1st party could poll for exceptions. If they add a new 3rd party, they'd have to request an new exception.
... on web-wide exceptions, we discuss it briefly that a domain could receive a web-wide exception.
... A first party could request an exception from a user anywhere it is on the web.

<chesterj2> +q

<Zakim> rigo, you wanted to support

rigo: Very good effort. But this is the kind of thing I was looking at that would help in the EU context. We shouldn't get too mixed up about the semantics.

<schunter> rigo: May need fine-tuning to align with the EU regulations. Usability important.

<WileyS> Continue to counsel the working group to not attempt to leverage DNT to cover the more extreme transpositions of the ePrivacy Directive

<rigo> http://code.w3.org/privacy-dashboard/

rigo: Encourage you to make it really easy to use. We have already done some work on the privacy dashboard.
... It will ask questions when you encounter a new domain, and you can see how annoying or not it is.

<WileyS> Agreed - we tried to limit the ability to use this as a digital fingerprint

sidstamm: I like it. Concerned about a few particulars. Querying could be used to simulate cookies (Issue 109?).

<schunter> Sid says that ISSUE-109 is important and should be investigated

sidstamm: Browser can take care of the user interface for not prompting on duplicate requests.

<npdoty> just to record, sid you specifically support the alternative to use requestSiteSpecificTrackingException rather than the list of siteSpecificTrackingExceptions

<npdoty> ?

<sidstamm> yeah

<sidstamm> npdoty, ^

<WileyS> Fair - good point, we can modify the language to make this more of a SHOULD than a MUST

<WileyS> Via Registration / TOS for example

<sidstamm> +1 to SHOULD, WileyS

<dsinger> …agrees

<dsinger> +q

<tl> +q

<WileyS> Publisher choice - let them take on the weight if they want it

<laurengelman> Yes

<rigo> look at the management of site-stuff in the privacy dashboard. It is complex but feasible. But we should take the restrictions of the mobile web into account

<johnsimpson> isn't this non-normative?

<npdoty> dwainberg: This is too definitive. I think sometimes trackers may have a particular relationship and can track a permission to track outside the context of the user agent.

<rigo> johnsimpson, it is normative

<rigo> but it has a different meaning as we have legal crossing technical meaning

<rigo> so I think people are talking passed each other

<npdoty> npdoty: Are there examples where this is important? Could create confusion if users have to remember some exceptions via the user agent and others via a site relationship.

<johnsimpson> I am looking at the section. It says "This section is non-normative"

<npdoty> I'd be very concerned about Terms of Service covering this

<sidstamm> which section number, johnsimpson

<npdoty> "The special string * signifies all document origins."

<JC> Who defines trustworthy?

<johnsimpson> 6.1 Overview

<rigo> +1 to have a first party request exception and collect consent

<rigo> that's what I need for 5.3

<WileyS> Agreed - but what if an express consent request was asked of the user prior to the implementation of DNT. In this case it seems fair to be able to honor that and not be forced to "reask" for an exception with the implementation of DNT

<JC> +1

<rigo> WileyS, they are different sources of permission and independent of each other

<npdoty> dwainberg: Sites should be able to ask for all of their third parties at once. (We'll choose third parties from time to time and you should trust us.)

chesterj2: One of the most imporant issues here, but I am concerned with how exemptions are structured. Users will be prompted through a variety of ways.

<npdoty> npdoty: can request with "*" for all 3rd-party origins from a site

<WileyS> +q

chesterj2: every web site will encourage users to opt back in, and will tell them this is to benefit them.
... This could undermine DNT.
... There's a slippery slope. And the other side of it -- enable users to have greater control over other data collection techniques.

<tl> zakim mozilla.a has tl

schunter: Would like a concrete proposal from Jeff of what things are too risky. Pinpoint a particular piece of the spec.

chesterj2: Will post something to the list prior to Brussels.

schunter: Flexible with regard to the user interface, but gives users control they need. Like it a lot.

dsinger: On other ways to opt back in. The DNT header signal is a very course instrument.
... Parties might have a more nuanced choice through, e.g. a web interface.

<rigo> Nick, Issue 67, IMHO that's a matter of evidence collection and who has to invoke it in case of dispute

dsinger: Users may wish to interact directly with advertising tracking sites, and we should make it possible to opt back in through mechanisms other than the header.

<npdoty> that's how I would personally want us to implement that situation (+1 to schunter)

tl: Makes it easy for users to find their exceptions. But also likes the idea of going to a preferences pane.
... What I'm really afraid of is going to visit a site, and they say you have to agree to the TOS, and para 12 says by agreeing you allow us to override DNT.

<schunter> Tom supports the idea that nuanced tracking preferences should only play once the ¨big¨ DNT switch for the site has been flipped.

tl: Would love to hear ideas about how to navigate that.

WileyS: I agree on the concerns, but wants to highlight an example.
... Yahoo had a property call mybloglog where they recognized users off of Yahoo.
... In that case, wouldn't want to have to re-ask consent. Wants the express consent from the user to stick.

<vincent> tl, I think UA managed specific excetpion actually prevent that while websit managed exception do not

<schunter> This is a new issue: How can one ´import´ prior consent into the new Scheme?

<chesterj2> Yahoo also has smart ads that uses data to personalize ad targeting "on the fly." Users have no idea how this works. Such techniques, inc rich media, will be used to urge people to opt-back in. Creating a system where the DNT standard is undermined.

<vincent> you can still check when DNT is enabled

schunter: I think this is a new issue. Given that you've collected consent via a different scheme, how do you get it into the UA.

<npdoty> that (MyBlogLog) seems like an example of wanting Web-wide exceptions, right?

<WileyS> Yes - good point Nick

<rigo> MS: how to get old consent into the new scheme?

WileyS: Yes, it's a way of casting historical consent mechanism into DNT, but also an example for allowing for something other than the UA mechanism.

<Zakim> npdoty, you wanted to mention ISSUE-67

<npdoty> issue-67?

<trackbot> ISSUE-67 -- Should opt-back-in be stored on the client side? -- raised

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

<ksmith> A similar problem occurs when a user uses multiple browsers or computers. It would be nice to have a mechanism that did not require me to approve or reject it in each UA

<JC> +1

<tl> vincent, i'm not sure i follow you?

<JC> Also multiple-user computers a problem

<chesterj2> "Should" would allow all kinds of targeting techniques to be used, inc. "immersive" rich media and even neuromarketing (which Yahoo, Microsoft and other use). This is a serious concern about the integrity of DNT

<vincent> ksmisth, it could be handled by browser sync mechanisms

npdoty: Different issues (Issue-67). There have been some objections. We may need to accomodate older browsers.
... And their might be some implementations costs. Reasons we might not want opt-in on the client side.

<sidstamm> vincent, +1

<tl> +q

<vincent> tl, I think that with UA managed exception you can implement a DNT "enforcer" that would monitor which entities receive DNT=2 (or 0)

<WileyS> Good example - in that case is the publisher able to somehow trigger the user's exception on the new browser?

tl: I think that's less of an issue than you think.

<WileyS> Only Mozilla allows that, correct?

<npdoty> when I switch devices I might want to have very different preferences

<JC> I don't agree

<JC> Sync is a problem

<npdoty> maybe I'm okay with tracking on my home computer but not while I'm at work

<npdoty> maybe I'm okay with tracking while at my desktop, but feel less comfortable about tracking of browsing on my mobile device

<fwagner> hi there, sorry for being late....

<vincent> tl, whereas if it's managed by the website you may not know when you are actually tracked

<Zakim> rigo, you wanted to say that one source doesn't exclude the other, but that a browser may have restrictions and we have to get around those

<tl> vincent, well, you'll get a response header

<schunter> I think that if a site has different means to store opt-back-in, we must obligate these sites to provide transparency in a standardised way.

<tl> WileyS, I don't think it'll be long before you log into Chrome with your Google account either.

<vincent> JC, problem is the same with opt-out cookies

rigo: we have to get out of the assumption that is underlying this discussion: if we have no DNT permission, we can't.
... Permission can come from many sources, and DNT is just one tool you use.

<npdoty> many people use different browsers, or incognito modes in their browsers, in order to browse at some times with different privacy settings

<JC> agreed

<vincent> tl, when you get the response header it might be too late :)

<tl> WileyS, But yes, we're leading the field on browser sync and identity.

rigo: Lawyers know there can be conflict of statements. If we prompt the users too many times we tire them.

<tl> -q

<tl> vincent, This is a problem with the web in general...

rigo: The service that does actual tracking leads to being challenged. They have to prove they had permission. So depends on in whose favor a certain statement is and where should it be stored.

<tedleung> taking over as scribe

<npdoty> scribenick: tedleung

<dwainberg> Thanks, Ted.

<rigo> => feedback mechanism

schunter: transparency to the user is important, user should be able to know how an opt back in happened

<rigo> should contain a way to convey that permission was acquired via another mechanism

<dsinger> yes, if ANY tracking happens, the user MUST know, in real time (thru the response header, ideally)

do we need some information in the response header to indicate that an opt back in from another source has happened?

<dsinger> "I see your DNT:1 but I claim to have permission to track you, and I am tracking you"

<schunter> Proposed text: Opt-back-in should be in the response header. In particular if the opt-back-in has been managed/stored outside the user agent.

<schunter> Draft decisions:

npdoty: realtime feedback doesn't help if you want to clear all your preferences everywhere in a single place

<schunter> 1. Opt-back-in SHOULD be managed by the user agent.

<ksmith> With the onset of cloud computing, device is getting less important and configuration is expected to go with the user wherever they are. This is the largest weakness with having the UA manage exceptions. I think its ok to have the UA manage things for DNT version 1 (since cookies have already created this same paradigm), but I expect the lifetime of this approach to be limited.

schunter: believes there is agreement and will document in IRC.

<schunter> 2. If opt-back-in is managed elsewhere, then the site MUST [inform] the user via an appropriate response header.

<tl> ksmith, Disagree. The cloud also synchronizes settings between UAs, just look at Firefox Sync.

<dsinger> I don't think (2) needs the leading "if" clause

<npdoty> ksmith, as above, I think we see examples where users now are intentionally using different UAs or different UA configurations to provide different privacy situations

<ksmith> npdoty - agreed - both options should be abailabler

<johnsimpson> sorry, have to leave.

<schunter> Tom: The response header may need to distinguish between opt-back-in from the browser and opt-back-in from other sources.

tl: thinks schunter's proposed text is insufficient,

<rigo> this is really looking very good for the 5.3 issue

schunter wants to defer details to response header discussion

<rigo> IMHO

<dsinger> 2 should be "2. If tracking occurs, through an opt-back-in, permission, or any other mechanism, then the site MUST [inform] the user via an appropriate response header."

dsinger: if the site does any tracking, the site must tell the user via the response header

tl: did you say the response header should have different values from an opt back in via the site vs via the browser?

<dsinger> …ok to defer to the response header discussion...

<tl> rigo, Mozilla really isn't tl...

<schunter> Site should tell user

<schunter> a) whether he is tracked or not

<rigo> tl, sorry

<schunter> b) Whether some opt-back-in was in place

<schunter> c) The source of the opt-back-in (browser, site, somethinge)

<WileyS> correction - a) whether he is "cross-site tracked" or not

dwainberg: language should indicate whether the site should be permitted to track

<schunter> correction: a´) whether the site may cross-site track him or not

<WileyS> +1 for SHOULD

<tl> +q

moving on to SHOULD or MUST for acknowledging DNT:1?

<WileyS> We should not be trying to create a 5.3 tool - that is not the purpose of DNT

<WileyS> +q

schunter favors SHOULD language

tl favors MUST b/c there a user has no recourse because the user agent got no information

<WileyS> They shouldn't - and that should factor into their decision to visit the site

schunter assumes that no answer means that the user should assume the worst, that is, tracking

tl: if the user doesn't see the header, then site should\ not be able to claim it implements DNT

<schunter> Tom: Part of DNT should be to acknowledge DNT; a site that claims compliance without sending acknowledgements is dangerous from a privacy perspective.

sorry tl

<tl> tedleung, Important semantic change there. =p

for sure.

<WileyS> Not true - a bit of an overstatement Icovers "deceptive" claims but not "unfair")

<JC> So are privacy statements useless?

<rigo> Yes! :)

<Zakim> rigo, you wanted to state that this may kill the 5.3 tool that we just created

rigo: it's tricky to use this as a consent mechanism, the SHOULD might mislead implementors

<chesterj2> Yes, privacy statements are useless.

WileyS: you need to deal with both deceptive and unfair

<dwainberg> rigo and chesterj2, privacy statements are legally binding.

<chesterj2> Users don't read or understand. They are largely deceptive and unfair, but both FTC and EU are just catching up on digital marketing and privacy

there are lots of reasons why a site might not respond, and for availability reasons, SHOULD allows that availability leeway

<rigo> dwainberg, both statements are not excluding each other

but also agrees with tl, that we should say that in order to claim to implemented W3C DNT, you must make every effort to provide a reponse header

perhaps a browser should signal the user that no reponse header was returned

<tl> +q

<schunter> Shane: User should interpret ¨no response¨ as a site not following a DNT;1 desire.

reponse headers should be absent only a very small percentage of the time

<WileyS> What if they've not implemented any response headers yet but are listening for the request header and honoring it?

<WileyS> Are they not compliant?

tl: could people send back a "DNT:beta" header to indicate that site is making some progress on DNT, but isn't there yet.

<tl> WileyS, No.

tl: believes that a site must return the response header in order to be compliant

<tl> WileyS, You're not compliant with the spec until your send a response header.

<schunter> mschunter believes that a site must stop the tracking in order to be compliant.

<dsinger> …thinks we need a fairly nuanced set of response header values (including "if you asked, I am trying")

npdoty: sites already have the option of not following DNT, so we can use MUST because sites can ignore

<tl> WileyS, Not to say that everyone non-compliant is evil, but you must respond to be compliant.

<WileyS> Disagree - SHOULD is the appropriate end point here. Would be nice to hear from others in industry on this topic.

<vincent> tl, I'm afraid we will have the "perpetual beta" problem then

rigo: do we have a legitimate case where someone who is fully DNT compliant may not want to send a response header. I can't think of one

<schunter> Rigo: Are there legitimate cases where a fully compliant site (following DNT;1) does not return a response header?

<rigo> hearing non, :)

<npdoty> Shane, you disagreed, do you think there are fully-compliant sites that still wouldn't send the response header?

<JC> +q

<WileyS> I believe compliant sites may not send a response header (they receiving the signal and processing it appropriately - and stating this somewhere other than a response header

<rigo> reason I heard was caching, AFAIK

<tl> WileyS, I do not think that those sites should be compliant.

<WileyS> We're over forcing a technical end-point here when there are many other possible communication channels with users. I agree MOST of the time this should occur but not EVERY time. Unfortunately we don't appear to have language to support that type of stance on a position.

JC: if we do MUST, then browsers will be bugging users all the time, and then users will turn off DNT

<WileyS> That's fine - becomes a natural forcing function

<schunter> Draft proposal: A site that receives DNT;1 SHOULD stop tracking (as specd by us) and acknowledge this with a header. If it does not send an acknowledgement, then the user can assume that his DNT;1 preference has not been honored.

dsinger: we're talking about 3rd party

JC: grateful for the 3rd party clarification
... favors some kind of beta period

<npdoty> WileyS, just to be clear then, you're talking about a case not just halfway-implemented but a final implementation where a site chooses a different communication channel than the response header to let the user know?

<dwainberg> Somebody's typing is really loud -- please mute.

<WileyS> npdoty, yes

<WileyS> Again - if browser highlight the failure of a response header this will force alignment

dsinger: if i don't get a response, maybe the browser just blacklists the site

<dsriedel> Example: how is this for companies offering web hosting? What does the webserver respond to the visitor?

<vincent> WileyS, isn it a good thing?

<npdoty> WileyS, good for us to clarify, I had thought you were talking about a different (the other) situation

tl: as a browser manufacturer, I think that we can make this not suck

<WileyS> +1 for SHOULD

JC: but you can't assume everyone will use just your browser

<schunter> Draft proposal (rev 2): A site that receives DNT;1 MUST stop tracking (as specd by us) and acknowledge this with a header. If it does not send an acknowledgement, then the user can assume that his DNT;1 preference has not been honored.

<ksmith> as a browser consumer - I am more skeptical

<WileyS> -1 for MUST (no consensus on this position)

<dsinger> do you mean "A site that receives DNT;1 MUST stop tracking (as specd by us) and SHOULD acknowledge this with a header. If it does not send an acknowledgement, then the user can assume that his DNT;1 preference has not been honored." ?

npdoty: if your not compliant with DNT, that's fine. only sites that want to comply need to do this

rigo: MSFT has a good track record, look at their implementation of P3P. Within 6mos, 70% of the internet was compliant

rigo would oppose rules on browser reaction to absence of the response header

<WileyS> Agreed - they should innovate around lack of response header - this will drive compliance. No need for a MUST here.

<tl> +q

<schunter> Draft proposal (Rev. V03) A site that receives DNT;1 either MUST stop tracking (as specd by us) and SHOULD acknowledge this with a header or else MAY continue tracking (opt-back-in etc) and MUST send a response header .

<schunter> If it does not send an acknowledgement, then the user can assume that his DNT;1 preference has not been honored.

rigo wants to allow browser innovation around responses

JC: i don't want to just rely on the browser

dwainberg: mabye 70% of sites had headers, but it's not clear they were accurate

schunter: enforcement is not our business

<WileyS> Agree: MUST stop cross-site tracking, SHOULD send header response.

<schunter> That was ¨rigo: enforcement is not our business¨ (not schunter)

<fwagner> +1 Rigo - enforcement is another thing

dwainberg: i'm not clear what we mean by sites. in the compliance discussion we are talking about parties

<JC> I feel the privacy policy is the best way to validate implementation and permit enforcement.

<rvaneijk> +1 rigo

<WileyS> JC, Agreed

<JC> If I'm not tracking why make me do work?

<rvaneijk> +1 shane

<rigo> Shane, I can live with a SHOULD if we explain in the Specification that not sending it may have very detrimental effects

tl: the spec details what servers need to do to be compliant

dwainberg: you're wanting to reconfigure every server on the planet

dsinger: only servers that want to act as 3rd parties

<WileyS> Rigo, that's great - and I like that approach. Provides publishers/1st parties with options but sets a real expectation that sending a response header is in their best interest.

tl: not all servers want to be compliant

<dsinger> it should be possible and trivial to add a static response header to your server config

<WileyS> +1 for SHOULD

??: a strong should is very close to a weak must

<npdoty> -1, I don't favor a SHOULD given that MUST means compliant

<JC> +1 for SHOULD

<schunter> Draft Consensus: Site that receives DNT;1 either MUST stop tracking (as specd by us) and SHOULD acknowledge this with a header; If it does not send an acknowledgement, then the user can assume that his DNT;1 preference has not been honored.

tl: the spec is incomplete without MUST

<vincent> +1 for MUST

schunter: is tom the only on in favor of MUST?

<dsinger> +1 for SHOULD, but we outline the very negative consequences (that the user assumes the worst, in the absence of other data)

<schunter> Negative consequences:

<dsinger> +q

<schunter> a) User will assume that DNT;1 was not honored

<schunter> b) Scanners cannot determine that you state that you are compliant and will assume that you are not

<rvaneijk> the respons opens the possibility to a dialog with the user

<Altaf> q

rigo: if we can live with MUST and say others are not compliant, and leave the action on non-compliance on the UA, this is the same as SHOULD, but UA's will react violently

<schunter> c) User agents may block you if you omitted the response headers

<JC> Bad dig.

<Altaf> quit

<WileyS> That was uncalled for - and that wasn't what JC said

<tl> JC =p

<vincent> I'm afraid of website starting to say "I swear I *almost* respect DNT", some users would be ok with that but the website would not have to do anything

<tl> -q

dsinger: should, but in the absence of other knowledge the user should assume tracking seems to capture it

<npdoty> schunter, do you want to write up the proposal and email to the list and then we can discuss?

<rigo> MS: opt-back-in will need headers anyway

schunter: in the case of opt back in, there will be other header information needed

<rvaneijk> please include hyperlinks

<JC> Send links to reading material

<rvaneijk> monday

aleecia said the 20th was the date

npdoty: can you assemble the notes?

<fwagner> bye cu in Brusseles

thx

<npdoty> trackbot, end meeting

- DRAFT -

Tracking Protection Working Group Teleconference

18 Jan 2012

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output