See also: IRC log
<npdoty> scribenick: npdoty
schunter: today the topic will change, a lot
... look at protocol messages between the browser and the server
... TPE doc, edited by fielding and dsinger
... since everyone has read and memorized the spec, we can jump right into it ;)
... quick intro / tutorial, clarifying questions only please
... look at the spec, unresolved issues, and a few areas to discuss (user-granted exception, server responses, non-compliant UAs)
<aleecia> (Nick, thank you. We'll make sure we get scribes for the rest of the day)
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
What is the Tracking Preference Expression about?
1. Communicating a user preference (request headers) -- largely stable
2. Communicating a tracking status (response header and URI) -- stable idea, details have been drafted
3. User-Granted Exceptions (JS API + out-of-band mechanisms)
schunter: at this point, we still agree -- today a day of agreement
... unset by default (no headers sent at all), as an initial state
... user can switch DNT to 1 or 0, on or off
... changing the state represents the preference of the user
... interacted with the user and confident of their preference, can change the state and reflect it in the headers
... a general purpose tool shouldn't be shipped with a fixed [?] preference
... for a site, it's important that when a site receives the signal, it's an expression of the user rather than an intermediary
... at the user's discretion, can change between these three states?
craig: you said "general purpose tool", can you clarify distinction from a privacy-specific tool?
schunter: we don't say how the user preference is collected. but for a tool that just turns on Do Not Track, just installing it can turn on DNT:1
... some gray areas, like an anti-virus tool, is that primarily a privacy tool? I would say no
aleecia: exact language here may change in the Compliance spec, but schunter has captured the idea
byran: the user also has the option to switch back to unset, right? -- yes.
rigo: rather than "on" and "off" (DNT:0 being explicit means something other than just "off")
<aleecia> Suggest Roy/David change from "on" "off" in the spec to "1 is set" or "0 is set"
felten: just call them "1" and "0"
<aleecia> Suggest Heather/Justin/Sean do a pass through as well
schunter: I agree, shouldn't just use "off"
... we consider all the inputs and then make a decision
<aleecia> We will write nice letters to reply to the comments
schunter: these inputs are very valuable (including letters from governmental actors) but may or may not change the spec
<aleecia> And thank them for their interest
<fielding> action item on fielding to change text around DNT on/off
<trackbot> Sorry, couldn't find user - item
schunter: the compromise was, rather than 1 or 0, to ship with no setting by default
<fielding> action on fielding to change text around DNT on/off
<trackbot> Sorry, couldn't find user - on
<scribe> ACTION: fielding to change text around DNT "on"/"off"/ [recorded in http://www.w3.org/2012/06/22-dnt-minutes.html#action01]
<trackbot> Created ACTION-217 - Change text around DNT "on"/"off"/ [on Roy Fielding - due 2012-06-29].
<aleecia> Open issue on language there in compliance spec
<aleecia> We'll work it through.
Chris_IAB: depends what you mean by "confident" when determining the user's preference with confidence
<aleecia> That had been on the agenda for Tuesday, but we didn't get through half the things I hoped to take on.
schunter: has to be an expression of preference by a user, rather than a tool provider
Chris_IAB: in that case, need to define "explicit"
<CraigSpiezle> user interation, but also respect an orgnization (company, govt agency) who may set it 1 or 2 by default
<CraigSpiezle> q
jchester: you're not suggesting that the spec would punish a browser vendor that wanted to develop a tool with privacy-by-design
CraigSpiezle: there are situations where companies or government agencies might configure settings for their employees
tl: should read into the spec on that
<returning to the overview>
schunter: site responses
... to what extent and how does it honor DNT:1, or it can request an exception
... double arrow because it might be some kind of negotiation, multiple messages
... some other information, we'll look at the fields later in more detail
amyc: interaction between response header and well-known URI -- we'll discuss later.
<aleecia> For new(er) folks, the spec we are discussing right now is fairly well baked. I strongly suggest reading it. If things don't make sense to you, please speak up: it needs to be readable by many types of people.
schunter: a site might also want to ask for an exception
... have a JavaScript API including:
... Web-wide, like a social networking widget
... site-wide, all resources on this site should have an exception
... explicit, site can specify which domains to request an exception
... some discussion on the "explicit" piece, concern that with hundreds of parties it wouldn't be meaningful to a user
<aleecia> If you are an observer, haven't had time to read the spec, and have a question, you might find it productive to put it in IRC. Someone can answer you here without derailing the rest of the discussion -- or tell you we do not yet have an answer and we should discuss more
@@: we're not envisioning that a third-party can call the API itself, are we?
schunter: any resource could make this request as is.
ChrisPedigo: I have a problem with that, our members don't want lots of pop-ups to appear on their site
tl: can do it, but it wouldn't be a good idea
Chapell: third party companies would just be shut down, publishers would stop it within an hour, or certainly that day
npd: I thought we had an agreement that we would prohibit 3rd-parties calling the API, even though they could via JS
schunter: volunteers to scribe, to replace nick?
<aleecia> thank you, Alan
<scribe> scribenick: Chapell
<npdoty> "I'm a rarity in this group that I only speak when I have something to say" --unattributed
<aleecia> Nick, how do we tell Zakim we are dnt?
placing diagrams into the spec can be helpful
<aleecia> and that Alan is scribing?
looking for input from group(?)
<npdoty> scribenick: Chapell
issue 112 - site specific exceptions
<npdoty> 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
need volunteers for proposals
nick volunteers for issue 112 proposal
roy: right now sub-domains are not included in the exception. and they should be included (if we have exceptions at all)
Ian: we all have other subdomains mail.google.com
... ICANN complicates things --
... fully qualified domain names
<npdoty> ifette: I prefer we use origin (that is scheme, host, port)
<hober> hober: alternative to using origin is to rely on the public suffix list ( http://publicsuffix.org )
<CraigSpiezle> concern on abuse on 3P exceptiions and how it could be both abused and create conflict with publishers. Perhaps the spec state that 3P Must not not ask for exceptions, without the approval of the 1P site.
TLR: concern about over engineering this piece
<npdoty> tlr: safest and simplest granularity is do this by origin
TLR: keep it simple, stick to concepts that work elsewhere and stick with origns
<npdoty> lots of people like origins?
Adrianba: Agrees with Ian and TL: start simple and enhance as needed in the future
Nick will create proposal around origins
<aleecia> issue-116?
<trackbot> ISSUE-116 -- How can we build a JS DOM property which doesn't allow inline JS to receive mixed signals? -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/116
<npdoty> ACTION: doty to write up proposal on issue-112 that we do exceptions based on origin [recorded in http://www.w3.org/2012/06/22-dnt-minutes.html#action02]
<trackbot> Created ACTION-218 - Write up proposal on issue-112 that we do exceptions based on origin [on Nick Doty - due 2012-06-29].
<npdoty> issue-116, action-180, my proposal: http://lists.w3.org/Archives/Public/public-tracking/2012May/0313.html
<jmayer> My suggestion was the cookie approach that allows for optionally including subdomains (e.g. google.com vs. .google.com).
<fielding> I am not aware of any outstanding text to be added -- perhaps David Singer is handling the JS API text
Brooks: re: 144 hard to discuss what a user agent should do unless we define what a User agent is
<WileyS> 143 is missing - we decided it should be placed on the list
<npdoty> Brooks, is there anything particular in issue-144 that would behave differently for a different definition of UA?
LT: User agent was defined on day 2 - if we want to revisit, we should (but only if the current definition is breaking things)
<hober> Our current definition of UA is http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#terminology
Aleecia: there are many things that are not UA that do change settings - which may impact the definition and rule set
<felten> Doesn't that definition come directly from the HTTP standard?
<aleecia> Yes, yes it does
Shane: Missing Issue 143 -- we had agreed to adress in TPE (re: whomever sets DNT 1 flag identifies in the header request)
<hober> ISSUE-143?
<trackbot> ISSUE-143 -- Activating a Tracking Preference must require explicit, informed consent from a user -- raised
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/143
Roy: current definition might be insufficient -- its not a UA issue, its an add on issue (issue 143)
<Brooks> avg is not a plugin and can't be a UA
<aleecia> this is the issue I want to discuss before 143
<aleecia> I think it will simplify a few things to talk about that first
<felten> Brooks, why do you say AVG does not use an add-on?
Rigo: if we want DNT to be a US tool as well as a worldwide tool, it must be able to handle exceptions as a consent mechanism
<npdoty> fielding, do we have a separate issue around extensions/add-ons?
<fielding> npdoty, it is the AVG issue IIRC
<Brooks> let me rephrase... it doesn't have to. There are many ways (notepad included) of changing a FF config file to enable DNT that wouldn't meet the definition of UA
matthias: currently, anyone may request an exception for anyone else
<npdoty> rigo is talking about issue-151
matthias: the marketplace will sort this issue out (Re: 151)
<hober> ISSUE-151?
<trackbot> ISSUE-151 -- User Agent Requirement: Be able to handle an exception request -- raised
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/151
<aleecia> Brooks, Rigo made an interesting suggestion in issue-151, which was that we limit UAs to only those that can accept exceptions
<npdoty> fielding, I see 153 that we recently raised, but don't know which issue is the "AVG issue"
<fielding> yes, 153 is the new (more specific issue)
<rigo> you can fix the AVG issue with resolving issue-151
matthias: 3 step structure
<aleecia> That would change the Notepad issue iff we talk through Rigo's proposal and adopt it
<fielding> I was thinking of 149
<npdoty> rigo, depending on how we resolve 151
<aleecia> We should talk through that and see where we are before we get much further along in other issues
<aleecia> (again, one of the things that I thought we'd get to on Tuesday)
<Brooks> So if we take Rigo's change what limitiations does this place on non-UAs? none?
matthias: 1. Well known URL (WKL), 2. [maybe] + header, and 3. [Maybe] + further informaiton
<rigo> if the AVG plugin integrates well in a browser that is able to handle the exception mechanism, fine. If the only thing it can do is sending DNT:1 then not fine
<aleecia> Note that we have not talked this through. We may or may not adopt Rigo's proposal. But we should know which way we're going before we open up the rest, since it changes the discussion quite a bit (potentially)
TL: User agent must hit the well known URI requesting a site - if response includes no header, you are done
<npdoty> rigo, I don't think we should add such a requirement, although I expect most users to have user agents with exception-handling mechanisms
<aleecia> we'll talk it through
<tl> Not quite what I said.
TL: can you rephrase?
<aleecia> we have two choices, no doubt there will be at least three opinions :-)
<Brooks> very good. glad you see the potential scope of the complication
<tl> tl: there are required fields, and the UA would only know that they are missing after going through all three steps (if applicable).
<vincent> npdoty, I think a way to handle exception might be to refuse (or accept ) them systematically
<vincent> in such case that might be a very lightweight requriement
Roy: these requests are only made by a client looking to know about tracking status - many clients will not need to go through these steps
Group agrees
<rigo> npdoty: :) it would be more enlightening, if you could tell why such a requirement would be harmful. Harmful to what and harmful to whom?
<aleecia> we'll talk it through
<aleecia> we're not going to figure it out in IRC right now
<aleecia> what I was aiming for was to explain the order of issues we'll be talking about
<Zakim> npdoty, you wanted to ask whether all servers can always determine the status via URI
matthias: need to discuss what happens when you get the request via all three mechanism?
<jeffwilson> q
matthias: Roy says Posting all info on the well known URL solves this issue. Ian may disagree
<aleecia> jeff, you may want q+ or q?
TL: Need to add a component to the root well known URL
<felten> You can add yourself to the queue by saying q+
Roy: There is already a way to indicate that there is no need for further headers
<npdoty> just to clarify, do we need to explicitly say that the "more information" header overrides the root URI status?
disagreement between Roy and TL on approach
JeffW: What is the user agent to rely upon?
TL: The most recent message they receive
<npdoty> tl: have we eliminated the path-based URIs? fielding: yes. tl: done.
<aleecia> best summary yet
matthias: keep it simple: the only thing that needs to be communicated is- I'm a "XXX" party and I comply with the spec
<npdoty> fielding, are we sure that path-based URIs are gone? "A user agent may check the tracking status for a given resource URI by making a retrieval request for the well-known address /.well-known/dnt relative to that URI."
Amy: For those who might be a first party or third party, can they simply say "if i'm a first party, I'll do XX and if I'm a 3rd party, I'll do YYY?
<fielding> npdoty, that is relateive to the real request URI
<fielding> i.e, same domain for absolute path
matthias: seperate distinction and communication needed for times when acting as 1st party vs 3rd party
<npdoty> fielding, right, does a browser that wants to do verification load /.well-known/dnt/rest/of/path? what about those servers that aren't using that technique, but need to use headers to specific more information policies? /cc tl
matthias: this allows the user agent to detect a first party element in the middle of the page
Ifette: will matthias' suggestion enable a cheap way of conducting third party content blocking?
TL: Isn't already easy to do third party content blocking?
Roy: it can dynamically switch
... The resopnse comes back from the server - the server rarely has control of how the individual page elements exist on the page
... The intention here is allow Google to say "because I know this request comes from Google, then I know its a first party"
... Conversely, when I know its not from an embedded request on a Google site, then I know i need to adhere to the 3rd party rules
<npdoty> ifette, does fielding's last comment address your concern? you couldn't correctly figure out by resource whether a URI is reliably a 3rd-party
Rigo: this is too compliacated. We already have the possibility to declare. Take it outside, folks (:
TL / Ifette to discuss later - but not in the spec
<npdoty> schunter: "naturally, everybody is free to discuss whatever they like"
not necessarily in the spec
Next Issue -- Data Transmitted Via URL
<tl> tl & ifette agree not to discuss it later.
What data should be conveyed by servers?
<npdoty> "p" currently indicates "prior consent", but I think in the compliance doc we refer to "out-of-band consent"
<aleecia> We will certainly need an editing pass to get it all uniform
<aleecia> One plan: the editors will swap documents for an editing pass
TL: what goes in the tracking status field? No changes to tracking status field
matthias: wants to make a sub-group to discuss later
RobSherman: we should figure out the right wording. Tracking / Not-Tracking is problematic
TL: response will be "true" those who don't collect any data may return as "false"
matthias: need a sub-group to iron our disagreements
Brooks: Does control have a different meaning in a 1st party vs a 3rd party context? TL: Yes
<Zakim> npdoty, you wanted to ask whether first/third party is required by the current language
TL: why delegate to a sub-group when we could just discuss this now?
<amyc> Thinks Brooks also asked whether same party principles applied to both first and third parties, and matthias answer was yes
matthias: first, a smaller group an reach consensu better... second, we may want two subgroups
<npdoty> <discussion of Solomon and splitting people>
<aleecia> +1
<npdoty> fielding: 1/3 is optional only because you might not be tracking at all. npdoty: so 1/3 is required if the first character is "t". fielding: yes.
Next Issue: Data Minimization Survey
<aleecia> (I agree with TL that we had consensus around Ninja's text, but readily admit I do not follow TPE issues as closely as Compliance. However, I thought we had this done. And we probably should use a different word other than "tracking" since that's not capturing the idea)
Fieds: Mandatory -- I like I can't live with I can't live without
TL: Likes all of these fields - maybe we add audit field and others down the road
Shane and TL agree - next, the Cubs win the series
<aleecia> So close
<Joanne> +1 to optional audit field
<npdoty> +1 on audit/auditors
<aleecia> +1
<aleecia> We had agreed it would be an array of URIs
Rigo: believes its vital to have a pointer to a P3P
<jmayer> Yep. Haven't heard any objection to an optional audit field.
<npdoty> not sure Rigo was saying it was vital, just that it would be nice to have an optional field for pointing to a P3P policy
Shane: we are discussing the elements, but not the specifics of what goes into each field
<Joanne> how about a optional pointer to a machine readable policy tather than perscribing that it be P3P policy
Rigo: Doesn't like header + code being optional
<fielding> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#status-representation
<fielding> "The content of such a policy document is beyond the scope of this protocol and only supplemental to what is described by this machine-readable tracking status representation. "
<jmayer> The policy field is intended as a pointer to a human-readable policy, not a P3P policy.
matthias: anything missing from the list?
<npdoty> fielding, rigo, does "supplementable" mean that it doesn't contradict?
Aleecia: an optional audit field would be helpful
<npdoty> any objections to an audit field?
<aleecia> Awesome
<npdoty> no objections to the audit field.
<aleecia> Resolved: Roy to add audit field as an optional multiple URI field
<fielding> action on fielding to add audit field
<trackbot> Sorry, couldn't find user - on
<Chapell_> Truste pinky swears us that this won't create additional complications and uncertainty in the marketplace (:
<rigo> for the record, I'm opposed to the policy field as it may contradict. At least we should have language that it can't contradict the semantics of the compliance specification
<Joanne> :)
<npdoty> ACTION: fielding to add optional audit field array [recorded in http://www.w3.org/2012/06/22-dnt-minutes.html#action03]
<trackbot> Created ACTION-219 - Add optional audit field array [on Roy Fielding - due 2012-06-29].
<fielding> rigo, the language is already in the spec and quoted above
<aleecia> I don't wish to kill puppies. We're fine.
<rigo> fielding: I'm scrolling and scrolling and not finding
Next Issue: User-granted Exceptions
<npdoty> I think rigo wants to make it clear that having sent a link to the policy in the response status does not imply that the user agent has accepted all the details of that policy (which could even contradict other claims about DNT)
<fielding> 10:28am
<npdoty> "The content of such a policy document is beyond the scope of this protocol and only supplemental to what is described by this machine-readable tracking status representation." rigo, fielding is talking about this sentence in the optional field's paragraph.
Agreement to allow site-wide and web-wide exceptions
Any opposed?
TL: Top bullet point should be conditional on the bottom bullet
<rigo> ok, but why should we mandate "human readable" could be also a P3P policy. Just say URI
<npdoty> tl: we should have site-wide exceptions only if we also have site/site exceptions
Roy: Doesn't see a need for an exception framework
<rigo> and "supplemental" is not really the semantics we mean
<hwest> Exception framework accomplishes different and helpful things that OOBC doesn't
Roy: Wants sites to keep their existing consent mechansisms
<hwest> Much easier for users, as long as we use exceptions that can be UI-d well
<jmayer> How about we reserve the EU compliance discussion for later?
<jmayer> The question here is which forms of exception we'll allow.
Roy: Sites don't trust browsers, so having a browser manage your legally required consent mechanism is problematic
... Sites will have to use cookies anyway
<rigo> I think it must state that "in case of conflict, the DNT-header semantics will prevail".
Roy: The exception mechanism provides very little value to site owners and adds some complications
Jmayer: What is topic? EU compliance or Exception framework?
... Deal with EU later.....
... don't constrain browsers or sites - give options
HWest: having this programatic browser based mgt tool will be helpful -
... having exceptions will be helpful with implimentation and user experience
<jmayer> Google doesn't think it can present a good explicit/explicit UI, Mozilla does. Why constrain browser UI innovation with the API?
Rigo: How do you revert user consent without providing multiple channels
<hwest> Because it expands complexity for other entities for no good reason
Roy: If this implementation adds six months to process, then that is bad - and there are no implementations of this features yet
<aleecia> going once...
<aleecia> going twice...
<aleecia> close queue
Adrianba: sympathetic to Roy's position. Many pubs would not want this generated on their pages. There would be a need for 1st and 3rd parties to agree. Also questions whether there will be demand.
... if we agree that the mechanism should be provided, then lets start simply and add more sophistication later if required
<npdoty> thx WileyS for as expected making my arguments redundant
Shane: Without exceptions, this moves us to an out-of band consent world. this provides users with a centralized place to make their choices
... re: Eprivacy.... The consent bound with site-wide or web-wide COULD meet eprivacy
DWainberg: Durability of user choice is imporant. Choice to allow tracking should also be durable. Having this in there will help implementability.
... The idea that we leave out important parts of this spec based upon time is problematic: better to get it right than to do it fast
Ifette: Not sure how one does out-of band consent in a safari browser that blocks 3rd party cookies
Roy: In Safari, first party may pass to third parties
Ifette: However, thatt still makes web wide exceptions impossible in Safari
<npdoty> it would also be a pain for first parties to always have to relay on remembered out-of-band consent to each third party
<npdoty> BerinSzoka: lowers transaction costs for negotiating and remembering/managing
Berin: With significant adoption of DNT: User preferences may actually be frustrated without exceptions. Without a tool, you create a mechanism that significantly changes the equilibrium in the ecosystem
... If the point of DNT is to enable privacy choices, why not spend time on this?
JMayer: alot of the concern has been with the alignment of EU law.
<npdoty> is there anyone other than fielding that wants to drop exceptions altogether? can fielding live with the exception mechanism?
matthias: anyone violently oppose the API?
Roy: Doesn't like it, and not sure he can live with Expicit-Explicit pairs.... next topic
<npdoty> I agree that it's easy. :)
<jmayer> My point: The API could allow for plain-text explanation and a read more link. That would facilitate EU law compliance.
<npdoty> jmayer, yes, we already have those optional parameters in the API
matthias: enumerate all parties on the site.
... a first party may not know all the parties on the site
<aleecia> side conversations are becoming problematic... there are side rooms around us if you want to step out for five minutes
JMayer: is this the same proposal re: taking a snapshot? matthias: YES
NDoty: What is the intent of the partners field? All partners or only partners needed an exception?
<jmayer> As David Singer and I explained on the mailing list, this seems a counter-intuitive, difficult-to-deploy version of an explicit-explicit exception API.
<rigo> I don't understand. Just declare nothing and then its site wide
Ndoty: not sure this solves the problem
matthias: If User has consented to say, 3 parties, NEW parties are not lincluded
<npdoty> as I understand it, it's always site-wide, it's always an explicit list of every party or an implicit list of every party
Adrianba: How do I get additional third parties into the exception?
<npdoty> but you still don't have the advantage of being able to ask for a subset of parties, and now you have the complexity of updates to the partner list
<amyc> how does "delegate further" work -- would this be as service provider
matthias: Need to call the API repeatedly so the User Agent can say that the number of partners has changed
<npdoty> I think we should also be concerned about "delegate further" if you can just re-direct to a potentially limitless number of other parties
<vinay_> Amy - I believe its the transitive party. So, if I get consent for AppNexus since that's the party the site contracts with, the consent is transferred over to the ad networks serving ads thru AppNexus
TL: This doesn't give users the info that they need? I don't know which 3rd parties I'm giving consent to track me
<vinay_> Which is why I don't think this actually helps consumers
Roy: Its not reasonable to require java script API's to make all of this information -- its more efficient for the java scrtip to KNOW what partners are on its list
... Its not reasonable to require java script API's to make all of this information -- its more efficient for the java scrtip to KNOW what partners are on its list
<npdoty> fielding: had removed the list of partners from the spec because I don't want JavaScript APIs to require initiating another HTTP request
IFette: the pointer to the list of parties was helpful for auditing from regulators and others
<npdoty> the same as a site-wide exception in that it simply is a site-wide exception
<Joanne> can consent be delegated to the first party?
matthias: by putting this info in the partners space, you can have user agent innovations
Rigo: May want to descriminate against certain third parties.
JeffChester: Agrees with TL. Users need to know who the partners are. And if they have said they don't want to be tracked by XXX, then we need to accomodate this
JMayer: This is optional API with a strange design --- low implimentation.
<npdoty> jchester: need to know who wins the bid in an ad exchange for example, who's actually tracking them
matthias: Who objects to Explicit / Explicit?
TL: Doesn't like E/E design
<npdoty> scribing has just missed something
<jmayer> My proposal: let's discuss an (optional?) explicit-explicit JS API instead of this weird, backwards design.
<aleecia> I can cut off the queue but not my co-chair
<npdoty> schunter: who objects to this particular handling/implementation of explicit exceptions?
<npdoty> tl: don't like this design.
<aleecia> tl, +1
<jmayer> I think this technical design is *really* bad.
<rigo> jeff, how can you know who takes the market in a bid? You can't know who will take the market. Having all partners known beforehand is just not possible with auctions. So it would just prohibit auctions
<rigo> and the smart alternative is to make those responsible who create the legal framework for those auction systems
<rigo> and cater to the system
<rigo> aka the third parties directly contacted
<npdoty> continue in large group after the break
<jmayer> Asking browsers to snapshot a JSON resource and handle versioning on it = lolwut.
<npdoty> <welcome back from break>
<npdoty> schunter: some people continued this discussion, perhaps with a proposed solution
<npdoty> scribenick: jmayer
<npdoty> sidstamm to back up
<aleecia> tl, two use cases for explicit, explicit can be solved:
<aleecia> tl, partners field in URI avail to UA
<fielding> in resource
tl: two challenges
<aleecia> ..., 2nd, if want DNT:1 nearly all the time but send DNT:0 except for evil corp
tl: 1) transparency in third parties
... accomplish with partners field
... 2) exceptions to site-wide exceptions (e.g. all ok but EvilCorp)
... "i accept your exception except"
<fielding> and by that tl means that evilcorp will continue to receive DNT:1
<sidstamm> jmayer: few different cases where explicit-explicit might be involved
<aleecia> we will really need to find a way to figure out how to talk about this that isn't just insane
<sidstamm> ... transparency about third parties, exceptions to site-wide, and a third use-case
<sidstamm> ... what about when a first party wants to request exceptions for third parties (a subset of third parties on their site)
<sidstamm> matthias: clarify, please, in your proposal do you allow UAs to snapshot partners list or can they ignore?
<sidstamm> tl: partners list is informational
tl: in my proposal, the partners list is optional
<npdoty> aleecia, this doesn't feel insane to me
tl: user agents doesn't have to look at list of partners
... but if it wants to, it can
<susanisrael> Is the site responsible for passing that preference to evilcorp or does evilcorp receive it directly?
<aleecia> no it's not, but talking about exceptions to exceptions is non-trivial for comprehension. We'll need better wording is all
matthias: would like to include language calling out that UAs can use the partner info
tl: I don't think we need to specify it
matthias: <disagrees with tl>
... want to see language about how UA may downscope exception (i.e. send DNT: 0 to certain sites)
<npdoty> susanisrael, in all of these exception examples so far, the signal is sent directly on each request (e.g. directly to evilcorp)
<susanisrael> nick, thanks
tl: why do we need language on browser innovation?
dwainberg: how does the browser implement something like an exclusion list?
tl: up to user agent, user choice
<npdoty> tl: could share lists, or otherwise configure your browser
dwainberg: what if a third party wants ask the user for consent?
matthias: it can ask for out-of-band consent
dwainberg: concerned with how this works
matthias: can ask the API again, too
tl: it's the user's choice, a site can ask politely
<npdoty> dwainberg: how can a third party ask the user to re-consider their opt-out determination
jmayer: sounds like there's not agreement on explicit "MAY" language about browsers downscoping site-wide exceptions
... but there's substance agreement
... but we've backed ourselves into a "super-jankety" explicit-explicit api
... might make sense to have an explicit-explicit api that's optional for UAs
<scribe> scribenick: jmayer
tl: did you just volunteer to write this matthias?
matthias: sure, i'll capture the view
egrant: many companies operate services that are both first party and third party
tl: follow the rules
... about first party and third party sharing
<npdoty> ACTION: mschunte2 to write up tl/matthias sub-group agreement on exception approach [recorded in http://www.w3.org/2012/06/22-dnt-minutes.html#action04]
<trackbot> Created ACTION-220 - Write up tl/matthias sub-group agreement on exception approach [on matthias Schunter - due 2012-06-29].
WileyS: Understand how user agent might be configured to auto-reject certain exception requests.
... How would the flow for exceptions work?
tl: Use the existing APIs.
ifette: Not as bad as Shane says. In a site-wide exception response, there might be some exclusions. Get to decide how to respond to that. Might not care (e.g. social widget), might care and message the user, do things.
WileyS: What about when a user overrides with an out-of-band consent?
tl: Same, again.
WileyS: Makes life harder for first parties, can't just look at DNT header
matthias: Have to do careful reasoning about third parties with/without exceptions anyways.
<npdoty> I think we may need to help WileyS whether we have these web-wide opt-outs or not
wheeler: What happens when there's a site-wide exception?
tl: They don't have to comply with the restrictions of DNT.
jmayer: not discusing whether first party can get exceptions for third parties, rather we're discussing whether or not all third parties on the site need to get exceptions
... the question is, can we select which third parties get exceptions
<scribe> scribenick: jmayer
matthias: moving on to out-of-band consent
... question is, should we have a dedicated mechnism for storing out-of-band consent in the browser?
<npdoty> ACTION: mayer to draft optional version of explicit/explicit exception api [recorded in http://www.w3.org/2012/06/22-dnt-minutes.html#action05]
<trackbot> Created ACTION-221 - Draft optional version of explicit/explicit exception api [on Jonathan Mayer - due 2012-06-29].
matthias: idea: javascript api that a site can use to flag out-of-band consent
tl: isn't this covered in the response header?
ifette: Good to be able to store out-of-band consent in the browser because of third-party cookie blocking (?). But let's suppose there's a place to edit the out-of-band consent. How does the site make sure it's getting the latest, correct version?
tl: If content is removed from storage, the site knows, right?
<fielding> This would be an in-band way to store out-of-band consent?
ifette: Setting up potential for conflict.
matthias: If out-of-band is in browser, you get DNT: 0.
rigo: <???>
ifette, once again, potential for conflicts
rigo: no, there's a misunderstanding, an out-of-band answer is a contract independent of DNT, this is just convenience in the browser
... change in storage doesn't change legal implications
<WileyS> Roy, yes - allows the Server as a tool to store perhaps a broader permission consent and/or control the UI for consent flow
matthias: think rigo is saying this is about independent mechanism overriding other mechanisms
<general confusion>
tl: If there's an out-of-band exception, why store it?
<WileyS> Ian, good idea - that can work
dwainberg: This isn't a control mechanism, it's a storage mechanism.
matthias: Purely informational for the user agent.
tl: If that's what it is, why implement it?
<sidstamm> scribenick: sidstamm
jmayer: so practiaclly, you get the storage, but the browser doesn't intermediate the ui
... I thought the point was that the UI in the browser was consistent and provided a central point of control
... and that the UA makers could pick UI that are best for the users
... prefers if the browser UI was for intermediating
<jmayer> scribenick: jmayer
WileyS: The alternative is harmful to the user.
... If the browser has a bad user interface, won't use it.
<aleecia> tl
<rigo> the storage of out of band consent in the browser is only positive. It allows the storage of all the consents a user has and an overview of all that information, may be even store a URI where one can manage the out of band consent
<npdoty> in that case, I'm not sure we need a JS api for this
WileyS: At least give the user some centralized control here.
... For example, must provide URL for control.
tl: Would you be OK with any site that uses this putting a control element in the well-known URI?
WileyS: Yes.
<aleecia> that's a great solution, IMHO
<aleecia> and gets to the point that users be able to change their minds multiple times a lot better than we had before
<sidstamm> yes, +1
<rigo> -1
<Zakim> ifette, you wanted to say oob provides a URL where you can edit your out of band stuff, the browser should just direct the user there
<sidstamm> out-of-band exceptions should be controlled out of band
<rigo> it just kills your wallet where you store your agreements
<npdoty> "DNT cookies" in case a user has blocked cookies
matthias: To be clear: if you want to use the out-of-band consent storage in the browser, fine, but you need to give a control URL such that the browser can put in a button for control.
tl: Yep.
WileyS: Yep.
ifette, Need some place to store consent, might not have third-party cookies.
<felten> Sudden outbreak of good engineering.
scribe: Rigo's inconsistency problem only comes from where browser isn't aligned with site preferences.
... This fixes it.
<tl> sidstamm: +1 to Ian
<Zakim> npdoty, you wanted to don't we already have that just by using the response headers?
<sidstamm> yes, was on the queue to agree with him and how to avoid putting the browser in an "inconsistent" state
<aleecia> the odds of people who block cookies and have DNT are a bit higher
npdoty: some problems of third-party cookie blocking, maybe, but those users might not want to be tracked
<npdoty> npdoty: and we have most of this functionality (for users) just by browsers optionally remembering when they see an opt-back-in message and including a control link
<npdoty> "no. what?"
rigo: should there be a control location in the browser?
ifette, don't understand rigo, think he wants the control URL to be optional, why?
<sidstamm> if there's no control URI, how do users properly revoke it?
<rigo> rigo wants simply that the UA can store all out of band consents, whether managed or not
WileyS: Seems reasonable, in some cases control directly in browser, in some cases follow control link.
matthias: Any opposition?
<sidstamm> works for me
<ifette> ACTION: ifette to document out-of-band js api [recorded in http://www.w3.org/2012/06/22-dnt-minutes.html#action06]
<trackbot> Created ACTION-222 - Document out-of-band js api [on Ian Fette - due 2012-06-29].
npdoty: Want to see text.
<aleecia> shhhh
<rigo> I think though that is covered by the possibility to convey information also by other means. But the js api shouldn't prohibit to just convey information without control - URI
matthias: possible discussions are non-compliant user agents and tracking status resources
... going to focus on tracking status resource
... working from tom's brussels proposals
<explaining tom's proposals>
<tl> Tom would like to do this.
<tl> And actually, use his DC proposal.
<npdoty> we don't have a service-provider code in the Response Value section at the moment
<aleecia> let's let matthias talk through first if we can
scribe: notion is a reasonable degree of transparency in practices
... roy has a proposal with more fields
tl: why use my abbreviated brussels proposal instead of my more recent washington proposal?
... <explaining latest proposal>
matthias: question for roy - fundamentally different?
roy: similar, but treat service provider as first party
matthias: save this small difference, the same
<npdoty> tl has a "c" for consent and roy has a "p" for prior consent
<npdoty> tl: existence of the response is the indicator that you comply with the user's preference
<frustrated cross-talk>
tl: response header is a commitment to follow the DNT specification, indicates applicable parts
<npdoty> rigo: if I send a DNT signal to a wall, it won't comply
<more frustrated cross-talk>
<amyc> amyc wants to ask whether this header is optional, as we decided before break?
<npdoty> amyc, this response will also appear in the well-known URI, I believe
<rigo> my point is that the current text is not really ok for creating matching declarations to create consent
<rigo> if we have consent + additional information, fine
tl: this is a short way for a website to explain what it's doing
<rigo> but if we say, see I only promise to honor this part of the specification we may have a dissent between the user and the service
matthias: ok, yes, a commitment to follow the spec and possibly additional information
rob: can't commit to track or not track when there's no clear definition
<aleecia> we could use different names, yes
tl: this is about "definitely-not-tracking" - where a (very unusual) site collects essentially no information
<npdoty> ninja's definition of "absolutely not tracking": http://www.w3.org/mid/4F3935E4.4030101@datenschutzzentrum.de
tl: information that is entirely arvind-proof
<npdoty> (some people don't think we should define that at all, or rather that we shouldn't use that name)
matthias: most enterprises will not use this
rob: don't like use of the term without more clarity
roy: without defining tracking, this violates http semantics. good luck disagreeing with me on that.
tl: We can define compliance and tokens. That's fine.
<cross-talk>
<felten> Is anyone arguing that these fields should NOT have defined meanings?
<npdoty> is the only objection that these tokens point to defined terms? everyone agrees we should define terms
<aleecia> +1
<rigo> +1 to mts
<rigo> I want the letter F
matthias: proposal <unclear>
WileyS: Let's talk about how to respond to non-compliant user agents.
matthias: Not quite what we're working on.
<hober> rigo++
<npdoty> tl: have an extra token for "reject" or "not complying with the spec on this request"
aleecia: Still an open issue, could have to give it the time it deserves.
<rigo> hober :)
amyc: could use out-of-band mechanisms for conveying they're super-privacy-preserving
<rigo> hober, I could also live with fy
tl: some companies want to make stronger claims about what they do
alex_: Where's the consensus proposal?
Did someone claim this was consensus?
<npdoty> will paste in Ninja's email again: http://www.w3.org/mid/4F3935E4.4030101@datenschutzzentrum.de
dwainberg: Ok if this is an "I think I'm not covered"
<npdoty> dwainberg, what would "not covered" mean?
tl: That's not what this is. "n" is a stronger statement than "3"
matthias: A third class of compliance, super-compliance.
<hober> ScribeNick: erikn
<jmayer> matthias: Any objections to the 1/3/n compliance expression approach?
WileyS: I think there will be a fifth
matthias: agreed that there are *at least* 4: u, 1, 3, n.
<hwest> So, we will need to outline at least one more state for the compliance doc?
<jmayer> CONSENSUS: There will be, at minimum, these four values.
matthias: this is in the header field
<npdoty> everyone can live with at least u/1/3/n in the response header field (and probably similar in the well-known uri)
<aleecia> Agreed: first character of u, 1, 3, n (obviously new issues could add to this later)
matthias: and is a guiding input for our WKL
<WileyS> Aleecia - are you going to discuss the next face-to-face soon? Many folks are leaving at 1pm.
matthias: so now let's talk about the next part of that field
<aleecia> Good point. Short answer:
<aleecia> We're not done...
matthias: should it be possible to distinguish between a service provider for the first party and others?
<WileyS> LOL - fairly obvious
matthias: maybe we don't need to do that here. expose internal details like that. Doesn't matter if it follows all the requirements
<aleecia> and the next meeting should likely not be before September since finding time over the summer without running into vacations
<rigo> hober, I think U+1F4A9 is the think we MUST use
tl: in the cases where abobe.com (for example) is run by amazon.com, there's a difficulty for the user. not clear what party is guarding their data
<aleecia> Which, as you might guess, kind of kills me to admit. But.
tl: say I have some analytics company that runs analytics off their domain, and has a service provider relationship. I (user) might think it is a first party, as opposed to "in the shoes of" the first party
<aleecia> If anyone can volunteer to host in Europe, that would be most welcome
matthias: if they both comply and tell you "1", why do you care?
tl: amazon isn't the same party as adobe. Visiting amazon.com doesn't involved adobe.
Roy: only because you defined party in a way that doesn't make sense to users
jmayer: where do we land outsourcing in the spec? Doesn't have to be here.
<npdoty> a lot of people don't care which particular section we put it in -- +1
jmayer: that's one issue. Separate issue: when the user gets a response, can determine if it is an "ordinary" first party versus an entity that's doing outsourcing stuff
<aleecia> Shane, does that answer what you were looking for?
jmayer: I think we should be able to distinguish, in part due to the risk of claiming outsourcing to stretch the 1st-party definition
<npdoty> jmayer: I think it's important to have transparency, given how some have suggested using the outsourcing exception
jmayer: again, this is separate from if there is a different token in this header field to distinguish this
rigo: we try with our definitions to explain relationships (like one processes data on behalf of another), then we might end up describing all relationships like who hosts this server's cloud data
... the header field is not the right location to do that
hwest: can decide we want to pack a lot of data into this header, but that isn't realistic. What is actionable knowing this is a service provider?
<rigo> perhaps you want more information on service providers and explicit third parties and what they do, but that shouldn't go into the header
Chesterj: I think transparency is important. Users will make decisions as they learn about the process based on practices of service providers
<jmayer> hwest, see my earlier comment about transparency into how the outsourcing exception is used. Want to be sure it's not getting stretched.
hwest: if my 3rd party is Amazon, you don't have a choice to not interact with them if you want to use my website
Chesterj2: right, I can choose not to interact with you
felten: say I go to a.com and it uses sp.com. I might care if sp.com is a service provider or a first party, because it changes their ability to share data
jmayer: ... agreeing with the preceding
... there are benefits even to the DNT ecosystem, outside of any individual user. research, regulatory, and other interests
<rvaneijk> "For the EU, the outsourcing scenario is clearly regulated. In the current EU Directive 95/46/EC, but also in the suggested regulation reforming the data protection regime, an entity using or processing data is subject to data protection law. A First Party (EU: data controller) is an entity or multiple entities (EU: joint data controller) who determines the purposes, conditions and means of...
<rvaneijk> ...the data processing will be the data controller. A service provider (EU: data processor) is an entity with a legal contractual relation to the Data Controller. The Service Provider does determine the purposes, conditions and means of the data processing, but processes data on behalf of the controller. The data processor acts on behalf of the data controller and is a separate legal entity....
<rvaneijk> ...An entity acting as a first party and contracting services of another party is responsible for the overall processing. A third party is an entity with no contractual relation to the Data Controller and no specific legitimacy or authorization in processing personal data. If the third party has own rights and privileges concerning the processing of the data collected by the first party, it...
<rvaneijk> ...isn't a data processor anymore and thus not covered by exemptions. This third party is then considered as a second data controller with all duties attached to that status. As the pretensions of users are based on law, they apply to first and third party alike unless the third party acts as a mere data processor."
rigo: this conclusion is only valid under a certain definition of service provider. If it is the EU "data processor" can only process data on behalf of the first party. In this case, it can't share.
... we don't have any data bleed then. Just an extension of a first party. Might be informational to distinguish, but then don't overload the header
fielding: agree with Rigo that his service provider definition agrees with that, in disagreement with felten's scenario
... like employees. I don't have a right to know which employees at Microsoft have access to my Microsoft data
<jmayer> My three rationales for drawing the first-party vs. service provider distinction in response/well-known URI: 1) different sharing boundaries for information (users might care), 2) different use direction for information (users might care), 3) ability to check application of outsourcing exception (researchers/advocates/policymakers might care).
<npdoty> it may be that we're not quite sure what "service provider" will ultimately mean
dwainberg: Rigo and Roy made my points. This is a choice mechanism, not a transparency mechanism.
... there will be friction to small publishers and small companies more impacted
felten: go to a.com, redirecting me to sp.com, acting as a service provider to a.com. Data can be shared within a.com, but not within sp.com (I might have that backward). Point being where data can be shared is still impacted
fielding: this does not replace the privacy policy, which tells users these things
matthias: suggest we move this out of the header field
... can put that in the WKL
<felten> Privacy policy doesn't tell me who is a first party vs. service provider in a specific interaction.
tl: objects
... if I can't tell if Amazon is a first party (Amazon) or a service provider, I don't know where my data can go. Without the s token, I can't distinguish this.
... these cases are manifoldly different, so we cannot remove this token and still have a user understand
matthias: let's try the reverse approach. who can't live with exposing this information?
<WileyS> Aleecia, that makes sense. We need to first find a host and THEN we can announce the 8 week timeframe. Any chance we can go back to DG Info / EU Commission again to host us?
<Chesterj2> we need time to sum up where we are, were we go.
fielding: there can be 20-30 service providers in a single response. can't put that in an "s"
felten: not talking about a.com using infrastructure from others
... if the UA sees a.com as where it's going, as opposed to being sent to a domain that's different
<aleecia> We can have the EC host, but we can also go elsewhere if we can find a host
felten: can have infrastructure that's not visible to the UA
<npdoty> I think felten is pointing out that you can't distinguish the service-provider relationship from the multiple-first-party example
<WileyS> Yahoo's office in Brussels is tiny so I'm not helpful for Brussels.
<aleecia> We fall back to EC if needed but - know anyone with an office building in Paris, Rome, Florence?
felten: this doesn't touch a lot of the service provider cases
<hwest> ...Isn't hidden infrastructure more of a problem than exposed service providers?
jmayer: this maybe needs much longer discussion.
<WileyS> Aleecia, I believe our Barcelona office may be large enough, I'll check (est 70 people, fair?)
<felten> Ed says X != FTC says X
<aleecia> Lovely! Thank you!
fielding: there are many service providers in that chain. there are limitations on what you can share
<aleecia> Estimate of 70 sounds right to me
tl: it doesn't appear you are communicating with them
<aleecia> We clearly need to end the meeting so people can watch the game
tl: go to x.com. I use rackspace, but you don't know that. If you go to x.rackspace.com, if they send you a response that says "1" in the header, you don't know if it's x or rackspace. If it's rackspace, it can share that in themselves
... if they are a SP for me, they can't use it for their own malarky. Otherwise they can
<hwest> Proposal: duke this out at some later date!
npdoty: or multiple on one page
<aleecia> +1 heather
matthias: evilempire.com ... with an s flag, you know it's okay, but with a 1 flag you should be afraid. Isn't this Tom's point?
fielding: go to the WKL and see who it is
tl: no
<aleecia> thank you sid
matthias: if they user has blacklisted evilempire, maybe only if it's itself and not acting as a service provider
sidstamm: alternate rephrasing
... there are SPs who have multiple customers. If they silo, they are acting kind of like 1P. If they are acting like a 3P, they could be sharing
... in a SP context, would only share the data with the 1P acting on behalf of
matthias: seem to have strong support for the s flag
... so we'll create text for it in the next draft
tl: in the next modification of the rec, it will have s, and then we will reconfirm the consensus to the draft?
matthias: yes
<aleecia> Agreed: adding s to next draft, will review text
<npdoty> tl, it's not in the editor's draft right now
<aleecia> thank you Erik
<npdoty> ACTION: mschunte2 to update text based on tl's proposal, due 6/29/2012 [recorded in http://www.w3.org/2012/06/22-dnt-minutes.html#action07]
<trackbot> Created ACTION-223 - Update text based on tl's proposal, due 6/29/2012 [on matthias Schunter - due 2012-06-29].
<aleecia> shane & tom agree
WileyS: why look for such a short response header and pressing very hard for brevity? The response content will far exceed the header.
matthias: reduce complexity as much as possible
... are all the tokens essential?
<tokens displayed on screen>
fielding: meaning of tokens is to say the site is tracking, but only doing so for this particular exception or another
... not a list of all permitted uses
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#status-response-value
<ifette> Are we still making progress? or would this be a good place to break...
<ifette> hober, by "break" i meant stop this subject, wrap up, and call it a day
npdoty: is this not 1:1 with permitted uses?
fielding: yes
matthias: intent is to explain
<felten> 1-1 with permitted uses, plus one more for prior consent
tl: almost all to line up with permitted uses. Will be slightly out of sync as we revise
... p is the exception to that.
... p is not a narrow use; not on the list of permitted uses
matthias: is this needed?
<felten> How much do users and UAs care?
dwainberg: p is valuable. everything else adds complexity
... and doesn't provide a lot of value
<WileyS> Tom, who would ever not implement all of them? Use case?
dwainberg: have to parse, understand the spec, make decisions. Easier for engineers than lawyers and others
<WileyS> Or add an "all"
hwest: agree with dwainberg
<tl> WileyS: I might.
hwest: if we want this field, we should just have the permitted uses
<WileyS> Build an entire spec on one web sites use?
matthias: assume that except for p that they are aligned with the permitted uses
<aleecia> (I asked him early, he is right)
jeffwilson: it seems like p needs to be a response code
<hwest> hwest: there is no reason to add complexity with this
<aleecia> (auto correct for the lose)
matthias: should there be a signal for prior consent?
group: yes
<amyc> +1 hwest
tl: if you think most people will use all the tokens, then they can be optional. None == all, but if you say some, you have to mean just that
... specifying that I do one and not others is a use case
<felten> How much do users and UAs care about these tokens?
<aleecia> How do we answer that yet?
matthias: do we want to communicate the different permitted uses?
<aleecia> I'd suggest we implement this and see
matthias: do we agree to spell them out?
<hwest> I would phrase it as "I see no reason to add this complexity"
<sidstamm> it would be nice for me as a user to know who is protecting me from fraud (for example)
WileyS: agree there is little value, is weight and complexity
... shouldn't design for just a few sites
... for sites that want to show their DNT compliance is better, can specify that outside the standard
dwainberg: should leave it all out. Especially "L" (local constraints)
tl: happy to remove "L"
meme: for DNT, less is more if we want adoption
... we should offer "compliant" or "not compliant"
... otherwise it will be complex and not get used
aleecia: question to EU side. Does it matter for compliance if they specify or not?
group: no
sidstamm: we should think about people using UAs. This could be beneficial to them. I'd like to know what sites are protecting me from fraud. That would be kind of cool.
<WileyS> Read their privacy policy or follow the "Pointer"
rigo: has long said it is worth giving users this kind of information. But it's being shoehorned into the wrong tool.
<aleecia> has the web changed at all in 10 years?
WileyS: can we use the Pointer to provide these kinds of details? Optional and can individuate permitted uses there.
fielding: fine with not having these values. Was trying to cover all use cases, but if the group decides not sufficient, that's fine
<aleecia> zakim close queue
sidstamm: there is value to users
tl: these can be in the tracking status resource, not in the header
matthias: we have consensus to remove the tokens except for p
tl: and make it optional in the status resource?
... does anyone object?
<aleecia> AGREED: fields become part of optional member of tracking status resource
<aleecia> ...except for p, which remains
aleecia: changing gears. next F2F
... practically, not worth meeting before Sept due to schedules
... looking for a host
... straw man compliance draft coming out soon, to be taken up in calls
<rigo> I know that the European Commission is keen on hosting
aleecia: we made progress in this meeting
... thank you to everyone for your efforts, particularly Nick and Thomas
... a huge thank you to Rigo
... and also JC for coordination
JC: and to those who provided food (missed the list)
aleecia: and to matthias for chairing this last session
npdoty: and thanks to Aleecia!
<npdoty> trackbot, bye