Tracking Protection Working Group Teleconference -- 15 Jan 2014

<trackbot> Date: 15 January 2014

<vinay> npdoty -- just as an FYI, I dialed in from a 408-536- number but Zakim isn't showing it

<vinay> I think Zakim may have categorized Peder as me (not sure though)

<ninja> we don't have a scribe yet. Volunteers?

<justin> http://www.w3.org/wiki/Privacy/TPWG/Proposals_on_limitations_for_add-ons

<vincent> I can try to do it, it's been a while

<npdoty> scribenick: vincent

<GSHans> i can take over scribe at 12:45

<ninja> thank you, vincent

issue-153?

<trackbot> issue-153 -- What are the implications on software that changes requests but does not necessarily initiate them? -- pending review

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

justin: David and Brad have been working on the language
... walter propose his own language on his issue
... issue in a group for while, should there be a second guess of the DNT header
... is this specific to add-on or is it related to issue 157?

issue-157?

<trackbot> issue-157 -- Charter is running out and we need to agree on whether to extend or recharter and what a revised charter would look like -- closed

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

<npdoty> issue-197?

<trackbot> issue-197 -- How do we notify the user why a Disregard signal is received? -- closed

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

<npdoty> actually, I think 197 is meant to still be open

<Zakim> sidstamm, you wanted to talk about addons, open source and compliance

sid: scho walter consernce on the mailing mlist, add-ons do not have control over the extension add-on and how they behave

<WileyS> Sid, the Mozilla team was saying they could blacklist add-ons.

<fielding> Matthias closed 197 on 17 Dec: http://lists.w3.org/Archives/Public/public-tracking/2013Dec/0089.html

<justin> That was incorrect --- as we acknolwdged earlier.

sid: that being said, point understood want ot be sure that the signal reflect the user choce but it's more a compliance document that technical

justin: do you support the editor text

<WileyS> That's fine - they are the bad actor in that scenario - not Mozilla.

<walter> WileyS: that would be incompatible with the Mozilla license

<justin> Matthias was not supposed to close that issue, and we said on an earlier call (in response to dwainberg inter alia) that it was still open.

sid: in response to change, yest we can block specific add-ons but they can change signature
... it then becomes a race

<WileyS> Walter, that is incorrect - Sid and team are explaining why now.

<fielding> justin, okay -- should I reopen it?

<WileyS> "to the extent" possible is fair - we could add that to the language

<justin> fielding, yes, or move to pending review, since we're moving to CfO today with 2 or 3 options.

<WileyS> "to the extent possible" (misquote)

<walter> WileyS: even if it is compatible with the MPL (which I still doubt) there are still other browsers with more copyleft licenses

sid: particularly completed since rebuild of firefox get popular

<WileyS> Sid, I'm fine with adding the "to the extent possible" clarification

<WileyS> +q

<sidstamm> WileyS, why do we need the text in the tech spec at all?

walter: you have several browser which have no option to blacklist add-ons

<sidstamm> Wileys, isn't that a compliance issue?

<WileyS> Does adding "to the extent possible" make you feel more comfortable?

walter: but open-source browser can not black-list anything and can not be held responsible for the extensions

<WileyS> Sid, I believe its more of a technical compliance element but should be repeated in policy compliance documents as well.

<walter> WileyS: that is putting legalese in a protocol spec which as a lawyer feels wrong

<npdoty> technical compliance, in that it's compliance of the client software? or does technical compliance mean something else?

<sidstamm> WileyS, what walter said

<fielding> Open source licenses do not make any difference (I authored the Apache license); browsers will simply ignore such a requirement.

<sidstamm> operating systems (especially on mobile) may want to send DNT too...

<npdoty> to Bryan's point, I think the existing language refers to other software, not just browsers

Bryan: limit the scope of the DNT to the browser and do not extend the scope of DNT to other element (did get that right Bryan ?)

<walter> fielding: Apache is not a copyleft license, of which you are undoubtedly aware

<fielding> walter, that makes no difference whatsoever.

<npdoty> "to the extent possible" is a request on organizations like Mozilla, not a requirement on a piece of software, right?

<sidstamm> npdoty, sounds like it, which means maybe it shouldn't be in the TPE

<fielding> copyright on redistribution has nothing whatsoever to do with controlling the network interface provided to add-ons, nor "taking responsibility" whatever that means.

<Bryan> The implication that anything beyond the browser are "bad actors" needs to be challenged

