W3C

Tracking Protection Working Group Teleconference

16 May 2012

Agenda

See also: IRC log

Attendees

Present
aleecia, tl, schunter, efelten, hefferjr, BrendanIAB, chapell, dsriedel, npdoty, aclearwater, [Google], justin_, [Apple], fielding, Lia, wilson, [Mozilla], pmagee, bilcorry, Chris_PedigoOPA, dsinger, cOlsen, [Microsoft], eberkower, hwest, enewland, vincent_, ksmith, jlenhart, hefferjw, johnsimpson, +1.202.530.aahh, rvaneijk, BrendanIAB.a, ifette, hober, sidstamm, Chris_IAB, Aleecia, JC, Marc
Regrets
jchester, wileys, rvanejik, rigo, jmayer
Chair
schunter
Scribe
ifette

Contents


zakim seems a bit baglogged...

agenda bashing

Matthias: no comments

Review of overdue actions

Matthias: reviewing actions
... first is on ROY

ACTION-131?

<trackbot> ACTION-131 -- Roy Fielding to sketch use case for user agent requests on tracking status resource -- due 2012-05-12 -- OPEN

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

roy: holding pending design of tracking status resource

matthias: think it was to explain the flow / interaction diagram / how it should work in practice

roy: takes a while, want to have some solution that works for people first

ACTION-131 due 2012-06-01

<trackbot> ACTION-131 Sketch use case for user agent requests on tracking status resource due date now 2012-06-01

ACTION-139?

<trackbot> ACTION-139 -- Thomas Lowenthal to improve wording of 3.9 "Meaningful Interaction" to avoid "affirmatively clicking" and make sure that "clicking" is replaced with something more general. -- due 2012-05-14 -- OPEN

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

matthias: and?

tom: thought we dropped it

matthias: will check minutes

tom: i'm not going to do it, if someone else wants it they can

npdoty: have we removed clicking from draft?

tom: dont know

<dsinger> "intentional interaction" was something like what we discussed

matthias: nick, can you check status of action and close if appropriate?

npdoty: clicking is still on draft
... we agreed clicking would not be enough, but action seems still open as-is

tom: previously we talked about affirmatively clicking

<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#meaningful-interaction

tom: didn't think you could determine affirmative clicking, but could determine if they clicked on something that meant they were trying to interact with you

npdoty: might not click at all, might have button on phone / touch / other interactions

tom: did david volunteer to add touch?

matthias: moving on
... will call for volunteers for the aciton
... if no one volunteers, text stays as is

ACTION-150?

<trackbot> ACTION-150 -- Ninja Marnau to analyse EU legal implications of exceptions to (thissite, *) -- due 2012-05-04 -- OPEN

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

matthias: noting ninja is not on call
... third time this action came u

ACTION-155?

<trackbot> ACTION-155 -- Aleecia McDonald to update slide 6 to note "aspirational timeline" -- due 2012-05-09 -- OPEN

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

<justin_> npdoty, the compliance spec says clicking OR OTHERWISE AFFIRMATIVELY ENGAGING, fwiw

<pde> I'm not on the call, but I can give an update on Action-160

aleecia: my deadline turned out to be aspirational as well

ACTION-155 due 2012-05-23

<trackbot> ACTION-155 Update slide 6 to note "aspirational timeline" due date now 2012-05-23

ACTION-159?

<trackbot> ACTION-159 -- David Singer to draft shorter language to describe conditions for consent (with npdoty) -- due 2012-05-05 -- OPEN

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

<npdoty> justin, good point, but then we are still using "affirmatively"

hober: at apple covering for dave who is traveling
... believe he's waiting on update to compliance document to make relevant changes

<aleecia> (sorry to be joining IRC late)

<justin_> npdoty, yes, but it makes sense where we moved it.

<pde> (Basically, A deadline of Wed next week is probably realistic for progress on 160)

dsinger: actually, believe this action is covered by shane's proposed language
... said on mailing list
... so does nick

Close action-159

<trackbot> ACTION-159 Draft shorter language to describe conditions for consent (with npdoty) closed

ACTION-160?

<trackbot> ACTION-160 -- Peter Eckersley to work with Shane on common ground on unlinkability normative/non-normative text -- due 2012-04-24 -- OPEN

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

