Tracking Protection Working Group f2f -- 05 Oct 2012

<BrendanIAB> Zakim is such a slacker this morning

<BrendanIAB> fielding, Zakim hasn't joined #dnt

<fielding> npdoty, no conferences scheduled -- I invites zakim and rrsaent

<npdoty> that background noise is people chatting before we get started

<BrendanIAB> I'm not hearing background noise.

<vinay> https://my.adobeconnect.com/vigoel

<npdoty> scribenick: npdoty

schunter: welcome to the final day <applause>
... discussion will get a bit more technical today

<ifette> I just want to apologize in advance if I seem grumpy to anyone. Please don't take it personally. I got 3.5h of sleep last night :)

dsinger has memorized everything in the spec

schunter: important we agree on the principles and protocol, but text details will be handled later
... walk through the agenda

no objections

hwest to scribe for the triage session

rigo to scribe for post-breakout

jchester to scribe timeline session

Issue Triage

<scribe> scribenick: hwest

schunter: First topic for triage is the exception APIs. Current state allows site to ask for an exception to DNT:1, which when granted will mean there is no header.
... Next look at issues and proposals to solve them

dsinger: Currently, API for site-wide and web-wide exceptions. Ste wide can ask for exception for all third parties on your site, list has to be maintained by the UA, shouldn't fiddle with bits of it
... list is optional on server and client side. API to cancel all site-wide exceptions
... UI for both kinds of exception should come from the site, consequences for denying exception, etc. Final confirmation UI from the UA.

<fielding> do we have any indication by UA folks of willingness to implement?

<ifette> scribenick: ifette

schunter: List is maintained on the UA, editing capabilit is optional.

… user may change their mind.

… One benefit of the API is reliable storage for these kinds of exceptions.

<npdoty> presumably user agents could do synchronizing if they chose to do so

bryan: Clarification - this proposal is related only to a single UA, like a browser, but no implication on hybrid web apps or other UAs on a device? No requirement for consistency of UA across the device?

dsinger: You could, but it's not explicitly discussed.

tlr: That's an implementation decision.

BrendanIAB: Had discussion about intermediaries potentially modifying DNT header. Some things up in the air about that, but calling out UAs specifically to handle exceptions, should let intermediaries off the hook.

dsinger: One of the reasons to restrict intermeidaries is because need headers and exceptions to come from the same point.

schunter: Goal here is to raise questions for clarification, not necessarily to raise problems. General purpose discussion is next.

<bryan> there were objections to restrictions on intermediaries mentioned yesterdy

dwainberg: Now, web wide exception is limited to single origin, have we considered all sites all origins as an exception?

<npdoty> user agents can turn on DNT:0 for all sites, if they wish

dsinger: We haven't, we can discuss later this morning. That's coming up.

schunter: Had this discussion at one of the first sessions. Function was deemed a privacy risk.

One that point, that is materially changed by UAs that ship with DNT on.

<jmayer> There is no major user agent that ships Do Not Track with a silent default.

… worth revisiting, given that the world has changed.

dsinger: We can rediscuss.

<justin> MikeZ: We don't have any mechanism for knowing whether DNT is set by default.

Joanne: How do out of band exceptions fit in this? Do they follow the same rules as the UA?

<bryan> I believe there should be some expectation that the effectiveness of the user agent managed experience is supported by ensuring that users have the ability to manage such exceptions on a device-wide basis rather than per user-agent

dsinger: They're completely undocumented.

WileyS: Do they need to be undocumented? Maybe not.

schunter: We will have this discussion later.

<fielding> Generally speaking, out-of-band means they are not part of the protocol, and hence cannot be documented by the protocol.

ksmith: Process question

<WileyS> thank you Roy

schunter: Flow here is to educate what's in the spec and then go through the open issues one by one.

… goal is to make sure the whole room understands what's in the spec now.

<bryan> The concern I have with focus only on a single component of what is a "user-agent" (browser in this case) is that it is a severe conceptual limitation re my comments: http://lists.w3.org/Archives/Public/public-tracking/2012Oct/0114.html

<npdoty> +1 on out-of-band, we discuss them in Compliance, probably don't need them mentioned in TPE since it's not part of the protocol

bryan: Sent a note this morning related to this. If you're going to implement DNT on a UA and give some control over the exceptions this is reasonable. I have concerns over utility and scalability. UA is only one facet of what this concept really implies.

… Notion that a UA is one software component is limited. Need to be careful what reccomendation we give on how to manage on devices.

<fielding> dsinger, consent flag is necessary for transparency, and control link is necessary for control of out-of-band consent, but we don't need to define how it works

… Consider hybrid web apps.

<dsinger> fielding: roughly my thinking, and it might be simpler to say those things in the TPE where the flag is defined

rigo: Will we discuss the implication on explicit-explicit exceptions? What is the current state of this?

schunter: We will discuss it.
... Now, we'll go through the issues.

… first issue is ISSUE-60

dsinger: Just asks via javascript for the header that they'd get

Is this asking "What would I get", or "what did I get"?

… edge case

dsinger: It's the current state of the DB, so whatever would be sent if the page was refreshed.

npdoty: Proposed to move the DOM property to window, so that iframes could have a separate value

<fielding> npdoty, I think that is under issue-161

dsinger: There are currently two methods, one is the user's general preference, and then this one which asks what header would be sent to the origin of the script request.

npdoty: Rather than having the general preference, we have the value always be what header was sent to the origin

<fielding> issue-160?

<trackbot> ISSUE-160 -- Do we need an API that will tell a host what its current exception status is? -- pending review

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

<fielding> issue-161?

<trackbot> ISSUE-161 -- Do we need a tracking status value for partial compliance or rejecting DNT? -- raised

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

WileyS: How would a third party know?

npdoty: It would call window.DoNotTrack

<fielding> er, guess not

schunter: We recorded your idea

<npdoty> ack npdoty

Chris_DAA: Is the implementation of the exceptions API required? Do we have consensus?

schunter: We don't, it's ISSUE-151

<fielding> npdoty, I agreed with your changes, but thought you were going to make the edits -- dropped off my to do list

schunter: ISSUE-160, question is whether all people are in principle ok with the API. Objections to including it?

tl: This is exclusivelty for third parties to see if an exception is set in the client?

dsinger: No, if first party calls it, then they get their answer.

<npdoty> this would not solve the problem for inline javascript

tl: Inline JS could appear to be one party but give info to another party

dsinger: Now based ond ocument origin, not the origin of the script itself.

<npdoty> I believe it's by "effective script origin"

tl: Now if I have a third party script, it gets the header that the root gets, not the header for the party operating the script.

dsinger: Even if you use a script library, you need to get the excpetion state for you, not the library.

<WileyS> +q

tl: Has to be in an embedded iframe to get around? Can we add non-normative text for implementation instructions?

<npdoty> I believe it was documented explicitly

tl: I don't have sufficient understanding to write that text.

<WileyS> 3rd parties don't know if they are in an iFrame so they won't know which implementation to call

fielding: We haven't heard any UAs indicate a desire to indicate. Would like to see desire expressed.

ifette: We might desire to implement what Adrian is going to propose.

tl: We also desire an API, not sure abotu which proposal is best.

