Tracking Protection Working Group Teleconference -- 14 May 2014

<trackbot> Date: 14 May 2014

<ninja> Chris_IAB is really Alan

<walter> Someone needs to find the mute button

<walter> or may have found it now

<walter> that's NL

<Chris> Chris Mejia just joined the call

<jeff> OK, I guess its me.

<Alan> Alan Turransky

<npdoty> scribenick: jeff

<Alan> Hello everyone!

<walter> Alan: welcome aboard

<ninja> Hello and welcome Alan

Ninja: Welcome to Alan Turransky from IAB, and Chris Mejia as an Invited Expert.

<justin> https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Disregarding

Justin: Disregard signal

Disregard signal, ISSUE-207

Justin: one word away from consensus
... Nick provided Proposal 2 in wiki
... addresses Roy's concerns

Justin reads -- > https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Disregarding#Proposal_2:_Proposed_revision_from_Nick

Justin: Nick's proposal captures Roy and Mike's issue
... discussion on mailing group
... use of word "unambiguous"

<WileyS> Support Nick's proposal - no need for the addition of "unambigious" as suggested by Rob and Mike

Justin: may be non-normative
... concerns about Nick's language? (other than unambiguous)

<moneill2> yes I am OK with non-normative bit

<Zakim> fielding, you wanted to say I still don't think "MUST be clear" is a testable requirement

Roy: We should be clear in a privacy policy. But, I don't think MUST be clear is testable.
... so why would it be a protocol/compliance requirement.
... use non-normative text

Justin: TPE states must say was signal is disregarded
... can test if language is there
... not if it is sufficient
... so you are saying existing language + non-normative text

Roy: Yes.
... conceptually OK with Nick's points as non-normative
... Within W3C, "MUSTs" should be testable.

Justin: How do we convey "ought"?

<moneill2> +q

Roy: "Ought" means MUST to people, but does not require a test suite
... different groups handle differently.

Justin: Reasonable.

<susanisrael> justin, instead of "ought" could it say that being clear will be "helpful"?

Walter: Technical validations don't apply to compliance
... regulator will ask how it applies in court of law
... compliance is non technical
... "Ought" in non-normative language is normative

Mike: Unambiguous is important
... it is open-ended for server
... no list of tokens

<walter> jeff: Actually, in many jurisdictions a regulator will be willing to give an opinion before going to court

Mike: hence unambiguous clarifies need specific reason

<fielding> I don't think "testable in a court of law" is a level we should be aiming for; courts can test anything, whether it is attached to a MUST or ought.

<WileyS> Please explain the difference between clear and unambigious in that context?

<WileyS> +1

<npdoty> was there an example that would be clear but also ambiguous?

<WileyS> vague does not equal clear

<walter> fielding: it goes with the territory of compliance specs

<walter> jeff: "in many jurisdictions a regulator will be willing to give an opinion on whether something is ambiguous or not"

Mike: Something can be clear in English, but vague in terms of true meaning

<vincent> Example of ambiguous: 'You're request has been ignored because your user agent is compliant or beacause we believe we have an OOBC"

<vincent> not compliant

Justin: Nick, are you open to an amendment: give reasons without requiring clarity
... put in non-normative
... or do you agree you need normative language

<fielding> vincent, that example does not apply; "C" is for OOBC.

Nick: I'm flexible.

Justin: Examples where there are requirements on clear statements (other specs)?

Nick: Geolocation. Collecting location data.

<vincent> fielding, I agree but I'm thinking of a case where there could be two reasons for rejecting the signal one of them being lack of compliance

Justin: Roy do you feel strongly? Everyone else is mostly on board.
... will this roil the standards community?

<npdoty> from Geo: http://www.w3.org/TR/geolocation-API/#privacy_for_recipients refers to "must clearly and conspicuously disclose"

Roy: I can't implement it.

<WileyS> After hearing Roy's arguments, I'm now more on the side of not having "MUST be clear" in normative text. Non-normative feels this is a better path here.

Roy: Is it necessary that compliance be implementable?
... I don't know

<npdoty> the problem isn't unimplementability, the concern was about testing it

Roy: geolocation not good example... didn't go through CR process
... I'm not a process maven

<walter> fielding: the problem with non-normative is that it makes it non-binding

Roy: Maybe W3C Team can make a recommendation