WileyS: not trying to build a standard for bad actors , not asking for rearchitecure but use what is avaiblae today

sidstamm: the tpedescribe the protocol the way it works, don't understand what it should be in here, example of HTML5 parsing
... not sure it should be in the document

<WileyS> +q

Bryan: w3c should be carefull about defining bad actors, not all good actor should be browser vendor

<justin> We've gone back and forth on this issue for weeks, we need to move to CfO.

<npdoty> I think the proposals have improved in not singling out non-browsers

<sidstamm> WileyS, would your misspeak make you a "bad actor?" ha ha. :)

<walter> that has been my point all along

WileyS: was not planing on using the word bad actors, bad actors just refer to actor that consistently change the signatur of the add-on

<sidstamm> yeah, agreed

<walter> you need DRM to enforce any of this

<jeff> [Jeff appreciates Shane's clarification that W3C did not define anyone as a bad actor.]

<sidstamm> WileyS, sorry, bad attempt at a joke

<justin> http://www.w3.org/wiki/Privacy/TPWG/Proposals_on_Disregard_signal

issue-197

justin: gonna work with shane and brad and david to see if the term to extent possible should be there

<sidstamm> WileyS, but intent doesn't come into it with technical specs... all that matters is behavior

issue-197?

<trackbot> issue-197 -- How do we notify the user why a Disregard signal is received? -- closed

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

thx npdoty

<npdoty> intend to go to Call for Objections on 153 tonight

justin: Discussion about the disregard signal, some pushing that you should not be able to do that

<walter> justin: to be clear I'm pretty agnostic on conflating issues 153 and 197

<fielding> updated the issue to OPEN

<fielding> issue-197?

<trackbot> issue-197 -- How do we notify the user why a Disregard signal is received? -- open

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

<WileyS> Justin, could you paste the proposed text here?

justin: worth moving the call for objection in the absence of David Wainberg?

<WileyS> Thank you

<justin> Note: This specification was written assuming that the D tracking status value would be used only in situations that can be adequately described to users as an exception to normal behavior. If this turns out not to be the case, either the logic that is leading to the D signal may need re-examination, or this specification, or both."

<justin> Dwainberg wanted to remove this: “Note that the D tracking status value is meant to be used only in situations that can be adequately described to users as an exception to normal behavior.”

justin: this is the language that Dwainberg wanted to be removed

<WileyS> I think we can keep the first sentence.

<WileyS> Note: This specification was written assuming that the D tracking status value would be used only in situations that can be adequately described to users as an exception to normal behavior.

<npdoty> WileyS, I suspect dsinger would be fine with that, as the second sentence is mostly a reminder to the group

walter: to clarify, if you'r oing to have the disregard signal, i'd like to have a criteria
... if someone is going to disregard DNT signal, user-agent must be informed

<npdoty> is Walter's proposal that "D" only be sent in cases of invalid syntax?

<npdoty> ... or that it has to be defined in Compliance doc?

<fielding> Do we even need to discuss that option?

justin: are you considerign the case where the signal is incorrect?

<WileyS> Then I would suggest we remain silent then on the scope of the signal and simply have the signal in the standard.

walter: base on the TPE

<sidstamm> I think if a server thinks the client signal is malformed, it can simply disregard it, right? No need to reply back.

<sidstamm> this is what roy just said

xxx: if the header sent is not conform then you shoudl not send D but you should sen nothing

<sidstamm> "D" should probably mean "I received the signal, but have reasons for ignoring it"

<npdoty> if someone sent DNTblah, then a server might ignore, or might send D

<WileyS> Wouldn't it be fair to reply with a "D" and provide the reason that the syntax is invalid?

<sidstamm> sure, but not necessary WileyS

fielding: if there is an error in the syntax, then the signal should be ignored
... not responsone should be sent

<ninja> sidstamm, the question that lead to this was whether a site that sends D in all or most cases can claim compliance

sorry did not capture what walter said

<sidstamm> ninja, thanks, I see.

npdoty: could we just move it to compliant?

walter: should not be an excuse to disregard the signal for technical reason

<walter> vincent: for other than technical reasons

<sidstamm> that language sounds fine

justin: thx walter

<WileyS> Sid, that's fair - if the sytax is so confused that we're unable to determine its even a DNT request then its probably better to not respond at all.

<fielding> The choice is whether you tell the user in an automated form "D" or ignore the signal and leave this information in the privacy policy only

<npdoty> there are requirements in TPE on user agent, but no language on whether/when to disregard a signal

justin: do you want to keep in the tpe that you consider only valid signal

<Brooks> what does "malformed" mean? Is it the header or the argument to the header?

<sidstamm> WileyS, yeah, but it would be ok to reply with "D" with a reason like "could not parse" or "don't know what that means", but surely not a requirement to reply to unparsable requests

<npdoty> can walter repeat that in IRC?

<fielding> malformed means it doesn't match the ABNF (formal syntax grammar)

yes I missed it

<walter> npdoty: given roy's arguments that http is built around the notion that malformed signals are ignored, I can see reasons to drop my text. However, if issue 153 is not resolved in a strictly technical way, I will reintroduce it.

<WileyS> Sid, I agree - to be on the safe side (individual company implementation decision) they could try to respond if they had a high degree of confidence that the signal was meant to be a DNT signal and was simply malformed in some manner.

justin: walter could you put in IRC exactly what you want?

issue-240?

<trackbot> issue-240 -- Do we need to define context? -- raised

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

issue-240

<ninja> https://www.w3.org/2011/tracking-protection/track/issues/240 http://www.w3.org/wiki/Privacy/TPWG/Proposals_on_the_definition_of_context

<justin> http://www.w3.org/wiki/Privacy/TPWG/Proposals_on_the_definition_of_context

<walter> npdoty: the origin of my language were the continuous attempts to introduce excuses to disregard valid DNT signals

justin: rob or mike suggested to add new language on context

<walter> vincent: is that precise enough?

<fielding> MUST not use MUST in a factual statement like definitions

<moneill2> +q

moneill2: the idea is to make sure that it's key and that the definition always apply

<WileyS> Context is becoming a defintion of "1st Party" - am I the only one seeing that?

<WileyS> Walter, the issue is defining what is "valid". I believe you're suggesting a signal that comes technically well-formed is all that is required for validity. Correct? I of course disagree and we can move that debate to the CfO.

<fielding> I should have said "same data controller (or joint controllers)"

I can't capture what justin said (too fast )

<justin> (more important to capture what everyone says --- I"m jus asking questions!)

fielding: context should be based on origin server, it would then be discoverable

<npdoty> justin: fielding, can you summarize your alternative to using same-party?

WileyS: speaking about the latest definition, instead of speaking of domain and branding, in the first version those were items in the defiintion of first party

<walter> WileyS: Indeed, a well-formed signal is valid at the TPE spec. If the DAA decides in their compliance specs that an otherwise valid signal only will be honoured if it has been sent under a full moon while spilling the blood of virgins, that is up to them.

WileyS: my issue we went with the word context because it was more fleaxible but now we're trying to define the word

<fielding> I meant that a link could be added to the TSR such that all resources belonging to the same context would all point to that same context, and thus the set is discoverable. This would be in addition to the definition of context.

<walter> eh, valid at the TPE level

WileyS: the current definition is just a proxy for 1st party
... we're fiding that defining a single context is not gonna be enough
... the current proposal is akind to first party and thus only one type of context is defined

justin: what use case are you worried about

<walter> isn't that what the SAME-PARTY signal is useful for?

<npdoty> these seem like reasons to re-use the "first party" definition, which includes some of these concepts (like widget interaction)

<fielding> but there is a problem with my design above: it doesn't work well with sharing the same resource (owned by the same party) in multiple contexts that are not along party lines

justin: we could pick the current definition that we have, based on discovarebility rahter than common branding

<walter> npdoty: I am now

<walter> apologies

WileyS: first party might be an appropriate replacement

<moneill2> +q

fielding: the real disticntion beween context and party is that we spoke of first party vs 3 party wheter the definition of context would allow to cover brand like Procter & Gamble

<npdoty> fielding's concern is that party-by-ownership would be broader than user expectations (like in Proctor & Gamble)

fielding: which has many domains no-one would expect to be part of a same party

<fielding> or any company that is making no attempt to share branding across multiple sites that they happen to own

walter: I agree with fielding that ithere is no a technical way to define context

<npdoty> fielding, was your suggestion to not define context so that the discussion of the breadth/user expectations can be defined in Compliance?

<justin> To be clear, we have explored the Proctor & Gamble issue for years :)

moneill2: it would be hard to see how JS api would work without the same origin rule (cosnidering the Procter & gamble example)

<fielding> npdoty, that wasn't my suggestion (it could, in theory, and then be determined by regulatory practice, but I personally prefer a definition in the spec so that user's preference is defined)

