See also: IRC log
<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: Disregard signal
Justin: one word away from
... Nick provided Proposal 2 in wiki
... addresses Roy's concerns
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
... 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
... 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
... conceptually OK with Nick's points as non-normative
... Within W3C, "MUSTs" should be testable.
Justin: How do we convey "ought"?
Roy: "Ought" means MUST to
people, but does not require a test suite
... different groups handle differently.
<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
... 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?
<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
... 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
Justin: Not a lot of discussion
... 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
... 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)
... 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
... anyone support current language in draft?
<npdoty> +1 to that
<ninja> I would rather have no text
<walter> I could live with that
<walter> but will happily provide a friendly amendment
Justin: I will take to mailing list.
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
... 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,
... 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
... 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
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
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?
<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.
<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].
<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
... 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> 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.
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/vauge/vague/ Succeeded: s/Are/Nick, are/ Succeeded: s/specificiation/specification/ Succeeded: s/concern/preference/ Succeeded: s/get this information/get the same-party array/ Found ScribeNick: jeff Found ScribeNick: Ninja Inferring Scribes: jeff, Ninja Scribes: jeff, Ninja ScribeNicks: jeff, Ninja Default Present: walter, Ninja, Fielding, Wendy, Jeff, npdoty, +31.65.275.aaaa, Peder_Magee, Alan, Carl_Cargill, MECallahan, +1.323.253.aabb, robvaneijk, Susan_Israel, Ari, Chris_Pedigo, eberkower, hefferjr, justin, moneill2, Chris_Mejia, WileyS, vincent, +aacc, sidstamm, Brooks, WaltMichel, schunter, MattHayes, [FTC], adrianba Present: walter Ninja Fielding Wendy Jeff npdoty +31.65.275.aaaa Peder_Magee Alan Carl_Cargill MECallahan +1.323.253.aabb robvaneijk Susan_Israel Ari Chris_Pedigo eberkower hefferjr justin moneill2 Chris_Mejia WileyS vincent +aacc sidstamm Brooks WaltMichel schunter MattHayes [FTC] adrianba Regrets: dsinger johnsimpson kulick JackHobaugh Found Date: 14 May 2014 Guessing minutes URL: http://www.w3.org/2014/05/14-dnt-minutes.html People with action items: doty[End of scribe.perl diagnostic output]