<schunter> Did any volunteer to scribe?

<npdoty> not yet -- who would like to step up to help out today?

<David_MacMillan> npdoty, yes

<npdoty> rigo, can you scribe?

<npdoty> scribenick: dwainberg

<vincent> ok for me

<npdoty> vincent can take over for dwainberg at what seems like a good turning point

<Zakim__aaa_is_isham> 61#

<vincent> dwainberg, let me know when you want to switch, ok?

schunter: pushed out all action items because it's not clear what's going to happen w/ the schedule

Ok. thanks vincent.

<Zakim__aaa_is_isham> mute 61#

schunter: action 61 for Mike O. Is he on the call?

<aleecia> +1

<Wileys> Closed or Pending Review?

<Wileys> I believe the hum is coming from Matthias's connection

yep

<schunter> Hmm. Maybe I should stay on mute ;-)

<schunter> I will fetch another phone. Give me 2 mins.

<Chris_IAB> just joined the call via Skype

npdoty: Rigo has action 258

rigo: action 258 was initially for Tom L, in a discussion about who is on a site composed of multiple parties.
... It would be unclear who is a 1st party, service provider, or 3rd party.
... the spec currently says a browser may consider an actor on the page and not declared in the same party as malicious.

<Wileys> Malicious or just DNT=0

<Wileys> ?

rigo: Tom argued that in the spec it should say that a 1st party site SHOULD name all 1st party entitites.

<npdoty> if you've joined us from area code 916 (Sacramento or Northern Northern California), can you identify yourself on IRC?

rigo: then I found an email from Roy, with a decision tree. Very important that the 1st party can somewhat control what others do.
... and one way is that 1st party is the only one to control the same party field.
... the SHOULD makes sure people put sufficient attention to this fact.
... has many advantages beyond what a statement about malicious would do.
... so provided language.
... (see http://lists.w3.org/Archives/Public/public-tracking/2013Jan/0093.html)

much better. thanks, Matthias.

<aleecia> :-)

schunter: Sent a batch closing email.
... discussion can continue on the mailing list.

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

<Wileys> Original language vs. Matthias' new language proposal

<Wileys> Current language allows for that outcome

bryan: believe in the current draft it does say that the setting must reflect user preference

<JC> +JC

<JC> +q

<jmayer> +q

<npdoty> issue-176?

<trackbot> ISSUE-176 -- Requirements on intermediaries/isps and header insertion that might affect tracking -- open

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

<vincent> dwainberg: are we mixing up combining two issues, intermediaries vs software that are changing the setting

<vincent> ... in ne case we might e talking about brwoser pluggins vs isp and proxies

brian: to the extent that a modification of a header reflects user preference, it is allowed regardless

<npdoty> dwainberg, would you suggest that we have different text for those two different cases (intermediaries vs. plugins)?

<Wileys> Rigo - agreed - if an intermediary wants to modify the DNT signal they must support all the same elements a UA must

fielding: not sure I get that. you can have a distributed user agent.
... proxies, for example, are never user agents.
... no as long as we stick with the terminology, we should be ok.

<npdoty> bryan: given the complexity of Web architecture, and the number of different pieces, not worth distinguishing [sorry, didn't capture in real time]

schunter: so a proxy because it's not initiating it's not a UA

fielding: it's the UA that's responsible for sending the request.

bryan: I believe the question is at what layer is that header set
... at what point does the user agent end.

schunter: so one proposal was basically it has to comply with UA requirements
... wouldn't this be a solution?

<npdoty> no matter where in the chain, it has to comply with the requirements in the spec -- that would approximate the proposal from dsinger and myself

<fielding> what is wrong with the current text in the spec?

<Wileys> Roy - I'm with you - current text already covers the issue

<schunter> Thanks for reminding me that there exists a queue ;-)

efelten: it makes sense to avoid trying to classify all the different types of software. If you are setting or modifying the header, you have a responsibility to meet the requirements.

<npdoty> fielding, Wileys, I think issue-153 was asking for additional requirements to make it clear that any software (even if not an http intermediary) has to capture the user intent

efelten: we can get to that goal more quickly by backing off the architetural taxonomy.

JC: how are we addressing IT departments that deploy the UA for employees?

rigo: it's a matter of where the declaration of the will comes from?