<justin_> npdoty, affirmatively clicking is clearly redundant, affirmatively engaging is only arguably redundant ;)

<fielding> shane sent regrets

<Chris_PedigoOPA> I think Shane is traveling today

<Chris_IAB> there were problems joining the call

tom: he's not on call, says update of next week is realistic for progress

ACTION-160 due 2012-05-23

<trackbot> ACTION-160 Work with Shane on common ground on unlinkability normative/non-normative text due date now 2012-05-23

ACTION-163?

<trackbot> ACTION-163 -- Roy Fielding to explain confusion or an alternative to text explaining the interaction with existing user privacy controls -- due 2012-05-15 -- OPEN

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

roy: will drop this
... think i don't even understand what i was going to change

Close ACTION-163

<trackbot> ACTION-163 Explain confusion or an alternative to text explaining the interaction with existing user privacy controls closed

ACTION-166?

<trackbot> ACTION-166 -- Heather West to draft updated text on definitions of "collection" and similar terms "Data collection, retention, use, and sharing" (with fielding) -- due 2012-05-11 -- OPEN

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

heather: looking at this, can't remember what end goal of the action was
... don't think the definitions are particularly problematic
... does anyone remember?

roy: definition of collection is defined in terms of receipt
... so any data you receive is collected
... whereas elsewhere in the world, collection is process of retaining data for purpose of organizing or using it
... hate having two different conversations
... ACTION-166, suggests collection is process of retaining data for purpose of organizing or using it

<trackbot> ACTION-166 Draft updated text on definitions of "collection" and similar terms "Data collection, retention, use, and sharing" (with fielding) notes added

ACTION-166 on fielding

ACTION-170?

<trackbot> ACTION-170 -- Heather West to provide an alternative approach to well-known URI for resources that are used in both first-party and third-party contexts without changing the resource URI -- due 2012-05-11 -- OPEN

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

hwest: in progress, need more time

ACTION-170 due 2012-05-23

<trackbot> ACTION-170 Provide an alternative approach to well-known URI for resources that are used in both first-party and third-party contexts without changing the resource URI due date now 2012-05-23

matthias: i probably have some input here as well
... will email

ACTION-174?

