See also: IRC log
<aleecia> chair: aleecia
<tl> I'm excited already.
<hwest_> I can scribe
<rigo> scribenick:hwest
<rigo> scribe: hwest
Aleecia: any comments on last week's minutes? No comments on the mailing list. Hearing no comments. Accepted.
Aleecia: Review of overdue action items
<aleecia> https://www.w3.org/2011/tracking-protection/track/actions/overdue?sort=owner
Aleecia: Justin draft text on URL shorteners
Justin: Just got sent to the list
<ifette> k
<WileyS> No update from Peter on that proposed text :-(
Aleecia: pde not on the call, Shane may simply send to the list
<pde> WileyS: sorry, I didn't manage to get to it before another bout of travel
WileyS: Would want to get review from pde, tl, or jmayer
<aleecia> peter, time frame?
<pde> aleecia: before the F2F
<rigo> there is the Hansen/Pfitzmann definition of unlinkability in the IETF
tl: I'll help on that one
<WileyS> Yes
<pde> I should be back from travel for a few days
Aleecia: Action-201 and Action-200 on ifette
<rvaneijk> @Rigo: https://tools.ietf.org/html/draft-morris-privacy-considerations-03
ifette: Busy/holding off given the developments last week
<ifette> ACTION-200 due 2012-06-13
<trackbot> ACTION-200 Write text for ISSUE-84 due 2012-06-01 due date now 2012-06-13
<ifette> ACTION-201 due 2012-06-13
<trackbot> ACTION-201 Write text for ISSUE-112, due 2015-06-01 due date now 2012-06-13
Aleecia: Action-205, creating new issues for UAs, decided that there was no point in creating new issues, will work through some of them on this call, will leave that open
<Chris_IAB> Chris Mejia of the IAB/DAA joining via Skype in 2-minutes
Aleecia: Rigo has Action-203 (ISSUE-140) and Action-269 (ISSUE-61)
<aleecia> (noted)
Rigo: Working on transitive exceptions that keeps ad chain working, needs another week
<ifette> ACTION-203 due 2012-06-13
<trackbot> ACTION-203 Propose text (with help from Shane) about transitivity model due date now 2012-06-13
<ifette> it can be very hard to switch to a single privacy policy for a large company... ;-)
Rigo: I think I'm dong with Action-169
Aleecia: Action-170, hwest
hwest: I've similarly had a very busy week given developments, no progress
<ifette> ACTION-170 due 2012-06-13
<trackbot> ACTION-170 Provide an alternative approach to well-known URI for resources that are used in both first-party and third-party contexts without changing the resource URI due date now 2012-06-13
Aleecia: Now checking unidentified callers
<Chris_IAB> Chris Mejia of IAB/DAA on Skype
<vincent> Chris_IAB, press #41 it'll add you to the question line
<tl> What dark magic is IAN suggesting!
<aleecia> queing
<aleecia> it's smart
<justin> This seems more like a card trick than deep magic.
<ifette> justin, according to http://www.w3.org/2001/12/zakim-irc-bot that was supposed to work
<tl> Apparently, Zakim has more features that is dreamed in my philosophy.
<rigo> it has!
<aleecia> https://www.w3.org/2002/09/wbs/49311/tpwg-belle-f2f/
Aleecia: Reminder on the face to face, if you haven't registered, please do so
... Send people who want to be observers there as well, registration closes next week
... You can look for the agenda late today
... Moving on to the reason that we're all on the call today... we will continue to discuss the idea of compliance for user agents, which we talekd about last week.
<JC> Please register for F2F by next Wednesday!!!
Aleecia: we have had an interesting moment, MS has announced that IE will have DNT on by default. Many of us were surprised and dismayed, though that's not a universal.
... please don't beat up on Amy and JC, if you have frustrations with MS I understand, but don't take it out on them.
... Last week suggested a section in the compliance doc for user agent compliace. At this point, seems clear that would be a good thing to add.
... Other piece is what we would require of UAs to be compliant in terms of default options in particular.
... A user agent can be a browser, plugin, mobile, apps, etc.
<dsinger> (They also announced that conformance for them was 'do not target', which is also not conformant)
<rigo> exactly
Aleecia: Could be looking at signals for cable on TV, for example. Not talking about just a few web browsers, looking at the univers of UAs.
... I believe that on the call we had a good consensus that UAs could not speak for users, and should not choose a DNT-1 or DNT-0
... Do we have anyone else that disagrees that UAs may not send a header 1 or 0 unless the user has made a proactive choice for privacy
<rvaneijk> Aleecia, please put question in IRC
tl: While most mainstream browsers a choice means a tickybox or slider, there will be apps that using the software at all is a privacy choice
... like the Tor bundle or the hypothetical "PrivacyBrowser" that we keep using as a placeholder
<bilcorry> Does it go other way, downloading a sharing app that sets DNT:0 is ok?
<Zakim> rigo, you wanted to add a requirement that a UA must be able to handle an exception request
Aleecia: Last week we left with some confusion over AVG, we should have a more specific threshold so that it's easier to interpret
Rigo: Fundamental disagreement with this paradigm, creates more trouble than we can handle. If service sees only DNT signal and can't tell where it's from, then there's confusion
... if UA can't handle exception mechanism, then can't claim compliance with DNT
... It also solved void DNT signals, so that signals the server suspects havne't made a valid choice can use the exception mechanism to ask
... This allows a server to do due diligence
... The ability to see is what comes down the pipe, for the server
Aleecia: We're at a different point in the conversation, suggest that you create a new issue on the notion that a UA must be able to accept an exception request
... just to add a bit more to what Rigo says, the idea is that a UA that sends DNT-1 should be able to accept a claim of out of band exception, should be more than just a DNT-1 beacon
... Just looking at the idea of setting a default of DNT-1 or DNT-0 in the absence of communication around a privacy preference from the user
<rvaneijk> -rvaneijk
WileyS: Agree with tl, have had the same conversation from the other side, on out of band consent. It is an informed and express decision by the user to grant the out of band consent, so we would basically be placing that rule in the opposite direction.
<rvaneijk> Just as we have out-of-band consent we should leave room for out-of-band setting of the DNT value.
WileyS: in either case, if someone is downloading a tool that is obviously meant to be used across multiple websites, then it might be deemed to fulfill the consent requirement
<fielding> absolutely not -- that would make all resources non-cacheable
WileyS: we should add a response in the response header to tell the user that in general the server supports DNT, but that will not honor the signal because the UA may not be compliant
<justin> This is a later question, WileyS
WileyS: once you add the user transparency element in the conversation, can support the perspective of no default
<fielding> there will be no custom responses just because of DNT
Aleecia: We are working on one small piece here
<jchester2> _q
Aleecia: All I'm looking for is any person that does not think we are at a consensus on this, we will come back to other points
... UAs should not send 1 or 0 by default unless the user has made a choice
jmayer: Explanation for why I think defaults should be allowed, and why it makes sense that they won't be allowed, happy to explain but will wait to see if it's immediately relevant.
DSinger: Don't want to see the balance here go off, want to avoid an arms race of disbelief on both sides
<ifette> Aleecia phone people can use 41# to add to queue
susanisrael: Agree, not questioning consensus, looking for clarification on the definition of UA that includes cable TV
<ifette> (or 40# to drop from queue)
susanisrael: would appear to extend scope beyond online, wanted some clarification on how that was included in the UA definition
Aleecia: We don't have a consensus view on that, but there is interest in DNT working there. We have mobile included in the scope, may go beyond that as well.
... may be other contexts as well that should have a DNT solution.
<ifette> isn't this covered by the traditional definition of 'user agent' ?
<fielding> hmm, pretty sure we have a consensus decision on that -- all user agents
SusanIsrael: Trying to seek clarification on whether this effort is considered applicable to those other spaces now, or whether those are questions that will be taken up separately
Aleecia: The question will be taken up separately, there is not a consensus there.
... applicable to web and apps, but may be more. Not just looking at just the major browsers, but apps and plugins etc too.
<Zakim> tl, you wanted to say that even if a UA's UI is non-compliant, a web service is non-compliant if they ignore that signal
JohnSimpson: Want to echo the point that this was the consensus, that there has to be definite user choice as it applies to broad purpose browsers. The consensus is appropriate as long as the spec relies on user expectation as the basis for defining parties.
... if we start to get away it seems to me that the fundamental underpinning of default user choice loses some steam.
<aleecia> PROPOSED: there must be user choice, which can include choosing a privacy-protecting setting (e.g. slider) or the UA itself (e.g privateBrowser)
<dsinger> can we check whether Roy's text reflects the consensus?
Aleecia: I am not hearing any dissent on this point
rvaneijk: I also would like to [..] possibility of a user interacting with a startup flow, if so, then I would be happy
Aleecia: That seems to fulfill a user choice
... would be good for nonnormative text
<fielding> yes, that would be making a choice, assuming they don't leave the answer blank
<rigo> RvE: would possible to have choice as part of startup or install interaction
<rigo> hwest, I added the "install" part
suegl: Asks for clarification of the small piece we're talking about here
<jmayer> I strongly disagree that this was a consensus view.
<jmayer> But I'm willing to compromise.
Aleecia: I think that jmayer is the only one that is not in consensus here
<amyc> Sue Glueck, Microsoft
suegl: We do think that DNT is something you could have a default setting on
Aleecia: Yes, that's what MS just implemented
<fielding> I am quite certain that a browser installed and enabled by an operating system installation does not reflect a user's choice for any privacy preference.
BerinSzoka: It seems like, from this conversation, that resolving this issue requires bringing some of the UI design into scope
Aleecia: No, that's out of scope by charter
BerinSzoka: How do you propose to do what you suggest without bringing UI into scope?
<dsinger> perhaps Roy's text in paragraph 4 at http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#determining can help explain?
<jmayer> UI is not in scope. Defaults are. Different issues.
Aleecia: All I'm saying is that a UA should not choose without asking the user.
<rigo> roy, would your mind change if there is an interaction as Rob suggested?
Aleecia: does it make sense to think more about how to do that? Yes, that would be a great thing to take up outside this group.
... Mozilla is interested in talking through that.
<fielding> Rigo, not if it was asked when installing the operating system. If it was asked on first use by a real user, yes.
ifette: I hate to disagree, because I feel like we were so close. I generally agree with what you posted in IRC in principle, but what you just said, I do disagree with
... that somehow we're saying that PrivacyBrowser can set DNT by default, but IE cannot
<rigo> ah, my fault that I assumed that OS installation had human interaction
<ninjamarnau> I think a DNT:0 default has a significantly higher impact on a user's rights than a DNT:1 default. So maybe we need a gradation.
ifette: need to be clear how to define a UA that is privacy-specific
<BerinSzoka> thanks, Ian. That's precisely the question I was getting at
ifette: would be ok with adding some of the UI stuff to the scope of the charter
<rigo> ninja, DNT;1 has significantly higher impact on the economy than DNT;0 :)
Aleecia: I do think we need something that is easier to decide for cases like AVG
... I think we can tighten that up without talking UI
<laurengelman> there might be different specs for what makes PrivacyBrowser
<jmayer> To be clear: good policy compels a choice architecture of DNT by default. This decision has the crass intent and effect of reducing the number of DNT users.
<Chris_IAB> I also disagree with Aleecia
Aleecia: We have two disagreements - suegl and jmayer. Otherwise, no one else seems to be disagreeing with the overall notion
<BerinSzoka> isn't there a difference between setting UI requirements and having some agreement as to broad standards for choice? the former may be out of scope but the latter IS what we're talking about in recognizing that some UAs may validly turn on DNT:1 by default
<hwest_> Have we defined UI anywhere in this process?
<jmayer> Well, I disagree that there was consensus. I am willing to agree to the current proposal, with the understanding that it is part of a set of compromises.
Chris_IAB: We should talk about scope before we decide this based on the scope
Aleecia: I do believe that we are on consensus for that high level point
<bilcorry> I disagree that DNT can be set via installer, splash screen, etc. The user should have to use UI to set their choice.
<tl> bilcorry: In what way is an installer not a UI?
<WileyS> JMayer - Disagree on "packaging" this with other compromises. This was always the consensus outside of your agreement.
<bilcorry> To change the setting, does the user run the installer again?
fielding: Sending DNT-1 by default doesn't actually improve privacy. In order to improve privacy, need to comply with DNT standard. Anything that dissuades compliance with DNT standard harms privacy.
<rvaneijk> @billcorry, sorry, but setting via installer IS a UI flow
<ninjamarnau> rigo, as long as I am working for a DPA and not for the IAB I am a little biased ^_^
<tl> bilcorry: The ability to set a preference in an installer does not preclude having the choice available in the setting dialog.
<bilcorry> User will not know how to change the setting if done via installer, setup wizard, etc.
jchester2: Want to say that I support the compromise saying that the default is not in fact setting DNT, but with the hope of resolving this with a package that protects privacy.
... in the absence of adopting a final package, giving up a consumer right ot have DNT1 as a default should be there. I support this in the context of the compromise.
<tl> bilcorry: Users won't know to change the setting if it's *not* in the installer either.
<jmayer> It's as if millions of web users's
Aleecia: As chair, I am calling this a consensus. Roy did a good job of starting the text, I will take an action to flesh that text out. It will belong in the compliance doc, we will post it to the mailing list to discuss.
<rvaneijk> @rigo, will address that at the OBA roundtable next week..
<rigo> yep
<bilcorry> I'm concerned the installer can sway a choice then make changing it very hard by burying the setting
<ifette> ACTION: aleecia to come up with further text to get the consensus declared in this call around DNT and whether it can be set by default (no) in the spec [recorded in http://www.w3.org/2012/06/06-dnt-minutes.html#action01]
<trackbot> Created ACTION-210 - Come up with further text to get the consensus declared in this call around DNT and whether it can be set by default (no) in the spec [on Aleecia McDonald - due 2012-06-13].
Aleecia: would like to pick up an important part here. What does it look like for a user to make a decision for privacy, with the concrete example of AVG.
<jmayer> Erm, smartphone and Star Wars reference fail.
<rvaneijk> @billcorry, I do see your point, but think it is a weak argument.
<justin> bilcorry, You're going to outlaw nudges?
Aleecia: is being an AVG user sufficient to be consent? What general guidance can we give here?
<rigo> bilcorry, it is not only by changing the preference, if the UA has to be able to handle the exception mechanism
<tl> bilcorry: ...and this is why UI is not on the table.
<dsinger> thinks we are looking for something that has a 'primary purpose' of *privacy*?
<vincent> bilcorry, Chrome provide some opttions during install/download that you can reverse through the settings (it's quite well documented)
<justin> It is hard to have this conversation at a conceptual level without specific text.
ifette: As a preface, I think what's important is that people understand what their UA is doing, and I'm very concerned that someone sees a one line bullet item on privacyBrowser that doesn't actually result in an informed user. We need UAs to be clear about what DNT does, and the UA that wants to set that needs to accurately reflect what the spec is
... needs to be more than 'don't track me on the internet', needs to be more nuanced
<dsinger> to ifette: this is an issue for the 'check-box' in ordinary browsers as well; how do you phrase what it does?
ifette: happy to take an action on how to say this, but generally, the UA has to inform the user about what the spec actually does so the user can make an informed decision.
<rvaneijk> @ifette, come on, that is UA stuff and out of scope.
<Chris_IAB> agree, slider is not sufficient
<rigo> +1 to Rob
Aleecia: so a slider would be out of scope?
<Chris_IAB> too vague
ifette: It hink this needs to be an explicit, unbundled setting.
<bilcorry> I agree, aggregate setting (sliders) should be disallowed
<rigo> do you want to send DNT;1? - Yes!
<vincent> ifette, I think that something like the chrome checkbox for "usage statistic and crahs report" with a "learn more" link would be ok
<aleecia> what is with DNT;1? we're doing DNT:1, with a colon :-)
jmayer: It will be rare to have extensions that do only this. Likely to be part of a larger package. Going to take a lot of what already goes on if we ask to call out DNT explicitly for users.
<rigo> not sufficient: Do you really want to send DNT;1 - Yes!
<rigo> not sufficient: Do you really really really want to send DNT;1 - Dam it!
<rigo> ok, I send DNT;0
<laurengelman> :)
tl: I disagree with ifette. Most features don't explicitly explain what they do. We create software by having small, simple signals that correspond to complex functionality. Slider should be sufficient.
... if it has to be unbundled, impossible to implement
dsinger: agree with ifette in the difficulty in explaining, disagree that it has anything to do with defaults
<rigo> +1 to dsinger
justin: Agree with tl and dsinger. When we talked about exceptions, we had explicit exception language and we didn't want to be overly prescriptive. If we don't want to be prescriptive for exceptions shouldn't be in DNT either.
ifette: Ironic that tl, from Mozilla, tells me that it's too hard to unbundle, since they offer lots of options. Also, notion of bundling, it's a very fine line - don't mean to disallow all bundling, but if a 'protect my privacy' tickybox is offered, of course they tick it - but unclear what they're doing
... general concern that it's unclear what you are or aren't getting. Objection is more over the lack of explicit explanation of what's going on. Goal is to make it clear what they are and aren't getting from DNT.
<ifette> even without about:config you still have waaay more options tom
tl: I think it's disingenuous to refer to about:config as a meaningful set of settings.
<laurengelman> think about a mobile interface. You're lucky if you get one check box on privacy. There is no way to provide an unbundled notice on mobile screen, for any functionality. DNT is not any more special than anything else that is bundled.
Rigo: FIrst of all this all explains why we have said that we do not want to interfere with the UI, because that's where the innovation is coming. Don't want to preclude that innovation. If we make it harder to express consent by requiring full explanation, then you make the point in the US market that you fall back to DNT unset default, and then still can track. But then destroy AU, JP, EU as an easy mechanism to acquire rights to track or do things.
... if it's hard to obtain consent, then it will be hard in EU to use DNT in any meaningful way.
... Rob is actually arguing for simpler exhanges than ifette is
jmayer: I want to emphasize that we have a real level of generality problem. No one is going to argue that users who enable DNT should understand everything in the spec. So we have to figure out where the bar is.
... it doesn't seem to me particularly challenging to make a general statement about this being for third party web tracking. Still hard to give to users.
... Going to be really hard.
<Chris_IAB> If it's difficult to explain, then it's not simple-- and I thought this was supposed to be simple?
<vincent> laurengelman, I guess we could set the DNT setting through the mobile os setting interfaces (I don't thik we're considering this now)
adrianba: jmayer said my first point, that you should not have to understand the DNT spec. But a point about UI, the trend is to reduce the amount of UI that users are presented with. In IE, we used to prompt users before they submit a form, we asked them if they really wanted to switch to https. Users didn't awnt all these questions, they wanted the browser to make the choice for good defaults. That's what we're trying to do.
<Chris_IAB> the reality is, this IS a complex choice (with extensive ramifications) and thus it may not be possible to simplify that choice.
Aleecia: Suggest a few action items for text on this, something that they can understand without spending a year of their life on this. We will take multiple texts, evaluate them.
<rigo> Chris, but the choice is living, can change at any moment in time
Aleecia: ifette will take an action, tl will respond in particular to the text.
... But we need more than one proposal.
<laurengelman> i'm just saying, everything in tech is bundled.
<Chris_IAB> Rigo, not sure I understand your comment?
<aleecia> Ian are you still up for an action here?
<Zakim> rigo, you wanted to have my fundamental different approach
<justin> Agree with dsinger: I disagreed with ifette's first explanation, less so with his second
Rigo: I have a fundamentally different approach to the entire problem. This comes from fundamentally different approach. Should take into account horizon of the user that receives feedback from the service.
<justin> I'll offer to write something less prescriptive if no one else wants to.
<ifette> justin, hopefully i can come up with a third that you disagree with even less :)
<aleecia> thank you, Justin
<Chris_IAB> with respect to other UI, and keeping UI simple, this should only apply to simple concepts-- the problem here is, as identified by Jonathan, is that this is NOT a simple concept.
Aleecia: At this point have heard offers from ifette and justin to write up proposed text within the next week.
... Lets talk about something we may not finish in 25 minutes. What happens when a UA does not comply with what we have for a specification?
<Chris_IAB> and the effect of the choice, will likely not be transparent to the user-- this is a bad day for users. I can't believe that any consumer advocate would agree that this is a good outcome.
Aleecia: if we publish tomorrow, then MS would not be in compliance. But from standards perspective, what, if anything do we say about noncompliance on the UA side?
ifette: Want to point out that there is a lot of second guessing online - server may say that it will give an image but actually gives JS, so browsers do guess at server compliance. Server also guesses compliance in Chrome, for example special site for IE. Server also guesses HTML5 compliance, etc.
<jmayer> Ian, you're welcome to second-guess the user's preference - by asking.
Aleecia: Are there specs that have them built in, or is that just what happens in practice to keep things from breaking?
<dsinger> (html5 has sniffing written in, yes)
ifette: The examples I'm setting are just the UA making things work, not actually part of the spec.
<rvaneijk> Ian, circumventing DNT will not look good in the EU..
<rigo> ifette, and how can we help the second guessing. How can we make it so that we come closer to what is intended and not having to create a thing that we know we have to patch and work around
ifette: would be clearer if there was a way for the UA/server to say 'I'm second guessing you'
Aleecia: Maybe we put in non normative text, but that's my opinion.
<aleecia> (thank you, Heather)
fielding: Talking about compliance is not a 0/1 issue in reality. It's about what they claim to do and what they actually do.
... if browser claims compliance but it's broken, then server has to deal with that.
... Such a wide stretch, not sure that it can be expressed int he spec at all.
<Chris_IAB> bad UI = user inputs something based on an intent, output is unknown or does not comply with the intent (thus getting intent clear, is critical)
dsinger: Big difference between protocol errors and second guessing what you mean by what you send. Would lead us into an arms race, should be silent on it in the spec.
... should limit this to in-protocol behavior.
<justin> I have said all this (repeatedly) on the mailing list, but agree with dsinger's points
<rigo> but you could test whether a UA can handle an exception is easy and testable on the wire
ninja: Agree with dsinger that spec should stay silent on this. Disregarding valid DNT signal should be dealt with by authorities, FTC, DPAs.
<Chris_IAB> David, what you outline here is indeed a fundamental flaw with this whole thing, which then begs the question, why are we doing it in the first place (if it can't be done well)? That to me, is irresponsible. We should get it right, or not do it.
<hwest_> But that's the thing, ninja, it's not valid
<dsinger> to ifette: oh, I absolutely agree that the server, to be compliant, has to indicate what it is doing.
tl: Second guessing whether the signal was what you meant to send would be problematic. Shouldn't be white/blacklisting UAs, makes it difficult to implement.
<fielding> if a server claims only "we support DNT, but not for MSIE 10.0 because it has a broken setting", then it is making a true statement. FTC enforces when you make a false statement. Note that in the EU, no DNT signal reverts to the applicable laws.
<justin> According to whom, hwest? :)
tl: any server second guessing of the signal is problematic
<hwest_> If no colon, it's me talking, justin
<WileyS> Tom - then its on the Server at that point. I was thinking more of a black-list approach.
jchester: I agree with what's been said with the last few. It should be unacceptable to make sure that if in fact a browser signal's DNT-on is ignored.
<justin> hwest, Yes, I was just responding to your point about who decides it's valid. But don't mean to interfere with your excellent scribing . . .
<ifette> no one requires a site to implement DNT
jchester: cannot have server undermining privacy protection.
<WileyS> That's fine - at least the user is clearly told the server is not honoring the signal from that particular UA
<rigo> exactly Shane, your response header is clear and solve it IMHO
<WileyS> Jonathan is pushing for the pure opt-in world
<Chris_IAB> why don't we ASK then up front, Jonathan?
<Chris_IAB> in the UI?
jmayer: I wanted to make sure to be explicit about what happens by saying you have to respect a DNT header even if it's not explicit user preference. IE UA has good reason to believe it's not a user expression. There are some users who will tweak the settings, too. So maybe the server just asks in popup, widget, etc. If user doesn't confirm, then you have an exception.
<jchester2> DNT will be the norm expected by consumers around the world. NGOs and DPA will help make that happen
<Zakim> ifette, you wanted to say you're going to have this second guessing anyways. Would you rather have the user believe that the server accepted the request, or know that the server
<justin> Can we second-guess by making the browsers aver compliance with the standard?
ifette: Lots of people saying that second guessing would be a bad road to go down. I don't think second guessing is a rosy proposition, but second guessing will happen one way or another. There will be people who do not think it is an informed user choice. If you beleieve second guessing will happen, then how should we make that happen? If it's default on, the user may think that the request is honored and they are misled, or the site should be able to say that th
<BerinSzoka> Jeff: as usual, our disagreement comes down to a fundamental disagreement about goals. You see the goal as "maximization of privacy." I see many competing values, including the principle of user choice and the idea that no-cost opt-outs don't scale, so forcing DNT adoption above a certain minimum threshold is going to have consequences that are bad for the entire ecosystem, and may well force reengineering of the ecosystem in ways that are actually bad for
ifette: nothing requiring site to honor DNT, site can just say 'nope, not compliant'.
<BerinSzoka> See Opt-in Dystopias by Nicklas Lundblad and Betsy Masiello: http://www.law.ed.ac.uk/ahrc/script-ed/vol7-1/lundblad.asp
ifette: creating some sort of agreement where user expresses a preference, and the server either does or doesn't agree to use that preference
<jmayer> Ian, if a site claims compliance with the DNT spec, it is legally bound to do what we decide on this issue.
<jchester2> The site can't mislead a consumer when they receive a signal. Advertisers will want sites who are classified as "safe" to honor DNT. We will also seek regulatory and congressional action to make sure a consumer's request is honored.
WileyS: A little bit more extremist: if we claim in our PP that we are compliant, we need an opportunity to say that we won't honor bad actor signals.
<rigo> sending back "not that browser" is very evil. "not honor DNT" is fine. But only from browser sniffing is evil. Because browser sniffing is evil!
WileyS: transparent that we received DNT1 and will not be honoring. Alternative is just not supporting DNT.
<dsinger> if we write anything about bad actor UAs, then we must write something about bad actor servers!!
<jmayer> Um, there is *nothing* transparent to users about an "I don't agree" response on the wire.
WileyS: providing a clear signal to the consumer with exactly what the practices are is the right middle position.
<ninjamarnau> ifette, though I support the server giving an explicit ACK or NACK answer, I do not want the server to be allowed by the spec to disregard=change (as in DNT;1 to DNT;unset) a valid signal
tl: In the situation where you think that there are some UAs that have misleading UIs, what stops you from putting that in your privacy policy?
<fielding> The bad actor response can be more easily and effectively made in the tracking status resource and in custom content presented to the user than in a header field that almost no user will ever see.
<jchester2> Not supporting DNT is not a sustainable position for the industry, politically. It's time to accept this.
<BerinSzoka> Jonathan: I agree that companies should be held to their promises to respect DNT but as a legal matter, it's important to remember that the FTC's Deception Policy Statement requires not only deception but materiality. in other words, I don't think the FTC would win if a server ignored a DNT header that didn't actually represent user choice
WileyS: Sure, we could. Just suggesting that having it in the response is better for the transaction.
<BerinSzoka> from the policy statement: "the representation, omission, or practice must be a "material" one. The basic question is whether the act or practice is likely to affect the consumer's conduct or decision with regard to a product or service" http://www.ftc.gov/bcp/policystmt/ad-decept.htm
tl: The response header is really important, and covering the gamut of responses is important, but we want to be clear that when we receive DNT1 and think that UA is not playing fair, that at that point you're not complying with the spec. Neither of you are.
<BerinSzoka> in other words, insisting on user choice here is actually critical to ensuring the FTC can enforce corporate promises to respect DNT. remove that, and you undermine the very legal enforceability of DNT. that's a disaster from a privacy advocacy perspective
<ifette> tl, you're only not in compliance if we don't give you a way to express that
<rigo> but then send back NACK tl
hwest: tom, what you just said is not true, there needs to be a place in the spec for you to NACK it
... we should distinguish between well-formed (DNT:1) and compliance ('is it playing by the rules')
... we are conflating the two
... may be able to separate things out
jmayer: Two points. You may know whether the UA is compliant but you may not know what the user's preference actually is.
<robsherman> hwest, I think that was Jonathan, not me.
jmayer: further disentangle too, noncompliant user agents and user preference should be separate.
<ifette> jmayer, right, so you don't know what the user's explicit preference was, so you should have a way to say 'sorry i can't figure out your explicit preference so FYI I'm ignoring your request'
robsherman: this is one of those examples of substance without a remedy. We see example of that playing out over the last week. To the extent that you start ignoring their DNT headers, you have no remedy.
<justin> ifette, But there's no mechanism for the user to persistently reply, "hey, I actually mean that" when a third party unilaterally decides it doesn't like a UI.
<BerinSzoka> So, Jonathan and Jeff, do you really want to set up a DNT that the FTC cannot clearly require companies to respect?
<rigo> send NACK :)
<ifette> justin, a user could be visiting a site that doesn't support DNT for _any_ user agent
robsherman: needs to be obvious that header is different than user preference, server may be able to do something expressly inconsistent with the spec. Better to put server in a place where they can handle that within the spec than to put them out of compliance.
<ifette> justin, and there would be no way for the user to say "Hey, I actually mean that" in that case either
<ifette> DNT is an expression of your preference
tl: We've been talking about compliance a lot. Two notions of compliance. Global compliance, ie, PP statement. But as we've been discussing, DNT is a here-and-now signal.
<ifette> the site then has to decide whether to accept that expression of your preference or not. It shouldn't lie to you about what it's doing, but it's under no obligation -- you don't get to dictate terms ;-)
<vincent_> ifette, two questions: 1) would not ask for an exception be ok to be sure that the user actually does not want to be tracked
<justin> ifette, Sure, but we're trying to find a way for DNT-complaint third parties to respect user preference to send DNT signals.
tl: if we have compliance include the option of 'we're not going to do that thing' then an assertion of being in compliance is not that useful.
<ifette> vincent, we have said that to ask for an exception there must be a user gesture, you can't just fire off javascript
<rigo> +1 to tl
tl: if we're going to be making promises about compliance, it needs to be in compliance all the time.
<justin> ifette, And actually, there would be a way to do that for third parties that do no compliance at all. That's a TPL :(
<ifette> vincent, so you can't just cheaply fire it off. ALso, the API is asynchronous so you have no guarantee of an immediate reply
<rigo> it can not be global compliance announcement IMHO
<WileyS> T1, Disagree - compliance means responding to the header and users then have an option on what to do from that point.
<rvaneijk> if I (hypothetically) would like to install an addon called 'keep-my-DNT-1', I should be able to do so.
<rigo> nack aleecia :)
<vincent_> 2) you said that chrome may have to spoof IE user agent to bypass second guessing at some point, how would the server know that the browser is actually chrome and resect dnt?
Aleecia: These are my views, not as the chair. Summarizing from the mailing list, not hearing that there should be a requirement for all incoming signals to be adhered to. Hearing a question of whether you may drop UA noncompliance or not mention it at all.
<ifette> vincent, it wouldnt
<ifette> vincent, but at least the user wouldn't be decieved
<WileyS> rvaneijk - agreed - and it would be difficult for any Server to argue not honoring the signal from UA 'keep-my-DNT-1'.
Aleecia: what I think for why not to take this on. Whether it is ok to drop a signal from noncompliant UA will vary from region to region. Not convinced that there is one answer for this that works in all places.
<rigo> rvaneijk, only if it would be able to handle exceptions
Aleecia: Regardless of what the spec says, that doesnt' change the legality. THere has been that point that you can't distinguish whether UA or user turned it on, puts companies in a difficult position.
<ifette> sad but true that we can't distinguish plugins
Aleecia: we're going to have multiple browsers, all sending a signal, so if we have something that is not a compliant UA, we don't know that. [Note: getting confused scribing, so please hop in?]
<bilcorry> Should prohibit one UA setting the DNT for another UA
Aleecia: As soon as we get to some sub-part of the browser, we no longer know who is sending the signal. Also, UA string spoofing.
<ifette> aleecia: if it's a plugin sending the signal, you have no way to distinguish between the plugin or the UA having set the signal
Aleecia: Leaving UA-setting-for-UA out of spec
fielding: HTTP editor hat, HTTP does not deal with anarchy. The group comes up with what it should do, and if the UA sends an invalid field/sematics, then that's an error.
... in the past, when the UA or proxies have sent invalid header fields, then Apache has blocked them.
... Apache wants to keep HTTP protocol free and standardized for the Internet.
... So while I appreciate the opinions of what a particular company can do, if MS has a default DNT1 and the WG decides that we require browsers not send a default, then Apache will quickly patch to delete the header from IE UAs.
<rigo> and all this because we can't send NACK?
tl: So if I'm an app developer and think it's ok to have some extra headers, can't use Apache?
<justin> fielding, How does the standard deal with the "anarchy" of a rogue third-party to send a false response header that it has out-of-band consent?
<WileyS> In Issue 143 we're still requesting the DNT Header Request come paired with the name of the "Setter" - this should cover one UA activating DNT on another UA
fielding: Can change implementation, could move header to another field, doesn't happen by default.
<aleecia> that conflicts with the decision last week, Shane
<jchester2> Responsible companies that want goor PR and relationships with the largest advertisers will have to respect the signal from IE.
<WileyS> Disagree - we didn't close on 143 last week Aleecia
<justin> Third-parties can falsely assert out-of-band compliance under the standard today.
fielding: if it's necessary then we'll make it impossible to read it entirely. What an individual developer wants is less important than the internet remaining free.
<jmayer> I think Roy's prediction here is totally wrong.
<justin> That does not mean the standard is broken.
Aleecia: We will talk more in Seattle. But we have consensus that MS is not in compliance with the spec as it would be published today. We will be getting proposals on AVG, and on AU text.
<fielding> justin, the standard does not. Apache does.
<justin> fielding, And what will Apache do for rogue out-of-band consenters? Feel free to move to mailing list.
<rigo> HTML5 tagsoup, what is Apache doing about it? :))
Aleecia: Adjourned!
<justin> Valiant job, hwest
<aleecia> heather, thank you so much for scribing
<aleecia> this was a wild one to capture and you were awesome