<npdoty> (the documented I cited was a Recommendation, FWIW; even though it's not my favorite section)

Justin: We are very close.

<walter> fielding: and a compliance spec that isn't binding is not a compliance spec

Justin: but how does document convey the meaning.
... I'll take it offline with staff
... Shane says Roy convinced him

Nick: We can decide on text and ask for comments about QA process

Justin: still some dispute. Walter, Rob, and Mike want normative

<fielding> walter, the reason it has to be non-binding is because clarity is in the eye of the beholder. What is clear to me is not clear at all to others. I have no ability to implement that requirement, and I would love to be clear ALL the time.

Carl: Let's do what Nick said. W3C staff can comment on the QA issue.

<walter> fielding: ultimately we're crafting a contract here and that is never done under the same constraints as engineering a protocol specification

<fielding> Carl's suggestion is fine with me.

<walter> eh, specification

Justin: OK. Notes that Roy is OK.

<walter> fielding: and as much I'm willing to yield to your opinions on the TPE, as little I'm willing to yield to them on this

Chris: Unambiguous is piling on top. Unnecessary.
... also Roy's concerns.
... how do we define unambiguous?
... frivolous words will make companies less likely to implement

Justin: It is not non-implementable; just not testable
... editorial decision.
... no CfO
... let's do what Carl proposed

<walter> I don't think it is an editorial decision

UA compliance

User agent compliance, ISSUE-205

<justin> https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_User_Agent_Compliance

Justin: Not a lot of discussion yet.
... two ways to go (unless someone has a third)

<npdoty> ACTION: doty to add updated 207/disregard text, with QA review to follo [recorded in http://www.w3.org/2014/05/14-dnt-minutes.html#action01]

<trackbot> Created ACTION-448 - Add updated 207/disregard text, with qa review to follo [on Nick Doty - due 2014-05-21].

Justin: Peter + W3C staff have language
... somewhat descriptive (what needs to be presented)
... less prescriptive
... Option 2: Not have anything in TCS about UA compliance

<scribe> ... done in TPE (section 3)

UNKNOWN_SPEAKER: remove section
... haven't heard from Alan Chappel
... Jack has proposed language
... TCS relies on signals sent by UA in TPE

Walter: UA tracking another party should not affect a website tracking a user

Justin: Alan's proposal would not affect 3rd party website
... would just say that have cloud based browser; also shouldn't track

Walter: I agree that cloud browser shouldn't do that.
... but if cloud browser goes to Amazon it should not affect tracking

Justin: Not the intent

Walter: That's how I read it.

Justin: Alan will accept a friendly amendment to make that clear
... any other comments?
... contentious in the past

<npdoty> (I think there might have been some confusion about the original proposal; as UAs aren't generally recipients of the DNT signal anyway)

Justin: maybe we are exhausted
... anyone support current language in draft?

<npdoty> +1 to that

<ninja> I would rather have no text

<walter> I could live with that

<moneill2> +1

<walter> but will happily provide a friendly amendment

Justin: I will take to mailing list.

<npdoty> great

Brooks: What are the implications of being testable?
... why not the same as in TPE?
... if not testable (must do user's preference) how is it valid?

<npdoty> is this related to the current issue? or just a question of interest?

Justin: Good question. Roy?

Roy: It is testable on the UA
... that's all that matters

<walter> someone calling from Belgium

[phone operator in some language I don't understand]

<walter> it was Flemish first

scribe: it is testable, how the user agent sets the signal

Brooks: But that is not related to the actual user preference that we must respond to.

Roy: That is a theoretical, conceptual problem
... I'm talking about testability at the user
... 100% testable

<npdoty> (as a philosophy grad, I love getting into epistemology)

<walter> npdoty: heh

Brooks: The requirement is that it reflect preference at receiving end
... must be testable and is not

<walter> npdoty: let's do a Plato's cave here

Brooks: says "signal sent"

Roy: It should say "sender"; but "sent" is sufficient.

Justin: Section 4 (TPE) is on the UA
... could be a Last Call objection or a W3C folks issue

<fielding> it is actually on the UA and anything acting as the UA (privacy proxies, for example)

Justin: Two more issues

Geolocation

<justin> https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Geolocation

Geolocation, ISSUE-202

UNKNOWN_SPEAKER: noone favored keeping Geolocation in there
... Mike objected

<npdoty> on UA section, justin will follow up on the mailing list regarding possibly closing this issue by removing text / referring to TPE

UNKNOWN_SPEAKER: because geolocation over time can be identifying
... Singer suggested non-normative text

<fielding> is that not already reflected in the definition of tracking?

UNKNOWN_SPEAKER: Mike is that OK with you?

Mike: Yes.

<scribe> scribenick: Ninja

<walter> Even postal code is often too fine-grained

<walter> I've seen a PhD thesis that claimed that it was identifying individuals in over 60% of the cases

Mike: Geolocation is used to identify devices and therefore individuals. We should have something somewhere.

<fielding> maybe not … when recorded by a single context

justin: I agree. But it is in my view not different from other identifying tracking data. Maybe could be added to definition of tracking?

<npdoty> should I remove the requirement section and add non-normative text to Deidentified section?

fielding: Pure geolocation data would not be considered tracking data under our definition.

justin: Issue is that over time geolocation data could become identifying.
... I will follow up with an email to the mailing list.

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

<npdoty> ACTION: doty to remove geolocation req; add non-normative note to de-identified or tracking [recorded in http://www.w3.org/2014/05/14-dnt-minutes.html#action02]

<trackbot> Created ACTION-449 - Remove geolocation req; add non-normative note to de-identified or tracking [on Nick Doty - due 2014-05-21].

Service Providers, ISSUE-206

<fielding> … unless it is collected under multiple contexts, in which case it might be identifying user activity across multiple contexts and therefore tracking

justin: reading out the wiki text proposal from Roy and the existing TCS text

<fielding> I am okay with service provider

fielding: Proposed only very small changes.
... Minor tweaks to the bullet list. And first paragraph is more precise in our proposal.
... Hope that our proposal is just as legally enforceable as the earlier TCS language.

justin: Another proposal from Dan Auerbach *reads out*
... Do some participants want to support this proposal? Or take up parts from it?

walter: How does this interact with the same party flag?

<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#rep.same-party

<npdoty> service providers might also use the "controller" property to indicate which first party

fielding: You would not get the same-party array from the service provider but from the first party via the same party resource.

walter: Not really answers my question. Will follow up with an email.

<fielding> also noted that the change in bullet (4) of our proposal is to allow contracts that are already consistent with the spec but do not use the exact same language

<npdoty> (wants to make sure I'm not missing an action item or something)

justin: On Service Providers, I would like to ask folks to look at the text proposals from Roy and Dan and further discuss the issue.
... Today was to surface the issue and discussion. Let us know what you think about this issue.
... Thank you for today.

Adjourned

- DRAFT -

Tracking Protection Working Group Teleconference

14 May 2014

Attendees

Contents