bryan: the IT department use case the same as the home router case.

<npdoty> JC, I don't think the current spec speaks to what an IT department does

<fielding> now we are rehashing a closed issue

<schunter> I agree.

<npdoty> (I'm not sure there's anything our spec could do to insist who sets the preferences on a machine)

bryan: if I exercise control over the domain, I should be able to set the policy.

<JC> Is this concensus?

<JC> I just want to make sure these scenarios are covered in spec.

<Zakim> rigo, you wanted to suggest that if they interfere, they have to be able to do exceptions

<fielding> See last para of http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#determining

jmayer: tendency to focus on specific fact patterns, but the considerations are more cross-cutting. If the question is what can/can't enterprise IT do?
... we can answer that.
... we can also answer what if settings conflict.

<aleecia> Rigo - we shot that idea down already

<Wileys> Nick, agreed on Issue-153 - I believe we're all saying the same thing: Any party that sends/modifies a DNT signal should be required to provide all the same functionality as the UA (explicit consent, further information, controls, exceptions, etc.)

jmayer: I suggest we describe these things to make it clear we're thinking about them, but knock down issues one by one.

npdoty: Do we need text on this at all?
... if there's some other piece of software that's not an HTTP intermediary, it has to follow the same requirements (proposed text)

<rigo> > Software outside of the user agent that causes a DNT header to be sent (or modifies existing headers) MUST NOT do so without following the requirements of this section; such software is responsible for assuring the expressed preference reflects the user's intent.

<rigo> http://lists.w3.org/Archives/Public/public-tracking/2012Aug/0001.html

npdoty: it would be adding one requirement, just to be clear there is no software not subject to the requirement.

<rigo> I think the exception mechanism is key

<npdoty> Wileys, oh, that wasn't what I heard. http proxies will not implement JavaScript APIs, for example

<Wileys> Nick, then they shouldn't be able to modify the DNT signal

<schunter> "Software outside of the user agent that inserts, modifies, or removes DNT information MUST NOT do so without following the requirements on UAs of this section including that such software is responsible for assuring the expressed preference reflects the user's intent."

<aleecia> Rigo - the problem was some user agents (already implemented) will not even have a UI. If you want to go with SHOULD do exceptions, that sounds sane, but MUST didn't work out. We've talked about this.

<Wileys> We shouldn't create different rules based on position in the communication chain

<vincent> dwainberg: some pieces of software that have direct interaction with the user should be responsible to make sure that the signal reflect the user preference

<jmayer> +q

<npdoty> Wileys, I don't think that's our previous agreement regarding intermediaries

<fielding> The language we use is "Implementations of HTTP that are not under control of the user must not generate or modify a tracking preference."

<Wileys> Aleecia, wouldn't you agree that UA's that have already implemented a DNT signal ahead of a final standard are not compliant with whatever that final standard is?

<rigo> +1 to wording of fielding

jmayer: I agree, with one clarification -- the agreement is that the same requirements apply. That doesn't mean we have agreement on the , such as how defaults can be set..

<Wileys> Nick, I thought it was and should be. Happy to have the conversation again.

<aleecia> Oh sure, Shane. But we have a question of implementations illustrating how people want to use DNT.

schunter: ok, so let's look at fine tuning the language

<aleecia> We're in no way obligated to follow what's happened, but when we already have implementations, we should pay attention to that as a valuable input

<rigo> just imagine opera mini as a UA and you'll see what we mean. This goes over a proxy and sends compressed images. It still can respect UA requirements

<npdoty> Wileys, okay, well, that's not what current text says, and we hadn't discussed HTTP intermediary spoofing of JavaScript when we agreed on that text

schunter: think it's not neceesary that it's under the control of the user, but that it refelects the preference.

<npdoty> fielding, does a plugin or software that modifies outgoing http requests count as "implementations of http"?

<fielding> Setting the preference is control

schunter: for example, an ISP that offers parental control. It's not under control, but does reflect the user's preference.

<Wileys> Nick, fair - I'm more focused on the philosophy of intermediaries

<fielding> :)

<Wileys> Di+q

<jmayer> +q

<Wileys> +q

bryan: let's be explicit wrt reflecting user preference. we're not saying the requirement must be fulfilled by every element..

