See also: IRC log
<tl> Just like last week, and every other week, so I'm not sure why this is a surprise to you
<aleecia> Zakim's forgotten me too
<aleecia> We've all made the obvious DNT and personalization jokes until we're done, right?
<tl> I want a site-specific exception for Zakim. I feel like Zakim and I have a special bond.
<tl> Sometimes it feels like an abusive relationship though.
<aleecia> You take, take, take: what have you ever done for Zakim?
<tl> All I ever give is love an affection, and Zakim manipulates me cruelly.
<aleecia> Alas - watching relatives age, that flag is implemented on older models.
<aleecia> 90% regrets sounds like a night of parties
<aleecia> Why don't I scribe for the first part, hand off late
<aleecia> later.
<wseltzer> I'll take a hand-off mid-way
<npdoty> scribenick: aleecia
<tl> It's the quiet ones you have to watch out for.
schunter: minutes? No comments, approved.
schunter: Starting with TPE doc, then Compliance, then action item review if time
... Reviewing TPE, start from the top.
<npdoty> dsinger, are you well-rested and have a summary?
schunter: Editors, summary since last week?
Roy: Last night, changes from Nick for JS
... site-specific changes. Andy's on fingerprinting to make requirements language consistent
<npdoty> that was the proposal that Tom sent out last week in Markdown, fyi
Roy: trimmed introduction closer to David's suggestions; added most of JohnS, combined with citation to KnowPrivacy privacy paper
... cleaned up intro before header proposal; wasn't needed any more
... re-org'ed header proposal into sections, easier to read.
<fielding> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
schunter: Things you cannot publish, please raise.
... Think we could publish as it stands
... Introduction shortened. Ok as is?
Nick: CG issue here, should we mark it?
Roy: Do we have an issue?
Nick: no, should we?
<WileyS> The only critical item in the TPE draft for us is the prohibition on server-side polling of site-specific exceptions. Uses cases were sent via email and I'll provide alternate text to the digitial fingerprinting concerns to remove that prohibition.
schunter: issue was didn't value privacy enough
<npdoty> aleecia: on our agenda to review and respond to Community Group after publishing these documents
jchester2: improved, but comments in the CG need to be ack'ed in some way
<aleecia_> (is mentioned in the Compliance doc)
<aleecia_> (perhaps good to add here)
schunter: need to add CG issues to tracker
<jchester2> I agree. Thanks. Make formal issues
<aleecia_> (agree)
johnsimpson: getting closer, progress.
... This intro seems similar to compliance language. Final rec should have one?
<aleecia_> (or: could have them the same)
schunter: both should have intro, should be self-contained, could be identical
... wouldn't mind if identical
... then a note on which doc does what
aleecia: let's copy & paste into compliance, unless there's something there people want to keep
<npdoty> no objections on all of chapter 2!
schunter: other feedback on intro? No? ready to publish
... nothing on section 2, ready to publish
... section 3, ready to publish
... section 4, 4.1 Expression Format
<npdoty> editors have added a pointer to issue-111 here (do we want a dnt:2?)
schunter: 4.2, syntax
... no comments
... 4.3, any comments?
Amyc: link?
<wseltzer> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
<aleecia_> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
<tl> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
<aleecia_> Nick, 111?
schunter: 4.3, any comments?
<tl> Well, aren't we just a bunch of pointdexters. We can all stay behind after class to clean the erasers.
Shane: open issue on server side?
... section 6, no problem
<fielding> we are looking at revision 1.97 date: 2012/03/07 13:37:42;
Shane: will raise later in the document, issue-111
<npdoty> WileyS, editors have added pointers to 111 around the DNT:2 question, which has server-side impact
schunter: 4.3 comments? None. 4.4?
... 4.5 is new. Language from David Singer.
4.5 Tracking Preference Expressed in Other Protocols
A user's tracking preference is intended to apply in general, regardless of the protocols being used for Internet communication. The protocol expressed here is specific to HTTP communication; however, the semantics are not restricted to use in HTTP; the same semantics may be carried by other protocols, either in future revisions of this specification, or in other specifications.
When it is known that the user's preference is for no tracking, compliant services are still required to honor that preference, even if other protocols are used. For example, re-directing to another protocol in order to avoid receipt of the header is not compliant.
schunter: comments?
tl: comment on 4.4
<fielding> right, TBD
tl: last sentence Therefore, we will define here various mechanisms for communicating the tracking preference via common plug-in APIs.
... task we could drop if it doesn't look like it's getting done before due date
... can leave to browsers
... no great loss if we fail to get to this
Roy: If we fail to do that, plug-ins cannot adhere to the protocol
schunter: replace with - browser vendors should look into way to do this, rather than standardized
tl: yep, sure
<jchester2> I think we should try and develop the API parameters
Roy: nice theory, don't see it works
<npdoty> tl, do you want to change the text here right now?
Roy: don't see a need to change this now, but if we don't have an API next time, sure
tl: let's just add a note to that
<dsinger> this text is about protocols, not APIs.
<dsinger> we're talking about FTP or ...
schunter: drop the sentence, raise issue of what we should say here on right api approach
Roy: fine
<tl> npdoty: "Note: this task is not of critical priority."
<dsinger> yes, we have an API issue with plug-ins; they need to know the DNT status
amyc: would this apply to applications on the same machine where the DNT pref in the browser or HTML app, where the app isn't receiving DNT signal?
tl: exciting adventure we can play, there are implementations that might work. Best to focus on other pieces first.
<npdoty> Mozilla's Boot-to-Gecko is a relevant example there (for OS-level communication), for example
amyc: sounds right to me too, seems difficult communicating to other apps that exist
tl: advert for B2G
schunter: think we agree
so we're adding a note?
<fielding> back to 4.5
<tl> I'm fine with just a note.
<tl> +1
<schunter> ACTION: fielding to remove last sentence in 4.4 + add a note instead [recorded in http://www.w3.org/2012/03/07-dnt-minutes.html#action01]
<trackbot> Created ACTION-144 - Remove last sentence in 4.4 + add a note instead [on Roy Fielding - due 2012-03-14].
<tl> Lets move on.
<johnsimpson> +1 to note
schunter: adding a note, removing last sentence - action for Roy
... 4.5 comments?
... completes section 4, can publish with single change.
... section 5, Communicating a Tracking Status
... two proposals, 5.1 Tracking Status Resource and 5.2 Tk Header Field for HTTP Responses
... comments on 5.1 as a whole?
tl: conversation with Roy, hope to compromise without contention
... working on writing that text
<fielding> for after this WD
tl: if it matches what Roy thinks, we can all go play with unicorns and so forth
schunter: won't get in for WD in time, but this is good news
request: add a note?
<johnsimpson> + to publish as is.
<npdoty> I'd want to see the specific text, but a compromise that uses a header for signaling something that has changed in real time sounds promising to me
<fielding> tl, I think we agreed that the header would be optional (MAY) unless a change was just made to status, but we can work on that after the WD
<tl> Yes, let's add a note.
<aleecia_> let's let people know we're close
<aleecia_> tom, could you draft a note?
<aleecia_> perhaps in real time?
<tl> Yes, action me up!
<aleecia_> was hoping for Right Now :-)
schunter: yes, let's add a note. comments on 5.1?
... 5.2 comments?
<tl> give me a sec
<npdoty> do we need an open issue for 5.3?
5.3 Status Code for Tracking Required
An HTTP error response status code might be useful for indicating that the site refuses service unless the user either logs into a subscription account or agrees to an exception to DNT for this site and its contracted third-party sites.
npdoty: there's an open issue for 5.3, should we add it to the doc?
schunter: don't know?
npdoty: didn't even get far enough we could have it contested
<fielding> this has not changed since FPWD, so let's keep it as is.
schunter: "might be useful" isn't the right final language either
... leave it as it is, but should raise an issue to come back to this later
<aleecia_> (could we add the issue to the doc?)
schunter: any other objections? Ok, 5 is done, section 6
<npdoty> issue: HTTP error status code to signal that tracking is required?
schunter: Site-specific Exceptions and JS API, Nick and Shane
... any objections to section 6?
<npdoty> WileyS, you had issues here?
schunter: as a whole?
<WileyS> No issue
issue-111?
<trackbot> Created ISSUE-128 - HTTP error status code to signal that tracking is required? ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/128/edit .
<trackbot> ISSUE-111 -- Signaling state/existence of site-specific exceptions -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/111
<WileyS> The open issue is listed that I was looking for - I was looking for it in the wrong place :-)
schunter: we're done, two minor changes
<npdoty> great, WileyS, thanks
schunter: we're ready to make fixes and publish
<tl> Note: We are currently working on a proposal which combines the Tk: response header and Tracking Status Resource. It would make the TSR compulsory and the Tk: header optional. However, it would be required to use the Tk: header to notify the user when something in the TSR has changed in real time.
<npdoty> scribenick: wseltzer
<tl> fielding: ^ Also, I added a proposed note on the Plugin API to you action for that.
<fielding> tl, I just finished adding one to the spec
<aleecia> http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html
aleecia: Moving to the Compliance Document
<aleecia> Notes to new readers: this document is a snapshot of live discussions within the Tracking Protection Working Group. It does not capture all of our work. For example, we have issues that are [PENDING REVIEW] with complete text proposals that did not make it into this draft. Text in white is typically [CLOSED]: we have reached a consensus decision. Text in blue boxes presents multiple options the group is considering. In some cases we are close to agreement, and
<aleecia> others we have more to discuss.
<tl> fielding: Don't see it?
<WileyS> +1
aleecia: Introduction: additions: Notes to new readers.
<fielding> testing first, then commit
<aleecia> We have not reviewed comments from the Community Group associated with this work. We thank them for their time and detailed feedback, and will address their comments in the near future.
<npdoty> minor editing, worth making the Note to new readers a boxed "Note"
aleecia: Second note: Community Group comments have not yet been incorporated.
<tl> Lulz.
aleecia: accept Nick's "Note" note.
<npdoty> look good to me
<johnsimpson> both good
aleecia: No objections seen.
<tl> fielding: Is your note live?
<npdoty> fielding, dsinger, moving these notes to TPE?
schunter: OK to add to DNT doc as well.
<fielding> sorry, I am lost
aleecia: Scope and goals. Sec 2.1
<fielding> will take action from matthias
<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#scope-and-goals
<aleecia> While there are a variety of business models to monetize content on the web, many rely on advertising. Advertisements can be targeted to a particular user's interests based on information gathered about one's online activity. While the Internet industry believes many users appreciate such targeted advertising, as well as other personalized content, there is also an understanding that some people find the practice intrusive. If this opinion becomes widespread, i
<aleecia> could undermine the trust necessary to conduct business on the Internet. This Compliance specification and a companion [TRACKING-DNT] specification are intended to give users a means to indicate their tracking preference and to spell out the obligations of compliant websites that receive the Do Not Track message. The goal is to provide the user with choice, while allowing practices necessary for a smoothly functioning Internet. This should be a win-win for busi
<aleecia> and consumers alike. The Internet brings millions of users and web sites together in a vibrant and rich ecosystem. As the sophistication of the Internet has grown, so too has its complexity which leaves all but the most technically savvy unable to deeply understand how web sites collect and use data about their online interactions. While on the surface many web sites may appear to be served by a single entity, in fact, many web sites are an assembly of multiple
<aleecia> parties coming together to power a user’s online experience. As an additional privacy tool, this specification provides both the technical and compliance guidelines to enable the online ecosystem to further empower users with the ability to communicate a tracking preferences to a web site and its partners.
<WileyS> +1
aleecia: Suggesting we sync from DNT doc, killing this paragraph.
<johnsimpson> OK with that
aleecia: no objections.
<jchester2> I am ok with that
fielding: can we move 2 paragraphs to status section?
<WileyS> We should mirror the approach in both documents
<npdoty> "status of this document" section for both documents
<WileyS> Consistency on shared elements is good
aleecia: ok.
<tl> fielding: Did you add notes to DNT?
<aleecia> 3.2.1 Option 1: User Expectations
<aleecia> 3.2.2 Option 2: Discoverable Affiliates
<tl> +1
aleecia: Sec. 3; 3.2.1 Options: change to give them names.
<WileyS> Where is the draft text that Amy and I came up with?
<WileyS> Was more text than that
aleecia: That became Option 2
<WileyS> Okay
<aleecia> 3.3.1.2 Option 2: Affiliates
<npdoty> 3.3.1.2 I think also comes from WileyS and AmyC
amyc: we can delete the ellipsis, replace with period.
... Defintion isn't solely focused on affiliates. Suggests "Discoverable ownership and affiliates"
<npdoty> "Discoverable Ownership and Affiliates" for 3.2.2
aleecia: Will accept the original authors' suggestion for title
<amyc> nick beat me to it
<WileyS> I default to Amy but I think yes
aleecia: 3.3.1.2 remove "or ...."
<aleecia> 3.3.1.2 Option 2: Affiliates
aleecia: We now have two parallel proposals; Jonathan & Tom, and Shane & Amy.
<dsriedel> Would there be time to elaborate a bit on "similar services" in 3.3.1.2 Option 2: Affiliates?
aleecia: We will need to resolve these; this doc shows the public our thinking.
... Clearly we're not done with either of these texts, but in good shape to publish as draft.
<npdoty> dsriedel, what's your question there?
<aleecia> 3.3.2 Data Controller and Processor
<aleecia> For the EU, the outsourcing scenario is clearly regulated. In the current EU Directive 95/46/EC, but also in the suggested regulation reforming the data protection regime, an entity using or processing data is subject to data protection law. A First Party (EU: data controller) is an entity or multiple entities (EU: joint data controller) who determines the purposes, conditions and means of the data processing will be the data controller. A service provider (EU:
<aleecia> processor) is an entity with a legal contractual relation to the Data Controller. The Service Provider does determine the purposes, conditions and means of the data processing, but processes data on behalf of the controller. The data processor acts on behalf of the data controller and is a separate legal entity. An entity acting as a first party and contracting services of another party is responsible for the overall processing. A third party is an entity with
<aleecia> contractual relation to the Data Controller and no specific legitimacy or authorization in processing personal data. If the third party has own rights and privileges concerning the processing of the data collected by the first party, it isn't a data processor anymore and thus not covered by exemptions. This third party is then considered as a second data controller with all duties attached to that status. As the pretensions of users are based on law, they apply
<aleecia> first and third party alike unless the third party acts as a mere data processor.
aleecia: text not final; may wind up in a different doc or place.
<dsriedel> @npdoty: Well, we were wondering where to draw the line, seperating ads from widgets. As every ad is a potential widget, something the user can interact with.
aleecia: thanks Rob and Rigo.
<aleecia> We will need an entire section, or perhaps another document, to address DNT in various countries and regions. While we cannot provide legal advice, we can provide pointers to more information. A small subset of the group is working on this task. The text that follows may move elsewhere.
<aleecia> , or not make the final document
tl: Note on 3.3.2 is different from agreement I recall. Suggest adding "text may not make the final document"
<npdoty> "move elsewhere or be removed."
<amyc> +1
<tl> +1 to npdoty
aleecia: We do have some uncertainty here.
<npdoty> rvaneijk, does that sound good to you?
<rvaneijk> I am fine with the addition to the note
<aleecia> , or be removed
<WileyS> +1
<aleecia> edit the note as such
<johnsimpson> +1
<aleecia> A "network interaction" is an HTTP request and response, or any other set of logically related network traffic.
aleecia: 3.4. Any objections to changing set to sequence?
<tl> Fine by me.
<johnsimpson> +1 to sequence
aleecia: no objections. Close note, change text.
<tl> "Happy."
<aleecia> 3.4.2 Non-Normative Discussion
aleecia: hasn't changed.
... 3.5, also unchanged
... 3.6, also unchanged
<aleecia> We are still working through how, or if, to define tracking. Some suggest the phrase "cross-site tracking" only. We will need to ensure both final recommendations use the same terms in the same way.
aleecia: 3.7, mostly format changes. New note ^
<justin_> Looks good
aleecia: no objections.
<aleecia> 3.7.1 Option 1: Non-first Party Identifiers
aleecia: 3 options for tracking, now given names.
<aleecia> 3.7.2 Option 2: Cross-site or Over Time
<aleecia> 3.7.3 Option 3: Silence
<tl> The rest, is silence.
aleecia: 3.8, boxes seeking names
<npdoty> "What we cannot speak about we must pass over in silence."
WileyS: Where is the Belgium text?
aleecia: different section, 4.1
<aleecia> Wording needs polish to ensure it works with accessibility issues, but other than minor edits this is agreed upon.
aleecia: 3.9, added note ^
... 3.10, 3.11 locked down for a while.
<WileyS> The main issue for me is that IE does not render the section IDs when viewing the documents. Which browser should I use?
aleecia: final call for Sec 3.
<johnsimpson> +1 to publish sec. 3
<tl> WileyS: Firefox, obviously.
<tl> Now for the "fun" part.
<WileyS> LOL - okay, I'll try that
<aleecia> 4. Compliance with an expressed tracking preference
aleecia: Sec 4.1, captures 5 different approaches discussed in Belgium.
<tl> +1 ! <3 Blue boxes!
<WileyS> MUCH better in FF - thank you Tom. :-)
aleecia: might put the entire thing in a blue box, but not 5 blue boxes.
<tl> WileyS: I take personal responsibility =p
<aleecia> add big blue box to 4.1
WileyS: Should we give these names as well? Still don't see all the Belgium text.
<aleecia> note that not all text is here
<tl> npdoty: Is there a CSS3 option to make the blue boxes larger on the inside?
<npdoty> editors?
aleecia: Trying to keep this small, readable; but there is text that's not here.
<aleecia> editors did the editing down to these 5, and I think they did a nice job summarizing
johnsimpson: This is a higher-level discussion of the options, not so specific as earlier sections.
... reflects where we are right now.
... Favors publishing, in a blue box.
<jchester2> I support John's proposal
<justin_> I'm fine leaving it as it is for now.
WileyS: Concern that we not lose the previous work.
... Fine not having them in the doc, so long as they are kept around.
... Titles would be helpful.
<bryan> +1 to Shane's suggestion
aleecia: Issue 17 links to the text, mailing list discussion.
... Add to the note above that there is substantial additional text, so public and we don't lose it.
... Make sure it's issue 17.
... Also will add titles. Will put names on mailing list and discuss there.
... but won't hold up publication.
<npdoty> no official standard
WileyS: In the TPE, when we list an issue, we give it title; here, we don't have the names.
<aleecia> shane would like: titles for issues,
<justin_> We'll see what we can do . . .
<WileyS> Thank you!
<aleecia> 1. add to note that there's more text
<tl> When did we stop committing the editors' time for things they don't want to do?
<aleecia> 2. list out issues
<aleecia> 3. big blue box
<aleecia> 4. names for options
aleecia: anything else on 4.1?
<WileyS> Yes
aleecia: ^ Addresses concerns.
... No objections.
... 4.2, Intermediary Compliance.
... lots of disclaimers; any comments?
... 4.3. Compliance by a third party
... fix typo; anything else?
... remove the > from 4.3.1 point 4
<justin_> These aren't options in 4.3
<tl> s/\>/\"\>\"
npdoty: Titles, to be taken offline
<fielding> schunter, note that intro text was moved to SOTD for both documentts
WileyS: The options are listed under 1st party, but they often address 3d party
aleecia: We could move them up a level
... under Compliance with an expressed tracking preference
... Any response from editors?
<npdoty> I'm fine with just having the editors do something reasonable that includes adding titles somewhere within 4
aleecia: Sec 4.1 Options refer to both 1st and 3d parties. Push it up to "Compliance" rather than "Compliance by first party" ?
<tl> fielding, Can you add this note to the header/URI section: "Note: We are currently working on a proposal which combines the Tk: response header and Tracking Status Resource. It would make the TSR compulsory and the Tk: header optional. However, it would be required to use the Tk: header to notify the user when something in the TSR has changed in real time."
WileyS: In Brussels, we didn't break up our text/discussions in that way between 1st and 3d parties
<WileyS> Okay - good to go then :-)
npdoty: Whatever the editors think is reasonable.
justin: retain the current structure for now.
... separate question why we have 4.3.1
aleecia: this will change as we reach a decision; close enough for now.
... 4.2 this overlaps with DNT, so may change or come out of the doc.
justin: Would prefer to add some options on geolocation
<npdoty> I think having just 4 and 5 would be the most relevant for that section
justin: will clean up tomorrow.
<justin_> If we have agreement, that's fine.
aleecia: to continue on mailing list.
<jchester2> we don't need options for location, but clearly delineating how DNT impacts location
<fielding> tl, done
aleecia: 4.3.2, 4.3.3 issues?
<tl> =D
aleecia: 4.4, pending review
... 4.5, Cookie syncing
... proposed text under review
<npdoty> formatting for 4.5.2, make a single Issue box for those numbered items and remove the Note box
aleecia: 4.6, pending review, Usage exceptions
justin: outsourcing, should it be an exception here or under 1st party.
<WileyS> +1 for moving it up
justin: my preference to move to sec 3. Disagreement?
<aleecia> +1
tl: prefer not to make that change right before publication
... location has implications for the way the text is read
<fielding> I would prefer to make the change now, for the same reason
aleecia: Suggest adding 2 notes; one where you'd move it, another here saying "this may move"
<WileyS> Now is better - I don't believe there will be a semantics impact
aleecia: last-minute changes are disfavored.
<npdoty> I expect we'll probably want this section to come after we discuss 3rd-parties, fwiw
aleecia: discuss at the end of the call, if there's time.
<tl> In the next thirteen minutes?
<justin_> The changes have no real effect, but for that reason, I don't care that strongly.
<justin_> Twelve
<fielding> TPE is done, afaik
aleecia: a pile of not-yet baked exceptions and issues
... Sec 5. Exemptions, lots of open issues
<npdoty> we're using "site-specific exception" as the term for this in the TPE doc
aleecia: 5.3 is baked
fielding: excpetions in TPE spec, exemptions here
aleecia: note, these terms are still being discussed
<justin_> I will add thatn ote
<fielding> okay if we change all to exceptions -- exemptions are never client-side
<justin_> Note
aleecia: we need new words
... Justin to add a note.
<johnsimpson> I thin it is exceptions...
aleecia: 5.4, 2 different options on logged-in
... 5.6, enforcement and compliance. Again note that final wording may change
... reviewed one audit proposal, may hear something else in the future.
... no agreement yet.
... please add yourself to doodle to be acknowledged.
<fielding> suggest that the last sentence in 5.6.2 should be a Note
<npdoty> http://www.doodle.com/z9672cm55hgzvwys
aleecia: if you've contributed and would like to be listed, please join the doodle.
<justin_> noted
aleecia: Does anyone object to publishing with these changes?
... None heard.
... Justin & Aleecia to make sure document is done Thurs;
<npdoty> can we remove the header-field/DOM stuff from the Acknowledgements section?
<fielding> I believe all requested changes have been made to the TPE spec during the call.
<fielding> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
Justin: Schedule works
<WileyS> Great work Editors!!!
<johnsimpson> yes to COB friday
aleecia: Can people review changes by COB Friday?
<npdoty> group to review changes by close of business Friday
aleecia: no objectionjs.
... expects to submit for publication on Tuesday.
<npdoty> submit to be published on Tuesday, March 13th
<WileyS> New iPad being presented at this very moment
<tl> WileyS: ?
<WileyS> http://www.engadget.com/2012/03/07/apple-ipad-3-liveblog/
<tedleung> do we have any more details on the f2f?
<WileyS> For those who care... :-)
<npdoty> yay!
Adjourned.
<npdoty> publishing drafts!
<johnsimpson> good work all
<aleecia> thank you!!!
<rvaneijk> thank you
<npdoty> thanks to Wendy for scribing!
<fielding> aleecia, I made the change to the SOTD in both documents