dsinger: Watching, interested in whether service providers want to call these APIs.

npdoty: Wanted to answer the question about the third parties. This version and past versions have made it clear that the JS can find out what the value is for it's effective script origen. Inline or loaded from another server would get the value of the current page. Need to explicitly document that.

<amyc> clairfying question, would 6.6 allow cross domain query, so that first party can determine exception status of third party on page?

… Other questions about how to help a third party know whether it has a header, if they don't have a separate iframe

<amyc> or is it just "what's my status"

WileyS: My difficulty is that third parties sometimes don't know whether they're inline or in an iframe, some seurity strcutres try to mask the structure

… hard to tell how to call it to get my own response regardless of how we set this up.

dsinger: Adrian's proposal may help.

<npdoty> in all cases, a third party gets an HTTP header

<npdoty> .. the JS has just been an attempt to provide a hint to the scripts

tl: Best solution may be reliabily getting the right thing by adjusting the DOM to draw a new iframe and call script from within the iframe. Horrific, but reliable.

WileyS: Industry is trying to move away from iframes.

<fielding> npdoty, sorry -- I was thinking of issue-116 and your message of http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0114.html

… maybe we just wait for Adrian's proposal

schunter: Want to close ISSUE-160.

<npdoty> adrianba, you believe that this doesn't affect it?

… this text may change if Adrian's proposal is accepted.

WileyS: Why close if we have significant technical issues? How about pending?

schunter: ok

<adrianba> npdoty, i don't think this one is easy to solve and avoid fingerprinting

dsinger: Trying to avoid cross-site leakage.

<adrianba> npdoty, i don't think my proposal helps much other than being able to query for exception status

