See also: IRC log
<npdoty> if you're on IRC and call in, please let us know who you are
schunter: very productive discussion yesterday, made some progress
... we'll walk you through the changes we made to the specs since yesterday
... then Tracking Selection Lists
... then discussion of issues for the Tracking Preference Expression
... lunch
... discussion of issues for the Tracking Selection List
... and some planning
choosing scribes by counting off :)
Matthias: yesterday was focus on compliance spec, today will be going through details of TSLs and TPE
... first session, Aleecia will walk us through changes to compliance doc
... big question is to find what blocks us from moving to FPWD. Want to move to FPWD with this document, make sure there's nothing the editors slipped in that is objectionable
... Aleecia reads diffs from the doc.
<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance-diff-20111101.html
JohnSimpson: Some ISSUES aren't labeled with numbers, will the spec be updated?
Aleecia: yes
<scribe> ... continues reading diff
RESOLUTION: move spec to FPWD
<npdoty> < many hands raised for comfortable, no objections, a couple abstentions >
Matthias: Will go over changes for TPE document
<paddyu> It's really hard to hear over the phone, can each speaker use the microphone?
<npdoty> the diff that Roy pointed to is here http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2011%2Ftracking-protection%2Fdrafts%2Ftracking-dnt-20111028.html&doc2=http%3A%2F%2Fwww.w3.org%2F2011%2Ftracking-protection%2Fdrafts%2Ftracking-dnt-20111031.html
ifette: are we using "exemptions" or "exceptions" in a consistent manner?
Roy: you set up exceptions on the client side, and then later we can talk about server-side exemptions
Heather: in that case it's not consistent between documents
Roy: yes, there's some semantic confusion
... in the spec it will be "exceptions"
Matthias: continues reading, points out more exemptions/exceptions
npdoty: still confused on exceptions/exemptions
Roy: When a party has an exemption, they don't have to do X
... if a user has given an exception to its requirements, the user has granted that exception
Aleecia: One is a category, e.g. security
... the other is the user opting back in to something
dsinger: not sure the terminology is appropriate, the thought that they become exempt from compliance seems odd
TomLowenthal: Agree with david but there's a twist. They are exempt from the general requirement that you must do X when Y
... MUST NOT... EXCEPT IF
dsinger: Exception to the general rule, but must comply with the rest
Roy: Currently it's all "exception"
... Continues reading from Section 3
<npdoty> we do use "exemption" a couple of times in the compliance spec, in describing categories with lessened requirements
<hwest> I don't think that we use 'exemption' and 'exception' in any sort of organized manner in the compliance spec - I propose that we task us editors with proposing a rationale for using one over the other, and come back to the group with it
<rigo> how do you want to use exemption and exception in any sort of consistent way if you don't know their meaning in the context of the spec?
<suegl> I suggest not referencing any specific laws in 5.1.
Rigo: Would prefer 5.1 to reference Section 5.3 of the EU privacy directive
Aleecia: Agree, and rather than "adherence to" say "consideration of"
<suegl> It's a matter of legal interpretation whether that particular law is relevant
<npdoty> suegl, can you explain why?
<suegl> It's not typical to reference specific laws in standards, AFAIK
<aleecia> Article 5, paragraph 3 of ePriv Directive
<aleecia> But we are an international standards body
<suegl> Yes, but we're not an international legal body.
<aleecia> So we should *consider* what they have done, we're not saying we will do what they have
<aleecia> (...which we really very much may not want to. But we should at least think about it, IMHO)
<npdoty> from the charter: "The group will actively engage governmental, industry, academic and advocacy organizations to seek global consensus definitions"
Matthias: Rigo makes a point that it's good to consider these things, would like to leave it in
Roy: Can we poll the group?
<suegl> I would recommend against providing legal advice in a standard
Karl: Can we put an ISSUE number here?
dsinger: don't want anything that would suggest we've done a legal analysis and that by doing X you are covered
<rigo> sue, I wanted to just express that helping with 5.3 is one of the intentions
<aleecia> Issue: should we consider applicable laws and regulations, such as the Article 5, paragraph 3 ePriv Dir
<trackbot> Created ISSUE-98 - Should we consider applicable laws and regulations, such as the Article 5, paragraph 3 ePriv Dir ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/98/edit .
<rigo> consideration, not adherence to
Roy: continues reading section 5.2
<aleecia> Sue, does this work for you?
<aleecia> We are not trying to claim to be lawyers... but would be foolish to build something that's DOA
<suegl> Yes, that works. It was "adherence to" that was the problem. Thanks.
<aleecia> Agreed - thank you
<npdoty> "no weirder than the rest of the paragraph"
<Joanne> agree with "consideration" instead of "adherence to"
Roy: Is there anything from yesterday that we've missed?
(silence)
Matthias: Need to make "Consideration of" instead of "Adherence to", after that, want to get a poll of whether we can move to FPWD
RESOLUTION: will move to FPWD
aleecia: we have not been talking about the third deliverable in the last weeks
... let us have an update on this
<paddyu> does anyone have a link to the doc?
<aleecia> (which doc, Paddy?)
<npdoty> paddyu, no W3C official doc here yet (that's the topic of discussion), but the Microsoft Member Submission would be relevant http://www.w3.org/Submission/web-tracking-protection/
Andy and Karl: Introducing Tracking Selection List
Andy: Tracking Selection lists allow the users to have control over tracking that is happening
... consists of allow and block rules. User can have more than one list
... multiple browsers support content filtering lists, e.g. Truste is a vendor of these lists
... goal is to allow users to surf with their tracking selection lists on, we want to create an interoperable format
<rigo> FrankGerstenberger: does it block only tracking or any content?
Frank: does this block only tracking
Andy: It's basically a file format
... lists can be specified to specific scenarios
<rigo> list only blocks third party stuff
Matthias: What is the effect on an actual site?
Andy: Site will look the same just without third party content
<rigo> Shane: it will just block the request
<npdoty> "third party" in the sense of the same-origin policy, not the "third party" concept we discussed yesterday
Shane: Why does this use a block or allow mechanism, why not just one
<rigo> .. .why did you have blacklist and whitelist? Not only black _or_ white
<rigo> AZ: that's exactly what we want to talk about
Andy: we wanted to support as many lists as possible, black and white lists
<rigo> ... overwrite blocking with withelist. dissallow site but allow parts of it
<npdoty> "the DVR of the industry"
<npdoty> "a really bad ad-blocker"
Karl: shows an actual example
... the first party got blocked w3.org in Opera
<npdoty> "the definition of easy"
Karl: unblocking needs to enter a list and delete it manually
... list is searchable
Andy: shows easy privacy tracking protection list of i.e.
... an ad blocking technology
... content is still there just hidden
<npdoty> just a comment for the minutes, I think Andy is saying that the EasyPrivacy list example is *not* an ad blocking technology
Tom: easy list is not the same as ad blocking, easy list is about blocking tracking content of specific kinds
<jmayer> We did a study of what these lists do: http://cyberlaw.stanford.edu/node/6730
<npdoty> tl: "a general purpose technology"
Tom: List allows to block certain malicious content very fine grained
<vincent> http://www.blaeu.com/uploads/tds-rules-rdef.html (rob) based on adblock technology without hiding rules
<vincent> http://www.blaeu.com/uploads/tds-rules-rdef.txt (Rob)
<rigo> sue, do you still want to talk?
Aleecia: I wanted to give people the same starting point for these tracking selection. Question on how technoligy works?
<npdoty> suegl, do you want to type or try to speak up on the speakerphone?
Andy: In the New York Times example beacons and invisible content was blocked
<karl> selective http requests lists
Matthias: Is this used to show user preferences?
<Frank> Agree it should be called something other than "tracking selection" as it is more general purpose
Andy: Anybody can make these lists
... There are ways to detect for a service provider if specific content is blocked by the user. First Party can see the user enabled and what didnot load
<npdoty> (that was in response to: Alex: is there any way for the first party to know that an image or other content isn't loaded?)
Karl: There are users that do not see images. So why does the first party need to know?
Dave: You are preventing loading. Preventing tracking is just a side effect
<jmayer> Graph of TPL effectiveness: http://dl.dropbox.com/u/37533397/tracking_the_trackers/tpl_study/results_graph.png
Shane: Aleecia: We need to discuss if we want to do this?
Aleecia: Should the working group pick up this topic? We need to find a consensus
<npdoty> Shane: the current DOM solution for determining whether content was loaded or not is burdensome
Matthias: Lists allow browsers to cooperate. For the sake of interoperability but it does not mean that every browser needs to implement it.
Roy: I disagree with having this in the charter. It is basically Ad Blocking not Tracking Protection
Ian: The lack of standardisation does not really pose a problem
Tom: It is one third of the charter. The group is required to deliver
... this is classic standardisation work
JC: Consumers should be able to whitelist as an exception to dnt
Dave: this is a hostile move of users to sites
<paddyu> I vote against including the web tracking protection in the spec
Dave: W3C should not say that is generally okay to block content
<Mike> I vote against including the TPL standard as part of this group's work
Dave: dnt should be about not needing content blocking any more
<JC> I feel we are conflating how lists are implemented versus providing lists for granular control
<JC> Users should have a way to indicate exemptions to the DNT signal
<Mike> Agree with Dave that W3C should not be supporting standards for blocking broad categories of content, including advertising.
Karl: developers need standardisation to enable their work.
<tl> s/quarter/third
Kevin: Filtered URL list might be a more general approach
John: if it is in the charter we should consider it
... we need to develop at least a strawman to see how this adds to dnt
<npdoty> JohnSimpson: I think a strawman document makes great sense and if we can't develop consensus on that, that would be the time to stop
Amy: It is not necessarily hostile but offers users a choice (not sure if I got it right)
Tom: users come first in priority. They are the boss of their browser.
Peter: We know there will be actors who do not respect dnt. Do we want to address these with blocking?
Ian: I think the lack of standardisation is not a big issue. Not much work to adapt to all three standards
<pde> ifette, one thing to note is that in addition to different syntaxes, the semantics of the lists are different
<pde> ifette, the MSFT spec allows one list to whitelist in a way that overrides any other lists the user has subscribed to
<npdoty> pde: could be a way to level the playing field for the good actors that respect DNT by enabling users to block bad actors
<pde> I believe the ABP lists do not work that way
<pde> (though I'm not 100% sure of that)
Shane: dnt signal turned on allows user a communication with a publisher. If wesupport selection lists (I do not support this) publishers need visibility of user preferences
Tom: Publishers and users need to have a dialogue. oneside blocking is not the way it should work. But not all parties will play by the rules
<hwest> Ok, so lots of talk about whether or not this is a good blocker - it is, or it isn't.
Tom: so there is still a need for the user to block content from prties who do not take part in this fair dialogue
<hwest> It either blocks ads and other things well, or it doesn't block ads and other things well
<jmayer> It's an exceptional ad blocker - that's why it's a good tracking blocker.
<hwest> Right - I think trying to argue that it's a bad ad blocker and a good other things blocker is somewhat misleading
<amyc> to Tom's point, addressing this issue in this forum would allow input from publishers and ad industry participating in wg
Frank: User will expect to have the freedom to be tracked or not. Content blocking should not be part of this dnt standard
<jmayer> The online advertising industry made design choices such that ad content == tracking content.
<pde> can I be on the speaker queue without being tracked on Matthias's piece of paper?
<jmayer> Users don't have any other choice if they want to protect themselves today.
<tl> citation for the priority of constituencies: http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
DaveSinger: I did not want to say that users MUST load all content of a site. But I do not want W3C to tell people blocking is okay
<fielding> FWIW, changing the expression of an online webpage is arguably the same as creating a derivative work. Users can do that for themselves, legally, but I think an organization that publishes such a mechanism for doing it automatically is infringing copyright and should be subject to the legal claims by all copyright owners.
<dsinger> I am not happy with the W3C saying that it thinks that normal operation of the WWW involves users finding and using "load blocking" lists
Rigo: What does it mean in term of financial loss. We need to openly talk about the elephant in the room
<vincent> would a TPL of 1st parties that embed elements from 3rd parties that do not respect DNT make sense and satisfy publishers?
<johnsimpson> Rigo is exactly right.
Ian: These lists block all major ad networks. so we probably talk about a major sum of money
Abine: we try to do it granularly. Block not all ad content. Standrard would allow for a much higher level of fine grained blocking
<Frankie> Why are people blocking ads ? My opinion: because they want not to be tracked, NOT because they will not look at ads....
Speed of site loading might be another reason
Ian: If there are too few people it is not worth the effort
... we are talking about 50.000 probably
<npdoty> Alex_2: many of the lists are proprietary content (about malware, etc.) and so companies might not invest in lists if they were publicly published
<npdoty> Aleecia: summary for Ian, either there are too few people for it to be worthwhile or too many that it's a revenue problem, so resolving this question isn't relevant for Ian's support -- Ian agrees.
<dsinger> on the number of users using it...my concern is that if these blocking lists get popular, legitimate businesses that find themselves adversely affected will take counter-measures. I am not sure where it will end.
<pde> procedurally, I am curious about whether anyone has been persuaded by this conversation to move from "we should not standardise TPLs" to "we should standardise TPLs"?
Aleecia: are there ways we can build this only on the advantages and illiminating the disadvantages we collected?
<karl> the browser adding to TPL if the server replies "no" to DNT?
Aleecia: building just another ad blocker is not good use of our time. Can we just specifically block data transmission?
... not blocking ads but invisible tracking, still showing the ads
quick poll: how many people will be satisfied with this approach: about half the room
Shane: it eliminates the economic value of ads
Aleecia: we have a disagreement in the room. split in half. we will continue to discuss this
<pde> it isn't clear to me that we should come back to TPLs unless we see movement from those opposed towards wanting to standardise
Roy: Dave: we should stick to work on privacy. The list is a much broader issue
<karl> do we want an action item to bring it to TAG?
<pde> tl, clearly the group members reason for opposing standardisation is not about standardisation, but about wanting to deny assistance to the underlying practice of content blocking
Peter Eckersley on fingerprinting browsers
<aleecia> panopticlick.eff to see if your browser is unique
<aleecia> DNT's minutes are public, Josh
<aleecia> At the very least after they're cleaned up...
<aleecia> IPv6 has MAC address for most OSes
<aleecia> Peter's full paper is available, we can ask him for slides too
<fielding> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt-20111101.html
<fielding> is the final version to be sent to W3T for publication as FPWD
Will look at blank spots in Tracking Preference Expression document
Will discuss what feedback the server provides when DNT 0 or 1 is ent
Will spend 10 minutes discussing goals
Reviewing goals in the document
Guidance for site specific exceptions - I see you have DNT enabled but I need you to opt-in if you want to access my site
<paddyu> frank, which document are we looking at?
<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
<npdoty> dsinger: the reasons I had in mind were knowing which servers responded to DNT at all, which clause I might fall under from the server's point of view, whether my DNT signal made it to the server at all
swiley: trying to think through how to get through cachable and non-cacheable environments, would have to be URL specific
tom: this needs to be on a per request basis, don't have enough state to tell what's going on
... we can have a variant on the header to deal with cached objects
Matthias: feedback should be on a per request basis. User should be able to know if tracking took place
... agreement on goals: feedback, auditing, transparency
<npdoty> in discussing goals, should we also talk about http://www.w3.org/2011/tracking-protection/track/issues/98 ?
JoshS: concern if you have too much information, will drown the user. If 50 elements on a page, too much info for a user
Thomas: In the charter, UI elements are out of scope. There is a lot of abstraction between what browser sends and what it exposes to customer
Matthias: Should we add as a goal consideration of legal and regulatory
tl: UI is out of scope. If I want to make a crappy browser that shows user everything, I am compliant with DNT
DavidW: Must be a balance between usefulness of the information and the cost or providing
Nick: Can someone provide more detail around the goal with respect to legal
DavidS: If you respond that you honored DNT, I have something from year that says you didn't track, and that is useful.
ninja: On EU regulatory, 5.3 requires some kind of consent from users when cookies are installed.
amyc: one of goals should be simplicity of implementation on server side.
<vincent> users consent means any freely given specific and informed indication of her wishes (Rob)
AlanC: Talking about complying with ePrivacy, doesn't seem like anyone in Europe knows what complying with ePrivacy means - each EU member state still trying to figure it out, so will be hard for this group to work towards
NickD: We should think about enabling usability for the end user. Even if we don't define the UI< we will make decisions that will impact usability
Thomas: disagrees with criteria of usability. We don't need to write a system that understands each transaction. Design a system that enables the agent (browser) to provide useful information to users.
<Josh_Soref> http://www.w3.org/TR/P3P/#goals_and_capabs -- The goal of P3P version 1.0 is twofold. First, it allows Web sites to present their data-collection practices in a standardized, machine-readable, easy-to-locate manner. Second, it enables Web users to understand what data will be collected by sites they visit, how that data will be used, and what data/uses they may "opt-out" of or "opt-in" to.
Aleecia: Goal is to give browsers enough information so they can do something useful with it.
NickD: we should do things that enable usability
DavidW: there must be some measure of the information that has to be provided to enable good usability.
... Express fine-grained track/no track is a goal, not a criteria
Matthias: communication efficiency is important
DavidS: Simplicity should be appropriate to the level of tracking that is going. Will be easy for simple sites, more difficult for more complex.
<npdoty> regarding usability, the CMU report: "Why Johnny Can't Opt Out" published yesterday, may be relevant: http://www.cylab.cmu.edu/research/techreports/2011/tr_cylab11017.html
KevinT: Data should flow. Two use cases: 1. could flow to a user through browser, 2. to a compliance tool
Thomas: we need a lot of features in the protocol. Doesn't mean they're all implemented in the browser. Users will want a simple indication, but have ability to drill down, or use third party tools. Take usability out of criteria, and have a sufficiently rich feature set to support desired use cases.
... The legal regulatory/legal compliance should be a criteria, not a goal.
Matthias: Go through response options
... 1st option, no response
<JC> Great session by Aleecia and Matthias
Matthias: well-known location for machine readable policy
... could be different flavors of policy. Parts of site might, might not honor
... whether static or dynamic
... A static header field for machine-readable policy
Roy: similar to previous response
Thomas: can we do a quick straw pole on 1st two options
Matthias: 3rd, static header field stating DNT is on.
... 4th, dynamic header field indicating that tracking is enabled or disabled for this user (and why).
DavidS: do the first 3 indicate if I'm tracking you or not?
Aleecia: the location is static but the content is dynamic
ChuckC: Is there any human readable element that goes with these expressions?
Matthias: focus is on different options to get information across
karl: the list is not clear to me. would love to see what I see
Rigo: well known location has many advantages. Know that site is DNT enabled.
... when you try and distinguish between different policies for different parts of sites, well known location still works, but the file that describes gets complicated.
Matthias: we have four options on the table. After break can discuss other options, will go into more detail on each of four.
Thomas: on dynamic header, sounds useful, but don't know what a user is. We need to narrow down each one a little more before talking about these in more detail.
<vincent> aleecia: Presenting "Track Gap: Policy implications of User Expectations for the 'Do Not track' Internet Privacy Feature
<karl> -50% expects that the ads clicked tracking will stop
<karl> wondering if there are variations of understanding depending on the countries, cultures
<paddyu> is there a link to this study/research?
<paddyu> w/r/t widgets
<vincent> dicussion about Lorrie's new paper "Why Johnny Can't Op out"
<vincent> I know what aleecia presented was published at the princeton workshop
<vincent> http://www.w3.org/2011/track-privacy/papers/AleeciaMcDonald.pdf
<npdoty> pilot results presented at Princeton, but this paper has the complete results
<Zakim> karl, you wanted to ask how people know what all these technologies mean?
<vincent> karl: surprised by the people knowing IP and global level of knowledge
<vincent> aleecia: IP address was explained
<karl> ahaha tracking following a link from twitter to an article http://marketplace.publicradio.org/display/web/2011/11/01/tech-report-if-you-tried-to-opt-out-online-tracking-probably-didnt-work
<karl> there was this at the end of the uri #.TrAUp3TBAI8.twitter
<npdoty> the CMU/Lorrie Cranor report I mentioned earlier: http://www.cylab.cmu.edu/research/techreports/2011/tr_cylab11017.html
<vincent> WileyS: in the 1st party context, did you try to use other term ( brand, compay)?
<vincent> aleecia: 1st vs third party was known from other context (previous study)
<vincent> Matthias: back to TPE, quesitons about the different options
<vincent> ... : discuss the different options and then the details
<paddyu> Can we get a link to the study about first v. third party and user expectations?
<vincent> ... first, visit , you sent a request with the DNT signal and you get a response
Thomas: the sever does something with DNT as part of his response
Thomas: second option the server send a response with a pointer to DNT
... what kind of information do you want to see at the UA end
karl: are the options exclusive?
Matthias: not exclusive, one might be for the user, the other one might be in machine readable language
tl: in the response I'd like to see
... what the user said
... does the server comply
... is the server beliving as a first or third party
... is the server believing it's acting as a first or third party
alex: first party vs third party, does it matter?
ninja: cant he server know if it's a first or third party ?
tl: it matters for the user interaction with the server (first party vs third party)
... the response from the server could block any futur requests
sid: the exact function of a paranoid mode is a UI question out of scope, but it's enough to show that it's a possibility
<karl> karl: the only way the tl case could be working, if the client was making a HEAD and then a GET depending on the HEAD, but that would be costly.
hwest: ping the URL of a well-known location and then decide if the browser is going to proceed
tl: one of the element in the response should be the echo of the request
john: user should only care if they have the request
aleecia: you may want to know what it is that you sent
<tl> to be clear: i can can get the html, see a dnt:101, then refuse to get any of the references, or 1x1 gifs &c
aleecia: DNT helps restoring user trust, if we want user to click on ads and know that nothing happens to them the ack worthes the cost
WileyS: the reply should be "I saw it and I comply" or "I saw it and I do not comply"
tl: people saying I have an exception are not saying I'm not complying, it means "I believe I have an exception"
npdoty: the answer would help user to know to which website they opted back in
<npdoty> amyc: what does the static site policy fail to capture? sites are either compliant or not
dwainber_: what is the cost of all the answer from a website
tl: I request a page and have a elements to download and in the response I see "what the party beleive they are (1st vs third)" and wether or not they comply
dwainber_: the cost is about the cost of the implementation
<karl> * issues with hotlinking and referer
<karl> * issues with ssl (no referer)
dwainber_: someone has to store if the user opts back in
tl: the cookie stored in the client could be used to store the "Opt-back in"
... and then the server respond "I see DNT and a opt-back cookie", browser pop up message for confirmation from user
Matthias: where to store the DNT compliance file
... static url: pros and cons?
hober: expecting a single well known url is to coarse grained for large website
dwainber_: one time, one party having different policy for different parts of the website
matthias: for ibm.com they're would be part respecting DNT before other parts (transition)
... some piece of a website may require DNT for business processes
WileyS: For Yahoo! it'll be different at least when they act as a first or a 3rd party
fielding: when large site do tracking they generally use different domains
aleecia: Exempl: mozilla labs collect data about you, other parts of the website do not
Matthias: now looking at the everything is dynamic solution
... pros and cons
<karl> I wonder how the DNT works with wikis history.
jmayer: the more dynamic we go, the more we give the browser the ability to enforce the user expection
hwest: cons: the reponse may change according to who request the policy (ex if it comes from the FTC)
... it'll allow descrimination
<npdoty> hwest, I'd definitely appreciate more detail on its not being feasible
<ifette> if you bloat each request by 100 bytes
<ifette> that will have a huge latency impacy
<ifette> having a URL in response to each request would be a huge hit
tl: the header is request specific, the well known URI gives lot of specific information but it is not related to the specific request
<karl> ifette, define "huge" :)
<ifette> karl, big enough for us not to send it
<npdoty> ifette, current proposal from tl is a single character -- is that too many bytes?
<ifette> no, single character is fine
<ifette> even 2-3 probably ok
<ifette> but a full URL would be not ok
<hwest> npdoty, I'll get more information on that for you. It's outside my realm but I have heard very strong opinions on it
<npdoty> ifette, but there's a number of characters at which point you will refuse on behalf of Google's servers?
<ifette> npdoty likely on the order of 4+, yes
jmayer: disambiguation between dynamic (there might be some option in what you get back) vs dynamic reponse : the server does have to send a different reponse every time
<ifette> what if we had a response that was a string that got appended to a known URL?
<ifette> e.g. dnt:0;<string> where <string> gets added to /dnt?reason=<string>
<ifette> or something like that
<ifette> gives us some flexibility of dynamic url/response
<hober> ifette: /.well-known/dnt?reason=<string>
<hober> :)
<ifette> yes
<npdoty> so your main complaint is with fielding because he wants to use "Tracking:" instead of "Dnt:"?
tl: three bits in the header and then pointer to the well known URI
<fielding> field-name + ": " + CRLF + length of field-value
<ifette> we prefer shorter header names :)
fielding: on the issue of verification : if the answer change every time it will be hard to verify (for example you can not go to court) it's not recorded
matthias: the next would be to discuss when the dynamic and static cases could be used
... well nown URL is limitied and dynamic is costly
aleecia: tl and hwest should write a proposal together
<tl> ACTION: tom, heather, and ian to propose a header/uri hybrid solution by tuesday [recorded in http://www.w3.org/2011/11/01-dnt-minutes.html#action01]
<trackbot> Sorry, couldn't find user - tom,
matthias: element such as caching should be discuss in more details
... other big piece is "opt-back in"
<npdoty> ACTION: tl to propose a header/uri hybrid for server responses (with west and ifette) [recorded in http://www.w3.org/2011/11/01-dnt-minutes.html#action02]
<trackbot> Created ACTION-30 - Propose a header/uri hybrid for server responses (with west and ifette) [on Thomas Lowenthal - due 2011-11-08].
matthias: 2 use cases: 1) I have DNT on and visit a website that do no honor DNT
... what the site should do?
<rigo> I suggest to look into the P3P policy reference file format and well known location:
<rigo> http://www.w3.org/TR/P3P11/#ref_file
redirect the user to a website "disable DNT to come back"
<rigo> it mainly does the same: distinguish different policies of parts of the sites and third parties
scribe: 2) persistence of the opt-back in (in the server or in the client)?
<rigo> especially 2.3.2.9.1 OUR-HOST Extension
jmayer: we could use standard stuff like cookies and leave the implementation to the website
dwainber_: if the persistence of cookie can be used to store the opt-back in, why not using them to store the "opt-out"
WileyS: User should be able to see a list of their exception in one place,
... therefore prefer client side solution to cookies
<ifette> also, the users who care about this are probably also the users who delete cookies
<ifette> so you don't want to confound the two
tl: cookies are an appropriate method to store opt-in cause if user delete them, they're prompted again
<hwest> I'm fully in support of the Felten thesis "if you're going to track me, use cookies" - essentially, use something that has transparency and tools around it
<hwest> So that the user understands what's going on.
<hwest> It seems weird to use tech that would otherwise would not really be supported by privacy folks to track privacy preferences...
fielding: have a standard cookie name for the opt-back in
<ifette> (fwiw i was referring to using cookies as an opt-out to be somewhat unnatural and strange, cookies for opt-in seems quite natural)
fielding: well defined cookie name, the browser would be able to know which cookies are opt-in cookies
pde: why not using user name and password?
<hwest> Not all websites have login systems
<ifette> i don't like the idea of forcing a specific cookie name / syntax
<hwest> And I wouldn't support shoddy login systems for the sake of an opt
FrankW: interesting to combine DNT with a cookie mechanism
<ifette> or expecting the browser to treat these cookies separately
<hober> ifette: me too
<ifette> it becomes a mess for the browser
<ifette> do we then show these with the other cookies? Delete them when the user says delete cookies? have separate ui?
FrankW: can you imagin to define different cookies, one for personal profile, one for analysis
<pde> hwest, it's true, but not all sites have opt back ins either
<hober> ifette: yup.
<ifette> you're essentially cramming a parallel system into another, and that just asks for problems
<ifette> they're either cookies, end of story, or they're something else
<ifette> but please no Frankencookies
<hwest> We have a lot of tools to do things like persist opt out cookies - I think persisting an opt in cookie should be rather similar, and I think the idea of using existing tech and waiting to see whether we need to enshrine that in standards or whether we can count on sites that need it to figure out how to keep opt ins
npdoty: does the opt-back apply to the visited website or to the third parties which may then track me everywhere
<pde> hwest, the tools I'm familiar with to persist opt-out cookies are extensions; are there any others?
<ifette> it's a bit of a hack tbh
<npdoty> because if I grant tracking while I'm on a particular first party, we probably don't want the first-party special opt-in cookie to be sent to all the third party trackers on that site
<ifette> i don't really like the idea of cookies with strange rules
<ifette> either use cookies or use something else
<hwest> pde, you're right, or standalone programs. Not saying that piece of it is wrong, but fingerprinting the user to persist an opt seems like a bad idea
<rigo> why don't you send dnt=0 in this case?
<pde> hwest, I agree :)
<pde> and to defend the "persist by login" approach...
<eberkower> Wouldn't the first-party's cookie come from its own domain and not from the various third parties' so that the first-party opt-in cookie wouldn't apply to the 3rd parties' practices
<pde> it isn't really clear to me when or why users would ever be opting back in without login
<amyc> do we need to specify technology needed to obtain or recall override?
WileyS: I like the cookie but we need a solution to skip back from the cookie to fingerprinting for some device
<npdoty> dwainberg: if third-party cookies are blocked, what would that do to this type of cookie?
<npdoty> amyc, I think we do need to know whether the browser will manage it or the site will manage it
hwest: we should give some example, guidance but not saying "that the way you do it"
pde: why would I opt-back in to a website I do not logged into
<hwest> Paywalls will evolve as will login systems as will all the other pieces of this puzzle - lets assume that it is good to futureproof this by giving guidance but not requiring a given technique
<ifette> indeed, why do we have to specify how the list is maintained
WileyS: payroll is not the sole option, there is also the solution "you either give us an exemption or you just do not visit our website"
<pde> I think WileyS just illustrated my point well
<pde> there are lots of sites today that say "you must log in before you can read this content"
<pde> and I find the idea that a user can opt-back-in and remain totally anonymous, tenuous
aleecia: login would be too complicated and we need something that goes beyond cookies (user delete them)
<pde> it seems to me that the best level of non-identification they can hope for is a pseudonym on the site
<ifette> I think we should just say that user agents maintain a list of things you've opted back in to
<ifette> and how that is done is left to the implementer
<ifette> fwiw
<pde> ifette, how does the user agent know what to add to that list?
matthias: I send DNT:1 plus some other stuff (login, cookies) which allows the website to ignore DNT:1
<ifette> pde, could be any number of things, a specific response in the DNT header that triggers UI, a JS call, ...
matthias: other solution the browser send DNT:0
<ifette> presumably you want some browser confirmation before it starts sending DNT:0, right?
matthias: why don't we consider option B?
<pde> ifette, that would work yes
<ifette> so, whatever causes the browser to send DNT:0 could trigger the browser to update its list
<ifette> however that list is stored
<ifette> if you still send DNT:1 with a magic cookie, that's a bit wierd
<ifette> presumably you want to not send DNT:1 if there's an exception the browser is aware of
dwainber_: how does the client gonna know the scope? the server does know the scope
<ifette> so whatever makes the browser aware of this, can be used to update a list
<ifette> re scope, good question, but applies either way if you want the user to know what the scope is when they consent
aleecia: DNT:0 is an explicit consent and that's better
<npdoty> aleecia: getting users to change their DNT to 0 for opt-back-in sounds like consent, which would be useful for various contexts
<pde> ifette, for one version of the server-side-response semantics of "Tracking: 0", that could be the prompt for the user agent
<ifette> a magic cookie that the user has no idea what it represents doesn't do a great job at explciit consent
<ifette> indeed, ideally in my mind something would happen that causes the browser to send 0 on subsequent requests
<ifette> that way, both parties are clear
<ifette> as to how you scope that or what triggers it, that's a good question
<ifette> but just saying "it's a cookie the server interprets" doesn't answer the scope or explicit consent issues either
<ifette> at any rate, i do apologize but i have to drop off
<pde> browser chrome is a blessing and a curse
<ifette> pde indeed
<npdoty> jmayer: interjecting the user agent can be advantageous, browsers can do a good job making sure users know what decision they're making
john: lot of adavantage for opt-in cookie, it'll maintain the user preference for DNT
... it'll let the site differentiate user preference
... if you delete the cookie you would just send DNT:1
<npdoty> fielding: I actually prefer B (user-agent-managed) except what about existing user agents that send DNT:1 and wouldn't have this additional functionality?
matthias: is anyone interested in fletching these options
John and hober take the action point on option B
Andy takes the action point on option A
<npdoty> ACTION: zeigler to write up a proposal for a user-agent-managed site-specific exception [recorded in http://www.w3.org/2011/11/01-dnt-minutes.html#action03]
<trackbot> Created ACTION-31 - Write up a proposal for a user-agent-managed site-specific exception [on Andy Zeigler - due 2011-11-08].
<npdoty> ACTION: simpson to write up a proposal for a site-managed (via cookie or other mechanism) site-specific exception (with hober) [recorded in http://www.w3.org/2011/11/01-dnt-minutes.html#action04]
<trackbot> Created ACTION-32 - Write up a proposal for a site-managed (via cookie or other mechanism) site-specific exception (with hober) [on John Simpson - due 2011-11-08].
Aleecia: Looking at dates available for the group to meet - week of Jan 16th and Jan 23rd
Location TBD
Someplace in Europe (default to Brussels at this time)
Roy has issues with Jan 17 - 19th - need our Editors there
Looking at the week of Jan 23rd
<npdoty> will send out a Doodle poll soon
Aleecia: What happens next? Nothing will be published this week due to TPAC but will occur soon after
... We may receive feedback from Community Groups from these initial drafts
... From the deadlines in the charter we have slipped a month - will update the calendar to reflect this
Tom: 1st public working draft - we'll continue to work in the meantime. The "Last Call Working Draft" will be what we work on in Jan
Aleecia: Publish LCWD in late Jan/early Feb
... Can see the process and schedule at the web site
... Any questions? (None in the room)
... Weekly calls are still on (not tomorrow) - the mailing list as well
... Okay with mailing list freeform for now but this will become more directed to be more productive as we move forward
Tom: We have a bunch of issues that are open - how do we close those?
Aleecia: These will be addressed over time (some may be related, 20 is too many to address via mailing list)
... We can expect to open more issues as time goes by and begin to resolve issues via phone calls and mailing list
... This is a lot of work to do by Jan
Matthias: Thank you for coming all the way to Santa Clara, the constructive atmosphere, and I believe we made a lot of progress (more than I expected) - I'm very happy. I hope we can continue the pace and close all of the open issues.
... Thank you to the Editors! (much clapping)
Aleecia: Much thanks to Nick! (much clapping)
and thanks to the chairs! (much clapping)
This meeting is adjourned!