<trackbot> ACTION-174 -- Ninja Marnau to write up implication of origin/* exceptions in EU context -- due 2012-05-04 -- OPEN

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

Matthias: ninja is not here

ACTION-175?

<trackbot> ACTION-175 -- Vincent Toubiana to draft API method for sites to remove, a la removeTrackingException() -- due 2012-05-05 -- OPEN

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

vincent: i'm here
... sent a draft yesterday and getting feedback from nick
... tried to integrate feedback

<npdoty> I think Ninja's two actions are duplicates of one another

vincent: question is whereas we should use the API only from the website that is requesting the exception
... or if we should consider the user agent
... proposed two APIs
... one used to mange exception from user agent
... removed the third one
... just one API
... should move to pending review

matthias: ok, pending review

ACTION-176?

<trackbot> ACTION-176 -- David Singer to update site-specific exceptions text to note that embedded third-party javascript may make the call rather than the first party (even though it probably shouldn't do so without working it out with the publisher) -- due 2012-05-05 -- OPEN

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

dsinger: provided an email
... when the origin of the script is not the same of the top level browsing context, suggest interpreting this as a third party exception request
... can either go that way, or document that such cross-site requests are not permitted
... might prefer a separate call for adding a third party event
... can also notice that origins don't match
... no one else has commented

matthias: resend email and link email to action

<npdoty> didn't I comment?

matthias: put action in the email subject/body

ACTION-178?

<trackbot> ACTION-178 -- Thomas Lowenthal to talk with Shane about an updated compliance proposal -- due 2012-05-05 -- OPEN

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

tom: doesn't your proposal have a problem with included scripts like jquery (presumably referring back to ACTION-176)
... running in the context of the site

dsinger: if you load script libraries from someone else, yes
... if we allow a script loaded from any site to make request on behalf of party, that seems dangerous

tom: don't see an obvious solution

<fielding> why would an origin that needed to know the DNT status do that via a js loaded from some other domain?

dsinger: should write restriction and have a separate api

ACTION-178?

<trackbot> ACTION-178 -- Thomas Lowenthal to talk with Shane about an updated compliance proposal -- due 2012-05-05 -- OPEN

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

<tl> fielding: Because they want to use jquery.

matthias: what should i do with action-176?

dsinger: pending review?
... we are reviewing what i proposed

matthias: ok, p-r

ACTION-178?

<trackbot> ACTION-178 -- Thomas Lowenthal to talk with Shane about an updated compliance proposal -- due 2012-05-05 -- OPEN

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

<ksmith> aauu is ksmith

tom: shane isn't here and we haven't spoken

matthias: so...?

tom: keep action

<npdoty> tl, do we have an update on roughly when this would happen?

tom: whatever happens on tracker is unlikely to affect my behaviour

matthias: so i should use other means?
... will leave it

<tl> npdoty, Sadly, no.

ACTION-179?

<trackbot> ACTION-179 -- Shane Wiley to draft section on seriousness of the request for a user-granted exception (with ninja) -- due 2012-04-19 -- OPEN

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

shane isn't here

nor is ninja

matthias: will send shane a reminder, and drop action soon

ACTION-181?

<trackbot> ACTION-181 -- David Singer to fix the language in the spec where necessary to reflect "permitted uses" and "user-granted exceptions" -- due 2012-05-05 -- OPEN

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

dsinger: think it's done a few hours ago
... p-r or closed

Close ACTION-181

<trackbot> ACTION-181 Fix the language in the spec where necessary to reflect "permitted uses" and "user-granted exceptions" closed

ACTION-182?

<trackbot> ACTION-182 -- David Singer to do a dependency check (TPE-Compliance) -- due 2012-06-15 -- OPEN

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

dsinger: think this is a dupe of 176

<npdoty> action-183?

<trackbot> ACTION-183 -- David Singer to double check API lannguage -- due 2012-05-05 -- OPEN

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

matthias: ok

ACTION-183: a duplicate of 176

<trackbot> ACTION-183 Double check API lannguage notes added

ACTION-184?

<trackbot> ACTION-184 -- Aleecia McDonald to move issue-14 text from Compliance to Global Considerations document -- due 2012-05-09 -- OPEN

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

ACTION-184 due 2012-05-23

<trackbot> ACTION-184 Move issue-14 text from Compliance to Global Considerations document due date now 2012-05-23

ACTION-185?

<trackbot> ACTION-185 -- Kevin Smith to draft specific field proposal for optional auditors -- due 2012-05-05 -- OPEN

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

tom: believe this is now on kevin

ksmith: out for a week and a half, will look intot his

ACTION-185 on kevin

npdoty: was this kevin trilli?
... not smith?

tom: believe so

npdoty: seems to make more sense

<aleecia> ...that was almost certainly my fault

ksmith: relieved

<aleecia> I probably grabbed the wrong Kevin while re-assigning quickly on the call last week. Sorry, Kevins.

matthias: done

ACTION-185?

<trackbot> ACTION-185 -- Kevin Trilli to draft specific field proposal for optional auditors -- due 2012-05-05 -- OPEN

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

ACTION-187?

<trackbot> ACTION-187 -- Thomas Lowenthal to write text for ISSUE-99 around identity providers as first or third parties, DUE May 5 2012 -- due 2012-05-05 -- OPEN

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

tom: have not done this

<npdoty> hwest and jchester offered to review

tom: if someone else would like to take this over, would strongly recommend
... in particular, someone who believes current text is insufficient
... would be preferable
... otherwise, if we have no text, definition we have is what we have, interaction based
... i can live with that

<aleecia> thank you, Ian

ifette: i'll take 187

ACTION-187 due 2012-05-23

<trackbot> ACTION-187 Write text for ISSUE-99 around identity providers as first or third parties, DUE May 5 2012 due date now 2012-05-23

Matthias: concludes review of overdue actions
... did I overlook anything, or other action-related homework?

identifying callers

tom: david expressed concern around anonymous callers
... can we deal with that?

matthias: good point

<tl> The syntax when zakim says that 123-4567-xxxx is on the phone, and you are 123-4567, is to say "Zakim, xxxx is name"

<Chris_IAB> Chris Mejia of the IAB via the Skype

<Chris_IAB> Brendan from the IAB

<aleecia> thanks

<johnsimpson> lots of staic

<aleecia> We will get faster at this, I'm sure.

<Chris_IAB> I am Skype but muted

<aleecia> well, looks like we drop the p54 and find out who it was... :-(

<aleecia> ah!

matthias: aleecia proposes to drop p54

<aleecia> great

matthias: we got it and are done
... thanks a lot
... no anonymous callers

<efelten> Somebody did drop off when we started calling the roll.

more feedback on responses from sites, tom and roy have a drafted chapter in spec

Matthias: received some comments from draft spe
... don't have agreement that this is a perfect solution
... want more comments/feedback
... want to fine-tune and enable roy/tom to improve
... specific use cases not satisfied, undesirable characteristics, more constructive and concrete the better
... continuing discussion
... responses from sites

<Chris_IAB> I'm calling from Skype, yes, but I have been muted the entire time

ifette: original version had the ability for a site to return an identifier for a policy, where that identifier could be retrieved at a well known location

matthias: why do you prefer this?

<fielding> ifette: the current proposal of resource space is unusable. previous mechanism of returning a code for specific status in header is more tenable

<fielding> ifette: depending on query parameters, may have different logging policy

ifette: the backend server serving the request is best suited to know the polciy at the time of the request, not a central oracle

roy: we've done something about ian's description
... disadvantage is that the client does not have the ability to check the tracking status before sending the request that performs tracking
... if you're sending the info in header fields in response

<npdoty> is that pre-check a major use case?

<npdoty> also, what about a HEAD or OPTIONS request?

roy: doesn't work to be able to send query parameters to the server as this often contains info you don't want to be logged int eh first place
... it's a tradeoff
... can accept some tracking will occur and we don't know what until the status has been received, but that's a tradeoff and the reason i avoided this earlier
... but as near as i can tell, the only way to solve ian's solution is with a return code based solution instead of resource based
... don't yet have a proposal for how to fix, but working on

matthias: other comments related to ian's comment

tom: i think that these two sets of needs are parallel
... and both have a ?

<npdoty> both satisfactory?, I think

tom: if we implemented a proposal that said you can either do a well-known URI and response header when it changes
... or a response header with a token pointing to a well-known URI
... we need to make sure clients can tell which type of server they're dealing with but should be noncontroversial
... if we let the site choose which approach works better for them, this will serve us well
... complex sites like google can deal with their situation as such

<schunter> I agree.

<dsinger> It would be necesary that they have the same expressive power (e.g. the alpha-code that indicates permitted uses claimed is currently not permitted in the response header)

tom: and those sites with very simple implementation where they can describe their entire configuration with a single polciy applicable for all resources have a simple deployment mechanism

matthias: giving the site a choice of what mechanism to use, good point
... david just put into irc <reads from irc>
... by only having a header, eith you only have...

tom: interrupts

<npdoty> is ifette asking for a Tk: response header with a meaningful code, or just a string that will be appended to a well-known uri?

tom: they have the same amount of expressiveness
... the URI is what contains all the content
... the questin is how you get to the right URI
... is it well-known-location + URL you're loading
... or well known location + token

<npdoty> currently http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#response-header-field doesn't just point to a URI, it has a tracking/not-tracking value

tom: same amount of expressiveness

<fielding> (i.e., do you get "/.well-known/dnt" or "/.well-known/dnt/875902"

<schunter> Header->URL or URL-only or URL-> Header are our choices.

tom: just different way to find the policy URI for your requet

matthias: get your point
... header pointing to URL or only a URL
... if you have both we need to define what it means, but good point
... other comments

dsinger: wonder if we shouldn't talk about permitted uses claims (alphanumeric + tracking/not tracking) in headers
... otherwise insisiting that you augment a URL resource for anything
... always two interactions

roy: advantage of not doing is that the resource can send same header to everyone, not suffer affects of caching

<aleecia> (ifette++ for knowing people by voice)

<npdoty> ifette: hate to make an analogy to p3p but...

<aleecia> (this idea pains me.)

<schunter> Why?

<aleecia> (it may be the best option, but: ow)

<npdoty> ... a short code that is describing a reference to more info (in contrast to expressing the whole thing in the response header)

tom: think requirements are related
... think we broadly agree on the URI issues
... some tweaking, but rough agreement

<aleecia> the pain is how you know if you're seeing someone for the first time when you're not tracking them

tom: paradigm of .well-known, interaction model is clear

<schunter> URI + header and URI-only as the 2 potential interaction patterns.

tom: don't need a response header first

<aleecia> and that it's just a non-trivial bit of additional overhead

tom: set of requirements about how much info we tell the user in response header straight-away

<aleecia> this may be the best of all possible worlds

tom: so that their user agent knows whether they want to continue

<dsinger> maybe linking header->URI is a good state to get to for the next round of public review, and maybe implementation and experience

matthias: any other questions

<npdoty> +1 to dsinger, I think we can use implementation experience

aleecia: my concern in part is that it's difficult to know the policy when you first contact a site
... one more piece of overhead
... may be best solution
... aesthetically displeasing

matthias: intend to have minimal set of attributes we really need
... once the generic, basic pattern is clear
... we can fine-tune

<aleecia> (typing in IRC in that "just ignore me if you'd like" way)

roy: did you want to ask about the specific fields

matthias: at some point yes
... but first better to settle basic scheme
... intend to have a straw poll listing the fields
... and getting a rough feeling of who needs them, who doesn't care, etc
... have no clue what's needed by whom
... want to gather some info and discuss as appropriate

ifette: on the first-time use issue, I understand that you can't get the policy before you make the request
... but I'm not sure why that's problematic

<aleecia> agreed

ifette: only matters when DNT is turned on
... 1) I honor your DNT status (in which case, fine)
... 2) I see your DNT status but I don't support it
... 3) I see your DNT status but I'm tracking you anyway even though you don't have an exception

<aleecia> ok

roy: if we require site-wide resource, then yes you can use that to figure out if a site supports DNT

tom: or there could be an out of band opt-in
... one particular sharing you've instructed me to do
... and i remember that and will do that

matthias: let's look into that later
... once we have a concrete proposal aleecia can circle back
... do you have sufficient info to update the spec?

<npdoty> I think the out-of-band exception case is important, that's a key time for a user to find out they're being tracked, and it may be a surprise

roy: yes

<aleecia> great, I'm just not sure the "first time" concept works well. But really: do ignore me here, I'm not trying to derail. You're better at this (Ian, and collectively) than I am.

tom: think we have info for a next revision

matthias: everyone still free to send comments to mailing list
... roy will update spec
... how long do you need to update?

roy: tpe next week?

matthias: two weeks?

aleecia: next week would be easier
... have meeting on wednesday

<scribe> ACTION: fielding to update DNT spec to take into account discussion around policies at just a well known URL or well known URL plus token [recorded in http://www.w3.org/2012/05/16-dnt-minutes.html#action01]

<trackbot> Created ACTION-199 - Update DNT spec to take into account discussion around policies at just a well known URL or well known URL plus token [on Roy Fielding - due 2012-05-23].

matthias: think we have consensus on site-wide exceptions
... and web-wide exceptions

explicit/explicit exceptions

<fielding> http://lists.w3.org/Archives/Public/public-tracking/2012May/0201.html

matthias: ongoing discussion, lots of points on both sides
... concerns around abilities of large sites to use this, and complex UI
... sent proposal to list
... point was to find a balance between privacy, UI, and transparency
... simplify by saying only list top-level third parties
... e.g. the ad-network but not everyone below this
... UI can make simplifications
... browser can use same UI
... e.g. for first/* and first/{third,third}

<tl> I have to drop off very shortly, which is unfortunate.

matthias: hope this is a nice balance
... and that we can move forward
... see during feedback phases what people think
... no surprise, people have opinions

ifette: all my previous points still hold, this slightly reduces the number of third parties but still has the same problem

<dsinger> I think sites that pull in widgets, or the like, might like to be cautious?

matthias: can you live with this being in the public draft
... if no one uses, easy to drop

<dsinger> 'not implement' on which side? the browser or services?

ifette: we would not implement this, we would likely thus be noncomplaint and therefore would not support this in the spec

<alex> will try again

<npdoty> ifette, sorry, who would complain in that case?

<aleecia> heifer, dsriedel, bilberry, and johnsimpson are muted

alex: wanted to point out that i have a proposal
... for web wide exceptions
... that we briefly discussed
... proposal at that time may be relevant
... the trees that identify each subsequent call
... are identified by the browser

<schunter> Ian, If the EU people are OK with over-simplifying explicit/explicit using the site-wide UI, then you would be OK with it, too?

alex: and there is a well-known URI that the first of those trees (the root of the tree)
... identifies who's responsible for the tree below it
... i make a call to nielsen, nielsen calls other parties, well known URL explains that I am responsible for those subsequent calls
... that allows the browser to make an intelligent decision
... that is the proposal brtiefly
... briefly
... may be a solution to this

matthias: good point, saying that if a party is listed it's responsible for it's children

<rvaneijk> I like the idea, alex

alex: or maybe it disclaims responsibility for people other than a given list

<rvaneijk> it expresses chain responsibility

<ifette_> npdoty, sorry for not answering earlier, hard being scribe

jc: sounds like these solutiosn require changes to browser to make them effective, don't realistically see that happening
... MSFT lists our third parties on our website
... can understand having a link / passing a link to browser
... but don't see the browser exposing that
... well known URI with policy seems more approachable solution

<aleecia> (presumably other sites don't know their third parties in any stable way?)

alex: JC, realize there's changes in browsers being discussed
... but from a third party perspective, there's a lot of changes we have to do
... expect shared burden

<aleecia> (and the browsers do have changes to make...)

alex: may not be a change for all browsers, only DNT
... could be done as a plugin or separate sort of thing
... addon
... believe browsers should share burden

JC: how many consumers would actually ever use this
... if that's less than 1%, why would a browse want to do this
... not speaking for IE here, but why would a browser do this if no one uses it

alex: we don't know
... how many people will use DNT, will care about explicit/explicit

<aleecia> 1% of 220M+ US users = a lot of people :-)

JC: we need to know

<ifette_> aleecia, not enough :)

<ifette_> aleecia, a lot is relative

JC: we have numbers on how often consuemrs click on things
... would like to state that those 'nice to have' features aren't as important as things that actually protect your privacy

<aleecia> don't we have issue with the EU?

JC: oh, let me see this list, i have no idea what it is, let me turn it off
... there's a way to find this anways, e.g. in privacy policy

<aleecia> Rob & Ninja aren't on the call today

<JC> http://privacy.microsoft.com/en-us/fullnotice.mspx#ESG

alex: big ecosystem

<rvaneijk> JC, having it readily available in a JSON would be important for me

alex: probably your description applies to first party and maybe immediate third parties

<aleecia> But I think we run into problems if we cannot somehow identify what you're consenting to

<rvaneijk> Aleecia, Rob made it off the train

<ksmith> I wonder what good it would do. This proposal may assign 'responsibility' and may even make 3rd parties discoverable, but not in the process of loading a site. This does not solve the basic problems of a)letting a user make a good decision and b) allowing a site to make changes based on that decision.

alex: what i'm describing is the current ecosystem of how the internet works
... if you implement what i described, you dont have to change the internet
... each person responsible for the calls they make themselves
... full disclosure

<aleecia> Hi Rob, please set me straight since my view of EU is not nearly as strong as yours..

alex: up to user to make the correct decision

<Zakim> fielding, you wanted to ask if the ad network transitivity works by telling the browser to send DNT: 0 to all redirects on the chain?

<rvaneijk> Aleecia, I like the idea of ALex, and having the info availlable in JSON would be great.

roy: generally agree with what ian has described
... even if we came up with perfect description of this mechanism, so complex that browsers wouldn't want to develop and servers wouldn't be able to rely as complex things on the client aren't likely to be consistent

<aleecia> "would be great" isn't the threshold that I think we're going for, per se. The question I had was more is it necessary (JSON or not) to fly in the EU

roy: end result of this whole process is a very complicated dialogue of a list of companies, none of which have a relationship with the user
... doesn't satisfy anyone's needs, even regulatory needs
... most ad networks have names/descriptions taht normal users wouldn't understand
... and thus it's not really an informed choice

<rvaneijk> if it expresses controller-procesor relation it is necessary

<npdoty> fielding, you wanted to ask if the ad network transitivity works by telling the browser to send DNT: 0 to all redirects on the chain?

<aleecia> can we do top layer, or do we need the chain?

dsinger: think we have to cope with having an explicit hostname on first or third party
... because we're dealing with a site-wide exception
... or a web wide exception
... so have to cope with that database problem of third party names in database

<fielding> npdoty, I think the answer would be yes, but OBE

dsinger: need to be cautious about what browsers will implement initially
... won't expose while DNT is establishing itself, don't want to warn every day
... want to be cautious about what we learn is exposed/used by users
... don't want to flood users with a host of warnings/dialogs as things get implemented
... think we might need
... may be first parties that don't actally want a site-wide exception for all third parties, some assumption of responsibility
... maybe they're not willing to extend that out

ifette: is there an assumption of responsibility?!?!
... that's new

dsinger: we need to have explicit for a while while we learn how things get used
... may be a UI problem
... but don't think unrecognizability of third partyy names is relevant
... would say NYT has asked you to trust X,Y,Z
... in either case, doesn't really matter to the user what the third party list is

<rvaneijk> it add transparency !

dsinger: more matters which first party is asking

<schunter> Would it be a viable solution for the EU to say that we only have (site+web)-wide exceptions while companies are free to then fix the set of third parties via the URL?

dsinger: having this data available is important

<Zakim> npdoty, you wanted to ask ifette regarding who will complain if Chrome implements in a certain way

<fielding> dsinger, then it should just ask first-party/*

<ksmith> it does not add transparency as transparency can be accomplished in many less confusing and less complicated methods

npdoty: we had discussed different UI implementations or interpretations previously
... allowing a browser to interpet explicit as *
... ian was concerned someone would complain
... wanted more detail

<dsinger> to roy: no, you missed my point that there may be mash-up sites that only want to ask for their advertizers, trackers, etc. and not whoever their mashed content may pull in.

npdoty: useful feedback
... not sure who would object

<Zakim> ifette, you wanted to say if it's an addon we don't have to standardize it

<dsinger> to roy - there is an implication of some responsibility over the 3rd parties, on the 1st party's part

<rvaneijk> ifette, I will respond, am in the queue

ifette: if you translate explicit to *, then does it still meet eu requirements etc

npdoty: implementation might affect whether it satisfies requirements of a jurisdiction
... but still feel it would be useful

<vincent_> i can wait as well :)

rvaneijk: let me quickly circle back to ian's comments
... useful (alex's proposal)
... but it gets interesting under assumption taht the user would shift a granular consent mechanism to browser
... having explicit info (top party, with a lsit of parties it's responsible for) is a way to increase transparency
... user doesn't ahve to worry about a whole colleciton of third parties that signal to be compliant
... think there are possibly less complicated solutions
... but since we're reacting on alex' proposal, there are a lot of possibilities there

matthias: posted to the list that concern from privacy perspective is that consent to an arbitrary list may not be ideal
... enterprises are free to bind themselves to specific list of third parties at well known URI
... if you do a site-wide exception, here's what it means (here's a list)
... have bound yourself to this list
... have the same info
... just packaged differently
... it's a site wide exception, what a site is may or may not be specified in detail at the well known URI

vincent: to clarify, are you referring to JS API that does what you described

matthias: proposal was to have JS api that is either web-wide or site-wide
... no explicit
... if a site wants, it can make it explicit by posting a list of third parties at the well-known URI

alex: fundamental problem
... my proposal tries to deal with this, which is there are certain first parties that do not allow JS from a third party to run on their website
... so this becomes problematic

<dsinger> oh ugh, that means the UA has to fetch the well-known URI EVERY TIME it needs to send a DNT header, doesn't it??

alex: for site specfic this will work

<dsinger> (if the site is on the list, send DNT:0 else DNT:1)

alex: for web-wide it will not work

matthias: could you raise as an issue
... separate from what we are discussing now
... somehow, third party has to get access to this framework and that shouldn't be gated on third party

vincent: suggestion to use additional parameter in exception request
... to make it mandatory
... (you must accept this)
... to ensure every user has required exceptions
... know which third party is granted an exception

<alex> sorry it's issue-138

vincent: intermediary between well known URI and adding explicit/explicit

ISSUE-138?

<trackbot> ISSUE-138 -- Web-Wide Exception Well Known URI -- pending review

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

<Zakim> ifette, you wanted to say i really like matthias's proposal

<fielding> sounds like david

<schunter> [Nick: understood what?]

<vincent_> the idea would be to have an additional parameter to the requestSiteSpcific exception which tells if a given exception is mandatory to be allowed to visit a first aprty

<vincent_> hence the first party would be sure that every visitor has granted an exception to a list of first parties

dsinger: you're either saying we're moving the parameters from the call to the well known URI

<schunter> to make ian happy ;-)

dsinger: or if the well known URI can change over time, the UA has to fetch this every time
... that's unimplementable
... don't follow

<npdoty> vincent, I'm not sure how we could make it mandatory for visiting the site, or if we would want to

<fielding> I think Ian meant UA would treat it as *

dsinger: ok, so sites with a list of trusted ads/analytics

<vincent_> npdoty, see http://lists.w3.org/Archives/Public/public-tracking/2012May/0117.html last paragraph

dsinger: but also mashup content that they do not wish to be responsible for
... they ask for exception,a lso take on repsonsibility for more

<fielding> (and a truly concerned UA could choose to request the info more often)

ifette: where in the spec does it say you take on liability or responsibility

matthias: think that it's best if i put a single line in the irc to describe my solution
... suggest i can put an action on me to further describe

<vincent_> npdoty, for the how we may just add the paramter and expect the browser to prevent the user to visit the website (keep visibility off for instance) if a required exception ahs not been granted

matthias: and maybe things become clearer
... but move parameter to well known URI
... still has advantage of informing people even if no call is made

npdoty: may be we can wait for more detailed proposal
... same concern to david around a site may wanting to narrow its scope
... can discuss in repsonse to more detaield proposal

matthias: we haven't yet closed ISSUE-140 but are making progress, which is good
... vaguely want to start a discussion on UA behaviour
... roy made comment that UAs are hard to police
... UAs may do stuff we do / dont like
... want to discuss obligations on UAs for exception framework

<npdoty> vincent_, I don't think we want to block access to sites altogether though, do we?! sites wouldn't have a chance to explain (via HTML) in further detail

matthias: not now, just queueing this up
... finally, some open issues
... want to resolve quickly

ISSUE-84?

<trackbot> ISSUE-84 -- Make DNT status available to JavaScript -- open

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

ISSUE-112?

<trackbot> ISSUE-112 -- How are sub-domains handled for site-specific exceptions? -- open

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

<scribe> ACTION: ifette to write text for ISSUE-84 due 2012-06-01 [recorded in http://www.w3.org/2012/05/16-dnt-minutes.html#action02]

<trackbot> Created ACTION-200 - Write text for ISSUE-84 due 2012-06-01 [on Ian Fette - due 2012-05-23].

<scribe> ACTION: ifette to write text for ISSUE-112, due 2015-06-01 [recorded in http://www.w3.org/2012/05/16-dnt-minutes.html#action03]

<trackbot> Created ACTION-201 - Write text for ISSUE-112, due 2015-06-01 [on Ian Fette - due 2012-05-23].

ACTION-200 due 2012-06-01

<trackbot> ACTION-200 Write text for ISSUE-84 due 2012-06-01 due date now 2012-06-01

ACTION-201 due 2012-06-01

<trackbot> ACTION-201 Write text for ISSUE-112, due 2015-06-01 due date now 2012-06-01

matthias: npdoty, can you associate ACTION-180 to this issue

f2f

<JC> f2f

matthias: did i overlook anything else

jc: talked about registration site for f2f
... can we push people to start registering

npdoty: will send out today
... have some people who have already replied

aleecia: people who have already sent email who cc'd aleecia, nick or aleecia can enter them
... but they may need to give dietary preference

jc: what is the cutoff

aleecia: propose one

<vincent_> npdoty, good point we should allow a website to explain itself (maybe throught the callback, did not think through that yet)

jc: need 1wk in advance

aleecia: 2wk cutoff
... or 1wk cutoff

<npdoty> sounding like June 13th for registrations, we'll send out a registration form

matthias: final words?
... bye
... next week, same bat time, same bat channel

<johnsimpson> thanks

<aleecia> :-)

<aleecia> I think that every call, Ian

Summary of Action Items

[NEW] ACTION: fielding to update DNT spec to take into account discussion around policies at just a well known URL or well known URL plus token [recorded in http://www.w3.org/2012/05/16-dnt-minutes.html#action01]
[NEW] ACTION: ifette to write text for ISSUE-112, due 2015-06-01 [recorded in http://www.w3.org/2012/05/16-dnt-minutes.html#action03]
[NEW] ACTION: ifette to write text for ISSUE-84 due 2012-06-01 [recorded in http://www.w3.org/2012/05/16-dnt-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2012/05/30 06:07:02 $