<npdoty> adrianba, I agree, which is why I suggested we just explicitly note what you can learn from it (and that it won't satisfy everything)

<adrianba> npdoty, which you could merge with the general preference

schunter: In the last two days, folks have thought about how to simplify. It's complex to design the UI for all these purposes.

<dsinger> notes that all these APIs have 'privacy' concerns for sites - you don't want competitors finding out your exception status, for example

… One goal is to make it simple.

… We now try to present Adrian's proposal.

<adrianba> My proposal is here: http://pages.adrianba.net/tpe/exception-proposal.htm (and on the list)

dsinger: Today, site informs user of consequences fto granting/denying request, but when API is called, user consent is assumed and the exception normally recorded wtih no required UA UI

… Proposal is to get rid of that. New API queries whether the exact exception still exists.

… So you don't have to bother user

… Cancel call and get request are basically as they were before.

schunter: Point is to provide reliable storage for the sites. Gets rid of all those popups on the browser. Usability studies show that users ignore popups or are annoyed by them, so they're not helpful.

… enhances transparency from the privacy side

… creates freedom of implementation for the UAs

<tl> +q

<vincent> so exceptions are granted by default?

<WileyS> Vincent, yes - highly auditable

adrianba: Quick clarification, the main idea with this proposal is to say that today, when browser sends DNT1, we trust the site to do the right thing. We should also trust the site to do the right thing when they ask for the exception. If the site chooses to do the wrong thing, the API doesn't make a difference.

dsinger: Current requirement to have atomic exceptions.

<tl> +q to ask about that we drop out into a small group session to work on this. I see a couple of wrinkles, and I think a little back and forth with a whiteboard will get us where we want to be.

<vincent> WileyS, but there is no consent then?

… under this API, much easier. Whether user deletes entirely or in pieces, you just get the answer for you

<jmayer> +q

<WileyS> +q

schunter: Simplified implementation is important, want to see it implemented in as many browsers as possible.

ifette: One of the questions we talked about was compliance in the EU, what is informed consent in various different regions. Thing I like about this is that browser doesn't know what informed consent means in different regions. Website owner probably knows better. Nice thing about giving control over to the website, whatever they're saying to the user is right for the rrgion.

… Normally when we have the browser pop a prompt, there's concern over abuse of info. Here, not getting additional information from the browser

<dsinger> UI people I talked to said they had no idea how to design a UI that satisfies all of (a) users (b) regulations and (c) sites...

… bad actor would just store the info anyway, rather than asking for an exception and then ignoring it

… if browser wants confirmation, still allows for that. Gives more flexibility to servers and third parties.

… Lets UAs manage flow better.

<Zakim> npdoty, you wanted to ask about UA confidence, given their compliance requirements

<fielding> It sounds fine, but given the extent of these changes, we should skip the rest of the API agenda items until the proposal is written.

npdoty: As I understand it, the UA could already choose whether or not to show UI. Change is that it's no longer asynchronous. Would advise UAs not to show UI.

schunter: Double checking user preference has disappeared.

npdoty: Most of this functionality could be done with the existing API.

dsinger: This is basically a change to documentation. Delete requirement to confirm with the user.

npdoty: UA compliance requires that they reflect the preference of the user. Why would they assert?

ifette: Just means that if we adopt this change, we need to make sure the rest of the draft reflects this.

<aleecia> +1

dsinger: General pref reflects general intent, exception reflects the user's intent towards site

<npdoty> it's a pretty basic requirement that the user agent has to confirm the DNT header respects the user's preference

<aleecia> It's the UA's responsibility to make sure the general pref is right, and the site's responsibility to make sure the site-specific pref is right (exception)

<aleecia> -- point made by David Singer, I'm just capturing

efelten: Both Ian and Adrian made arguments around security. Not a problem that a malicious or mistaken site coudl claim to have consent because thet could also claim OOBC. Two cases to consider. One is the case of a web wide exception, then teh argument is pretty compelling. In the case where a first party is asking for a site wide exception, argument is more difficult, site is telling the user that they have given consent, but the third party didn't ask for tha

consent.

… First party that is malicious or mistaken could cause other entities to send the wrong signal when a user is visiting that site.

… Concern is that a third party is sending a signal that might look like bad faith when they're actually just following someone else's mistake.

adrianba: Current API has a site wide exception, only difference is the confirmation dialog. Doesn't mean that the site couldn't be tricked.

efelten: Current API has user confirmation.

<Zakim> tl, you wanted to ask about that we drop out into a small group session to work on this. I see a couple of wrinkles, and I think a little back and forth with a whiteboard will get

<jmayer> Mistakes are certainly possible. Another risk: malicious abuse of the API. It's now possible to poison a website's consent mechanism.

<fielding> efelten, wouldn't the third party receive DNT:0 in that case?

tl: First of all, we're removing a requirement that the UA does present a UA. Doesn't prevent them from presenting UI. UAs are good at figuring out what to present.

<justin> ?

… this API as proposed has a couple bugs. Best way to work this out would be to whiteboard this with a few folks in the breakout.

<npdoty> I'd be happy to have a small group discussion.

<jeffwilson> it also presents a new tracking mechanism for bad actors with no interest in dnt, since it allows read/write of state without any kind of user prompt

schunter: Proposal is to have a technical breakout to debug this with stakeholders. Will continue discussion on general ideas here.

<efelten> Yes, the 3P would receive DNT:0, and might (mistakenly) tell the user that the user had given consent. The potential problem is that the 3P might not be able to prevent itself from sending false indications of consent, if some 1P messes up.

<Chris_DAA> jeffwilson, this seems like a good point-- you should raise it with the group

<WileyS> Jeff, bad actors could simply ignore DNT:1 - they wouldn't want to create an auditable breadcrumb trail of their bad actions.

… if you have technical concerns, let's do that in the breakout. Other broad concerns?

jmayer: I like a must around browser UI. Not sure I'd be happy with should.

<fielding> efelten, the third party can't distinguish that from a user sending DNT:0 to everyone, so it wouldn't say it has consent -- it would say DNT is off (or, more likely, not say anything)

… rationale to have a browser UI is not to make life confusing for websites, it's to create a predictable and consistent UI for users, it's a closer alignment of incentives for the UI interface with the entity granting the exception. Ability to design a choice architecture can be abused.

<npdoty> I believe current text doesn't have a MUST requirement on UI; for example "A user agent MAY use an interactive method to ask the user about their preferences"

… We hopefully make satisfying regional privacy law easier. May or may not be successful, might as well try.

<ksmith> "rationale to have a browser UI is not to make life confusing for websites" - might not be the rationale, but it would certainly be the result

<jeffwilson> shane, i meant its just another "evercookie"-like option for those who already use those kinds of techniques

… For that reason exceptions should live int he browser.

lmastria-DAA: Don't understand the atomic piece of this. Explanation?

<efelten> In any case, the 3P might end up telling the user something about the user's permissions/consent that the user thinks is inaccurate. Ideally a 3P would have a way to avoid this.

schunter: Old proposal, had requirement to have all or nothing for third parties on a site. Not a good idea to ask for exceptions for half your third parties.

<scribe> … New proposal doesn't require all or nothing.

… Can decide what to do if you get word that you don't have the exceptiosn you need.

lmastria-DAA: Does that mean that the user is checking or unchecking those five?

schunter: User can edit or drop specific ones.

… So have to check whether essential permissions still exist.

<BerinSzoka> hey, as long as we're talking about how UI can be abused to shape user choices, I would remind you all of the downsides of any opt-in system (which DNT will be either because IE10 turns on DNT:1 by default or because other UAs can easily get people to turn it on, making it more difficult for sites to get opt-in exceptions). read, if you haven't already, Betsy Masiello and Nick Lundblad's excellent paper "Opt-In Dystopias" http://goo.gl/H8YE or see my Senate

dwainberg: May not be different from previous version. What happens if a UA does create a UI to confirm a user's choice. Site asks for confirmation, then after confirmation, browser pops UI, but site never gets feedback unless they query the API?

<aleecia> tl, care to put that in IRC?

schunter: You can query, may be able to query in between.

<npdoty> in adrianba's current text, the JS would not get an answer. in the current draft, the JS API returns a boolean regarding the user confirmation

dwainberg: Looking at consistency.

ksmith: I have several questions. Sounds like we're moving the UI management piece to the website but maintaining the exception at the browser level. This has the potential to work, so I like it better. Moving in the right direction. Why would we have the UA manage the exception?To have a single place to manage the exceptions?

<tl> +q to explain a sample browser UI.

… may be hard to map the exception from the site to the browser for the user.

… What is the key value pair? Is the key anything you want/

<adrianba> there is also the ability with the API for the site to manage the preference - it can call an API to revoke the exception

<npdoty> I believe in adrianba

… You need to be able to ask about the exception, so you have a key?

<npdoty> 's proposal you would still request exceptions based on (lists of) origins

dsinger: It's the same parameters in the API as setting it up, it's the origin.

… If you have made multiple calls you can call them independantly, providing the same paramters as you did in setting it up.

schunter: This is for the whiteboard.

WileyS: Doesn't work that way. Can't set an exception for a third party, it's keyed to the origin.

ksmith: How does the browser know which header to send for any of those scinarios?

<npdoty> I think this doesn't change the origin pair concept which the browser uses to determine which DNT header to send

dsinger: For first quesiton, still have OOBC for the server to manage the exception themselves. Don't have to let the browser manage it. API here helps with browsers that don't allow third party cookies

ksmith: How does the browser know which header to send?

<npdoty> ksmith, I think that hasn't changed in adrianba's proposal

dsinger: Let's whiteboard it.

<tl> -q

WileyS: As part of submitting the request, we always had the concept of a resource link, we always had the ability to go back and change

<Chris_DAA> Chair, wouldn't it be more efficient to yield the management of this discussion to Adrian, since he authored the proposal?

<npdoty> "resource link" -- is that referring to the control/edit link in the tracking status resource?

… Allowing UAs to manage the dialog with users was going to be a highly untrusted experience between sites and browsers. This lets sites manage the language presented to users. Any UA implementation of exceptiosn was most likely not going to be accepted by servers anyway. This gives us a much more realistic path forward to finding that middle ground.

<BerinSzoka> Caveman Lawyer is confused about scope. Why is this issue unquestionably in scope while the many other equally important questions raised have been deemed out of scope?

… Bad actors can't take advantage of this. This would be highly auditable, and bad actors aren't going to go out of their way to create an audit trail here.

bryan: In general, this simplifies user experience and puts emphasis on user relationship with the site, which is good.

… what about multi-user devices?

… Question is about instantiation on the window object. Does that come from some sort of persistent preferences?

… Or when a new window is created, does that re-establish from the default?

… Can hold the question and ask later

ifette: Wanted to reply to some comments.

<npdoty> bryan, the setting would be reflected in outgoing DNT headers, and in a JS DOM property or method response

… jmayer wanted a consistent UI, based in browser. From the server side, having control over the UI leads to a consistent UI from the POV of the server. Not as simple as just looking at the browser.

… Want the same consistency across browsers, too.

<bryan> my comments were that if this proposal simplifies the user experience and puts more reliance upon the user relationship with 1st party sites it's a good thing, and this might alleviate some of the concerns I have over which user's intent is being served by UA-set DNT headers. but I still have some concerns over how the default/persistent settings get instantiated in new windows, which may be opened by a new user and thus not represent their preferences.

<bryan> the site a user visits may then want to change the UA-managed preference to what it thinks is appropriate, setting up a conflict between different users of the same device/browser.

… jmayer also pointed to "are you sure" UAC prompts as a model of success, and would not agree that is a success. Folks don't know what's going on when OS asks about security decisions. Shouldn't follow that model.

… browser confirmation UI could be a big problem if the API is expecting an immediate reply.

… if you're worried about bad actors, can pop information about ht eexception, doesn't have to be a modal 'are you sure'

<npdoty> I think the API still needs to be asynchronous if the UA may allow users to confirm

… browsers can innovate and provide transparency here

<ksmith> ifette +1

jmayer: To clarify, talking about consistency of experience goal was from user's POV through the browser

jeffwilson: I like the concept, it's a good one. Like Ian's idea of a non-modal indicator. But this could create a new tracking identifier if you set a bunch of exceptions.

tl: UAs can be smart enough not to provide this if a user has not made choices.

schunter: API doesn't let you see all the details. There's a small fingerprinting risk but not a big one.

<npdoty> I believe jeffwilson is referring to a new fingerprinting risk

<fielding> adrianba, a minor suggestion -- include 'DNT' in the method names, preferably as a prefix

schunter: Used to have old API, with all the data back, that has a big fingerprinting risk.

tl: Also posisble to rate limit from the browser end.

<Zakim> rigo, you wanted to ask whether the appearing - disappearing UI would work with javascript

<adrianba> fielding, i didn't define on which interface the methods would exist - but yes, something like that would be needed

rigo: Does the current definifion of the API exclude browser API?

<adrianba> fielding, perhaps on an object that has DNT in the name

<fielding> adrianba, that would be fine too

… if we want to have an extension to do stuff in the chrome, we could still do it?

<npdoty> currently the methods are on the navigator.doNotTrack object, yeah?

schunter: Does not exclude browser UI

<dsinger> notes that it IS envisaged that sites might call this API when you arrive with no preference set, especially for regions where lack of a preference is closer to dnt:1

<jmayer> s/through the browser./through the browser. The reason we've been developing this mechanism is to facilitate an accurate reflection of user preferences. Considerations about site design certainly matter too, but they seem secondary./

<npdoty> (which might be window.doNotTrack, depending on that question)

rigo: If we have this on the page, how do third parties that are independant services get exceptions?

<npdoty> web-wide exceptions would need to be called by the host in any case; like from an iframe

… From a negotiation point of view, would be nice if a site could have more options than all or nothing. May decide they need the counters but not all the trackers.

<vinay> the bad guys will not seek an exception. The bad actors would likely not implement DNT; or say they implement DNT but not really honor the spec

dsinger: Then you do two setups and inquire about them separately.

<ksmith> bad actors automatically get the ultimate exception - ignore DNT completely

<aleecia> this sounds like an implementation note to me (for rate limitation) rather than anything normative

<aleecia> my guess is the UA makers can figure that out better than we can

<Chris_DAA> rigo, what do you mean by "rate limitations"?

<npdoty> I believe schunter means "site-wide" not "web-wide", as in contrast to origin-origin specific

<dsinger> notes that we are trying to avoid database-walker APIs, as they are hard to build, hard to use, and have terrible fingerprinting and cross-site issues if not carefully designed

<aleecia> reminding them there's an issue sounds like a good plan, though

schunter: In prior discussion had the idea that side wide exceptions will be most common. Less common to explicitly list third parties.

<WileyS> Nick, +1 - he's confusing them a bit...

… so you can do subsets for the most important ones, etc

<npdoty> Chris_DAA, I believe rigo is referring to rate limiting of the querying of exceptions, as a way to address fingerprinting

… can query your list, but can't ask for full exception list

<Chris_DAA> npdoty, it's totally out of scope

ifette: The second question there was how a site requests an exception, and that doesn't change in this proposal.

<Chris_DAA> financial models of the ad industry is not in scope

<npdoty> Chris_DAA, I don't think this refers to financial models, just a possible UA implementation detail

lmastria-DAA: When you say ask, it's server to server ask? The user would be asked?

dsinger: Let's whiteboard that.

<fielding> I think this proposal is better than the current API

<npdoty> jmayer, do you have a question for the straw poll?

schunter: Straw poll on this proposal.

<jmayer> Yes, npdoty.

<jmayer> I want to be clear about what this proposal changes.

Chris Mejia: Also should see if people dislike all of them.

<Chris_DAA> ifette, not dislike

jmayer: Seemed like people didn't understand what changed in the two proposals

<Chris_DAA> maybe "not satisfied"

<adrianba> this proposal is a starting point - i expect it to change with feedback - i hope it makes progress towards what we want in the end

schunter: Three choices - go with existing API in the spec, requires browser to confirm exception with the user. Second choice is Adrian's, giving browser choice over whether to confirm. Third choice is that you don't like the API choices.

<npdoty> I think schunter is suggesting a poll of the general approach, not an adoption of specific texts

<jmayer> s/giving browser choice/making websites responsible for conforming to user preferences and giving browser choice/

… So, old solution, new solution, or no API. Can do antoher straw poll if we get a third proposal

<aleecia> Chris, if you have a suggestion of a third way, that's great. Just "I don't like it" doesn't work so well. New text? That's something we can evaluate

<npdoty> I don't think it's mandatory UI, I think it's the requirement of the UA confirming the user's preference

<fielding> SKIP THE POLL

… raise your hands as many times as you like!

<jmayer> +1

<npdoty> we're not voting

<aleecia> I think we're looking for: is the new proposal an improvement or not

<aleecia> Do you prefer the old way, or the new way, as a way to work on next

<fielding> A STRAW POLL IS NOT A DECISION

<fielding> WE DONT EVEN NEED ONE

<aleecia> Neither will be final either way

<npdoty> I don't think we conclude from not polling a preference that you agree with a proposal

<aleecia> ifette suggests:

<aleecia> two general paths, one is the one before, UA is required to confirm an exception

<jmayer> +q

ifette: This should be a really easy question. We want an idea of whether these general paths are good. One general path is the previous one, where a UA is requred to confirm an exception. The other is where a UA is not requred to confirm the exception.

<aleecia> second, UA not *required* to confirm an exception

<fielding> ifette, we cannot CHOOSE paths via a straw poll

<npdoty> general paths: the UA is required to confirm the preference, or UA is not required to confirm the preference

<fielding> please, it's a good idea -- just proceed

<jmayer> What happened to responsibility for the website?

<Walter> +q

<npdoty> I think we are agreed that this is not a decision point for the group.

<Walter> -q

schunter: Ask a different question: are we ok with investigating Adrian's proposal on the whiteboard?

<jmayer> I'm ok with focusing on MUST vs. MAY on browser UI, just want to make sure the responsibility issue isn't dropped.

<jmayer> -q

<ksmith> we had a straw poll yesterday which resulted in about a 95% to 5% split, and yet did not resolve the issue. So, clearly people are putting to much importance on the straw poll.

Rigo, I think we're swapping scribes soon - are you up?

<dsinger> OK, seems like general consensus to continue to explore this direction

<rigo> sure

<rigo> scribenick: rigo

<ifette> schunter: More issues, these were the easy ones

mts: two more issues,

issue-137?

<trackbot> ISSUE-137 -- Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s) -- pending review

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

