See also: IRC log
<npdoty> scribenick: tedleung
<aleecia> https://www.w3.org/2011/tracking-protection/track/actions/overdue
<npdoty> action-131?
<trackbot> ACTION-131 -- Roy Fielding to sketch use case for user agent requests on tracking status resource -- due 2012-04-25 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/131
<ifette> ACTION-131?
<trackbot> ACTION-131 -- Roy Fielding to sketch use case for user agent requests on tracking status resource -- due 2012-04-25 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/131
waiting until response is clarified. Postponed 1 wk
<ifette> ACTION-131 due 2012-05-09
<trackbot> ACTION-131 Sketch use case for user agent requests on tracking status resource due date now 2012-05-09
<aleecia> (updating Ninja's now per email)
<ifette> ACTION-141?
<trackbot> ACTION-141 -- Rigo Wenning to draft text on clarity that this is for user agents (addressing his concern) -- due 2012-03-07 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/141
<npdoty> Rigo wrote this: http://lists.w3.org/Archives/Public/public-tracking/2012Mar/0045.html
rigo to review action
<ifette> 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
<aleecia> (added more time for Ninja)
ninja needs more time for her actions
<aleecia> (taken care of)
rigo done with work for action-141
<fielding> ACTION-163 due 2012-05-09
<trackbot> ACTION-163 Explain confusion or an alternative to text explaining the interaction with existing user privacy controls due date now 2012-05-09
<npdoty> rigo, what do you mean that you don't see it in tracker?
<ifette> ACTION-141: rigo thinks this is done
<trackbot> ACTION-141 Draft text on clarity that this is for user agents (addressing his concern) notes added
<npdoty> pde, are you here?
<aleecia> I know Peter and Shane are working on this
<aleecia> Last I heard, it's not done.
<tl> pde is rarely on the calls
<aleecia> But is well in progress.
<ifette> ACTION-153?
<trackbot> ACTION-153 -- Jonathan Mayer to draft a permitted use/definition for unlinkable data -- due 2012-04-04 -- CLOSED
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/153
<npdoty> 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-09 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/163
action-163 pushed back 1 week
<ifette> 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-01 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/166
<ifette> ACTION-166 due 2012-05-09
<trackbot> ACTION-166 Draft updated text on definitions of "collection" and similar terms "Data collection, retention, use, and sharing" (with fielding) due date now 2012-05-09
action-166 delayed by one week
<ifette> ACTION-169?
<trackbot> ACTION-169 -- Rigo Wenning to create text describing "if your privacy policies don't match, don't claim an associated domain" -- due 2012-04-19 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/169
<vincent> hum i'm on mute actually, i must have get the wrong prot number
<ifette> ACTION-169 due 2012-05-09
<trackbot> ACTION-169 Create text describing "if your privacy policies don't match, don't claim an associated domain" due date now 2012-05-09
action-169 delayed 1 week
<ifette> 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-04-19 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/170
<ifette> ACTION-170 due 2012-05-09
<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-09
<johnsimpson> apologies for joining late
action-170 delayed 1 week
<ifette> ACTION-190?
<trackbot> ACTION-190 -- Ian Fette to write up proposal for allowed uses for protocol data in the first N weeks -- due 2012-05-02 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/190
<aleecia> thanks Justin - that's going to be useful sooner rather than later, I think
<aleecia> https://www.w3.org/2011/tracking-protection/track/actions/190
<scribe> New Business
<fielding> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#responding
<aleecia> 5.1 Overview
<aleecia> The Tracking Protection protocol is designed to be applicable regardless of the response from servers that receive the tracking preference expression, allowing conformance to be achieved without impacting the operational performance of site resources. However, there is also a desire to support verification or pre-flight testing of a site's conformance with this protocol for evaluating conformance before sending data, enabling specialized user interfaces,
<aleecia> discovering the scope of protocol deployment, and testing adherence to potential regulations.
<aleecia> This section explains how a user agent may discover an origin server's tracking status for a given resource. It defines a required well-known tracking status resource for describing a machine-readable tracking status and a Tk response header field that may be sent in any HTTP response and must be sent in responses to requests that modify the tracking status for that user agent.
<tl> [my phone just disconnected, so I'm typing my comments]
<tl> It does not look as though the most recent draft which we discussed in DC has been incorporated into section 5.
<aleecia> I don't understand the phrasing of "regardless of the response from servers"
<npdoty> we're looking at: http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#responding
tl: does the current text include the changes discussed in DC?
fielding: I merged the content into the draft keeping to "best editorial style"
<npdoty> fielding, are there substantive differences from what you discussed in DC?
fielding: in some cases i changed the content
<npdoty> maybe could you summarize those changes for us quickly?
schunter: are we seeing disagreement between the proposal co-authors?
<aleecia> (What I think you're saying is that servers can respond in two different ways, rather than "regardless of the response" which to means something a little different)
<npdoty> http://www.w3.org/mid/E1SORt7-0006O6-2g@lionel-hutz.w3.org
following npdoty's suggestion to summarize the changes
<rigo> to me this looks like too much P3P reloaded and thus does not respect the direction of the protocol
tl: it looks like the vast majority of normative content that I proposed was not added
<fielding> http://lists.w3.org/Archives/Public/public-tracking-commit/2012Apr/0004.html
<tl> Well, this phone connection is just fantastic.
<tl> And I'm back.
rigo: i was originally a proponent of a feedback mechanism, but what we have now looks close to a P3P protocol, e.g. an announcement of a policy, which is the reverse direction from DNT
<npdoty> rigo, is your concern about the complexity of the well-known URI content? or that it doesn't seem responsive to the user expressed preference?
<rigo> the second
schunter: what exactly don't you like about the proposal
<tl> Correction: the I was looking at an old cache. I retract my concerns.
<fielding> To be clear, we DID NOT have consensus on Tom's text at the DC meeting. We didn't even discuss it as a WG whole -- only in a single breakout section -- and even then we did not receive consensus. So I am trying to find a proposal that addresses EVERYONE''s concerns, not just Tom.
<schunter> tom: Is it OK to discuss the section anyway?
rigo: I fear it's getting so complicated that it's almost becoming a policy, it's not just reflecting the preference of the user
<schunter> fielding: I perceived that a majority was OK with tom's 'minimal' header proposal that was created with Shane, Rigo, and others.
fielding: that's not the use case that we have in front of us
tl: agrees with fielding
<aleecia> Rigo we're trying to build so that user agents can express these details if they wish
schunter: i'm unsure because we don't really have a complete set of technical requirements
<npdoty> fielding, you were making the point that this isn't just an echo, which I believe Rigo would agree with
tl: we looked at the technical requirements and added the necessary fields
<npdoty> I thought we hadn't actually considered the list of fields as a group, leaving that open until later
<aleecia> Perhaps now is later
<aleecia> as it were
back and forth between schunter and tl regarding the set of requirements
<ifette> oh really?
<npdoty> aleecia, yes, I think we've reached now now
<ifette> if any one person has a requirement it goes into the spec?
<ifette> in that case, i have lots of requirements
<tl> As long as nobody else objects.
claim is that requirements for a single person can be added to the spec, unless there are objections
<aleecia> The second paragraph in the intro seems clear to me
<fielding> Should we restore the section on WG notes?
schunter: we now must have a well-known URI, we cannot just use headers
<tl> This is not the text that we reviewed in DC, there have been substantial modifications.
fielding: was trying to say the server must respond
<fielding> tl, yes
<npdoty> do we believe the full set of requirements/desires are listed in this Overview section?
<schunter> Well-known URI and headers should be as simple as possible (but no simpler) ;-)
<tl> No, absolutely not.
<aleecia> I'm having trouble with the subject and object in the opening line. Something like (and maybe this is wrong) "Servers must abide by DNT regardless of the response" or something along these lines? I don't quite get who must do what.
rigo: i'm unclear on what this feedback mechanism actually says.
<aleecia> even "the response" is bad there, I want who is responding -- I'm not helping.
<npdoty> tl, fielding, should we document all the desires in the Overview given that we're documenting some?
<schunter> es
<schunter> yes
<aleecia> But perhaps the problem I'm having becomes more clear, I want the subject and object nailed down
<aleecia> 5.2.1 Definition
<aleecia> An origin server must provide a tracking status resource at the well-known identifier [RFC5785]
<aleecia> (relative to the URI of that origin server) for obtaining information about the potential tracking behavior of resources provided by that origin server. A tracking status resource may be used for verification of DNT support, as described in section 5.2.4 Using the Tracking Status.
<aleecia> A valid retrieval request (e.g., a GET in HTTP) on the well-known URI must result in either a successful response containing a machine-readable representation of the site-wide tracking status, as defined below, or a sequence of redirects that leads to such a representation. A user agent may consider failure to provide access to such a representation equivalent to the origin server not implementing this protocol. The representation might be cached, as described
<aleecia> section 5.2.5 Caching.
<aleecia> If an origin server contains multiple services that are controlled by distinct parties or that might have differing behavior or policies regarding tracking, then it may also provide a space of well-known resources for obtaining information about the potential tracking behavior of each specific service. This parallel tree of resources is called the tracking status resource space.
<aleecia> New: When sending a request for the tracking status, a user agent should include any cookie data [COOKIES] (set prior to the request) that would be sent in a normal request to that origin server, since that data might be needed by the server to determine the current tracking status. For example, the cookie data might indicate a prior out-of-band decision by the user to opt-out or consent to tracking by that origin server.
<aleecia> All requests on the tracking status resource space, including the site-wide tracking status resource, must not be tracked, irrespective of the presence, value, or absence of a DNT header field, cookies, or any other information in the request. In addition, all responses to those requests, including the responses to redirected tracking status requests, must not have Set-Cookie or Set-Cookie2 header fields and must not have content that initiates tracking beyond
<aleecia> what was already present in the request. A user agent should ignore, or treat as an error, any Set-Cookie or Set-Cookie2 header field received in such a response.
fielding: mostly unchanged, added the final 2 paragraphs to cover what should be done with cookies
ifette: if you have different policies for subspaces of the site, then what does the policy for the top level-space look like
<aleecia> So that's the section I didn't paste in:
<aleecia> The tracking status resource space is defined by the following URI Template [URI-TEMPLATE]:
<aleecia> where the value of pathinfo is equal to the path component [RFC3986] of a given reference to that origin server, excluding those references already within the above resource space. For example, a reference to
<rigo> I wonder if we have to register the well-known location somewhere. For P3P we had to do that. I think we have a simpler mechanism now in RFC 5785
<aleecia> http://example.com/over/here?q=hello#top
<aleecia> may have a corresponding tracking status resource identified by
<aleecia> http://example.com/.well-known/dnt/over/here
fielding describes the search mechanism to find the correct policy
<npdoty> if my homepage (that is, "example.com/") has a different tracking status than all the pages underneath "/", what path should I use in JSON for the top-level tracking-status resource?
<npdoty> (maybe that's related to your question, ifette)
<ifette> so is this going to blow up the number of queries to the server?
tl: there's the pathinfo in the well-known-uri, and that's binding, but if there is a more specific policy, then an additional request would be made
<tl> ian fette, only when I don't know the TSR.
<fielding> max two additional queries per 24 hours per UA that does active verification. It is not expected to be much.
<ifette> and what if i track only a percentage of requests?
schunter: i'm unclear on the precedence rules, and it seems complex
<tl> And I can always make a deeplink request to start.
<ifette> roy, 2 queries per resource on a page?
<fielding> tracking a percentage is still tracking
<tl> ifette, The TSR must cover your practices.
<npdoty> ifette, you also have the optional Tk header if you the server want to give a more granular response
aleecia: looks like we need some non-normative example text
<ifette> npdoty, but the uri is required
<fielding> I still have that action
<ifette> and it doesn't seem clear to me how i would express 'i'm logging 1% of these queries'
<fielding> ifette, right
<tl> ifette, You'd say "I'm logging these queries."
<aleecia> Roy, to be clear, I think you've just said you're writing a non-norm section for 5.2.1 with basic and advanced examples
<fielding> aleecia, yes a use case and examples section
<ifette> that's a problem...
<aleecia> thank you
tl: if there are 2 policies that apply to the same resource, that's conflicting, if there are 2 policies for different resources, that's the whole point
<ifette> i have a requirement that i be able to publish a broad polciy and override it as necessary
tl: for each resource there is at least 1 policy that describes it
<aleecia> I think that's a non-unique use case that Ian has, to say the least
<fielding> ifette, sounds like an interesting use case
schunter: better documentation needed
<aleecia> I'm going to guess Ian doesn't want to use headers due to cache issues, but that's a fair question
ChrisPedigoOPA: what's the functional reason for well-known-uri / response headers, since bad actors can still fake it.
<aleecia> transparency, auditability, enforcement
tl: if you lie, you are subject to legal measures such as deceptive practices
<rvaneijk> chris: for me the reason is that it adds value in comparison to the existing opt-out system.
<fielding> URI's don't lie, people do
<aleecia> where "researchers" includes regulators and users
<npdoty> I think tl is making the point that users and researchers could more easily get transparency into the tracking practice if we have a machine-readable tracking status
schunter: the goal is for browsers or other tools to be able to see whether a site is stating compliance or not
<rigo> the response header is crucial for the consent mechanism
<rigo> because the scope of the declaration is different from a press release
ChrisPedigoOPA: isn't english text at the bottom of CNN.com the same thing?
<rvaneijk> recital 66 gives an opening towards letting the browser express user consent...
<JC> I feel we are trying to force 100% of sites do something that < .001% of users would ever use or care about
schunter: yes, but it's not helpful for a machine
<fielding> The response is only necessary for one in a million users that wants active verification.
<npdoty> fielding, there are multiple conflicting predictions about how many users will take advantage of the tracking response, and how their agents will use it
ChrisPedigoOPA: do we need to make a statement about every page on a site?
<aleecia> but we know if we don't support the data, 0 users and users agents will use it :-)
<schunter> good point ;-)
schunter: the current proposal allows you to make a statement for the whole site and additional statements for pieces of a site
<fielding> npdoty, sure, but that one is mine
tl: it also gives information such as "this site is a 3rd party"
ifette: i thought that response header was going to return a policy code, which could then be tacked onto the well-known-uri to obtain more information on the policy
<aleecia> so for Chris, it's been true for a long time that the value of a property and who owns it is filed at the county courthouse. It is different when it's online and accessible, able to be automated. Same idea here: having "we're DNT compliant" in a text footer is the same statement, perhaps, yet has totally different utility.
<npdoty> I think it's very important for us to know if tracking statuses vary based on query string or body of the request or other information not in the path
ifette: the current proposal drops query params, but google uses query params to figure out which site, it's hard to see how we could use this for google.com
<rigo> Ian, the path matching was a major hickup in P3P's policy reference file
<npdoty> ifette, would Tk headers work for your cases? per response values?
tl: supply an unmet technical requirement and a fix
<fielding> Google's tracking policy does not change per query. That's nonsense. Google tracks ALL requests on ALL resources, ALL of the time and only drops some records based on cookie data
<aleecia> could we not talk over each other?
ifette: I've done that, but it's been rejected
<JC> We are spending too much time on this.
<rigo> JC, this is critical
<aleecia> actually, we do need to work through this JC
argument over whose proposal is unworkable, but hard to scribe due to people talking over each other
<aleecia> you've been doing an awesome job scribing, by the way
<rigo> JC, because it is a predictable hickup that has haunted P3P for month
<fielding> I can live with no response at all.
<ifette> i'll note there's also an open action on heather to come up with an alternate proposal
<aleecia> good note, Ian
<ifette> schunter, yes
<fielding> yep
disucssion seems to be leading to a review of requirements/proposals leading up to the current
<rigo> Roy, I can't, because for an agreement I need two matching declarations
<ifette> ACTION: ifette to document difficulties around well known URIs for large sites and propose alternatives [recorded in http://www.w3.org/2012/05/02-dnt-minutes.html#action01]
<trackbot> Created ACTION-193 - Document difficulties around well known URIs for large sites and propose alternatives [on Ian Fette - due 2012-05-09].
<rigo> Matthias, what about the q?
schunter: ifette to sent his requirement/use case to the list
<aleecia> thanks, Ian
<npdoty> tl, the action also includes proposing alternatives
tl: suggesting that ifette send use case and a proposal
<fielding> Note that the policy only needs to express the worst case for path.
<Zakim> rigo, you wanted to note that I need the same expression-power in headers
<schunter> Rigo: Header-only should be possible
rigo: I have technical requirement too. W3c.org uses date space, and the path matching doesn't work at all for our site. We need a header only solution.
<npdoty> well, it's not the case that path matching doesn't work at all, just that we wouldn't get the efficiency of caching the status for a large group of resources, right?
<npdoty> I don't think rigo is suggesting a header-only requirement, just that the header should be an option
rigo: maybe it's the case that simple sites use the well known uri, and complicated sites use the header, but then the header must be as expressive as the well known uri
<fielding> W3C has one and only on tracking policy.
<schunter> I read rigo/ifettes requirement as being able to point to a URI from a response header. This would mean that at "/" you may permit a policy 'please look at the headers'.
<aleecia> Could we please not talk over one another?
tl: rigo what stops you from having a tracking status resource for every uri on w3.org?
<npdoty> I think Rigo is just giving the example that two resources in the same subdirectory might have different tracking statuses, so it wouldn't get any of the advantages of caching the status for a particular path
<aleecia> Given we're not going to get through the full agenda on this call, I suggest we take the last agendum early on a future call, since jmayer is particularly interested in it yet has a conflict for the end of calls
rigo: how do i do the matching, and where do the policies go, and how big is the file that has to hold the policies?
tl: how many policies are you really going to have?
<npdoty> hwest?
<aleecia> ok
<rigo> its not about how many policies but about how many resources have a policy and how to find which has which
<fielding> and I still haven't solved Heather's issue regarding different policy per reference context
schunter: people should send their comments to the list
<npdoty> sorry fielding, what is "per reference context"?
<fielding> first-party and third-party usage of the same resource URI
<fielding> … where one tracks and the other does not
schunter: we'l discuss this over the next 2 weeks, issues by issue, not calling for complete alternative proposals
<fielding> … or has different policy links
<tl> fielding, I thought we were waiting for Heather to make a proposal on that.
<fielding> tl, I don't segment my thinking that well … and we don't have time.
<hwest> Yes, there's an open action for me to submit text on this - my concerns haven't changed (but am having phone trouble)
tl: i thought we had finished with this in DC
schunter: I'm not convinced that all issues have been resolved
<aleecia> noted, Heather; thanks
tl: maybe I don't understand the issue resolution process
schunter: this is the first time this chapter has appeared in full in the spec
<aleecia> if we had consensus, we wouldn't be having this disucssion
<fielding> tl, regardless, I have to reflect consensus or lack of it in the draft even if we don't have replacement text yet
<aleecia> the group will need to sign off (or not) in a similar way on compliance; if you're frustrated here, you'll be frustrated there too
<fielding> yes, the cost of my freedom is that I don't get to say we are done. ;-)
<aleecia> shall we take up the next section?
ifette: now that we see the details issues become apparent, when maybe they weren't before
schunter: if we ignore issues now, we'll just get formal objections later
<aleecia> 5.2.2 Representation
<aleecia> The representation of a tracking status resource shall be provided in the "application/json" format [RFC4627] and must conform to the ABNF in section 5.2.6 Status-object ABNF. The following is an example tracking status representation that illustrates all of the fields defined by this specification, most of which are optional.
schunter: i believe that we can get to consensus with some more work
<ifette> sgtm
<schunter> ?
<johnsimpson> makes sense
<ifette> sounds good to me
<ifette> sgtm
<npdoty> can we get updates in a week so we can discuss again in 2 weeks?
<aleecia> Are we going through the other sections?
<npdoty> thx, I just mean getting email updates within a week so we have time to read and discuss over email before the next call
<aleecia> issue-140?
<trackbot> ISSUE-140 -- Do we need site-specific exceptions, i.e., concrete list of permitted thirdparties for a site? -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/140
schunter: we have agreement that it is okay for a site to ask for an exemption for all my 3rd parties
... the question is, can the site ask for exemptions for 3rd parties on a party by party basis
... this complex, and poses complex UI challenges
<ifette> arguments against also includes that it may change over time
<ifette> requiring re-promoting
<ifette> prompting
<ifette> freudian
<ifette> "i think it is a requirement that explicit-explicit exceptions not be implemented"
tl: i think is a requirement that explicit/explicit exceptions be implemented
<npdoty> arguments for also includes sites that want to increase opt in by making limited requests
<schunter> tl: explicit/explicit enables competition on privacy
tl: this allows sites to compete on privacy, and gives full visibility to users
ifette: I think it is a requirement that explicit/explicit *not* be implemented
<npdoty> and I think it satisfies a data minimization principle
ifette: points have been made in the e-mail thread
<schunter> rigo: Is this API meant recursive or only direct sub-third parties are named/used/mentioned by this API?
<schunter> ?
rigo: is your concern "direct" 3rd parties or "brokered/marketplaced" sub providers?
ifette: I'm including the sub provider issue, and I believe that exceptions should transitively descend from a broker to the sub providers
<schunter> ian would be better if 1st level only is included in the API and this basically grantes a "*" exception for all corresponding sub-sub providers below this 3rd party.
ifette: i still think that a transitive model is too complex, but would be better than explicit/explicit
<ifette> +1
fielding: I tend to agree with ifette. I'd prefer to remove the entire exception framework, and rely on site developed mechanisms as the only means of escaping dnt
<rigo> -1 on having no exception mechanism
<ifette> i would support roy's proposal
schunter: tjat
<schunter> fielding: One alternative would be to drop the complete exception framework and do exception handling from the spec.
schunter: that's quite a radical proposal
<ifette> +1 to alex as well
<ifette> you can list out your third parties outside of the exception mechanism
<fielding> I mean, continue sending DNT:1 to everyone with that preference and let each site develop their own consent mechanisms with cookies.
alex: there are ways for sites to compete on privacy besides at the point of asking for an exception
<schunter> concern: Enumerating third parties vs. exempting them.
<rigo> * is mainly a blank check that you sign and can't express consent as the content of the agreement is not determined
<schunter> also: before loading (via DNT) vs. after loading (vs browser logging)
<aleecia> knowing number of 3rd parties on a site doesn't tell me how deep the rabbit hole goes, too
tl: but who knows how big "*" is, since it was claimed that it is impossible to determine the number of 3rd parties on a site.
<aleecia> Rigo's point on consent not being valid in EU is non-trivial
<aleecia> yet how to make things work with the current auction model is also non-trivial
<aleecia> +1
<rigo> +1
<Chris_IAB> ok with me
<npdoty> +1 for pushing agenda item
<johnsimpson> +1
schunter: propose that we move last item to next call since jmayer is now absent
npdoty: the user agent doesn't have to display the full list of 3rd parties all the time, even if that list is returned by the JS API
<ifette> ISSUE-111?
<trackbot> ISSUE-111 -- Signaling state/existence of site-specific exceptions -- postponed
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/111
<schunter> q
npdoty: perhaps additional bits in the headers might help <scribe not keeping up>
<npdoty> tedleung, sorry, that was a long piece of text I was giving
rigo: a 1st party selects 3rd parties based on reputation and performance, so I am not concerned about taking into account the sub providers
<schunter> rigo: Proposal to change spec to only allow sub-third parties (at direct / 1st level). This exception then automatically inherits to all subsub, subsubsub, ... providers used by this 1st level third party.
<ksmith> if I remember right - a flag of 2 tells you that some 3rd parties may have dnt:0 and others dnt:1. Knowing that you are in a state of partial exception is useless unless you know which parties are allowed - which is the problem. And even then even if you knew, it gets very expensive to support partial states
<npdoty> npdoty: if the concern was visibility for the publishers to the state of their third parties, we absolutely should take that up (as in 111) and that a separate DNT header value might be what's needed (dnt:2 or 10/11, as we discussed in DC)
<npdoty> ksmith, we can define DNT:2 or 10 or 11 as we want
<npdoty> what if DNT:10 means "you have a site-wide exception for all your third parties"? would that work for you?
<schunter> I postponed this issue-111 to a later point:
rigo: if we have web wide exceptions, then we are already into a model where not all 3rd parties on a site are treated equally
<ksmith> all or nothing works, its the partial that gets hard
<npdoty> so it would help your sites if you the first party could receive a DNT:10 which is an all-or-nothing request? ksmith
ifette: 1st parties don't rely on web-wide exceptions to cover the 1st party's 3rd parties
<ksmith> agree with Ian - web wide exceptions will usually be for 3rd parties that are providing a service directly to the user - not to the 1st party
<ksmith> or likely both
<Chris_IAB> agree with Ian: BIG +1 on this comment
<tl> I am sad to see that Ian doesn't want to compete on Ux.
<npdoty> "are all of my third parties covered or not?" -- that's why I'm suggesting a * option and a DNT header to signal a site-wide exception
<schunter> new issue: compliant behavior of user agents.
ifette: not going to rehash the UI issue, but does not thing that we should be doing translation of user intent in the UI.
<aleecia> Ted thanks for scribing this call
ifette: we should be processing user preferences directly
<ifette> if and only if these are transitive
<tl> Which they are currently not.
schunter: rigo thinks that permitting the first level of 3rd parties is useful in the EU context
<ifette> correct
<tl> Because this is the first that we have heard of transitivity.
schunter: we need some more discussion on this
<aleecia> thanks, Ian
<ifette> ACTION: ifette to write up a proposal for transitive third party exceptions [recorded in http://www.w3.org/2012/05/02-dnt-minutes.html#action02]
<trackbot> Created ACTION-194 - Write up a proposal for transitive third party exceptions [on Ian Fette - due 2012-05-09].
<npdoty> cheers to tedleung for scribing a challenging call
<aleecia> +1 to that