See also: IRC log
<aleecia> Are there objections against creating a snapshot of this document to be published as our next TPE working draft?
<aleecia> thanks, Brendan!
<aleecia> good morning, Matthias
<aleecia> are people not able to join the call, or not identified, or both?
<ninjamarnau> today not able to join, just reading IRC
<aleecia> thanks, Ninja
<aleecia> and thank you to whomever just muted :-)
<aleecia> minus the spurious m that crept in there
<aleecia> ok, so long as people are making it on
<aleecia> agenda 1
<npdoty> agenda is available here: http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0229.html
<Chris_IAB> just joined via a blocked number
<amyc> i can scribe
<amyc> for first half
<aleecia> Thanks, Amy!
<aleecia> scribenick: amyc
<npdoty> scribenick: amyc
<dwainberg> I can take the 2nd half
<aleecia> thanks, David!
Matthias: going through agenda, overdue action items
<trackbot> ACTION-131 -- Roy Fielding to sketch use case for user agent requests on tracking status resource -- due 2012-09-18 -- OPEN
<trackbot> ACTION-245 -- Matthias Schunter to review spec for indicating service provider relationship (with singer and mayer) and propose changes if necessary -- due 2012-08-22 -- OPEN
<npdoty> fielding, do you have an estimated date?
<trackbot> ACTION-238 -- Matthias Schunter to follow-up re: David, regarding purposes of the WKR -- due 2012-08-22 -- OPEN
<trackbot> ACTION-253 -- David Wainberg to propose dropping any tracking status value for None/Anonymous -- due 2012-09-12 -- OPEN
Matthias: Roy not done yet, Matthias has not completed actions yet but have had discussions
<aleecia> It's gone to the dlist
<aleecia> I'll move to pending review
Matthias: David Wainberg has posted his action item to mailing list so moved to pending review
<trackbot> ACTION-251 -- Heather West to add DNT:0 definition and non-normative text to Compliance -- due 2012-09-12 -- OPEN
<trackbot> ACTION-161 -- Shane Wiley to work on issue-49 -- due 2012-09-05 -- OPEN
Matthias: Heather not on call,
Nick to send reminder
... concludes open actions, short list, thanks for work
<ifette> i can't understand what nick is saying, anyone else hearing bad connection?
<aleecia> (Nick is not understandable)
<ifette> still bad
perhaps just update in IRC?
<npdoty> minutes haven't gone through my cleanup process, but are all available from the home page
Matthias: asks Nick to describe what minutes have been updated, Nick to call back in
<Chris_IAB> I'm on a private/blocked number
<aleecia> sorry adam - which one?
<AN-NYC> 646 number
<aleecia> aacc is chrisOlsen
<susanisrael> susan israel is on phone at 917 934 xxyy
<BerinSzoka> I'm on from 202---4246
<AN-NYC> this is adam turkel, 646 number
<Brooks> 678.580 is Brooks
202 may be Chris Olsen, FTC
<aleecia> aacc is craig
<damiano> i'm on google voice, not sure what my number is
Matthias: appear to have identified everyone, still looking for 508
Matthias: now everyone is
... feedback on tripartite decision, input gathered, chairs tried to find decision with least justfied objections
... published decision in URL in email, wants feedback on process, not substantive decision
<ifette> Sorry, where was the result announced?
<ifette> Not seeing it
<Chris_IAB> I don't know that we all fully understand the proceedure
<sidstamm> ifette, it was in a long email
<Chris_IAB> can you recap the procedure and how you came to a decision?
<tl> Chris_IAB: You should double-check with the W3C governance documentation. It's pretty comprehensively described.
<npdoty> I could put together a page listing decisions in HTML, if that would be useful in finding/keeping track
<tl> Repeating it here would waste almost everyone's time, Chris_IAB
Roy: no issues with quality of
decision, but wants to speed up, probably about 50 critical
issues to resolve
... before last call, need to do this fast, not months at a time
<Zakim> ifette, you wanted to discuss process
<susanisrael> @npdoty-that would be helpful to list decisions
<ifette> nick, np, i've been having email problems. I get 11,000 emails per day which apparently exposed a bug in the version of gmail that's on the test clusters
<aleecia> oops - sorry, jumped the gun there
<aleecia> thanks, Ian
Roy: more in parallel, faster and
lighter weight, not so much focus on quality of response
... would rather go back to revisit decision than wait for decision
ifette: process was difficult
because we may think that we know what acceptable options are,
then get feedback from management that is not on menu of
options, if trying to figure out what we could live with then
we need a way to express concern and what we can live
... rather than forcing into two options
<Zakim> rigo, you wanted to say that we should not have textual options as this is just continuation of mailing-list in WBS
Rigo: large amount of text with last decision, how can we reduce without turning into voting?
<aleecia> Hi Ian, we spent a fair bit of time in person reviewing those texts. We then had almost two months with them.
<aleecia> But what I hear is we need a more formal call for "this is the text, unless we hear otherwise"
Matthias: sometimes text responses were repetitive, but overall informative, about 5 pages of text
<fielding> yes, it was informative and useful history -- but try doing 50 of those in three months
Matthias: this time took 2 days
to consider, next time maybe half day
... but still adds up
... ready to publish version as working draft? anything we cannot live with in order to publish as working draft
<tl> +1 Matthias
<npdoty> I believe we set that deadline last Wednesday, right?
Matthias: proposes deadline of
... still marked as working draft with notes and open issues, not claiming consensus
ifette: fine with working draft,
but how to resolve issues in working draft
... just got last decision (silence), but may need to create new issues, so questions whether there is progress?
<aleecia> If someone would like an action for non-normative text, we're happy to hear that
<aleecia> The issue itself is resolved at the normative level
Matthias: no, concern was creating undue bias through user agents, all sides found unacceptable
<aleecia> But we may be able to provide best practices and guidance in non-normative text, should someone wish to take that on
Matthias: not a good idea to discuss between the lines, think about what issues to open, and tackle on mailing list
ifette: will create issue
<aleecia> So: yes, the decision is set, but there may be ways to address concerns through non-norm means
<BrendanIAB> End of next tuesday, what timezone?
Matthias: end of next Tuesday ok to publish working drafts?
<aleecia> That was on compliance
Matthias: working draft of TPE
<aleecia> Those comments are due today
<BerinSzoka> I just got dropped from the call and have gotten an error message ("You have reached a non-working number") each time I tried to call back. Anyone else having this problem?
Nick: was there a call on this on email list?
<ifette> ISSUE: How in the spec should we ensure user agents don't twist a user preference one way or another? (Text that biases user decisions, "express" work flows, etc). Related to outcome if ISSUE-149 and http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0197.html
<trackbot> Created ISSUE-163 - How in the spec should we ensure user agents don't twist a user preference one way or another? (Text that biases user decisions, "express" work flows, etc). Related to outcome if ISSUE-149 and http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0197.html ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/163/edit .
<dwainberg> Nick -- I'd like the week to review
Nick: sees that this was for compliance spec, not TPE
<dwainberg> Yes, please
<Casey> Yes Berin, I'm getting non-working number message as well.
<dwainberg> call went out last week for same on TCS
<dwainberg> another week on TPE is fair
Matthias: do we need more time?
<BerinSzoka> skype info?
Matthias: acknowledges that participants want time to review,
<ifette> Can we get a diff of what's going to be published vs previous working draft?
Matthias: so if no objections to publishing as working draft received by Tuesday evening, then will publish TPE as working draft
<npdoty> hi BerinSzoka, Casey, we know some people are having trouble calling in as it gets crowded, please do keep trying
Matthias: discussed issue 137 in last call, had call with Tom and David on use cases being addressed with current draft
<aleecia> Tom's on IRC...
Matthias: is tom on call?
<BerinSzoka> so if we call in by skype, should we just dial the # or is there a way to do Skype-to-Skype?
<tl> I am actually here, just didn't unmute fast enough.
Matthias: want to be able to use same party attribute, UA should be able to say that these 20 URLs form a party ...
Matthias: since service provider
can declare themselves to be a first parties, for many first
parties, may cause boundaries to blur
... have not considered whether UA should be able to draw boundary around party, is this important use case?
<aleecia> (we've heard from Jonathan and Ed Felten that Tom is not the only person interested)
<ifette> added complexity, little benefit
<Zakim> rigo, you wanted to say that blurring is excluded by our service provider definition
<dwainberg> Aleecia, I think they've raised a slightly different use case
<aleecia> (and Jonathan is not on the call today)
<dwainberg> (but they can speak for themselves, I suppose)
Rigo: just wrote before call to
mailing list that issues 137 and X are related, definition of
service provider, which is close to data processor
... service provider has no independent right to collect data
... must separate via technical and organizational processes already
Rigo: may be interesting to have this flag, but doesn't make a difference between 1 or S, already addressed with Issue 49 and COmpliance spec
<schunter> serviceprovider.com (says 1)
Matthias: scenario is that
service provider says "I am part of first party"
... but can be part of two first parties, so siloing is not visible to UA
... Tom may be concerned about combined data?
<BerinSzoka> that's me that just joined by skype--finally
Brendan: TPE should be focused on current interaction, not series of interactions
<tl> BrendanIAB: But if the responses from multiple requests are inconsistent, we have a problem.
Brendan: should be talked about in Compliance, not TPE, just focused on one render, one transaction
<johnsimpson> thanks, nick
<aleecia> tom is also on the call
Matthias: tom on IRC, not on call
<npdoty> BrendanIAB, I thought the question was just how to communicate a particular status technically, which would need to be in the TPE document
Matthias: in one transaction, SP is part of A, and in another transaction, SP is part of B
<tl> I am also on the phone.
<schunter> ok. I hope I stated your point of view correctly.
<BrendanIAB> npdoty - true, but the technical status relates to the current render.
Roy: two points, SP flag provides no useful information, would still be providing S on both sites
<aleecia> This might be an easier discussion with text
<tl> +1 aleecia
<aleecia> Is anyone working to write text?
Roy: secondly, problem that you are trying to solve is addressed by SP policy link clarifying which party it is responding for
Roy, please correct if I didn't get it
<rigo> aleecia, I think the text is already in the compliance spec for once. But I don't see the TPE text
<tl> That sounds like a requirement which would satisfy this use case.
Matthias: policy link is mandatory for this scenario, is that right?
<tl> But only if service providers are required to do so.
<npdoty> and the policy field is mandatory in that particular case (where you are a service provider for some other first party)
<fielding> The tracking status resource published by the service provider always distinguishes which first party controls the data
<tl> Some user agents might be parsing it.
<tl> Not all have to, but it must remain possible.
ifette: what do we want out of this? do we want UA to parse? If someone is worried, can still do investigation, added complexity without benefit
<aleecia> (or plugins)
Matthias: need to determine whether actually acting as data processor, or is actually combining data across sites
Roy: how does that violate privacy?
<tl> Privacy is about control of info. If I don't know where my info is going, I am not in control.
<tl> In particular, if I can't tell where it is going, I can't have my user agent *not* send it to some of those places.
<fielding> Yes, that is already addressed by the policy link
Matthias: scenario is if there is element that is intended for first party use, and first party element is embedded in site but is actually used as third party context, then will not follow third party rules
<rigo> I think such a behavior would violate the Spec anyway
Roy: addressed by policy link
<tl> fielding: Only if the policy is *required*.
Matthias: confirms that policy link is required
<npdoty> tl, `policy` is currently required for these cases (though not in general)
<fielding> tl, it is required when sp is using domain not owned by first-party
ifette: scenario that you are
worried about, this is already occurring because DNT will not
be universally adopted, so there will be portions of sites that
will not respond to DNT
... this is expression of preference, sites can;t and don't guarantee that everyone complies, this is corner case
<tl> npdoty, fielding: So all service providers who use a domain not controlled by the first party must send the service provider flag, and use a TSR linking to the master domain, and must not claim to be the same party as the first party?
<ifette> It's an expression of a preference. THe server may or may not respond
<fielding> tl, no service provider flag is necessary
Rigo: in case someone
accidentially in third party context, when in first party
context, may have violated own feedback to user agent, already
addressed by DNT
... just need right response back, don't need S
<npdoty> ifette, the spec requires compliant servers to respond, per decision of the WG
Rigo: blurring border between first and third party, complicating semantics
<tl> fielding: I can live with it if the flag is required, not otherwise.
<fielding> tl, what flag?
<rigo> I still maintain that it would be extremely useful for research and statistics
Matthias: would like to close this issue, unless tom comes up with scenario where policy link will not solve privacy concerns
<tl> fielding: The service provider flag.
<rigo> responding "s" instead of "1"
<npdoty> tl, does the `policy` field need to be required for all cases? or are you fine with just for cases where the service provider uses a different domain?
tl: fine if service provider not operating out of same domain, must use 1 or 3, and SP flag, and include policy
fielding: doesn't want service provider flag
<aleecia> That's not how this works, Roy
fielding: this is recommendation, and parties that have to implement should decide issue
tl: this is designed to protect privacy
<fielding> No privacy harm has been identified.
Matthias: not about group
decisionmaking, this is consensus driven
... tom has said he does not need s flag under certain condiitions
<tl> npdoty: I only need this requirement to apply when the service provider is not on a subdomain of the party for which they operate.
<aleecia> The Do Not Call list has no privacy harm and still exists to give people control. Even if you cannot see harm, that's hardly the metric.
<rigo> we need text + action
Matthias: just need to make sure that conditions are specified in spec
<rigo> can Tom suggest?
<aleecia> Or rather, has no marginal privacy benefit.
tl: if not operating out of domain of first party, must include 1 or 3, and s flag, and tracking status policy link
Rigo: why need sp flag?
<npdoty> tl, can you accomplish the same goals just without the 's' flag, but with the 'policy' statement?
Rigo: legally and materially these are same parties, they are data processor
tl: not same party, important to me
<rigo> I think this is a security thinking vs Privacy thinking issue
<ChrisPedigoOPA> Seems like a lot of effort for very little benefit
Matthias: perhaps a candidate for decision-making process
<dwainberg> tl -- I still don't get how it's important or how a user might act on that distinction.
<fielding> unless it is *necessary* for privacy
<dwainberg> +1 Rigo
<npdoty> fielding, are you comfortable with the policy field being required if it reveals the same information as the 's' flag would?
Matthias: don't see consensus that everyone can live with, will discuss with Aleecia to tackle as part of decision-making process
<tl> +1 Matthias
Rigo: may call Tom to discuss
<fielding> npdoty, yes because the information is being revealed by the first party
tl: don't think call will be helpful, should just move to call for objections process
<aleecia> We have one proposal in the draft. We do not have a second proposal in text. We should have someone take an action for that.
Matthias: suggest talk to Rigo
<npdoty> aleecia, we did have a version of the draft with the 's' flag already
Matthias: need text for s flag
tl: previously had text
<fielding> the 's flag did not solve this use case
<aleecia> Ok. So we copy & paste
<aleecia> Thanks, Nick
<npdoty> fielding, tl, so if we agree on the information revealed to the user, is the question just what flag/field is used?
dwainberg, want to switch scribing as we move on?
<dwainberg> yes, amy
<aleecia> If that takes you 15 minutes, that seems like time well spent
tl: will double check text and will submit to chairs again to go through process
<dwainberg> scribenick dwainberg
<npdoty> scribenick: dwainberg
<aleecia> thank you, Amy and David, for the smoothest handoff ever
schunter: who's going to take an action?
<fielding> one CP is "no change to current draft"
schunter: aleecia and schunter will develop a text proposal, then take comments, and w/ agreement those are the right proposals we go ahead.
<aleecia> Tom, I do suggest you speak with Rigo in parallel -- not holding things up -- to see if there's anything useful there for either of you
<aleecia> understood, Roy
<fielding> We still haven't asked the question of whether same-party is required
<tl> rigo: Email me to set up a time to speak.
schunter: anything else on issue-137?
<npdoty> ACTION: matthias to prepare text options for a potential Call for Objections on service providers [recorded in http://www.w3.org/2012/09/19-dnt-minutes.html#action01]
<trackbot> Created ACTION-257 - Prepare text options for a potential Call for Objections on service providers [on Matthias Schunter - due 2012-09-26].
schunter: (none heard) assume
we're done with 137
... next is 116
<tl> We still haven't discussed whether same-party is required.
schunter: on requiring same
... websites can declare they belong to the same party, e.g. Lotus and IBM
<ifette> this notion of "UAs being confused" confuses me
schunter: this is beneficial otherwise UAs may be confused if elements on different URLS say they are intended for 1st party use.
<ifette> that we expect UAs to do anything with this info
<tl> Suggestion: "SHOULD"
schunter: currently optional
<ifette> UA conveys the user preference and then gets out of the way...
<ifette> (we are overcomplicating it)
<npdoty> we talked about this once as a separate well-known location with a text file list, fwiw
schunter: question is whether
... or whether we mandate
<tl> +q to suggest that sites SHOULD specify it.
ifette: we're overcomplicating by added these cases that are secondary
<Zakim> tl, you wanted to suggest that sites SHOULD specify it.
<fielding> In other words, this would allow the UA to confirm that a first-party believes some non-FP domain to be part of their FP/SP group
<ifette> apologies, conflicting meeting
<adrianba> +1 on ian's point
<fielding> still no sound from tl
<ChrisPedigoOPA> +1 to Ian's point
tl: disagrees w/ ifette. UA's may be able to do useful things for their users.
<laurengelman> +1 to Tom
<npdoty> tl, useful to have a response (we already have group agreement on that), but is this field necessary for that response?
tl: think this should be a SHOULD
<adrianba> for all practical purposes MUST == SHOULD - i don't think it should be SHOULD
<rigo> I think the response is crucial as it determines whether a service is telling the right thing
ChrisPedigoOPA: why do we need this?
tl: example. first party hosts resources on a bunch of domains. also embed resources from other parties.
<BerinSzoka> I just joined by phone
tl: now users see requests to a bunch of different domains and UA cannot tell which are 1st party and which are wrongly claiming 1st party.
ChrisPedigoOPA: so this is a case where parties are wrongly claiming 1st?
<schunter> goal: legitimate first parties that belong to each other join themselves into one same-party.
<schunter> This allows singling out the illegitimate first parties.
ChrisPedigoOPA: what about pages
w/ 2 first parties?
... think this adds a level of complexity...
<npdoty> I think I would be supportive of "MAY" and then we can provide incentives where it would be useful for a first party to list that info
<dsriedel> naive question: isnt the domain entered in the browser URL field the first party?
<npdoty> scribenick: npdoty
<dsriedel> and that domain delivers well-known with its other servers, like CDNs, etc. to claim them: under 1st-party umbrella?
dwainberg: agree with ian, as
complicated feedback (like p3p) for the user agent, beyond what
we're trying to do here, and too difficult to implement
... and SHOULD would also be strong, so would like to avoid it
<rigo> the misunderstanding is that Tom thinks that being outsourcer to two first parties allows them to combine and correlate, but 3.4 said they can NOT. So they are two siloed outsourcers for two first parties
<scribe> scribenick: dwainberg
<tl> Assertion: SHOULD != MUST
<fielding> rigo, which is why outsourcing should be inside the definition of party
adrianba: eg, a marketing website on a new domain for a short period of time, it's impractical to go to other dozens or hundreds of sites and add a new temp domain.
<tl> Large companies which have lots of sites have the option of non-including this info. However, the user-agent implementation will likely determine whether it's worthwhile for them.
<schunter> I personally believe that user agents may use heuristics to identify "illegitimate" first parties. If this pain is sufficient, large 1st parties will have sufficient incentive to declare same-party. No need to mandate it here.
amyc: thought we'd walked through
this. we're back into the conversation about what is a first
... thought we'd come to a reasonable complication.
<rigo> +1 to AmyC
<tedleung> +1 to amyc
<npdoty> I think this is just a discussion of whether the party breadth is signaled, not a change to the agreement in compliance about what the breadth is
schunter: take is that most people want to go as simple as possible. if in doubt, take the simple version.
<efelten_> Wasn't the definition of party breadth based on an understanding that the affiliation would be easily discoverable?
schunter: leave spec as it is, with same party attribute, but not mandated. is this ok?
<efelten_> Or at least discoverable?
tl: I keep saying there are UA implementations that make good use of this information.
<amyc> yes, efelten, I agee
<npdoty> efelten_, yes, I think "easily discoverable" was the rough agreement, this would be one particular way to accomplish that
schunter: other supporters of this?
<npdoty> are there other supporters of making this attribute should/must?
<aleecia> Not a group member, but I believe Jonathan also agreed and is not on this call
<amyc> I'm concerned that this mandates a specific implementation, and that if one site is not on the "should" list then it falls outside of party definition
<fielding> I think there is a use for it, but not one that justifies the cost of a mandate (SHOULD is still a mandate)
<rigo> if the user agent interferes with data processors, they actually interfere with the data controller's relations and tooling that goes WAY beyond the EU Directive
schunter: it's signal-able, but do we want to force sites to use it?
<efelten_> If we make technical changes that make affiliation no longer discoverable, that could be entangled with the past discussion.
<npdoty> laurengelman is speaking, though I'm having trouble hearing
laurengelman: if we don't mandate the signal no one will implement.
<fielding> efelten_, it is still discoverable via the domain names -- it is related to the automatable solution that tl wants for boundaries
<amyc> Aleecia, that's a bit pejorative
schunter: as an alternative to mandating the flag, we could say it's ok for UA's to use a procedure to do this.
<npdoty> I don't think we have agreement yet on what counts as precisely discoverable enough
<aleecia> I'm sure you have good stats on how many people read them
schunter: would this be a good way forward?
<amyc> I think that there are many ways that the affiliates could be discoverable, and there may be wayts to innovate in terms of making easily discoverable, without requiring machine readable list of all URLs
<aleecia> Great, what would that look like?
<amyc> that's UI :-)
schunter: "should" language is strong language in the spec, if possible you have to implement it
<aleecia> How do we get to a UI without something machine readable?
tl: I am using should as in RFC, a recommended component
<npdoty> can we have tl propose something on the mailing list? if there's other support, we can talk more, if not, we can close this and note any objections
<fielding> SHOULD means you must do this unless you encounter a situation we did not describe that overwhelms the rationale for doing it
schunter: don't see a way forward
<BrendanIAB> should This word, or the adjective "recommended", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
<laurengelman> I agree that I don't see how you are calling it discoverable without a signal of what "it" is
<BrendanIAB> That's from RFC 2119
<tl> Thank you BrendanIAB, that is exactly what I mean.
<laurengelman> easily discoverable is key to the whole definition of first party as "brand" based
<rigo> tom, would it be sufficient if you will only consider a party a service provider to the 1st party if it is enumerated in the same-party definition?
<aleecia> Rigo I don't follow what you're suggesting?
schunter: thinks this is in scope, because it's about a message of a server responding to a preference
<aleecia> We have service providers to both 3rd and 1st parties.
schunter: procedurally, ideal
outcome is where we get text we can all live with
... 2 people say they cannot live without this
<rigo> I think the current text says one can claim being a service provider (in the sense of 3.4 of compliance) withtout being in the same-party declaration of the first party (top level domain)
<rigo> this means people can make statements out of control of the first party
<aleecia> Ah, I am starting to understand more
<rigo> which is tricky, I admit
schunter: if there are objections, "i cannot live w/ this text" we must address.
<rigo> and one very simple addition would be to mandate same-party declarations by the first party and no "s" flag
<aleecia> So basically you are saying first parties are responsible for their service providers, and can declare them?
npdoty: sometime if it's only one person prefers something else, chairs will say we basically have consensus here.
<aleecia> And presumably third parties are responsible for their service providers too in that model…
npdoty: individuals can raise formal objections. Suggestion: Tom should write up why this should be and put it on the mailing list.
<rigo> if a service provider claims to be a first party and the first party hasn't declared him, the browser should be cautious
<tl> Can you create an action for me to write this out for the list, npdoty?
npdoty: we go through a process and if someone want to raise an objection...
<npdoty> sure, tl!
<aleecia> But if a service provider claims to be a third party and a third party (out of n third parties) hasn't declared, that is not information?
BrendanIAB: scope of this is enabling a validation mechanism to ensure parties claiming 1st party are.
<npdoty> ACTION: lowenthal to propose 'should' for same-party and why [recorded in http://www.w3.org/2012/09/19-dnt-minutes.html#action02]
<trackbot> Created ACTION-258 - Propose 'should' for same-party and why [on Thomas Lowenthal - due 2012-09-26].
<rigo> aleecia, if someone claims to be a third party, they are in hell anyway, so we shouldn't care :)
<aleecia> not exactly no.
<aleecia> (to rigo's point)
<schunter> Proposal: If we add language that user agents MAY use an algorithm, this may incentivize the sites.
<npdoty> agreed with BrendanIAB that we're only consider MAY/SHOULD, not MUST
<aleecia> for example, someone doing financial auditing for a third party might be sharing data between that third party and themselves.
<aleecia> without a service provider relationship that would not be allowed
<aleecia> under a service provider relationship, that data remains siloed and that can work
BrendanIAB: we're deciding between MAY/SHOULD. UA developing tech would motivate sites, with MAY. With SHOULD sites would have to develop up front, whether or not UA use it.
<rigo> aleecia: right!
tl: disagrees UA's can do whatever they want. the only way UA's can conclusively determine which parts of a site are 1st party, so would rely on sites to provide this documentation.
<aleecia> …that's not the response I was expecting :-)
BrendanIAB: if sites don't provide, UA's can penalize sites.
<npdoty> one interpretation of MAY would be that there might be user agents that would take advantage of it and that might encourage servers to document it
tl: don't like it
<npdoty> "it would be really quite great if sites would do this" as an alternative to MAY/SHOULD/MUST :)
<laurengelman> It's about incentives. This is a chicken and egg issue. If there is no critical mass of signals, there is no incentive to build.
schunter: could you live with that idea -- language saying UA may use a well defined algo for finding sites that illegally claim 1st party status.
<aleecia> (tl, when you get a chance, perhaps you could fill in more than "don't like it" that was scribed)
schunter: if we say there should be a should are there objections?
<rigo> why? Don't you want to control your services?
I object to shoulds
<efelten_> Object to shoulds in general?
schunter: for tl, do you see any way to phrase the text w/out a should?
tl: it sounds like we need to go through the chairs' procedure.
<npdoty> we have an action item open for Tom, to see if we have support for the SHOULD approach
<tl> In the event that I have a flash of brilliance, i shall be sure to share it.
<rigo> Chapell, you're forced to by compliance spec anyway, so why not give it a technical security?
schunter: tom has an action item, but if that doesn't work, we'll do the chairs' procedure
npdoty: please register for the f2f before the end of the week
<fielding> I will not be at the F2F -- will try to be online/call
schunter: new participation policy: members and participants. anyone else contact chairs.
<johnsimpson> Was there a decision on making TPE a puiblic draft?
observers must contact nick and the chairs
<fielding> johnsimpson, input will be on list, deadling next week
<npdoty> yes, we're making sure it'll be possible to call in
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/all/call/ FAILED: s/complication/consensu/ FAILED: s/deadling/deadline/ Found ScribeNick: amyc Found ScribeNick: amyc Found ScribeNick: dwainberg Found ScribeNick: npdoty Found ScribeNick: dwainberg Inferring Scribes: amyc, dwainberg, npdoty Scribes: amyc, dwainberg, npdoty ScribeNicks: amyc, dwainberg, npdoty Default Present: aleecia, BrendanIAB?, Rigo, damiano, dwainberg, cblouch, schunter, RichardWeaver, +1.703.265.aaaa, Joanne, npdoty, jeffwilson, hober, +1.646.827.aabb, fielding, vinay, sidstamm, susanisrael, tl, ifette, +1.202.642.aacc, [Microsoft], +1.425.985.aadd, hefferjr, Chris_IAB?, +1.206.369.aaee, tedleung, ChrisPedigoOPA, FTC, vincent, +1.207.619.aaff, +1.508.655.aagg, dsriedel, Brooks, KevinT, Chris_Olson, CraigSpiezle, Adam, +1.413.230.aahh, Bryan_Sullivan, adrianba, +1.609.310.aaii, efelten_, +1.612.554.aajj, +1.310.392.aakk, johnsimpson, +1.202.643.aall, hwest, Lee, BerinSzoka, +1.303.661.aamm, +aann, +1.917.318.aaoo, +1.650.888.aapp, [IPcaller] Present: aleecia BrendanIAB? Rigo damiano dwainberg cblouch schunter RichardWeaver +1.703.265.aaaa Joanne npdoty jeffwilson hober +1.646.827.aabb fielding vinay sidstamm susanisrael tl ifette +1.202.642.aacc [Microsoft] +1.425.985.aadd hefferjr Chris_IAB? +1.206.369.aaee tedleung ChrisPedigoOPA FTC vincent +1.207.619.aaff +1.508.655.aagg dsriedel Brooks KevinT Chris_Olson CraigSpiezle Adam +1.413.230.aahh Bryan_Sullivan adrianba +1.609.310.aaii efelten_ +1.612.554.aajj +1.310.392.aakk johnsimpson +1.202.643.aall hwest Lee BerinSzoka +1.303.661.aamm +aann +1.917.318.aaoo +1.650.888.aapp [IPcaller] Regrets: JeffChester DavidSinger JonathanMayer WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Got date from IRC log name: 19 Sep 2012 Guessing minutes URL: http://www.w3.org/2012/09/19-dnt-minutes.html People with action items: lowenthal matthias[End of scribe.perl diagnostic output]