<Chapell> +1 to Roy. I'm concerned about expanding the definition beyond user expectations

<GSHans> I can take over scribing

<npdoty> scribenick: GSHans

<vincent> I missed what justin just said

Carl: finishing 240 now. trying to get more closure by next week.

<npdoty> comments on issue-240 by email by next week

Npdoty: yes that's how we have it in the agenda.

<walter> Carl was breaking up for me

CarlCargill: more closure and trying to work towards a better definition. Trying to close the can of worms and get back to finishing it

issue-239

<ninja> next topic: ISSUE-239

<ninja> http://www.w3.org/2011/tracking-protection/track/issues/239 http://www.w3.org/wiki/Privacy/TPWG/Proposals_on_status_URL_array_for_compliance_regimes

CarlCargill: next agenda item. ISSUE-239.

NPDoty: Roy made some changes to try and recopule compliance and TPE so that TPE doesn't make normative requirements. We've been working on creating a URL array for compliance regimes so that it can indicate which regime it is complying with. I personally have been objecting to that - may not be clear to users.

ChrisPedigo: echoes nick's concern. Makes sense to add 1-3 back in. since the group started, we've agreed on a 1-3d party construct, and doesn't seem wise to disregard it. There may have been disagreements about it but it has value.

Fielding: These distinctions (1st v. 3rd parties) don't matter to users, but only to the working group members.