mts: quick look at issues and then coffee break
... now different corner of the Specification
... header sent and response from Server and server can explain its status

question: should service providers reveal themselves as service providers?

<dsinger> notes that 'service provider' here only includes HTTP end-points; we are not talking about provision of service that is not an HTTP transaction

<fielding> disallow the SP to disclose they are not the FP

Roy was against it, because some subcontractors are not allowed to disclose that you're a service provider

scribe: objection by Tom to drop it completely

<fielding> and because there is no privacy rationale for this information

mts: thinking about the specific case when service provider is needed

<susanisrael> dsinger thank you for clarification re: which service providers are being discussed.

<jmayer> I'd like to discuss the service provider flag.

<aleecia> uh, we had privacy discussions repeatedly for this

<aleecia> disagree if you like, but they did happen

<fielding> aleecia, no record of any that would indicate why a user needs to know that a service provider is handling their request

<fielding> please link to one

rigo: we do not need service provider flag as the spec says, service providers are considered first party under certain conditions

issue-164?

<trackbot> ISSUE-164 -- To what extent should the "same-party" attribute of tracking status resource be required -- open

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

<aleecia> the discussion was around wanting to know who the SP is, not a boolean for SP or not. From memory, we heard from Ed, Tom, and Jonathan on more than one call.