<aleecia> That sounds right - some notion of "if you represent a user's choice, you better be sure it's the *user's* choice"

<npdoty> our proposed text was referring to requirements in Section 3 on "Determining User Preference" (to respond to bryan)

<Wileys> Disagree with Bryan - anyone setting a preference that doesn't allow for exceptions is not compliant with the standard

rigo: good example, matthias, because if I set a preference that only sends a fixed header, this is not a communication mechanism anymore, so I would argue for a more narrow interpretation of control.

<npdoty> bryan: we're not saying the requirement that an intermediary implement every element in the spec, the JS API for example

<aleecia> DNT is not a negotiation. DNT is not contracts-lite. DNT is a user preference.

<npdoty> to be clear, an intermediary could allow exceptions in the sense that it could have a UI where it allowed you to choose to send DNT:0 in some cases

jmayer: to respond to bryan. we may say in the spec you don't need the JS api if it's not practical. we might come up with cases, and some may be network level, but not necessarily because it's network level.

<npdoty> but http intermediaries are extremely unlikely to implement a JavaScript API; they won't commonly read those sections of the spec, even

<Wileys> Nick - disagree as this disintermediates the owner of the site (publisher) and creates unnecessary implementation overhead

jmayer: and about what degree of preference is required ... is how we deal w/ conflicts that

bryan: yes, if we have requirements where technically applicable or feasible that's fine.

<npdoty> WileyS, you disagree that HTTP intermediaries could allow sending DNT:0 in individual cases? or just that they shouldn't?

<vincent> Wileys, would an intermediary that always deny (or accept) exception be ok?

Wileys: I'm still on the hard line side, that intermediaries must be fully able to support other elements of the standard, especially exceptions. Disintermediating API calls breaks the balance we're trying to build.

<aleecia> The idea that all UAs must be browsers (which is where this ends) seems wrong to me

Wileys: as long as we're saying that intermediaries fully support the rest of the standard that's fine, but we should create carve-outs, because we create imbalance, or greater burden on pubs and 3rd parties.

<aleecia> If a party asks for an exception and a user is not able to see the ask, why not just turn the user away?

<npdoty> in the earlier agreed upon text we say: "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."

<Wileys> Aleecia - we're trying to build user friendly experiences - that doesn't meet the goal

<npdoty> that is, they must not modify it, *unless* it was user-configured to do so

<aleecia> I agree, Shane. Neither option does, is the problem.

schunter: we should take your proposal as a working assumption, and require all elements on whatever thing is doing the modification, and then look at the other UA requirements that are impossible or hard to satisfy at the network level.

<Wileys> Aleecia, removing intermdiaries that are unable to fully support the standard is the cleanest path forward

<aleecia> The cleanest path forward is to shoot DNT in the head. Doesn't mean it's the best...

bryan: starting w/ that analysis is a good thing to do. we should avoid definining everything in terms of UA te hnology, because that is overly limiting.

<vincent> Wileys, if the intermediary inform the user that it'll always grant (or deny) exception request, why it is not ok?

<aleecia> It's entirely reasonable that someone be able to deliberately choose to turn on DNT but do so through a light-weight way that does not even have a UI in some cases

schunter: let's not decide at this point, but let's follow Shane's approach and do the analysis.
... anyone disagree?

<aleecia> What's not reasonable is for a UA to decide for users what DNT should be

<aleecia> (where "reasonable" encompasses some pragmatic issues)

<Wileys> Aleecia, why is that reasonable? Supporting a standard means just that - supporting ALL of that standard. I don't believe just being able to turn on DNT=1 means you're standard compliant.

npdoty: the text dsinger and I proposed would apply to any software for all the requirements in the section on Determining User Preference. I don't think it makes much sense to require all the other elements of the spec. It makes to apply all sections on determining user preference...

<aleecia> Shane we are so far down the road that supporting DNT will not mean supporting all of DNT. You can predict everything I'd say in response here :-)

<vincent> dwainberg, switch?

<npdoty> schunter: volunteer to go through the spec and analyze which requirements would be a problem for an intermediary?

yes, thanks, vincent

<aleecia> If you *really* want that approach, cool, but then you need to live with it everywhere ;-)

:)

<vincent> scribenick: vincent

