See also: IRC log
<npdoty> scribenick: npdoty
schunter: thanks for returning to our third day
... already made a lot of progress
... today diving in to the technical details of our protocols
... smaller groups to dive in on areas that are unclear
<ifette> ScribeNick: hwest
Matthias: Reviews agenda
... David put together the open and pending issues into a tracker; one group where it looks like we have agreement, second group where items have been discussed, and a third group we should talk about today
... most of these are listing as pending review, we have text, they've been around for a while. Would like to close them.
... ISSUE-47, regarding the response of the server - all proposals on the table address the question
npdoty: Well known URI proposal, that's true. I think it's an open question tho
WileyS: Other proposal has optional append too
Matthias: I'll send our consensus to the list to make sure everyone agrees
<npdoty> for my own reminder, for header proposal, have the optional code that you can append to a well-known URI, which can describe the policy
Matthias: next item ISSUE-84, make DNT status to JS. I think I made a mistake here. Page loads and sees the JS. Removed at some point, but want to re-discuss it later. Will discuss today.
... ISSUE-108 re DNT in other protocols
<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#other-protocols
<npdoty> looks good to me
Matthias: this doc only specifies HTTP, but could be applied to other protocols. No objections heard about this, can close.
Dsinger: There's a para in the doc that seems to belong in the compliance doc, can address later.
<aleecia> 4.5 Tracking Preference Expressed in Other Protocols
<aleecia> A user's tracking preference is intended to apply in general, regardless of the protocols being used for Internet communication. The protocol expressed here is specific to HTTP communication; however, the semantics are not restricted to use in HTTP; the same semantics may be carried by other protocols, either in future revisions of this specification, or in other specifications.
<aleecia> When it is known that the user's preference is for no tracking, compliant services are still required to honor that preference, even if other protocols are used. For example, re-directing to another protocol in order to avoid receipt of the header is not compliant.
Matthias: ISSUE-109 about fingerprinting risks of an API, API was closed. Shane and others disagree.
Dsinger: we can discuss in the breakout.
WileyS: If we have same-origin rules on who can see what, lower risk.
Matthias: Looks like we can close it after the breakout.
... ISSUE-14 also remains open until after the session
... ISSUE-114 I mean
... ISSUE-115 seems closed, we've decided to include out of band consent for exceptions.
Dsinger: we don't explicitly have text but can definitely happen. Seems we can close this.
Matthias: Have answered the question and can close the issue.
npdoty: do we have corresponding language in the compliance doc?
Dsinger: UA has a means to find out other than the API
Matthias: ISSUE-115 is closing.
Aleecia: that means a MUST for a response header?
Matthias: ISSUE-118 closing.
<npdoty> can anyone help me find the corresponding issue for compliance doc on requirements/text for out-of-band consent?
Matthias: ISSUE-125 was over email discussion, sufficient means of testing whether the UA supported DNT
WileyS: would prefer DNT null but that's ok
<npdoty> WileyS, so we're all comfortable with http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#exceptions-when-not-enabled
Matthias: ... ISSUE-125 closing. We'll update the tracker ASAP and migrate that to the doc.
... Now two big blocks for the working groups
... server responses working group and exceptions working group
... will discuss
... Roy and Tom will lead the server responses working group
... goal of the session is to address feedback from site to user agents
... whether site is first party, complies with DNT, thinks it has an exception
... three texts on the table - Tom's header, Roy's URI, and a hybrid
... purpose is to agree on one of those three texts, or a mixture. This group needs to get to a final and consolidated document
mgroman: Does this include whether it's may or must to respond, and which parties are responding?
Matthias: Both those issues are in this group. I think that for the response there is a MUST, just not sure which one it'll be.
WileyS: not optional if you support DNT
<npdoty> issue-48?
<trackbot> ISSUE-48 -- Response from the server should indicate the server will honor it -- closed
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/48
WileyS: for all parties
Aleecia: If I understand the group, there are two things that first parties must do - respond with their status, and can't append data
Matthias: Also input for this group is optimal requirements - status transmission, ease of implementation, transparency, granularity, maintainability, transmission of larger info (?), compatibility, resources
... questions?
Chris: Some of these are subjective, is the goal to firm up that language?
Matthias: Goal is to find a mechanism that does these things
... for this, headers are easy, for URI...
... may want to have an intro with these goals in the document
Kevin: Is this high level requirements or are we specifying elements etc?
<fielding> Tom's hybrid proposal is at http://lists.w3.org/Archives/Public/public-tracking/2012Apr/att-0067/tsr-tk_hybrid.markdown.txt
Matthias: I think currently we want to avoid policy language
... but some indication is useful
Kevin: Decided on the list it was out of scope
Matthias: Not our intent to put compliance spec into machine readable policy
Kevin: If UA can read it?
<aleecia> May I just say: I have no plans to a 2.0 on compliance :-)
Matthias: Related issues are 107 (format), 120 (must or may), 124 (expression), and 112 (subdomains)
... questions
Ifette: It's not always request-response, some HTTP includes a server push
... not always in direct response, can provide something ahead of time without an actual request
Fielding: doesn't impact tracker status here. but will affect dynamic response header field because server doesn't know your status
Rigo: Should we have non normative lines in the spec?
fielding: No, the resource will work fine
<npdoty> have we talked about long-polling as well?
<ifette> ISSUE-130?
<trackbot> ISSUE-130 -- Site-specific Exceptions b) Global Exception for Third Parties (thisthirdparty, anywhere) [refining ISSUE-111] -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/130
<fielding> npdoty, not that I am aware of
Matthias: The exception API for sites to ask for exceptions
... site specific, site-wide, and web-wide exceptions
<fielding> we haven't talked about non-browser uses of HTTP
<aleecia> (could someone remind me what we're officially calling business uses?)
alex: What about when it's not a known third party? They're trusted but no formal relationship?
<npdoty> (maybe long-polling doesn't have any particular impact on either proposal)
<npdoty> aleecia, permitted uses
<aleecia> (thank!)
Matthias: So the question is whether this can only be caught when visiting a third party, or whether you can ask for a web wide exception
Alex: additional caveat is that there's no business relationship between first and third party
... a pixel tag on a third party through an ad network
Matthias: When we decided on these exceptions we thought first parties would be calling these expceionts
... so can third parties call it tow?
Alex: I have a proposal...
matthias: You should join this working group!
<npdoty> alex is referring to: http://www.w3.org/mid/2DB61344-AB42-4533-9763-39F348479222@nielsen.com
tl: Any party can call JS
ifette: do we want everyone to load JS?
Amyc: If we've already agreed on an out of band exception, then you can do that
Matthias: at this point I'm generating input for Nick and David
Dsinger: mental model for the web wide exception was that a third party would ask for that kind of exception, ex a social network
Rigo: Important if we're not sure or if it's not set etc, that any party in this game can actually trigger the consent
Matthias: I think that's where we're heading
Dsinger: Clearly we need to discuss origin resctripctions
Matthias: it would be weird if a party that is not first or third can ask for exceptions for others
tl: so there may be a business case, might go to an opt out page, i.e. the NAI page opts out (or requests DNT) for all members
WileyS: We have an all-off and all-on model
Matthias: Questions around whether third party can call API, how to populate and manage third parties list, transparency, origin restriction, accountability
<npdoty> do we have text on this all-off/all-on question? I think we have some sections that explicitly contradict that, but if it's an open question, maybe we should create an issue
Matthias: issues 113, 128, 129, 130 will be addressed in that WG
... ISSUE-111 may need a WG too, has content from the list, but not sure who read these messages and whether we agree or not
... you hit a site and you want to tell it whether there are DNT exceptions
... can use API for polling, easier to tell whats going on from the header
... three values for DNT here
ifette: This is wrapped up in the discussion of whether we allow granularity in the site wide exception or not
Matthias: You're right to some extent. This is based on the current spec which allows these pairs, but could lose the last line if we don't have that kind of granular pairs
Dsinger: So we're asking the group about granularity?
ifette: Yes
Dsinger: We'll discuss that in our breakout
Matthias: loose ends - ISSUE-116, re JS, agreement was no, closing
npdoty: that's not a yes or no question
<ifette> ifette: specifically, the group should consider requiring a * on one side or another, e.g. you can get a "all third parties on this site" or "this third party across all sites" but not "abc on xyz"
Matthias: Seems like no one is interested, but if someone wants to write text on the DOM
WileyS: Wasn't there a thread on this?
fielding: Not in a way that's been defined, Mozilla implemented but it's not defined
Matthias: Either someone can propose a text, and then we discuss. Or we remove it.
<ifette> ScribeNick: ifette
dsinger: what is the concern?
tl: DNT is related to the specific DNT interaction
... if you are seeing a header, it's the specific request
... the DOM property may not reflect the specific request / interaction
Matthias: What do we do with it?
TomL: volunteering to take an action
<jmayer> Check my slides from the meeting last March.
<scribe> ACTION: lowenthal to come up with updated text for a DOM api to allow access to DNT state [recorded in http://www.w3.org/2012/04/12-dnt-minutes.html#action01]
<trackbot> Created ACTION-167 - Come up with updated text for a DOM api to allow access to DNT state [on Thomas Lowenthal - due 2012-04-19].
<jmayer> I walked through some of the challenges to a DOM status flag.
<fielding> the version that Mozilla mentioned does not match what MSIE implemented, nor what we have specified
<jmayer> Erm, last April.
Rigo: Going back into the past is very complex
<jmayer> http://www.w3.org/2011/track-privacy/slides/Mayer.pdf
Rigo: if the easiest mechanism of what you have in mind is revocation is overriding new header...
Nick: Maybe revocation has special meaning
... i mean if you persist something you should be able to unpersist something
Rigo: I debate your assumption of persistance
... when we talk about the user preference, a newer preference overrides an older preference
roessler: if something is stored, there's a way to change that preference
rigo: don't need technology
npdoty: if you persist granted exceptions on the UA
roy: you need a way to edit such exceptions granted on the UA
dsinger: you can go back to the site and renegotiate so that it calls the JS api again, or the UA might give you UI to edit your excepions
npdoty: referring to latter part
dsinger: you want suggestion that a UA should provide such a UI?
npdoty: yes
lowenthal: don't like requirements for UI, market can take care of this
matthias: proposal is for npdoty to go to the exceptions WG, and if he's dissatisfied, create an issue
<hwest> ScribeNick: hwest
Matthias: Right now this issue doesn't exist, not in the database, will get created if we need it
<npdoty> apologies for not creating this issue in the database originally
Matthias: homework for the editors and me, dependancies in the compliance spec
... ISSUE-61, 117 need to do a pass on the dependancies in the spec
tl: Isn't 61 fixed by the well known URI?
Matthias: Yes, but still a dependancy to ...
<ifette> ACTION: matthias to go through the document with editors and address ISSUE-61 and ISSUE-117 to address dependencies in the compliance spec [recorded in http://www.w3.org/2012/04/12-dnt-minutes.html#action02]
<trackbot> Created ACTION-168 - Go through the document with editors and address ISSUE-61 and ISSUE-117 to address dependencies in the compliance spec [on Matthias Schunter - due 2012-04-19].
tl: no, doesn't matter what the policy is, could be absurd and you could still publish it
... just a mechanism
Dsinger: can we close 61?
Rigo: If we allow for lists where somebody can say "a,b,c,d,e belong to me and are the same" and A responds that they honor DNT, and the rest don't, and A says 'not my business', then you go into a problem saying that if you state that others belong to you, you have to take responsibility for that
Dsinger: May want to add to the compliance spec that incompatible privacy policies may mean that you're not the esame party
Rigo: can be fixed by taking responsibility for the assertion
Matthias: Suggest we close, we have a mechanism. But should open issue for compliance doc to get a line in there about this.
... but 61 will be closing.
... or flipped to the other doc
... last piece of the agenda was other issues, but we'll do that later
Dsinger: I think we can close 117 too
... Roy, do you want it open?
fielding: this issue is about whether there's a definition of tracking in the spec
<npdoty> issue-5?
<trackbot> ISSUE-5 -- What is the definition of tracking? -- raised
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/5
dsinger: ok that's definitely an open issue
Matthias: Defining the meaning of a term is the issue, we'll define in the compliance spec
... will take it offline
... now, breakout groups for 45 minutes, then coffee break
... so coffee at 11 and reports at 1130
... the header URI group will stay here, the exception WG to go outside
<fielding> issue: does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s)
<trackbot> Created ISSUE-137 - Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s) ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/137/edit .
<fielding> ACTION: hwest 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 [recorded in http://www.w3.org/2012/04/12-dnt-minutes.html#action03]
<trackbot> Created 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 [on Heather West - due 2012-04-19].
<npdoty> scribenick: Joanne
Roy: Tracking status resource designed to use a diff URI for tracking status resource
... Heather to take on action item to change
... on IRC
... distinguish first party and outsourcing for 1st party
... increaine open issues by 1
JohnSimpson: hybrid idea don't know where we are at
David reporting for exceptions group
David: discussed two questions
... yes cross orgins restrictions should apply to API
... site wide, web wide exceptions
... do we also need explicit exceptions
... raises operational questions on how the API behaves
<rigo> ifette, I still believe there is a misunderstanding
David: did not agree on keeping or elimnating that explicit/explicit
... open question calling for postion papers
... recognized to be a hard question
tl: will the browser enforce that provision
David: yes
<fielding> west, what if we allowed the Tk header field to carry the response status for those resources that dynamically choose between first/third party compliance?
<npdoty> I can take an action to write up the list of use cases (based on what we discussed in the room, largely, but maybe with more detail) for the origin/origin exception pair
<fielding> s/west/hwest/; damn au tocorrect
<hwest> fielding, I'm still concerned about dynamically generating responses or resources that way
David: did not hit on our other questions
Matthais: WG made progress but not done
<npdoty> hwest, fielding, that sounds promising to me -- use the header when it's dynamic in a way that's inconvenient for the resource
<hwest> fielding, npdoty - yes, I think that it may be much easier to implement
Matthais: go back after lunch to resolve issues
ifette: David's group issues are hard - need discussion
... Roy group are there rewirtes
... Matthais group has issues where the group is blocked
jmayer: would it be productive to go back into small groups
<ifette> It's just that for our group, I don't think another 45m is going to do anything productive
<ifette> we're rather blocked
<aleecia> If you can help more productive conversations, you really don't have anything to be sorry about, Ian!
Roy: doesn't think there us a need to go back to small group and issues created is for a larger group discussion
Matthias: are you suggestioning smaller group is done and go back to larger group
<npdoty> dsinger, ifette, are there other issues besides this origin/origin question for the exception discussion?
<npdoty> dsinger, ifette, it seemed like we had a reasonably long list -- were all of those dependent on the single issue?
Roy: leave issues open until closed
tl: can you put text into draft
<amyc> Closed to me implies that group has considered, this has not been discussed by whole group
<npdoty> ACTION: fielding to insert the tk/uri hybrid into the tracking-dnt draft [recorded in http://www.w3.org/2012/04/12-dnt-minutes.html#action04]
<trackbot> Created ACTION-171 - Insert the tk/uri hybrid into the tracking-dnt draft [on Roy Fielding - due 2012-04-19].
Roy: 1 response to tracking status. tom wants issue maker for service provider issue and other issues
... Heather has action item
Matthais: create action for Roy to add to draft
... that's it and back to dsinger
ifette: for issue 111 can be done over email instead of larger group
dsinger: open issue to be considered through postiion pieces
npdoty: will take action to write up some use cases
<npdoty> ACTION: doty to write up more detailed list of use cases for origin/origin exceptions [recorded in http://www.w3.org/2012/04/12-dnt-minutes.html#action05]
dsinger: ifette to write up why it is problematic for user agent
<trackbot> Created ACTION-172 - Write up more detailed list of use cases for origin/origin exceptions [on Nick Doty - due 2012-04-19].
<ifette> ACTION: ifette to provide writeup on why managing explicit-explicit pairings is problematic from UI perspective [recorded in http://www.w3.org/2012/04/12-dnt-minutes.html#action06]
<trackbot> Created ACTION-173 - Provide writeup on why managing explicit-explicit pairings is problematic from UI perspective [on Ian Fette - due 2012-04-19].
ifette: his write up will address Rigo's question
dsinger: can thrid parties call the API
... can call it with origin match
... #4 is an easy question
<npdoty> ACTION: ninja to write up implication of origin/* exceptions in EU context [recorded in http://www.w3.org/2012/04/12-dnt-minutes.html#action07]
<trackbot> Created ACTION-174 - Write up implication of origin/* exceptions in EU context [on Ninja Marnau - due 2012-04-19].
dsinger: can the API be used to revoke
WileyS: can it make a user setting or remove a user setting
<npdoty> action-174: rvaneijk and rigo may be interested in helping
<trackbot> ACTION-174 Write up implication of origin/* exceptions in EU context notes added
<rigo> action-174?
<trackbot> ACTION-174 -- Ninja Marnau to write up implication of origin/* exceptions in EU context -- due 2012-04-19 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/174
dsinger: yes, it should be designed so the user can change thier mind
Tl: there should be a different call, not the same call
<fielding> hwest, another possibility would be to have a parent structure of JSON objects in the resour ce representation, one per context (indicated by domain or wildcard)
WileyS: it is a simle removal
<hwest> Yes, fielding, that was one of the things I was going to think about/write up
<rigo> action-174: We should wait for the write-up from Ian Fette on why this doesn't work
<trackbot> ACTION-174 Write up implication of origin/* exceptions in EU context notes added
Tl take action item
<npdoty> ACTION: lowenthal to draft API method for sites to remove, a la removeTrackingException() [recorded in http://www.w3.org/2012/04/12-dnt-minutes.html#action08]
dsigner: broswer allows remove some expcetions and not others
<trackbot> Created ACTION-175 - Draft API method for sites to remove, a la removeTrackingException() [on Thomas Lowenthal - due 2012-04-19].
<rigo> ifette, npdoty, what issue are actions 173 and 174 attached to?
<ninja> Scribenick: ninja
<Joanne> thanks Ninja
dsinger: Action for the editors to modify the text on question 5
... Question 6 on transparency
... no text change on that one. The UA has sufficient information. We do not decide use.
... Question 7: Sending DNT:0 to the first party
<npdoty> ACTION: 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) [recorded in http://www.w3.org/2012/04/12-dnt-minutes.html#action09]
<trackbot> Created ACTION-176 - 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) [on David Singer - due 2012-04-19].
tl: there might be legal implications of this signal
dsinger: We overload one character
tl: this is a matter of the API
dsinger: we postpone that until we have decided on the site wide exceptions
<npdoty> dsinger: I think maybe we should have a second character rather than overloading the single character
dsinger: we need to seperate the answers to finding about your own first party status and the status of your third parties
<ifette> ifette: I think the issue of how do you get the browser to tell "Hey Mr. First Party, you have a special exception" is very tied up into the site/* ISSUE-111 question
dsinger: We have an open question on how we convey these answers
rigo: DNT:0 on the first party is important in the EU. I don't believe we need an expression in the header. In the US the first party can just ignore this signal. In the EU it has a meaning.
<npdoty> dsinger: harmless to separate the two statements even if in some cases we won't need both
<jmayer> jmayer: Some jurisdictions may want to impose additional restrictions on first parties. We've gone to all this trouble to build a consent mechanism, why not support a first-party domain/first-party domain exception? If a jurisdiction decides it wants to attach a semantic to "DNT: 0" to the first party, so be it.
schunter: WWe have agreement that we want to be able to send DNT:0 to first parties.
... we now need to find out how to convey that.
tl: possible answers are header and APIs
<Zakim> npdoty, you wanted to note that even in the * case it's not-trivial (and we'll definitely have to figure that out)
dsinger: A first party can always call the API to find out about the status of its third parties
ifette: We have 3 options. 1. DNT1 and no exceptions. DNT1 and all third parties have exceptions. 3. DNT1 and some third parties have exceptions. A first party needs to know this before loading content. I don't want to do a roundtrip to find about about the third party status.
<schunter> Current proposal (on my slide):
<schunter> DNT;0 = You have a site-wide exception
WileyS: we have proposed a DNT2 signal indicating that you have a mixed state and need to find out
<schunter> DNT;1 = You don't;
<schunter> DNT;2 = some third party exeptions exist for your side (please poll if you like).
dsinger: I think we need to take this to an email discussion.
<ifette> ISSUE-111?
<trackbot> ISSUE-111 -- Signaling state/existence of site-specific exceptions -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/111
WileyS: Please respond to issue 111 on this matter. It is not yet covered.
dsinger: We also will create a new issue.
<ifette> Zakim_, what is the status of flight DL1539?
<aleecia> (thanks for the reminder that I need to check in... :-)
<npdoty> added to my to-do list for Zakim features
dsinger: Question 8 - API for web-wide exceptions.
schunter: one concern about this web wide APIs - if the user changes his mind the APIs might not always reflect the truth.
dsinger: If you given a web-wide exception - you will always see this in the response header.
... this gives the user more granularity than not enabling this API. though we might run into mixed signals.
jmayer: we have 3 possible API answers: 1 webwide, 2. not webwide, 3 webwide with exceptions
... Concern is - How do we convey this.
<npdoty> I don't have doubts in social networks building good features and granularity
<hwest> There are networks with these kinds of preferences now
<npdoty> just that some users are going to have their particular preferences
jmayer: if a social network wants to build it - great. But it's currently not done.
<jmayer> hwest, which networks?
<jmayer> Facebook lets a user opt out of instant personalization on all sites.
<rigo> +1 to tl
<jmayer> That's the only third-party control I'm aware of.
tl: An API does not bind your choice for all future.
<jmayer> Google lets a user opt out of +1 personalization on other sites and in ads on other sites.
<jmayer> Also not granular.
<ifette> ACTION: lowenthal to add an API to let a site request a web-wide exception [recorded in http://www.w3.org/2012/04/12-dnt-minutes.html#action10]
<trackbot> Created ACTION-177 - Add an API to let a site request a web-wide exception [on Thomas Lowenthal - due 2012-04-19].
dsinger: Back to the Question: we agree that we want the API to convey web wide exceptions
fielding: Would the response for a third party calling the API be true or false?
tl: Yes. (hope I got that right)
<npdoty> I think the out-of-band consent mechanisms (which I totally support having!) are not well-positioned for this particular granularity question
<npdoty> also, I'm really not trying to object to any concept of a Web-wide exception, just trying to explain the concerns we had that would be needed in such a proposal
<npdoty> action-172: vincent may be interested in helping
<trackbot> ACTION-172 Write up more detailed list of use cases for origin/origin exceptions notes added
<fielding> I meant that the *other* API, the one for asking if I have an exception on this page, will return true if there is a web-wide exception (no additional API needed on that front)
<npdoty> scribenick: npdoty
<aleecia> slides: http://www.w3.org/2011/tracking-protection/dc/finalDC-f2f.key.pdf
aleecia: have a better understanding of where we're going
... down to two primary proposals
... ideas from three other proposals
... want to get more people listed as authors
<cross-talk>
continue to use the standard of significant contributions of text
aleecia: some agreements
... agree on using meaningful interaction to handle first parties
... generally agree on what a third-party is
... third parties siloing data by party
... high level agreement on outsourcing
... agree on permitted uses (and the name! yay!)
... agree on unlinkable data
... agreement on some short time for raw server logs, still need to figure out the details
... disagree on permitted uses
... overview of the areas we disagree
... big vs small
<laughter about our use of photos, no offense intended>
aleecia: what I think I saw from FTC was the party size being small but the permitted uses are fairly broad
... and on the Article 29 side, not as worried about the party size, but more concerns about limiting permitted uses
rvaneijk: more concerned about permitted uses
... if these data flows contain unique identifiers, permitted uses won't pass compliance test in the EU
<will be pasted in to IRC, because scribe cannot capture the paragraph numbers, etc.>
rvaneijk: proposal
<scribe not capturing the proposal, rvaneijk should follow up>
<rvaneijk> Addressing permitted uses for 3rd parties:
<rvaneijk> When the status of a party is third party,
<rvaneijk> AND the third party does not have an exception,
<rvaneijk> AND the user has explicitly expressed to have DNT=1,
<rvaneijk> the permitted use descriptions for dataflows for 3rd parties enabled MUST not contain unique identifiers.
<rvaneijk> If these dataflows contain unique identifiers the 'Permitted uses in 4.4.1.1'
<rvaneijk> will not pass the compliance test in the EU.
<rvaneijk> The test is: strictly necessary to provide the service AND requested by the user.
<rvaneijk> Normative tekst:
<rvaneijk> A third party MUST take reasonable privacy safeguards (i.e. technical and organizational)
<rvaneijk> to prevent unique identifiers in dataflows when the third party does not have an exception, AND the user has
<rvaneijk> explicitly expressed to have DNT enabled.
rvaneijk: really hoping we can work on text regarding proportionality
wileys: agreed that if we add the appropriate non-normative text for proportionality, could be compliant
amyc: understand the concern on unique identifiers
... in addition to the cookie, the unique IP address would also count
rvaneijk: as we discussed yesterday, certain elements of the protocol are strictly necessary to set up and maintain the communication
... IP address is necessary for the communication and therefore strictly necessary
amyc: regardless of whether the unique identifier is the cookie or IP address, but the question of whether it's necessary during later uses
alex: a lot of talk about our being relevant to EU laws, will the EU reconsider laws or directive if we decide that a id cookie or something is acceptable?
rvaneijk: not representing the EU, representing Article 29, will do our best to give feedback
fielding: the unique identifier can be present if it's not collected
rvaneijk: that's why I say reasonable efforts to prevent the use, I hope that in a non-normative part we can make that more explicit
pde: services requested by the user seems to be particularly important
... when I load a newspaper page, am I also requesting the analytics and other services even if I don't realize?
rvaneijk: should be both necessary and requested by the user
... like the meaningful interaction thing we were talking about, that's specifically requested
... the necessary part is about enabling the communication
jmayer: collection vs. no-collection point, some user configures their browser or network adds an ID header to traffic
... some cases where there's no responsibility from the server
... why would you set a unique ID that you never log or you never use?
fielding: would only log a hash of it to a particular site, so that you can't correlate that activity across sites
questions about who can speak for whom
rvaneijk: unique identifiers must not be used, even when siloed per first party, yes
fielding: but if the use of it is necessary for a particular purpose?
<pde> (if the room will allow me a quip) fielding, it's great that companies have this practice, now Please Please Please just do the hashing on the client side when users send DNT:1, and we will all be happy
tl: we're having a detailed discussion of legal compliance, better put in the Global Considerations document
... we're talking about a voluntary system to do a particular thing with a particular preference
... we should expect the legal regimes to do the best thing for their citizens, may facilitate ways to comply with those legal regimes
ShaneW: art29wp side, if we add non-normative text narrowing down the use cases, we'll actually be in alignment, in the same ball park?
rvaneijk: will send a template for the non-normative text, work with Shane on that
ShaneW: re FTC, talked about user expectations and examples, examples may bridge the divide more cleanly
... descriptive guidance on how we might find a hybrid here
<rvaneijk> (proportionality and subsidiarity weight against the intrusion on user privacy)
<laughter about putting FTC folks on the spot representing the full commission>
rigo: shouldn't get in to legal discussions, but should decide if our stuff is useful in a certain surrounding
<rvaneijk> WP29 does care about party size, but discussion still has to be done on how big is a party.
aleecia: I think what we heard on the call last week is that the FTC can do tradeoffs, trading off larger party size for narrower uses
efelten: the FTC report did talk about some of these issues and I would refer you there
... if there's a lack of clarity, feel free to ask ed
... Julie Brill was here yesterday and talked about conversation and a process where not everyone will get everything they want
... I don't think the Commission feels they want to push this group to a single position, just strongly support this group moving towards consensus
aleecia: happy face!
... closed 59% now, including the issues we've opened even being here
... unified drafts on points of compliance
... Tom and Shane to discuss next week
if not done, invited to Aleecia's house for dinner
<scribe> ACTION: lowenthal to talk with Shane about an updated compliance proposal [recorded in http://www.w3.org/2012/04/12-dnt-minutes.html#action11]
<trackbot> Created ACTION-178 - Talk with Shane about an updated compliance proposal [on Thomas Lowenthal - due 2012-04-19].
aleecia: and there's an action open on Aleecia to present that to the full group
... sharpened where we are divided
... still need to do a response to the CG, though it might be lightweight
... some editorial work on readability
... Last Call means we're not taking more issues internally
... if you need more time to discuss internally, please start early
... are there new issues that we haven't thought about? we need to know those
... would prefer not to hold another f2f, but we are more effective in this format
... looking at a possible meeting end of June, more to come soon
... thanks for your participation and to schunter for his patience
no objections to closing this meeting early -- we'll be done by 3
<justin_> I can scribe if you need a break, npdoty
encouraged to continue discussing stuff, but the main group will be over
<scribe> scribenick: justin_
<fielding> FYI, scheduling, I plan on not being available during July and August due to sabbatical.
<npdoty> thank you justin_!
dsinger: outstanding questions: 2. how do we populate an manage the list for the site?
<hwest> Question, since I was not in the exception group - does the API have a full list of third parties?
Wileys: thought this had been resolved, but questions about to handle removal
<hwest> Or is this list the list of exceptions?
dsinger: let's take off-line until we see what APIs we need
<scribe> . . . new question: (3) What is the accountability for a site-wide exception?
<aleecia> heh, fail
WileyS: we should add non-normative text warning about risks about overly broad exception requests.
... use SHOULD and MAY language, but ultimately up to companies to convince consumers to grant
<npdoty> this sounds like a section for the Compliance doc, that the TPE doc can refer to
(crosstalk about who should draft action item)
WileyS working with ninja and npdoty to develop text
Wileys: Is working group OK with this being non-normative?
tl: I'm comfortable with that too
<npdoty> ACTION: wiley to draft section on seriousness of the request for a user-granted exception (with ninja) [recorded in http://www.w3.org/2012/04/12-dnt-minutes.html#action12]
<trackbot> Created ACTION-179 - Draft section on seriousness of the request for a user-granted exception (with ninja) [on Shane Wiley - due 2012-04-19].
tl: companies are taking brand responsibility in the requests they make
... consumers can make their decisions based on trustworthiness
<npdoty> action-179: nick may also be interested in drafting
<trackbot> ACTION-179 Draft section on seriousness of the request for a user-granted exception (with ninja) notes added
<JC> p?
<aleecia> JC is helping us mind our p's and q's
rigo: giving the first party responsibility for the constellation of third parties is very common law approach
... you can't convey liability to first parties for third party behavior in this spec
dsinger: stick to question --- OK just to have non-normative text?
<hwest> A note on this language: we will likely need to tweak it based on the outcome of the exception discussions
jmayer: agree non-normative text is fine, but want to be clear about implications
<hwest> (i.e., if we don't have granular exceptions)
jmayer: some had been under impression that site-wide exception implied a legal representation on the part of the first party
... admitted, there are still non-legal incentives in place . . .
... difference in understanding my change people's opinions
WileyS: non-normative text should be clear that it doesn't affect liability
hwest: like the language, but it will need to be tweaked based on what sort of user-granted exceptions we end up allowing
<npdoty> there's no proposal where we don't have site-wide exceptions, so this text will always be necessary, right?
dsinger: one last issue: Who asks for permission, and how, if a third party doesn't have a script presence?
WileyS: This is a web-wide exception ('cause it's a third party).
... The answer is the NAI/DAA website in reverse. First-party provides a laundry list of third parties you want to ask for permission for.
... user would then pick the ones she's fine granting permission for
tl: partially agree with Shane, but not sure it needs to be that complicated
<rigo> everything that is simpler than what Shane just depicted would be better
<rigo> but we need a possibility to ask for permission
<npdoty> "effective script origin", yeah?
WileyS: yes it does, because we've agreed on origin restrictions
<schunter> Can a pixel/image start a redirect (using a header) to then load html with Javascript?
dsinger: first-party has to initiate it somehow
<npdoty> does this satisfy alex's use case?
alex: my concern with that approach:
... in this case, I have no real estate on the page, and no business relationship with the first-party
everyone: then what are you doing there?
alex: here's the use case
... if there are two first parties and we want to measure both of them . . .
schunter: <obscured by voices in the hall>
alex: today's model has to adapt for the things we want to do
<npdoty> schunter: can a pixel re-direct to load a script? --- sounds like: no.
<schunter> schunter said: TrackingPixeler needs relationship with someone who has a someonw who is able to load HTML on the page,.
jmayer: this is super-trivial, can change your practices very easy
tl: +1 to jmayer
<aleecia> action-120?
<trackbot> ACTION-120 -- Alexandros Deliyannis to write a proposal on web-wide exception API (for ISSUE-113) (with npdoty) -- due 2012-04-04 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/120
dsinger: relaxing x-origin restrictions probably not worth it for your problem
<jmayer> To be precise, you can just use an iframe instead of an img.
alex: I have suggested text on this issue, action-120
<npdoty> alex, I think maybe we can talk about different mechanisms that user agents could use to make a decision
<jmayer> If the iframe gets DNT: 0, do the same tracking you would do with the img.
<jmayer> If the iframe gets DNT: 1, return HTML with script in, request an exception.
tl: we've already worked this out, I strongly object to a new parallel technique for those who don't want to embed a script
<aleecia> queue closed.
<hwest> A response - why would we be encouraging more people to use more scripts?
dsinger: and you shouldn't have the authority to follow the user
<jmayer> hwest, this is a one-time exception request script in an iframe.
<hwest> (Or more specifically, do we want to open that particular pandora's box?)
dsinger: that was the last issue --- all done here!
<jmayer> It's sandboxed from the main page.
<hwest> jmayer, I don't think that works
<jmayer> hwest, is that a technical claim?
<npdoty> thanks to dsinger for leading us through all of these!
schunter: I'm going to do something nasty. Going through raised issues list and see if that raises any new ones
<hwest> Or at least you can't just do the iframe when you need the request
npdoty: W3C likes logos for high-profile works. We did this with HTML5 recently.
<fielding> Alex's proposal is at http://www.w3.org/mid/2DB61344-AB42-4533-9763-39F348479222@nielsen.com
npdoty: our PR guy wants me to develop an image for this process.
wseltzer: <displays snazzy HTML5 shield>
dsinger: this brings up issues of messaging to users
... this is a conversation we can have offline
<jmayer> iDNT
<npdoty> dsinger: I've talked to hwest about having a conversation (with users and research and so on) about text presented to the user, etc.
schunter: just one raised issue left
<fielding> see link above
schunter: it's ISSUE-137: Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s)
<ShaneW> Suggested Title: Web-Wide Exception Well Known URI
schunter: will leave this as open issue
<ShaneW> Alex, All yours now :-) ISSUE-138
dsinger: Can we reserve and say that "extensions are currently reserved"?
fielding: this issue isn't ripe yet
dsinger: don't want the question to get lost in the future
<amyc> or do we just delete any language about extensions?
<amyc> from current spec?
action item created for dsinger
<aleecia> (also on actions, we still have Tracking Preference Expression (DNT) and could drop the (DNT) at some point)
schunter: anything else?
... thank you very much, <gavel>
<npdoty> <applause all around>
<npdoty> schunter: amazed how much progress we can make during the f2f's
schunter: hopeful this can be resolved without another f2f
... but will get back to you about new venue shortly!
... adjourned
<aleecia> thank you to MSFT!
<wseltzer> +1 on the thanks!
<dsinger> Summary of notes on exceptions/API questions [via email]:
<dsinger> 1. Can third-parties call the API? Yes, if you have a presence on the page. Editors to check.
<dsinger> 2. How do we populate and manage the list for the site?
<dsinger> 3. What is the accountability for a site-wide exception? ACTION: Shane with Ninja and Nick to write non-normative text.
<dsinger> 4. Can the API be used to "remove"? YES, action on TL
<dsinger> 5. Nielsen issue: who asks, and how, if a 3rd party does not have a script presence? Mailing list discussion.
<dsinger> 6. Transparency: how does the user find out the status? The UA can keep whatever records/logs/databases/UIs it likes.
<dsinger> 7. How does one send DNT:0 to the first party? Open issue: How do we convey the DNT-permission status of the first party itself, AND the permission-status of its 3rd parties.
<dsinger> 8. Can the API be used for web-wide exceptions? Yes. Action on TL.