<npdoty> does anyone object to having same-party be optional?

<Walter> +q

mts: explaining issue 164 and whether having all other same party things should be mandatory or not

<aleecia> right or wrong, that's a different question. But we have had discussions here. That's all I'm making as a point.

<efelten> I did discuss the service provider flag, for certain cases. If I recall correctly, Roy revised or clarified the spec in response to my question.

<fielding> aleecia, that is not a rationale for knowing who the SP is --it was a rationale for knowing who the FP is

<ChrisPedigoOPA> +q

mts: if you have many pieces in your origin from other things you should declrare same party

<dsinger> notes that many of the same issues come up as with service-provider; under what circumstances could a UA/user be anxious about a site that's not the first-party but claiming 1st-party status?

ifette: scope is also in the tracking resource document?

mts: yse

<Zakim> npdoty, you wanted to ask does anyone object to having same-party be optional?

mts: never in the header, only in the resource wkl

<ChrisPedigoOPA> -q

<aleecia> I'm not trying to get into if this is reasonable or not. That's for others to raise if they care to. I was just pushing back on the notion that there was no discussion.

npdoty: do people want it a may

<npdoty> yes, I think there are good reasons/incentives to implement

tl: if we would make it a should, we would break a lot of implementations

<npdoty> does anyone object to continuing with "MAY"?

tl: good reasons to use it, but no obligations

<WileyS> +1 to Tom

tl: indicating all domains you control does not help at all

<fielding> aleecia, there was plenty of discussion -- just no rationale. I don't see why people who want this tag can't explain why it is necessary to preserve privacy

<npdoty> I think tl's point is that it does help, but that it doesn't need to be compulsory

<jmayer> Proposal: best practice language.

<npdoty> jmayer, are you fine with non-normative example text as tl is proposing?

<npdoty> tl: would like to provide examples of cases where it would be good to implement

<npdoty> ... otherwise a recipe for silly mistakes / prevent valid implementations

<dsinger> fielding: I think that the same issues may come up; there may be circumstances where its use is advisable to maintain clarity at the UA that a site that appears independent is actually under an SP relationship; I don't see any reason for mandate, nor do I see a reason to make it impossible to signal

<npdoty> walter: I think it's a very good idea to make it mandatory because it gets rid of the confusion around 1st/3rd party

<npdoty> ... would clarify for the user/agent which is 1st or 3rd

<npdoty> ... might help clarify this problematic situation

<npdoty> scribenick: susanisrael

<scribe> scribenick: susan

<npdoty> scribenick: susanisrael

<aleecia> Roy, I don't think I can help you

<npdoty> I think the response header will still tell you whether a resource is 1st or 3rd party

matthias: from a technical perspective whenever you want a user agent to know whether a third party is part of transaction you have to tell it

<npdoty> the same-party is just a helpful indicator for learning the relationships among affiliates, etc.

walter: severl entities delaring others as part of them because it's a subcontractor--this permits party to say a party operating under its

mattias and dsinger: whether service provider is third party is separate question

<npdoty> if it's a subsidiary with an easily discoverable relationship, then I think it would be part of the same first party

<npdoty> more agreement on questions between jchester and lmastria !

jeffchester: ex of quadrangle ad [network?] owned by ny times is third party ?

lou mastria: would have asked that too

<fielding> dsinger, the flag is about the protocol -- the only reason to have it is to discriminate between service providers and wholly-owned sites

jeffchester: hope lightning does not strike

walter: pointless to define parties because roles change, so i wouldn't dwell too long on that

matthias: from tech perspective to make website work you have to tell ua that party is not malicious but is part of me

walter: yes, that's my understanding and why i am in favor it - clears up thing, says party is part of me

<dsinger> notes he hears everyone thinking same-party is useful and should exist; the question is only 'is it mandatory?' (always, or under some circumstances) or only recommended?

matthias: not mandatory but you will need/want to do it so you make your site work better

<rigo> mts: it is not mandatory, but site may run into trouble if they do not declare same-party

<npdoty> tl, are you willing to take an action on examples of why?

<jchester2> I mean QuandrantOne--which the Times co-owns: http://www.quadrantone.com/

<rigo> ... people are free to shoot their own foot

matthias: don't require declaring large lists of things, but the minimum, there are consequences to not doing it but people can shoot own foot if they want to

<rigo> ifette: large entities can not do that because they have too many of those

<rigo> ... UA should look over that is too heavy, useful, great, but not mandating

<npdoty> I don't think there was advocating for UAs should look at it and make changes to behavior from it, just that they could

<tedleung> ifette: +1

ian: talk of consequences worries me bc hard for some site to do it. We have tens of thousands of domains. Notion that ua should look at this worries. me. field should be there but don't think we should say if you don't do this you will face problems or make it a must

<adrianba> +1 to everything ifette said on MAY for same-origin

ian: i think in 4 min we are supposed to present results of breakout session and i am starting lose context

<npdoty> we had a second breakout session on the agenda, which I think is what we can use

<jmayer> The use case isn't listing all domains owned by a company. It's the domains present on a page that are owned by a company

tl: i think third party sending back first party domain ....[tl pls clarify this--didn't get it to scribe accurately]

rigo: sympathize with walter's point when you consider liability. and ian if this is too hard for you to do we have designed poorly and should make it easier

dsinger: remind gently that we are trying to allay anxiety about parties claiming 1st party status that don't seem to be service providers. Question is do you wish to allay anxiety

<fielding> I agree with dsinger, ifette, and tl. :)

ian: you are presuming there is anxiiety

kevin: can we quickly review agenda bc we are way off and i have a driving question and want to get to it. Can we know what we'll do for 1 1/2 hours so i know when to ask questions.

<npdoty> coffee & whiteboarding with adrianba, for those who are most interested in that

mattias: suggest 45 min of coffee/breakout sessions at white board then we can have a quick report out back to group

dwainberg: what have we done with this issue?

rigo: nothing

<npdoty> walter, do you want to provide an alternative proposal on same-party-mandatory?

<fielding> people who are interested in "S", please spend the five minutes it takes to explain why it is needed in an email to the group, or link to one if it already exists.

mattias: pending review from status point of view-send around formal email then deciding whether to close

<Walter> npdoty: to me thomas explanation that from a technical perspectiva mandatory was unwarranted was sufficient

dwainberg: so oppty for later new language? [ms: yes]

<jmayer> Roy, I've explained the rationales for a service provider flag multiple times. I appreciate that you disagree.

<fielding> jmayer, no you have not!

brooks: should not close anything with term not defind

<fielding> … all you did was reiterate that you want one

<dsinger> fielding: I will try once more to explain why I think it should exist, and under what circumstances it might be recommended to use it. Like you, I do not use mandatory

<dsinger> s/use/support/

matthias: so 45 min on adrian's proposal. who likes nontech discussion as parallel?

jeff chester: should do it as one

<npdoty> 45 minutes of coffee and whiteboard discussion with adrianba

matthias: then should discuss getting to last call

kevin: i think we made mistake when we started exception process and if they don't work i think dnt is dead