ChrisPedigo: the references weren't removed by consensus.

Fielding: Schunter asked for them to be removed. No way to express without knowing what the requirements are for 1st vs. 3rd.

ChrisPedigo: Could be expressed in the context of another compliance regime.

<npdoty> issue-241?

<trackbot> issue-241 -- Distinguish elements for site-internal use and elements that can be re-used by others (1/3) -- open

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

FIelding: meaningful interaction has to be defined somewhere.

<moneill2> +q

ChrisPedigo: lots of compliance elements are still in the spec. There are going to be other regimes that come in and do compliance. It makes sense to keep 1-3 here so people can plug into that.

Fielding; anyone can add a 1 or a 3 in the qualifiers to explain what they mean for compliance. no need to define in the protocol on the assumption that the agreement will be done elsehwere

ChrisPedigo: including 1-3 expresses consensus from the group at an early point in the process.

NPDoty: willt ake over for call

Walter: TPE and compliance are considered simultaneously. [couldn't hear rest of comment]

<walter> GSHans: TPE and compliance were considered simultaneously originally, before I joined in. The 1st and 3rd party distinctions never made sense to my limited understanding of the HTTP protocal, nor for foreseeable compliance regimes outside the USA.

MONeill: If you're doing something not covered by tracking, there's no problem. 1-3 was supposed to differentiate between resources written by different contexts. We have to define what that means. Not sure what the problem was for using 1-3

<walter> GSHans: If anything removal of the 1st and 3rd party definitions makes the TPE less parochial and more global

NPDoty: could be related to next issue. Tied in with how we indicate compliance. Could define an informative response as defined for a 1p context, even though not for a specific set of compliance rules. Could be informative but not necessarily going to the model of indicating compliance.

<fielding> We would need text proposals for new meaning of 1 and 3

CarlCargill: We have Roy's original proposal. Qs as to why we're doing it - where do we go from here? Do we go to CFO or stay where we are?

<WileyS> Sounds like CfO is appropriate here

<fielding> … and would that be in TSV or qualifiers?

NPDoty: Roy suggested in IRC doing a text proposal. Could do that for 1 and 3. Would be good if current objectors - Walter, Mike, Roy - could give a sense if that would be workable.

Fielding: Concern would be that it would have to be something that servers can communicate. Must be able to be programmatically determined by server. In long term, don't think we'll need it, but understand desire for proposals.

<npdoty> my current expectation is that it would be a qualifier

<walter> are we going to be haunted by 80's synths again?

CarlCargill: What cannot be programmatically defined based on discussion heard today?

Fielding: Server line request has to be acknowledged based on response it gets. Can't be implemented if server needs to guess. If 1-3 meaning changed for some other purpose have to read the def to see if it would work.

<npdoty> that's good feedback, and I think that's achievable

<walter> fielding: could it work to tie in a dependency on the referrer URL?

CarlCargill: That's the limitation for those who are going to work on this. Definitional must be exclusively stated to allow server to determine.
... We will discuss this again next week.

<fielding> walter, I doubt that … referer itself is not very reliable

NPDoty: Hope is that I or others can do this before next week.

<walter> fielding: I was afraid so, just checking

Ninja: List of change proposals. Next week CFO, but we can delay this.

CarlCargiill: Would prefer to close this week to avoid CFO and go with consensus. NPDoty will work for consensus, and failing that, will put on agenda for next week.

CarlCargill: Issue-241

<fielding> issue-241?

<trackbot> issue-241 -- Distinguish elements for site-internal use and elements that can be re-used by others (1/3) -- open

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

<ninja> next topic: ISSUE-241 https://www.w3.org/2011/tracking-protection/track/issues/241

CarlCargill: Do not pretend to understand this issue. Schunter is highly concerned about it. Discussed at length at chairs session.

<fielding> hmm, I thought we just discussed it

<ninja> fielding, they are closely related due to Nick's proposal

NPDoty: Part of what we just discussed. Proposal that I gave to get out of 239 concerns would also addressed 241.

CarlCargill: If we successfully pursue 239, we can close 241?

NPDOty: Yes - or vice versa.

CarlCargill: Will hold 241 until we see how we address 239.

<moneill2> +q

CarlCargill: 241 comments?

MONeill: Would need to see user agent to determine the 1-3 from an embedded 3d party. Would add more work rather than reducing.

<fielding> So, we can actually go quickly to CfO on 239 (compliance array) since Nick's text is actually about 241

<npdoty> I tend to agree that it's not the most useful debugging aid

CarlCargill: If we do 239, do we still need 241?

<WileyS> From a pure TPE perspective they seem duplicative

Fielding: 239 is simpler.

<WileyS> Fair call out from Roy.

CarlCargill: Can we take objections from 239 and move to 241?

Fielding: Would rather do 239.

<WileyS> Is anyone against 239? I thought we all agreed we'd need an array since different markets may require different compliance pointers (or possibly multiple pointers for a single market - for example, DAA and NAI)

CarlCargill: NPDoty will address. 239 and 241 seem to be intermingled. If we sort 239, we may obviate 241, or we may redefine 241.

<walter> 241 seems very different to me

NPDoty: different people see these issues differently. Solving 241 may remove my 239 objections, or weaken them. Personally, I think if we solve 241, we deal with 239.

<WileyS> +q

CarlCargill: How do we solve this?

<kulick> i dont see them that tied together

WileyS: They are two different discussions. 241 is about should we include in TPE response signal for 1 and 2. That's a yes/no. Based on today, I think we can move to CFO now. Seems like discussion has evolved to endpoint. ON 239, agree with Roy.

<fielding> no, we need text proposals for 1/3 before it can go to CFO

<npdoty> we need to put the concrete text together on 241, and then see if there are different objections

WileyS: this is about allowing one server to allow multiple pointers for compliance regimes. Trying to determine technical merits of approaching that appropriately.
... but they are on two different discussion

Walter: if a server invites multiple refs to multiple isssues, how does server know how to reconcile?

<WileyS> +q

<WileyS> -q (Roy said what I was going to)

<WileyS> -1

<WileyS> -q

<WileyS> Roy said what I was going to

Fielding: currently, server complies with all. If there is a contradiction, they would be the origin servers fault for saying so. If there is an extreme contradiciont b/w regimes, sites will choose one or other, or will create another regime that will meld the reqs. What really matters here what users respect as compliance or not.

CarlCargill: Will pursue both. NPDoty thinks that if we do 241, 239 will fall out of its own accord.

NPDoty: Yes.

<WileyS> I disagree - one does not solve the other

Fielding: I think they are unrelated.

<walter> I think WileyS is right, they seem unrelated

CarlCargill: We'll proceed with 239 as we were, and Nick will try to structure 241 as well.
... CFO for 239, and 241 we will structure for next week's discussion.

<npdoty> it could be that I'm entirely crazy, and it's just that those who expressed objections were concerned about both

NPdoty: 239 could do CFO next week; 241 shd have proposals by next week.

CarlCargill: agenda is complete. We now have AOB.

<end>

- DRAFT -

Tracking Protection Working Group Teleconference

15 Jan 2014

Attendees

Contents

issue-197

issue-240

issue-239

Summary of Action Items

Scribe.perl diagnostic output