<npdoty> ACTION: schunter to review which requirements in the spec would be problematic for an intermediary [recorded in http://www.w3.org/2013/01/23-dnt-minutes.html#action01]

<trackbot> Created ACTION-356 - Review which requirements in the spec would be problematic for an intermediary [on Matthias Schunter - due 2013-01-30].

schunter: next issue is 144

issue-144

<trackbot> ISSUE-144 -- User-granted Exceptions: Constraints on user agent behavior while granting and for future requests? -- open

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

<jmayer> -q

schunter: currently with the new exception approach it means that the UA saw and retransmit the exception informatio and are allowed to modify as long as it reflects user preference
... david's point was that we can just close issue 144

npdoty: just to clarify, we have two different question on issue 144, one about the UI and one about the future requirement

<Wileys> Aleecia - I already thought I did. If I say my company is W3C DNT compliant, then I would expect that to mean we agree with the full standard.

schunter: collect opinion, anyone want to keep 144 open?

<npdoty> question 1: do we have any UI requirements? our answer: no.

<npdoty> question 2: once an exception granted, what is future behavior? our answer: send dnt:0 when an exception persists.

<npdoty> npdoty: I'm not aware of objections to those

schunter: I suggest to move 144 to pending review and will be in the next batch for closing
... no discussion, it seems that we have a consensus

<jmayer> +q

schunter: move to issue 137

<npdoty> issue-137?

<trackbot> ISSUE-137 -- Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s) -- open

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

issue-137

<trackbot> ISSUE-137 -- Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s) -- open

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

jmayer: I can't speak if the new technical design allow to know if the sp is a 1st party/3rd party
... roy opposed to flag for the sp flag (if I understand correctly?)

roy: couple of different things, in some cases the SP can't reveal that the 1st party is not sending the response (for contractual reason)
... even if the sp had to do this, it would not do it

<aleecia> I do not understand why those contracts would exist, at all. That seems broken and astonishingly wrong. What am I missing?

roy: the 1st party could do that
... the other issue is "what does sending a S in the response tell the user"

<jmayer> aleecia, I also would like to hear more about these claimed contractual obligations.

<npdoty> is the ability of the first-party to list its service providers likely to resolve jonathan's requirement?

<npdoty> if not, I think we should ask for an alternative proposal

<aleecia> If 1st parties are required to list SPs that works for me

<aleecia> If 1st parties may optionally list SPs, no

<npdoty> (or maybe we had a previous 's' proposal text that would count as the alternative)

<jmayer> npdoty, I want to make sure a service provider can always be identified. I don't care so much about the technical mechanism.

<aleecia> Since I do not understand why there is this contractual obligation, I don't know if that's likely

<fielding> But first parties aren't required to list SPs because that is undue burden for a feature that nobody has implemented

<jmayer> Note that this means a MUST, not a MAY for identifying service providers.

rigo: I would support Roy, because the SP does not have control over the data, it would only bring only statistical data about who is SP on what but no privacy material

<aleecia> Roy, to flog this again: add-ons are very likely to use this data

<aleecia> In the US, SPs are *not* part of 1st parties

<fielding> If there eventually becomes benefit to list all same parties, then that benefit will lead to implementation (far more effectively than a SHOULD).

<npdoty> jmayer, aleecia, so do we have an alternative to Roy's most recent text that we should compare to?

rigo: the defintion of SP is such that they are part of the 1st party
... nice for those who want to make statistics only

<aleecia> presumably the text prior to Roy's mods, but I'd have to look to confirm

schunter: SP follow the same privacy practices in the EU language of the data processor

<aleecia> we need to build something that works in areas other than the EU...

<jmayer> npdoty, yes, mandatory service provider flag language has floated about for a year

schunter: if the SP has not the same privacy principle, that it is considered as a 3rd party

<aleecia> because in the EU, there are legal liability issues, and we cannot visit those upon DNT implementors

<fielding> The text I have does require identification of the data controller (first party), so that is a means to detect a service provider when it is using its own domain.