<BerinSzoka> Couldn't agree more with Kevin Smith: we should all take exception to a DNT without implementation of exceptions

<npdoty> we have support in the room for exceptions, yes.

kevin: going down road of where people will go--may monetize some people differently, won't want to have internet not work so must get exceptions right

<MikeZ> +1 to Kevin's comment that lack of implemented exceptions kills DNT for users and industry

<efelten> Is anybody here suggesting doing away with exceptions?

kevin: we approached this by thinking companies will WANT to track. I from big co don't want to work on exceptions, i'd rather customers have dnt on so i don't have to deal w exceptions

<npdoty> some sites won't implement exceptions, we all agree on that too.

<jmayer> Coffee?

<dsinger> puzzled, we are all recognizing that exceptions are important. we also all recognize servers have choices.

kevin: its tool for user not company. must make exceptions work for user and provide incentives for company to use it. this must be a way to let dnt work for people or it's dead

shane: i think we did that

<npdoty> +1 dsinger, I don't understand any disagreement

kevin also had said that otherwise only the extremely paranoid will use dnt

<npdoty> I think we may be able to close 164, and assign an action to lowenthal to write up non-normative examples on the same-party attribute

<dsriedel> *ping*

<npdoty> scribenick: vincent

Reports from Breakout

report of the breakout

schunter: get report from adrian and then go through the issue and assign actions

ifette: actions already on me to draft the text for the proposal

<npdoty> ACTION: fette to draft normative text based on adrianba's exception proposal [recorded in http://www.w3.org/2012/10/05-dnt-minutes.html#action01]

<trackbot> Created ACTION-313 - Draft normative text based on adrianba's exception proposal [on Ian Fette - due 2012-10-12].

schunter: adrian, could you summarize the eprspective

adrianba: very quickly, not huge amount on rogressing, huge amount of people intersting in this
... started with tl descibing what the exception API does
... resources request for site-wide exception, then spetn time discussin efelten's concern
... if a a malicious first party ask for a site-wide exception and then the third party get DNT:0
... the third party keep the data in good faith, but then the user is mad at the third party becauyse they did not give consent

<efelten> We also talked about how optional browser UIs might mitigate the issue.

adrianba: we fragment then in differennt groups to discuss different issues

<npdoty> and thanks for the patience all around in trying to manage that queue in the most informal, jump-in way

ifette: tl and I discuss the UI could work and if the exception should be scynhronous or unsynchronous
... for the UI there could be a bar telling "did you grant an exception yes/no"
... discussion about synchronous/asynchronous the user agent is not expect to conform the user intent
... the API should return a value if there is some syntax error or to report an error but not to report user consent

adrianb: in my proposal, doing anything with the list (of third parties) is optional
... because asking if a particular exception has been granted is complicated
... currently if you pass the array, you could still get a sitewide exception
... feedback from the beakout is that it is really really hard to manage this list
... it adds so much complextity

WileyS: is this about explicit/explicit vs site-wide?

tl: this is not the discussion, current API can do both

dan: npdoty and I are still beleive that we should rely on the user agent instead

npdoty: hwest and I UA may still provide interface to confirm the user consent

ifette: no, the purpose of this proposal is to not have the UA confirming consent

<npdoty> sorry, I honestly did think that maybe that was a good way forward

schunter: review issues, who would like what action on this issue...

<vinay> for those remote, matthias is presenting at my.adobeconnect.com/vigoel

Issue-144 ?

<trackbot> ISSUE-144 -- User-granted Exceptions: Constraints on user agent behavior while granting and for future requests? -- open

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

<johnsimpson> good morning

<npdoty> issue-111?

<trackbot> ISSUE-111 -- Signaling state/existence of site-specific exceptions -- postponed

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

<npdoty> this is currently postponed, in case we wanted a header extension

WileyS: if we remove explicit explicit we get ride of issue-111

<npdoty> I don't think having only site-wide exceptions resolves 111; unless we're saying that a DNT header of 0 is sent in that case

WileyS: in the current state you can not know which exception was granted so you have to query all the time
... I suggest we move to pending to see if explicit-explicit leave

ifette: explicit-explicit do not have to go away for this, if you use it then you have the issue

WileyS: the probelm for me is if the UA enable explicit-explicit, in the sense that it remove some exception

<npdoty> I think we always have the concern that a user could make a global opt-out

dsinger: if you get exception, you get an entire exception or not at all
... at some point we need to write a position paper on this

schunter: potential for furhter discussion on this issue

<npdoty> whether or not the exceptions allow asking for a list, a user might globally opt out from a particular third-party tracker

<npdoty> tbc, 111 was already in the postponed state

schunter: for adrianba we have action for ifette to add normative text for this proposal

issue-112

issue-112?

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

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

<npdoty> I think we can use same-party for this

schunter: how do we handle subdomain, if excpetion si granted for 2.site.com, what happens to3.site.com

<tedleung> npdoty: it's at least related

dsinger: the pushback is that it is currently based on string matching not dmain domain matching
... if we go on cookie-like management, then it gets more complicated

tl: i think we need it

WileyS: one of the concern was the wordpress.com

dsinger: that was part of adrianba proposal

<npdoty> or use same-party

adrianba: the proposal contains already something to apply exception for subdomains

<npdoty> if ifette is writing up a normative version of adrianba's text, and adrianba's text includes this subdomain handling....

<adrianba> ifette, let me know how to help with writing this up - not sure how you landed the action

schunter: if I understood adrianba, his email explain how to adress issue-112, ifette text should also have something on this issue
... let's wait for ifette proposal and then have a look at it
... an issue that is not addressed is multi-domain exception

npdoty: issue-112 was for subdomains, this one is for multi-domain

dsinger: adrianba does not address this issue

<jchester2> +q

WileyS: it's a not 1/3 party issue, it is for domain that do not match
... example for yahoo.com and yahooimg.com
... currently we would have to ask exception for these domains, iframe model discussed in DC
... in the backend I'm doing 2 calls, one for yahoo.com and one for yimg.com
... could it be done with one call

ifette: we discuss this in one of the breakups
... for instance if you DAA and you want to get consetn for many parties, how do you do that

<npdoty> because the UA wants to confirm that a DNT:0 represents the user's preference

<npdoty> ;)

<WileyS> +q

ifette: if I'm requesting an exception I'd like to be sure that the exception is requested by the right entity
... abc.com should not ask for yahoo.com

jchester2: unfair for the user to be asked for an exception when they have no idea what are the practices of the different third parties

<jmayer> +q

ifette: when you requesting an exception you're either upfron and clear or you're not

schunter: the point is WileyS who rises this requirement is ok with not having the feature in this version fo the API because we can use the iframe
... my point is we waint for adrianba solution and then discuss it

<aleecia> Please don't cut people off mid-sentence

jchester2: what is in the proposal that assure that the user granted the exception

adrianba: I did not propose anything about the multidomain thing is to be sure that the site requesting exception for another domain is allowed to do so

<npdoty> jchester, I think the requirement adrianba is referring to, is that compliant sites have to get informed consent

WileyS: I'd propose to create an action to write non-normative text to cover this use-case, with example of iframe codes to show how you would do multidomain exceptions

<dsinger> and then if we see the non-normative text is too complex, we can think again

