See also: IRC log
<trackbot> Date: 11 December 2013
<npdoty> volunteers to scribe?
<JackHobaugh> I will give it a shot
<npdoty> scribenick: JackHobaugh
Justin: the chairs have evaluated
Issue 5 and 10 and decided. Will be publishing results. Chair
are in three different continents. The definition of tracking:
have decided on option A - that definition should be
... on the party definition, we have decided on option A which is based on Roy's reformulation of current text in the Compliance document.
... I can give a brief overview of why-adhoc. on tracking we found the objections to option B was broader. The TPE document is to be an expression of a desire not to be tracked.
... the TPE is heavily dependent on parties. In order for the definition to have meaning it must be know who is being referred to. Cognizant that many members of the group do not want definitions brought over into the TPE. So this is meant to be very closely limited.
... We thought the objection to D. Wainberg's definition were stronger because it was too open ended.
... We will be providing a written decision document.
... Don't want to debate the merits now.
... would be happy to take questions thought now.
Matthias: noticed shortcoming in
the options when doing analysis. In the future people should
make better proposals.
... feedback from the group was that the options were too broad.
... need to put more effort in to fine tuning the proposals.
<dsinger_> it is regrettable that the chosen option therefore conspciuously lacks a definition of Multiple" and "contexts"
Justin: agree with Matthias
... would be good to get to consensus by front loading discussion instead of going into C for objections process
<johnsimpson> apologies for joining late. which tracking option was selected?
<dsinger_> I think Roy's recent edit has also removed a lot (most? all?) occurrences of first/third party from the TPE
Matthias: Issue-239: Roy has removed dependencies in the TPE to the compliance spec. The TPE has to be self-contained. Let's walk through edits and then go to the issue-239
fielding: refers participants to
his email the summarizes the edits
... issue-136 has been moved to the top.
<wseltzer> Roy's email
fielding: section 5.2: I removed
the 1 and 3 tracking status values
... replaced that with a "t" to indicate tracking with the notation that it would be explained elsewhere.
... changed the symbol used for the dynamic tracking status value from "x" to "?"
... in 5.4.3: I added "compliance array"
<walter> wseltzer: yes, they're too adorable
fielding: the compliance document
will explain the qualifiers. removed third party member array.
too hard to maintain array. in 6.11, I removed a
... possible that I could have missed something. look for when reviewing - examples that assume a particular view of compliance on part of the server.
ChrisPeidgoOPA: Concerned about
the removal of first and third party tracking status
... seems like the group has already agreed on that construct.
schunter: If we don't need the definitions then the best is to remove them.
<npdoty> +1, I think indicating 1st/3rd was one of the more informative fields for users
schunter: signal called "1" means
complied with the first-party rules so it is technically the
right thing to remove.
... if we later have a compliance regime that distinguished between first and third parties then definitions would reappear. but don't want technical dependency on the definitions.
<dsinger> we could easily change "claiming compliance to 1st party rules" to "believes they are, and is acting as, a first party", if we have the definitions in the TPE
<fielding> We have issue markers in Terminology for the party definitions, awaiting the decision today. The 1/3 does not indicate whether the site is a first or third party
schunter: they would reappear as qualifiers.
ChrisPeidgoOPA: believes the
distinction regarding parties would be useful. agrees that
another compliance standard could set the rules for the
parties. believe it is important to note that an agreement
... I strongly oppose and think there is value in keeping.
<susanisrael> dsinger's suggestion seems worth exploring
justin: when we return to the compliance document the first and third parties will be addressed
<fielding> dsinger, no site is capable of knowing that
justin: the 1 and 3 values in the TPE do not equate to first and third party.
<fielding> it depends on how the link was used, not how the site was designed
<dsinger> fielding: the site knows what role it thinks it is claiming.
<npdoty> fielding, dsinger, sites can know what they believe about how it's being used
<moneill2> it can be described because the whole idea of context is vague
fielding: the actual definitions
of third and first parties will be the TPE definitions section.
the only entity that knows the first or third party distinction
is the user and that is not possible to describe in the TPE. It
will specified in the compliance document. the 1 and 3
distinctions can still be added to the qualifiers sections -=
cannotn still respond as a first party or third pary.
... so the information can still be communicated if needed.
... this is not the time to objection that level of detail. If you object to anything I removed, please write to the group explaining why.
dsinger: feels strongly both ways.
<Zakim> npdoty, you wanted to maintain agreement somewhere
npdoty: shares Chris' concern.
<susanisrael> +1 to npdoty
npdoty: but might be important to write down the qualifier route we are taking. Willing to do that in a separate section of TPE or in TCS.
walter: good idea to allow TPE to express what the server thinks the status it is operating in. Reason: compatible with notions of processor/control data.
ChrisPeidgoOPA: agree with
... long standing agreement for 2 plus years. Want it documented that the group agrees.
<npdoty> +1 to Fielding that we take these details to the mailing list as well
ChrisPeidgoOPA: have already ported over definitions into the TPE that have compliance
<trackbot> issue-239 -- Should tracking status representation include an array of links for claiming compliance by reference? -- raised
<trackbot> issue-45 -- Companies making public commitments with a "regulatory hook" for US legal purposes -- pending review
<fielding> The next substantive edit is to incorporate the definitions decision today -- note that the definition of tracking does not depend on a distinction between first and third party, which is new information with regard to the WG's prior work. It would be a shame to get stuck in a very unsuccessful past.
schunter: Issue-239: user needs
to know what compliance regime is being used. Could have
different versions - W3C compliance plus something else. Do we
want to keep the old link or do we want to make explicit
... I have to unfortunately run. Justin, take over.
<fielding> yes, these are all just proposals regardless.
<trackbot> issue-239 -- Should tracking status representation include an array of links for claiming compliance by reference? -- raised
<trackbot> issue-183 -- Additional Tk header status value for EU -- raised
justin: on Issue-239 linked issue 45 that has grown over time to include D Wainberg proposal. Also issue-183.
isn't issue-47 also related?
<npdoty> JackHobaugh, Shane had asked about 47, but then suggested we use issue-45
<fielding> Note that this provides only the technical ability to communicate one or more compliance regimes. It does not justify there being more than one, nor does it prevent the W3C compliance document from being the only one recognized by browsers.
dsinger: choices: TPE could be silent. Could have W3C as baseline Or we could have an alternative documented in the TPE. We need to have a discussion about it.
But on October 30 Chris Mejia also asked that Issue-47 be reopened. The problem with Issue-45 is that it is against the TCS and not the TPE.
moneill: don't understand how a
user would understand the implementation of Issue-239.
... should be determinable by UA, plug-ins, etc. - pretty vague
... need to bring in some definition to this.
<fielding> As mentioned on the list, the URIs are just hierarchically assigned names. The W3C does not define central registries -- this is how we do IANA stuff.
<trackbot> issue-47 -- Should the response from the server indicate a policy that describes the DNT practices of the server? -- closed
<justin> yes, jackhobaugh, I think that issue is implicated here too.
<moneill2> some of the group
<fielding> This is not issue 47 -- there is no indication that the user needs to follow those links.
npdoty: some concerns around designers options. we would like to get to some consistent view. trying to be clear about what the user is expressing. don't want to put a field in unless it will be used by the UA. wouldn't expect user's to inspect the different compliance policies that they might be using. May cause unwanted blocking. if it doesn't help the user, then don't see the value.
<dsinger> I agree with Nick that there are concerns here, and we need discussion
justin: is there defense against nick's concern?
fielding: that concern can be
addressed by one array value.
... there is no guarantee that there will be a universal regime for compliance but if there is than an array of one will handle it.
<npdoty> but we aren't parameterizing the DNT header, we aren't giving users N options for different tracking they want to prevent
fielding: defining a protocol
that is incapable of communicating that array is wrong on many
levels - doesn't permit a server to communicate its status.
Doesn't have to be evaluated by users.
... for example if the EU wants a stricter definition, then one way to do that is to provide an additional link in the array.
... all that is a reference to a standardized compliance document. Very easy to configure the client to have them verify a white listed set of tolerated policies.
justin: regarding one array value - if W3C leaves that open it would be on the UA to configure?
<dsinger> I believe that an issue was opened; would it be better to get written pieces, questions, concerns, and so on, in email? It seems odd to be spending time on a new issue on the call
<moneill2> fixed uri strigs?
<dsinger> (Indeed, formally we said that any issues raised after a deadline that was some time ago would be addressed post last-call. This one seems to be getting special treatment.)
fielding: point is that this is
syntax provided for the flexibility to set more than one
... if we don't added it would probably be added outside the spec
... that could come back to bite us at last call.
justin: regarding why this issue
is now allowed: we realized that we have some dependency
issues. And there have been related issues raised and that have
been before the group for a long time.
... yes, in a perfect world we would be discussing this in the mail list instead of here.
<fielding> I don't think we ever closed the issues on TPE -- that was a closure for TCS
<npdoty> we can all agree now that we've chatted that we're going to use the mailing list for civil and constructive discussion on this issue.
would someone else like to take over scrubbing?
I meant scribing. :-)
<jeff> Jack, I can scribe
<ninja> JackHobaugh, I can take over
<npdoty> scribenick: ninja
<JackHobaugh> thanks! spell checker got me.
justin: Would like to have some constructive discussion before christmas. Encourage everyone to bring their opinion to the list. It's a crucial issue for the spec.
<trackbot> issue-153 -- What are the implications on software that changes requests but does not necessarily initiate them? -- pending review
justin: Now ISSUE-153
justin: explaining both options currently listed on the wiki.
<dsinger> notes that the issue description correctly recognizes that plug-ins or browser settings are not intermediaries
justin: Matthias urged that we batch close, but there were objections and then a discussion on the mailing list.
<dsinger> I also wonder what new information has come to light since we settled this in June?
moneill: My thought was first that an intermediary must not change the dnt signal. But in there may be constraints with regard to children. There are legal reasons to override the decision by a child to allow tracking, which is not allowed e.g. by EU laws.
<dsinger> pending review means "did the editor integrate the decision correctly?"
<Zakim> bryan, you wanted to recommend we stay with the existing text, any more restrictive text would place non-UAs out of scope of DNT, and not reflect reality in the market's response
<dsinger> (or it did back when I did the edits)
bryan: the proposal for the text
chops off where there are requirements to change a signal. This
would prevent innovative services to protect users
... This is contradictory to users' needs
kulick: one of the concerns I had: Giving the consumers an easy way to communicate their preference. We have not addressed yet how to handle exceptions etc. To build trust I was concerned of several different edge cases in the first versions
<bryan> if the goal is "ease", then requiring the user to set DNT preferences in each and every browser/app/device that they have, will not serve that goal. An add-on that can sync preferences across all of the browsers/devices that a user uses is the best and easiest way.
npdoty: The text as it is does not need additional prohibitions for edge cases. If we want to get it out quickly, prohibitions do not improve the spec
<dsinger> The current text is pretty stiff already. Why do we need to prohibit software that helps configure the browser, or works as a plug-in?
<dsinger> An HTTP intermediary must not add, delete, or modify the DNT header field in requests forwarded through that intermediary unless that intermediary has been specifically installed or configured to do so by the user making the requests. For example, an Internet Service Provider must not inject DNT: 1 on behalf of all of their users who have not expressed a preference.
npdoty: suggest to focus on requirements than on prohibitions.
<walter> dsinger: +1
dsinger: The text is already clear on the user being the one making the request and setting the preference. I don't see additional need to add the proposed text. We should not limit it to browsers as this would raise anti-trust concerns
<dsinger> The browser is *responsible* for the behavior of plug-ins.
<moneill2> they are set by the user
kulick: one of the problems with plug ins that we have is that we cannot identify who is actually setting and sending the signal
<npdoty> 153 was opened for non-plugins, because I think we had agreement on using text on plugins as of our discussions in December 2012.
<dsinger> We discussed this at length
kulick: we want to make sure that there is transparency on who is sending the signal
<trackbot> issue-151 -- User Agent Requirement: Be able to handle an exception request -- open
<dsinger> we *had* consensus on this, we were merely verifying the integration of text
justin: issue will go to CfO next
... Options are well captured in the wiki right now.
<dsinger> I am puzzled that new options have appeared well after the deadline passed
<wseltzer> me too
<npdoty> dsinger, these options were submitted December 5th, at the chairs' request;
<npdoty> ... I may have gotten them into the wiki later, apologies
justin: .justin: *explaining the options on the wiki*
<Chapell> I don't think Shane is on today's call
<Zakim> wseltzer, you wanted to comment on "consensus"?
<dsinger> Jack concerns intermediaries; Shane's concerns origins
justin: possibility of eliminating a few of those?
wseltzer: on the last issue: I think there was just one objection to keeping the text as it is
<kulick> Alan supported my call for 151 going to CFO
<kulick> to the mailing list
<Chapell> Wendy - I supported Brad's call for 151 going to CFO
<Chapell> As did other folks
wseltzer: maybe no need to go to CfO with this. consensus does not need to be unanimous
<npdoty> Wendy is talking about 153, we have the multiple options on 151
justin: Happy to take guidance. If a subset of the group wants to go to CfO with this, we will do so. Would like to hear rationales for this.
<wseltzer> [in part, I wanted to make sure the minutes were clear]
<dsinger> to bryan: quite; there is no functional difference between JS disabled, an API that the user has instructed always to say no, and no API
bryan: Are we forbidding out of band messages with this? Bcause of the mandatory java script req
<fielding> OOB consent overrides anything in the protocol
<fielding> … assuming it is correctly noted in TSV as "C"
<JackHobaugh> For a device to state it has implemented the TPE version x, doesn't it have to support the ENTIRE specification?
<sidstamm> apologies all, I have to drop off
<dsinger> yes, the TPE still has "C", as Roy notes: the origin server claims it has consent
moneill: We have been talking about out of band overriding DNT. If we now say that UAs must support java script we open the possibilities to ignore valid signals that are implemented differentlx
npdoty: Software has to implement all pieces of the spec saying MUST or SHOULD, but not those from the server side
<JackHobaugh> I believe my proposal can be added to Shane's language if Shane agrees.
npdoty: Suggestion to merge Jack's and Shane's proposal
<fielding> … and a Cookie-based exception mechanism would have worked with intermediaries that add DNT:1
<kulick> Sorry, I dont think I can represent on this point for Shane
justin: will talk to shane offline
npdoty, sorry, understanding and scribing did not work in synch :)
justin: reminder for the open Call for objections. Please participate
<npdoty> ... thinking that interactivity would be useful, and that it didn't have to be guaranteed, just a common case
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/reformulation./reformulation of current text in the Compliance document./ Succeeded: s/ca/cannot/ Succeeded: s/Will/Willing/ Succeeded: s/sticker/stricter/ Succeeded: s/Suggestion to merge Issue 153 and 151/Suggestion to merge Jack's and Shane's proposal/ Found ScribeNick: JackHobaugh Found ScribeNick: ninja Inferring Scribes: JackHobaugh, ninja Scribes: JackHobaugh, ninja ScribeNicks: JackHobaugh, ninja Default Present: Jeff, RichardWeaver, dsinger, efelten, WaltMichel, hefferjr, npdoty, ninja, wseltzer, Jack_Hobaugh, Peder_Magee, +1.919.388.aaaa, Ari, schunter, hober, kulick, Susan_Israel, LeeTien, David_MacMillan, walter, moneill, justin, Amy_Colando, [CDT], AnnaLong, Fielding, GSHans, sidstamm, Bryan_Sullivan, Chris_Pedigo, adrianba, Brooks, Chapell, [Microsoft], johnsimpson, MattHayes, rvaneijk, dwainberg, eberkower, AWK Present: Jeff RichardWeaver dsinger efelten WaltMichel hefferjr npdoty ninja wseltzer Jack_Hobaugh Peder_Magee +1.919.388.aaaa Ari schunter hober kulick Susan_Israel LeeTien David_MacMillan walter moneill justin Amy_Colando [CDT] AnnaLong Fielding GSHans sidstamm Bryan_Sullivan Chris_Pedigo adrianba Brooks Chapell [Microsoft] johnsimpson MattHayes rvaneijk dwainberg eberkower AWK Found Date: 11 Dec 2013 Guessing minutes URL: http://www.w3.org/2013/12/11-dnt-minutes.html People with action items:[End of scribe.perl diagnostic output]