<npdoty> jmayer, great, I think it might be good to clarify what the exact text is (even if we're just pointing to a previous email/proposal)

efelten: there is a case where users have a reason to know the difference, imagine that there is a primary site that include content from SP.com
... SP.com indicate that it is a 1st party

<aleecia> which is a good step. but we know service providers don't always use their own domains.

<jmayer> Off to class. I sure hope we don't batch close this issue...

<rigo> in case firstparty.com has not indicated fp.com "same party" I wouldn't believe any "1" from fp.com

efelten: it could mean that SP is a first party and can use the data for itself, if it s a pure service provider SP can not use the data for itself
... it's a case where the difference matters

<aleecia> My guess is if we go down that path, we'll see more SPs not using their own domains.

<fielding> aleecia, the only reason that 1st party does not include its service providers is because we defined it that way. It is not a US thing. In EU, they have data controller and data processor.

schunter: this issue will take longer than the last one, would like to have several proposal for the next face to face and try to find common ground
... postponed the issue until f2f

<aleecia> yes - in the EU, to use the terms we have here, the 1st party is responsible for the SP. not so in the US

schunter: propose alternative text into the spec
... fro the enxt f2f

roy: the 1st party member is not really an alternative to the S flag, it's a solution to indicate multiple 1st parties
... would not be a complete alternative

rigo: if somebody is sending back S instead of 1, it'll be fine to?

<aleecia> so that's where i'm having trouble: the idea that there's no way to visualize the difference between a service provider and a 1st party

roy: yes, but we would have to change the meaning of 1

<aleecia> users should be able to have visibility into where their data flows

schunter: but it would not give much information

rigo: legally tehre is no protection between 1 and S

<aleecia> this is basically FIPPS -- it's "no secret databases" into current times

<efelten> S does not have the same meaning as 1. S means data can be used on behalf of a (separate) first party. 1 means you can use the data yourself.

<fielding> aleecia, there is no way to visualize the difference between contractors and employees. It is NOT a privacy problem and has nothing to do with DNT.

schunter: proposal is to add 2 lines to the spec to have a concrete proposal to discuss during the f2f

<rigo> ed, I haven't really understood your use case. Can you put that in email?

npdoty: make sens, do we have an action item?

<aleecia> of course we can visualize the difference between 1st parties and SPs.

<aleecia> this is not contract employees working for a first party. this is an entirely different company

schunter: roy can you write this text and then send it to jmay or the complete list?

<aleecia> with different data practices

<npdoty> fielding, would you be willing to take that action?

fielding: lack of time

schunter: will see with dsinger

<Zakim> npdoty, you wanted to ask about volunteers for text

<aleecia> it doesn't have to be a privacy *problem* at all, just a way for users to see where their data goes.

schunter: anything else on issue 137?

<fielding> aleecia, not according to our definitions.

issue-111

<trackbot> ISSUE-111 -- Signaling state/existence of site-specific exceptions -- open

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

<npdoty> ACTION: singer to add service provider option text (with jmayer) as an issue in the draft with an option box [recorded in http://www.w3.org/2013/01/23-dnt-minutes.html#action02]

<trackbot> Created ACTION-357 - Add service provider option text (with jmayer) as an issue in the draft with an option box [on David Singer - due 2013-01-30].

<fielding> and the letter "s" does not inform the user of where their data goes.

<aleecia> not according to what you've proposed for definitions :-)

schunter: we had this postponed, the point is that if you get DNT:0 you don't know if it's a general preference or an exception

<Wileys> All of the UAs in the room said they will support site-specific exceptions - if we remove them from the specification then we can equate an exception to site-wide exception (as the publisher)

<Wileys> +q

<fielding> I did not propose those definitions.

<aleecia> either we let users block data collection, which we aren't, or at least we have to offer users a way to see what's going on. if we cannot even do that -- this is untenably broken.

schunter: do we need some extra signal to tell if the 0 is an exception or a general preference

<npdoty> action-357: the goal is to have a concise alternative/additional text for the "s flag" or otherwise an alternative to roy's most recent proposal

<trackbot> Notes added to ACTION-357 Add service provider option text (with jmayer) as an issue in the draft with an option box.

<aleecia> if you want to back away from giving users the ability to have transparency, then we need to let them just block collection. full stop.

<fielding> aleecia, that simply isn't relevant. Go ahead and block the entire Web.

Wileys: somewhat tide to what we decide on site-specific exception, the publisher receiving DNT:0 could know if the 3rd parties are covered

<aleecia> having DNT mean "your data flings around and you have no control over it, and no idea what's even happened" is not a reasonable outcome.

schunter: we agreed that we have explicit-explicit api, so there can be a case where you have explicit list

<Wileys> Okay - if explicit lists exist, then the publisher will need a way to determine which of their 3rd parties are not covered.

schunter: there can be arbitrary wierd user preferences supported by wierd user agent

Wileys: then the publisher need to know which 3rd party are not covered either to ask new exceptions, modify user experience or block third party

schunter: this would have to be handled o the server side cause user could modify the browser

npdoty: two points: 1) wether we provide the explicit list, the exception does not inform the publisher that there is an all--target exception

<schunter> Even if we have DNT0e (for: you have a site-wide exception), my self-compiled user agent can still continue sending DNT1 to all third parties.

npdoty: there is a JS API now to know if there is an exception for this lsit (I missed some of it)

<aleecia> SPs have to be knowable. it's just that simple. i'm not asking for users to be able to block SPs, which would be an entirely sensible thing, but if users cannot even know who the SPs are, this is a bankrupt exercise.

<npdoty> I was trying to clarify that we need to solve this whether or not explicit lists are supported in our JS API

I'm ot on the call anymore

<npdoty> scribenick: npdoty

adrianba: propose that we remove the array of domains

schunter: be optimistic, leave things as they are; if we find that there are mixed signals, we can come back to it then

adrianba: I expect us to request that this feature be marked "at risk"
... will send a mail with problems, shouldn't send time solving them

<Zakim> rigo, you wanted to say that it doesn't exclude a summary treatment, this is not a feature to me

<fielding> aleecia, SPs have requirements on data is siloing, non-disclosure, and no independent use -- all to ensure privacy; the corresponding benefit they get is that they are not treated as a third party.

rigo: explicit/explicit domains can be complex, if you allow for *.* and the UA is clear, the specification would not force you to implement it, just doesn't exclude others from doing it
... what is the hindrance?

<aleecia> i'm not suggesting treating SPs as third parties.

<aleecia> but i am saying no secret data stores.

rigo: can't be forced to implement it, don't see why exclude it

<aleecia> pretty basic.

<Wileys> The question is "Can we really believe that?" If not, publisher need a way to poll.

<fielding> alecia, and I am saying that if a first party can keep a secret data store, then a service provider can too -- there is no difference to the user's privacy risk.

<aleecia> huh? no. the identity of the SPs is the issue here. users should know who they're dealing with, that's all.

npdoty: we don't currently require the UA to send DNT:0 to the first party if there is an all-trackers, site-wide exception

<vincent> npdoty, I'm having phone problem, can't join

npdoty: because the user is still indicating to the first party that they want the first party compliance

<rigo> aleecia, the service provider has no own rights. So if the service provider lacks secure storage, it is the fault of the first party not ordering the sp to have secure storage

<aleecia> if that means the 1st parties list the SPs rather than the SPs list themselves, that's fine

<aleecia> Rigo - that's not the point at all. (and isn't quite true in the US i expect...)