<amyc> +1 on consent parity

WileyS: general section on exception that would also applied to exception

<npdoty> ACTION: wiley to draft non-normative examples of how a multi-domain site technically can ask for exceptions [recorded in http://www.w3.org/2012/10/05-dnt-minutes.html#action02]

<trackbot> Created ACTION-314 - Draft non-normative examples of how a multi-domain site technically can ask for exceptions [on Shane Wiley - due 2012-10-12].

aleecia: we avoid to define "user consent" because that's a legal term that have different meaning in different juridictions

<tedleung> WileyS: willing to review your text for 314 if that will help

<adrianba> WileyS, please let me know how I can help with ACTION-314

Chris_DAA: technical question, a site would be able to query the list sotred on the browser, the user would be able to edit that list
... would anybody else being able to change? like a plugin

<JBWeiss> Just as "informed consent" has a legal meaning, so does "consent" no matter what adjective is added

Chris_DAA: e.g. could a privacy plugin remove the exception

<npdoty> I think that depends on the per-browser implementation

adrianba: it is implementation depdendant

Chris_DAA: : could the user agent ask for confirmation?

adrianba: currently supporting that array is optional, what you can do is call the query "is there an exception for the website or for the subdomains"

Chris_DAA: a site can't change the settings for itself but a plugin could

schunter: the important point is that it is browser specific

rachel_n_thomas: on issue-171, when it comes ot the DAA as a definition about multisite excpetion, inform consent

<aleecia> (this wasn't a chairs' decision, it was requests from the WG participants)

schunter: DAA is an important use case for issue-171, could you validate if the iframe mechanism could be used

<npdoty> rachel_n_thomas: so DAA members would have specific guidelines on valid consent for requesting an exception

<BrendanIAB> I may be able to

amyc: maybe BrendanIAB could have a look at this

<amyc> sorry Brendan

<npdoty> donottrackchoices.org use case, yeah?

jchester2: there are many of us from the US who beleive that the DAA is inadequeste

lou: it is not the place to have this conversation

<adrianba> i think rachel was more making a point about defining consent but separately i'd welcome input about whether the API proposal works for DAA members

<amyc> just technical question

<npdoty> I think jchester2 is noting that he may have concerns about a consent proposal from DAA

<BerinSzoka> apparently, jchester2 speaks for all US NGOs--which is news to me

<BrendanIAB> Yes, assign it

schunter: I just want to have their technical expert to have a look on this

<BerinSzoka> I would like to register my objection to everything Chester just said

jmayer: the discussion emphasize that there is a close linkage between the design of the excpetion system in the browser and how we define user cosnent

<npdoty> ACTION: brendan to verify whether ad associations' use case will work with the proposed resolution for 171 from Shane [recorded in http://www.w3.org/2012/10/05-dnt-minutes.html#action03]

<trackbot> Created ACTION-315 - Verify whether ad associations' use case will work with the proposed resolution for 171 from Shane [on Brendan Riordan-Butterworth - due 2012-10-12].

<npdoty> I think that concern has been raised earlier in this conversation

jmayer: some browser may not have the right UI and expect that website will have it, it put a lot of pressur on website to know what to do to get user consent

<WileyS> +q

jmayer: we're going to have a discussion about what a user should do to have user consent

<adrianba> +1 to rachel's comment

<aleecia> You might re-read the charter; that was not actually correct as stated.

rachel_n_thomas: the working group charter does not discuss the definition of UI...

<npdoty> lmastria-DAA, WileyS, do you have comments on 171?

<jmayer> A consent standard is plainly within the charter.

<Chris_DAA> I can say that the mechanism would work (re the DAA mechanism)

<Chris_DAA> Brendan and I just conferred on this...

lmastria-DAA: we were talking about one issue and got wrapped up about on issue about consent, consent should not be discussed now

<npdoty> jmayer, did you need a direct response? I think we're only talking about 171

<npdoty> are we talking about 171, or about consent?

<BrendanIAB> Yeah, wrt the artion 315, there's a strong analog with the current methodology for managing opt-out cookies.

WileyS: that is the role of advocate to investigate implementation, it's not a conversation we're going to solve here, need real world implementation

<adrianba> +1 to WileyS

schunter: discussion on issue-171 closed

<Chapell> +2

issue-137 ?

<trackbot> ISSUE-137 -- Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s) -- pending review

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

<jchester2> But the consent mechanism needs to be thought about within this process, to make sure it's fair to users.

schunter: dsinger volunteered to write some text, and when we have some text we could have a look at it

<jmayer> To recap, my point was: If we move away from browser-based exception UI, that puts a lot of pressure on the definition of consent. We'll have to think carefully about what is required of websites before they can claim a user-granted exception.

schunter: any other input on issue-137?