schunter: so you might send DNT: 1e or DNT: 0e, to indicate the difference between the first party and the third party

adrianba: in response to nick's question, depends on the wildcard
... a query method with the same signature as the set method

<rigo> +1 to adrianba on the relation to the domain wildcards

<rigo> which is precisely my point

<fielding> aleecia, they should know who is the data controller. The notion that the user ever knows "who they are dealing with" on the Internet is not realistic.

adrianba: if you call the query method with the same parameters, then it will tell you whether that set method has been called in the past
... changes it from being a simple property to a method

<aleecia> ephemeral data and packet forwarding are an entirely different issue, Roy

adrianba: call the query method with the same arguments
... tell the site whether it previously recorded that exception

<rigo> +1 to adrianba

<vincent> schunter: from your point fo view the query api is enough to inform the site?

<vincent> adrianba: I think the API need to be able to know if it's a web wide or site wide exception

<vincent> the primary purpose of this is to not bother the user but know when the site get the exception

<aleecia> this is just so basic. it's pretty much Shane's "discoverable" approach, in a different context.

<rigo> +1

<adrianba> +1

<vincent> schunter: what I'll do is leave this open and wait until we have the wild-card api

<aleecia> blocking users' ability to find out what's happened with their data, even after the fact, is a broken approach

<Wileys> Aleecia, the difference here is the legal concept of "agency" and/or "service provider" - depending on which side of the pond we're on. In both cases, a company is not compelled to disclose those that work on its behalf as legally they are the same party in that context.

adrianba, can you read over the confirmSiteSpecificTrackingException code and see if that's all you need?

<vincent> npdoty, did not capture that

<vincent> schunter: anything else o issue 111?

<adrianba> npdoty, yes, hadn't seen that was added

<Wileys> Aleecia, from a domain listing perspective though I don't see how we'll be able to avoid listing the domains for our service providers/agents so they get the appropriate DNT signal.

<aleecia> If a SP screws up and accidentally publishes all the data they hold, we sue the SP, right?

npdoty: dsinger already wrote up a confirmSiteSpecificException, which does have the same parameters, as adrianba indicated, so that might be sufficient

<adrianba> npdoty, don't think it was in when i reviewed for this on monday

<vincent> schunter: that's all from my point of view, reminder: registration for the f2f

<aleecia> thursday 31st?

<vincent> ... please register before the end of the month

<kulick> If we are unable to attend the f2f, will there be a dial-in line that can be used?

<Wileys> Aleecia - it depends, if an SP/vendor is hosting an element of my business and that is breached - then I'm sued and I in turn sue my SP/vendor.

https://www.w3.org/2002/09/wbs/49311/tpwgmit2013/

<vincent> schunter: any questio about the f2f, how do we register people that would attend but are not part of the group?

<kulick> q

<vincent> xxx: how do we register people that would attend but are not part of the group?

s/xxx/bryan/

<kulick> If we are unable to attend the f2f, will there be a dial-in line that can be used?

<Wileys> Aleecia, good example was a recent breach by Epsilon of email addresses for some of its largest clients - their clients are being sued by their customers and they are in turn suing Espilon

<vincent> npdoty: send an email to the chair

<rigo> kulick, I think so

<aleecia> But they're not the same entity...

adrianba, it's possible that dsinger has been adding that recently, I haven't kept up with his schedule ;)

<aleecia> …as that example demonstrates.

<Chris_IAB> npdoty, when did you send the f2f registration email?

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/brian/bryan/
Succeeded: s/requirements/, such as how defaults can be set./
Succeeded: s/of/for/
Succeeded: s/brian/bryan/
Succeeded: s/any software/any software for all the requirements in the section on Determining User Preference/
Succeeded: s/Not/Note/
FAILED: s/xxx/bryan/
Found ScribeNick: dwainberg
Found ScribeNick: vincent
Found ScribeNick: npdoty
Inferring Scribes: dwainberg, vincent, npdoty
Scribes: dwainberg, vincent, npdoty
ScribeNicks: dwainberg, vincent, npdoty

WARNING: No "Topic:" lines found.

Default Present: npdoty, efelten_, schunter, yianni, dwainberg, Fielding, JeffWilson, vincent, +49.431.98.aaaa, ninjamarnau, Peder_Magee, +385345aabb, vinay, kulick, Keith_Scarborough, hefferjr, Rigo, WileyS, David_MacMillan, Brooks, SusanIsrael, Aleecia, [Microsoft], bryan, adrianba, hwest, Chris_Pedigo, +1.916.985.aacc, RichardWeaver, Chris_IAB, Jonathan_Mayer, Ted_Leung, +1.646.654.aadd, eberkower, +1.646.825.aaee, +1.919.349.aaff, AnnaLong?, johnsimpson, +33.6.50.34.aagg
Present: npdoty efelten_ schunter yianni dwainberg Fielding JeffWilson vincent +49.431.98.aaaa ninjamarnau Peder_Magee +385345aabb vinay kulick Keith_Scarborough hefferjr Rigo WileyS David_MacMillan Brooks SusanIsrael Aleecia [Microsoft] bryan adrianba hwest Chris_Pedigo +1.916.985.aacc RichardWeaver Chris_IAB Jonathan_Mayer Ted_Leung +1.646.654.aadd eberkower +1.646.825.aaee +1.919.349.aaff AnnaLong? johnsimpson +33.6.50.34.aagg

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 23 Jan 2013
Guessing minutes URL: http://www.w3.org/2013/01/23-dnt-minutes.html
People with action items: schunter singer

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report