<npdoty> ACTION: singer to draft update on when service provider indication is necessary (with fielding) [recorded in http://www.w3.org/2012/10/05-dnt-minutes.html#action04]

<trackbot> Created ACTION-316 - Draft update on when service provider indication is necessary (with fielding) [on David Singer - due 2012-10-12].

<npdoty> action-316: related to issue-137

<trackbot> ACTION-316 Draft update on when service provider indication is necessary (with fielding) notes added

<WileyS> Jonathan - it will require "user consent" - it'll be up to many to determine if that consent was valid (informed, transparent, accurate, etc.). That is true of "Out of Band" consent as well.

rigo: this is currently a non-issue because we consider a service provider that has no independant right

<npdoty> Chris_DAA, BrendanIAB, if you can update action-315 already, that's great -- on the mailing list would probably be most useful

schunter: do you object and want yo right some text?

rigo: no

issue-164 ?

<trackbot> ISSUE-164 -- To what extent should the "same-party" attribute of tracking status resource be required -- open

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

npdoty: I think tl volunteered to right something on this issue

<npdoty> tl didn't volunteer, but thought it would be a good idea

tl: I agreed that I could leave with that if MAY is proposed

<fielding> s/right/write/

tl: dsinger taking the action

<npdoty> ACTION: singer to draft non-normative examples on same-party (issue-164) [recorded in http://www.w3.org/2012/10/05-dnt-minutes.html#action05]

<trackbot> Created ACTION-317 - Draft non-normative examples on same-party (issue-164) [on David Singer - due 2012-10-12].

schunter: any objection on dsinger working on this

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: I think there is an action on me to write a draft

<npdoty> ACTION: doty to update draft with JS window/navigator change (coordinate with dsinger/adrianba text) [recorded in http://www.w3.org/2012/10/05-dnt-minutes.html#action06]

<trackbot> Created ACTION-318 - Update draft with JS window/navigator change (coordinate with dsinger/adrianba text) [on Nick Doty - due 2012-10-12].

<WileyS> +q

schunter: raised by nielsen to say that with a 1x1 pixel thay can not get consent

WileyS: it's a broader question, 1 you can rely on the publisher to request that for you

<npdoty> you can work with your publisher to, if necessary, include an iframe at some point to talk to the user and ask for a web-wide exception -- yeah?

WileyS: it's true that if you're a simple tag (beacon) you would not have the state to activate the JS api, it's more a business problem
... I can't think of a simple techical way to request exception without JS

<npdoty> I believe that was the original request (non-JS method for asking for an exception), and agree that there isn't a functional way to do that

WileyS: we're not going to build a non-JS api method for exception

<npdoty> +1 on closing it and not providing a non-JS api method for exception

<efelten> Examples?

lmastria-DAA: there is a number of business models that are diffulct to solve here

<dsinger> issue-138?

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

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

schunter: there was a technical proposal attached to head, using special header to get an exception
... my way forward would be to put non-normative text to say that you have to work with publisher to get consent

<dsriedel> Clarification question: 3rd-parties can directly request an exception from the user, actually by-passing the real 1st-party?

dwainberg: leave it open until we get normative text

schunter: does not work if nobody volunters to write non-normative text

<WileyS> s/normative/non-normative

thx WileyS

<dsriedel> 3rd-parties that are not included with the 1st-party exception request

npdoty: I think I respond to alex and I can add non-normative text, I can work with lou about business models

<npdoty> ACTION: doty to draft non-normative text on how to accomplish non-JS third parties that want to request for exceptions (with lou) [recorded in http://www.w3.org/2012/10/05-dnt-minutes.html#action07]

<trackbot> Created ACTION-319 - Draft non-normative text on how to accomplish non-JS third parties that want to request for exceptions (with lou) [on Nick Doty - due 2012-10-12].

schunter: lack of text about out-of-band exceptions

<WileyS> +q

schunter: it sounds like dsriedel is voluntering

<fielding> and for the control link in tracking status

WileyS: out-of-band consent should not be part of the discussion

<Joanne> David, happy to help with writing text

schunter: just want to define what it is, just a few lines

<jmayer> +q

<npdoty> ACTION: singer to write reference/examples as necessary for explaining out-of-band consent in TPE (with Joanne) [recorded in http://www.w3.org/2012/10/05-dnt-minutes.html#action08]

<trackbot> Created ACTION-320 - Write reference/examples as necessary for explaining out-of-band consent in TPE (with Joanne) [on David Singer - due 2012-10-12].

<aleecia> David Singer is drafting text explaining what out-of-band exceptions *are*

<aleecia> With a few examples

<npdoty> I think there would still be a section in Compliance on out-of-band exceptions

jmayer: we're not defiing what type of consent is required for out-of-band exception, this is a separate discussion

schunter: conclude section on the TPE, it is important to come with new text for the proposal

<jmayer> s/we're not/just to be clear, we're not now/

<fielding> Matthias, can I add a question about qualifiers?

<npdoty> s/defiling/defining/

thx jmayer

thx npdoty

<jmayer> s/this is a separate/this will be a separate/

<npdoty> fielding, did you have a question to share with the full group?

<fielding> yes

schunter: thanks a lot, lot of progress that will go quickly in the text

<fielding> I want to know if they are supposed to be in header values -- that was not my recollection from Bellevue (and David wasn't there)

schunter: text that people produced should be very simple to copy past in the text

<npdoty> I think the qualifier originally applied to both (because it came next to the tracking status value)

<johnsimpson> nick, when someone talks on the phone there is an echo and it is difficult to understand. is it because the microphone is also n?

npdoty, I did not get it

<aleecia> Perhaps David you might re-send to bump it up on the dlist

<npdoty> singer: still have an open question about what list of question the user agent might want to handle, what information is needed

<npdoty> tl: could we set up a call for that?

schunter: create an issue "validation use cases from a user-agent perspective"

<fielding> johnsimpson, yes it is because the mics in the room pick up the speakerphone in the room and echo it back to telecon

xxx: question about the definition

<npdoty> ACTION: lowenthal to set up a call about discussing singer's list of questions about what information is needed in response headers and status resource [recorded in http://www.w3.org/2012/10/05-dnt-minutes.html#action09]

<trackbot> Created ACTION-321 - Set up a call about discussing singer's list of questions about what information is needed in response headers and status resource [on Thomas Lowenthal - due 2012-10-12].

<susanisrael> vincent i think that was peter kosmala speaking

<BerinSzoka> Caveman Lawyer seconds the motion for definitions, encourages all to add to his list of undefined terms http://goo.gl/DZAak

schunter: in the TPE we focus on thecincal term, the terminology is less important

<npdoty> s/xxx/peterkosmala/

thx susanisrael, npdoty

<tlr> s/thecinal/technical/

<BerinSzoka> and for those non-Americans who don't get the reference http://en.wikipedia.org/wiki/Unfrozen_Caveman_Lawyer

<fielding> TPE will define the semantics for the header field

<fielding> s/field/fields/

<npdoty> fielding, but those semantics are likely to point to definitions in the Compliance doc, yeah?

<fielding> assuming they exist in the compliance doc, yes

<fielding> they will be consistent

<npdoty> from our host: the interests of my little daughters and their privacy, the interests of publishers (like ours) in responding to dutch law and Internet across boundaries

<fielding> vinay, tell Matthias to stop sharing

<npdoty> ... we hope we have been a good host for you

<npdoty> ... those who stay, enjoy the better weather

host managed the weather as well, raining all the time :)

<npdoty> ... lots of success with the last minutes/hours

tlr: thank youto the host, smoothest network that we had

<npdoty> scribenick: jchester2

<johnsimpson> are microphones off?

<johnsimpson> yes

wrap-up

We are getting ready for discussion by Aleecia on the last call doc

<johnsimpson> thanks

<npdoty> +1, big thanks to the editors

<npdoty> http://lists.w3.org/Archives/Public/public-tracking-commit/

Aleecia giving last thoughts. Editors taking in changes; thanks to the editors, we checked in new options for security, fraud, etc. If you want to know more, subscribe to tracking committ list. 180 issues in database at this point.

<tlr> ScribeNick: tlr

<npdoty> re last call, talk about what's useful for external feedback

aleecia: hope for early implementations
... flurry of actions recorded in the past two days. Most due within a week.

<jchester2> Tom. Are you scribing? OK by me

aleecia: next conference call will discuss opposing texts

sure

scribe: do we have cases where we get consensus on one text, or do we have at least well-baked proposals?
... process reminder: if nobody writes something, then we close things for lack of interest
... first formal objection came in -- rite of passage
... happy to set up a call with the authors of the objection to figure out ways around it
... no conference call next week

<npdoty> links aleecia has referred to:

<npdoty> http://www.w3.org/2011/tracking-protection/decision-policy.html

<npdoty> http://www.w3.org/2011/tracking-protection/objection-status.html

scribe: Tom volunteered to do a call on some issues, could use this time slot
... minimum timing (slide)

<susanisrael> will the time frames be posted on the mailing list?

scribe: on decision process, will ask editors with some of the mechanical prep work

<fielding> aleecia, do you want us to group them as options in ED drafts?

<jchester2> +q

<jchester2> -q

<npdoty> yeah, big props to people who called in middle of the night

<jmayer> Have to get a little sleep before morning class. Thanks all.

<johnsimpson> thanks to all

<npdoty> tl: will use next week's usual slot for the smaller group call

<npdoty> aleecia will follow up with timing slides on the mailing list

- DRAFT -

Tracking Protection Working Group f2f

05 Oct 2012

Attendees

Contents

Issue Triage

Reports from Breakout

wrap-up

Summary of Action Items

Scribe.perl diagnostic output