See also: IRC log
<npdoty> scribenick: aleecia
schunter: congrats on shipping, now we go back to open issues.
... topic today is TPE, want to discuss open issues and assign actions
<scribe> scribenick: KevinT
<ifette> is there a link to the minutes to comment on>
<ifette> great :)
minutes approved
<aleecia> :-)
<aleecia> Karl is unlikely to get to this. Why don't we send email and see if he's still interested.
Action26: Karl - not present
<aleecia> If not, we can ask if anyone else wishes to take it up
Action47: Jonathan related to 49
<dsinger_> Action-79?
<trackbot> ACTION-79 -- Karl Dubost to dubost to validate whether TPE lists can be use to store opt-back-in features or not -- due 2012-02-10 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/79
jonathan: drafting in a couple hours
<aleecia> Let's ping Karl please.
<aleecia> If Karl is not going to take it up, let's see if someone else is interested in doing so.
<aleecia> Andy is a good candidate.
Amy to work with Andy on action-79 to get status (Matthias to close it) and re-open if necessary
action-93?
<trackbot> ACTION-93 -- Jeffrey Chester to write suggestions for best practices for issue-115, assisted by Ninja, Alan, Jim -- due 2012-02-29 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/93
Ninja: in review - Matthias to send Jeff reminder
action-104?
<trackbot> ACTION-104 -- Peter Eckersley to draft text for issue-24 -- due 2012-02-09 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/104
<npdoty> issue-24?
<trackbot> ISSUE-24 -- Possible exemption for fraud detection and defense -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/24
<aleecia> Amy, can you take point on this one?
<aleecia> Disagree
<npdoty> does anyone else want to take on this action?
<ifette> There's 125 emails on that issue, /someone/ needs to do text for that issue
Amy to take ownership to check with Peter on this issue.
<tl> issue-24?
<trackbot> ISSUE-24 -- Possible exemption for fraud detection and defense -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/24
<WileyS> We have draft text for security discovery and defense operational purpose exceptions
<dsinger_> Action-104?
<trackbot> ACTION-104 -- Peter Eckersley to draft text for issue-24 -- due 2012-02-09 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/104
<npdoty> aleecia, are you talking about action-104 (security) or action-107 (offline data)?
<tl> WileyS, That's you, Amy and pde?
<WileyS> Correct
<tl> =]
<laurengelman> isn't this issue 24?
Amy to take ownership for 104 and 107
<WileyS> Yes - Action 104 is linked to Issue 24
action-109?
<trackbot> ACTION-109 -- Adrian Bateman to draft text for issue-54: Can first party provide targeting based on registration information even while sending DNT -- due 2012-02-13 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/109
Adrian sent proposal, moving to pending review
<npdoty> right? logged-in state? we had a proposal there?
tl: Action-137 should also move to pending review
action-120?
<trackbot> ACTION-120 -- Alexandros Deliyannis to write a proposal on web-wide exception API (for ISSUE-113) (with npdoty) -- due 2012-03-07 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/120
<WileyS> Nick, I made the argument to dropping Logged-in State exceptions via the public email list yesterday
<WileyS> Alex, it's 111
<aleecia> thanks for issue-24 texts, Jonathan.
alex_: waiting on discussion from action-111, will submit next week
action-123?
<trackbot> ACTION-123 -- Jeffrey Chester to draft a response to 1st/3rd proposal (with Lauren) -- due 2012-02-29 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/123
<npdoty> great, thanks, WileyS; and can you confirm that it's in response to action-109?
<aleecia> https://www.w3.org/2011/tracking-protection/track/actions/123
<aleecia> Are you still working on it?
jchester: no progress, needs one more week
action-130?
<trackbot> ACTION-130 -- Matthias Schunter to collect use-cases for URI vs Response header -- due 2012-02-29 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/130
<WileyS> Nick, correct, Action 109
<aleecia> that one's fine to close
tl: defunct, will be discussed in Agenda 5 today
<aleecia> has been overtaken by events
action-133?
<trackbot> ACTION-133 -- Matthias Schunter to collect comparison criteria and summarize comparison in URIvsHeaders table -- due 2012-02-29 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/133
<johnsimpson> +1
<npdoty> can we add the URI to that table to that action?
<aleecia> good idea, Nick
<npdoty> okay, will do
move to pending review
action-135?
<trackbot> ACTION-135 -- Shane Wiley to detail use case for ISSUE-111 (DNT;2) -- due 2012-02-29 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/135
<WileyS> Thank you
<aleecia> Shane - time estimate? :-)
keep open due to active discussion
<johnsimpson> do you want to assign a date?
action-136?
<trackbot> ACTION-136 -- Matthias Schunter to propose simplified set of fields for URI and response headers -- due 2012-02-29 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/136
<npdoty> fine with me
schunter: next meeting
<WileyS> Aleecia, if everyone would simply agree with me, then the time estimate would be today. :-) Difficult to guage an estimate at this time.
<npdoty> WileyS, the action is just to provide a detailed use case, right? we don't all have to agree with you on it :)
<aleecia> I agree -- it's hard to estimate right now
tl: suggest closing and waiting for unified response discussion
action-137?
<trackbot> ACTION-137 -- Thomas Lowenthal to draft alternate proposal on first-party targeting based on registration information -- due 2012-03-10 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/137
<scribe> pending review
action-138?
<trackbot> ACTION-138 -- David Singer to investigate definitions of user action/input in HTML5 or similar specs -- due 2012-03-07 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/138
<WileyS> He was on but dropped a few minutes ago
<WileyS> Now he's back on!
<aleecia> David's back
action-139?
<trackbot> ACTION-139 -- Thomas Lowenthal to improve wording of 3.9 "Meaningful Interaction" to avoid "affirmatively clicking" and make sure that "clicking" is replaced with something more general. -- due 2012-03-11 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/139
<npdoty> dsinger sent a small piece of text on 138: http://www.w3.org/mid/2CA04067-5D89-4B30-81D9-47A64461FA38@apple.com
<aleecia> Action-138, status when you get a chance please David
tl: needs until next week
<aleecia> I think this is pending review for 138
<dsinger> action-138?
<trackbot> ACTION-138 -- David Singer to investigate definitions of user action/input in HTML5 or similar specs -- due 2012-03-07 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/138
<npdoty> action-140?
<trackbot> ACTION-140 -- David Singer to work on updates to TPE introduction (harmonize with Shane/John) -- due 2012-03-07 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/140
action-141?
<aleecia> action-140 is close and shipped
<trackbot> ACTION-141 -- Rigo Wenning to draft text on clarity that this is for user agents (addressing his concern) -- due 2012-03-07 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/141
<aleecia> 138 should be pending review, 140 is closed.
<WileyS> Action 111 has several detailed use cases - if we feel we've collected enough use cases at this time then perhaps we can move the item to "pending review"
<trackbot> Sorry, couldn't find user - 111
dsinger: action-138 completed
<aleecia> yes
<aleecia> done, shipped.
dsinger: action-140 completed
<npdoty> "not completely harmonized, but certainly improved"
<WileyS> I'll provide edits later but feel the new draft is moving in the right direction (but still too long)
<tl> How quaint is it that we use the verb "shipped" to describe pointing arrows to specific revisions of a version-control system?
<npdoty> +1 to WileyS on a shorter intro
<aleecia> Shane - my guess is we'll be fiddling with that text until the final.final.final version
<WileyS> Aleecia - agreed.
<aleecia> My tendency is to write the abstract last, after the rest. Same idea here, I think.
<aleecia> If it would make anyone feel more comfortable, we can do a new action of "revise intro" in deep sleep and take it up later.
<scribe> New business: issue-111
<aleecia> I'm not offering to open it right now...
issue-111?
<trackbot> ISSUE-111 -- Signaling state/existence of site-specific exceptions -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/111
<aleecia> (sigh)
<jmayer> If we have web-wide exceptions, the same issues around exchanges crop up.
WileyS: worked with Adobe on proposal for two key perspectives before proposed text. 1) consumer - I trust the "site", 2) I trust this "third party" - web wide
<jmayer> I'm concerned the practical effect of this proposal will be shunting sites and consumers to blanket exceptions instead of site-specific exceptions.
<jmayer> Previous proposals would have simply allowed more flexibility.
<jmayer> ifette, I imagine Google...
<jmayer> Yes ifette, social widgets would likely be a common use case.
<dsinger> so this is "I trust the NY Times and their choice of 3rd parties, and do not want to go through all their 3rd parties explicitly"?
WileyS: Large publishers: would prefer only trust site (vs. third party) . Recommend use of wildcard that is passed from site to third parties under contract (DNT:0)
<schunter> new semantics: DNT;0 = you have an exeption
<schunter> DNT;1 = do not track me
WileyS: removes needs for server-side calls, polling, etc...
<jchester2> I am also concerned that this proposal would weaken a user choice on DNT, providing uninformed blanket exceptions.
WileyS: there is some need for server-to-server communication; adchoices meta data is a possible recommendation
<ninjamarnau> the problem is that nyt does not know which third parties are part of such an ad chain like kevin mentioned in his emails
<npdoty> can someone point me to this proposal on the mailing list? I thought I was up to date on these threads, but I haven't seen this.
<ifette> http://lists.w3.org/Archives/Public/public-tracking/2012Mar/0276.html
<ifette> (I think)
<dsinger> can't the browser notice "you are visiting NY Times" and therefore send DNT:0 to all 3rd parties pulled in by that site?
<tl> schunter, Not "exception", DNT:0 is "You have consent to track me right now."
WileyS: adchoices meta data— gives more data on what is inside the ad chain
<aleecia> We run into problems in Europe with *
<jchester2> We need to understand the full impact of using AdChoices metadata, and its impact on user choice (based on how its operationalized)
<ifette> What if YieldManager has an exception but the ad network it syndicates to does not
<ninjamarnau> European law demands knowledge or at least possible knowledge of third parties - a blanket exception is no option
<WileyS> Disagree Ninja - as processors do not need to be disclosed per the Data Protection Directive (and the draft regulation doesn't change this stance)
<ninjamarnau> WileyS, the third parties are not processors here but rather controllers in my opinion
<npdoty> WileyS, I thought we were talking about additional "third parties", i.e. controllers
<WileyS> Ninja - exactly, your opinion, which is not EU law :-)
<aleecia> Shane you're suggesting you know EU privacy better than Ninja? :-)
<ninjamarnau> I'm not talking about all third parties, but all cases when they collect and process data on their own behalf
<WileyS> Aleecia - no comment :-)
<aleecia> Wow
<ninjamarnau> you're always welcome to prove me wrong Shane :-)
<WileyS> Ninja, I could agree with you, but then we'd both be wrong. :-)
<npdoty> tl: the site-specific exception API is orthogonal to server-to-server communication, which would always be allowed if receiving DNT:0
<ifette> So if YieldManager gets DNT:0 and redirects to AdExcahngeXYZ....
<Zakim> ifette, you wanted to ask for examples of third parties we expect users would "trust" across the web
<npdoty> (personally I don't think user agents ever need to send DNT:0 to the 1st-party site)
<WileyS> Dynamic delivery environments break the 1st party / 3rd party list concept
ifette: user would have to add an exception for a third party
<WileyS> Nick, how is that possible? Isn't the first party the one requesting an exception for their site. If they never are told they've been granted an exception they'll have to ask the user for one every page of the site (or at least the first page of the session)
ifette: potential conflict from browser setting vs. backchannel passage through ad chain?
<npdoty> WileyS, first-party sites remember a lot about my preferences right now without asking me over and over again, with cookies, for example
<WileyS> Nick - but they still need to capture it once. AND users need to go back to each first party to manage those preferences. By capturing exceptions in the browser, the user has a single place to manage their preferences.
<JC> I agree
<JC> Browser could send ad.com DNT:1 and 3rd party on site could send ad.com DNT:0
ifette: will craft email to address issue with multiple redirects to get better clarity
<aleecia> indeed if Ian can't figure it out, the doc is deeply broken in terms of communication
<npdoty> Agreed, WileyS! The JS api returns a value to the first-party so they can capture it. And I agree, site-specific exceptions are best managed by the user agent for that reason.
<dsinger> I share the confusion. Reading and thinking needed
<WileyS> Nick, I'd rather not carry the weight of JS APIs if I can get the simple signal in the header.
<ifette> ACTION: ifette to review the proposed text for ISSUE-111 in the context of a redirect chain where some parties get 0, some parties get 1, and there is potentially some data sharing between the parties in the redirect chain [recorded in http://www.w3.org/2012/03/14-dnt-minutes.html#action01]
<trackbot> Created ACTION-146 - Review the proposed text for ISSUE-111 in the context of a redirect chain where some parties get 0, some parties get 1, and there is potentially some data sharing between the parties in the redirect chain [on Ian Fette - due 2012-03-21].
<npdoty> That was how you and I designed the JS API to begin with, right?
<ifette> that's similar to what i was asking
<npdoty> scribenick: npdoty
<KevinT> thanks npdoty
jc: there's an ad network on the page, sends a request to another page to serve the ad -- doesn't it just send on the signal it received?
<WileyS> Nick, I agree and for "known" 3rd parties it makes perfect sense. But as the discussion moved to dynamic serving environments (like exchanges), it breaks our original approach so we've been looking for simpler implementations.
<schunter> I believe so far, I have not seen any argument for changing the API?
tl: dnt:1 doesn't mean that the user isn't allowed to know things about the user, just about this particular http interaction
... doesn't stop you from going down to the pub tomorrow and telling other wacky stories about me
<aleecia> tl: DNT is specific to a specific network interaction, the specific request. Just about the conversation now
JC: sounds good, I hope that's clear in the spec
<aleecia> dsinger: if DNT to some third parties and not all, the first party doesn't know who those are. First party can pass info to the wrong parties.
<aleecia> ... 3rd parties can ignore it, better if no passing at all
<aleecia> ... two fall backs, including API
<schunter> mute me
<aleecia> tl: as long as this specific network interaction, yes.
dsinger: the third parties who receive DNT:1 should still ignore the data they receive back-channel from the first party, and it would be better if they didn't receive it at all, but we're still good
npdoty: this is one reason I think the first party should always receive DNT:1
<aleecia> jmayer: three points. first, motivation is exceptions are "broken" by ad exchange model. disagree, see dlist.
jmayer: concern that exceptions are "broken" for the ad exchange model, but they aren't for the reasons I described on the list
<aleecia> ... but 3rd parties still have web-wide exceptions under Shane's proposal.
<aleecia> ... unless CNN prompts you to change status, you have exception for Yahoo! and no others, if you had previously trusted Yahoo!
jmayer: when I go to CNN and I have a web-wide exception for Yahoo and no other advertiser, still have the question of propagating different DNT status
<aleecia> ... need browser API or other method anyway; problem does not go away (if there is a problem)
<aleecia> ... 2nd: new communications on backend between 1st and 3rd parties
<WileyS> Not true - many server-to-server APIs in place across the Internet today
<aleecia> ... bad outcome if DNT incentivizes new channels to share more about users
jmayer: I am concerned about opening more back-end communication channels between 1st and 3rd parties, good because it gives us more insight into what's going on
<schunter> I believe that if a site knows its third parties {tp1, ...., tpN}, it can ask what subset has exceptions.
jmayer: would be unfortunate if DNT incentivized more back-end communication channels
<aleecia> ... 3rd, fingerprinting. Different technical suggestions here, but don't think blanket first party - fingerprintable information there (missing part)
<aleecia> ... need to deal with fingerprinting both for what we allow, and what advice we give to implementers
<scribe> scribenick: aleecia
WileyS: confusion, but dynamic environment is the core issue.
<schunter> If a site does not know its third parties, then it cannot ask and some may not have exceptions.
WileyS: publisher's ability to gain an exception for themselves and 3rd parties they work with.
... dynamic adsorbing, no way for 1st party to know who ultimate 3rd party to be
... polling mechanism doesn't work. Until ad is served, the 3rd party isn't known (or on the list)
... that's the problem we're trying to solve
<jmayer> Why does it matter if the page knows which *ad* is served?
<vincent> how does that work with opt-out cookies currently?
<jmayer> They don't know now, and that's fine.
WileyS: if we're trusting a website and what happens there, removes the need for the JS API.
... all parties on that site get DNT:0 signal
<jmayer> What may matter is a publisher knowing which third parties are and aren't excepted.
<schunter> In the current proposal, you need to ask for ¨*¨ thirdparties if you want to use dynamic serving (=do not know the actual third parties).
ifette: similar question, as a first party want to know status of third paries.
<jmayer> ifette, agree that first parties should be able to learn third party exception status
<jmayer> many ways to do this, see the list
ifette: is it worth having a FB plug in, or should I not display it? If DNT to some ad networks, choose the one with DNT:0
... what info does 1st party get about their 3rd parties on their site
<Zakim> ifette, you wanted to state the first party may wish to know the state of what's happening with the third parties, e.g. is it worth displaying this giant facebook plugin
tl: covered by tools available. for Shane's point: not knowing the final leaf of the ad serving decision tree, only way to request DNT:0 to all those parties is a this_site, * exception. That's transparent. Some sites know all of their third parties.
<laurengelman> that could be good for competition if publishers could choose ad networks that have better privacy (assuming that the increased DNT:0s are a fair indicator of that)
<ifette> whenever anyone says "if users understand that" i get big red flags going up in my mind :)
<schunter> I agree.
tl: for other sites, need to make a * request to understand. Users can understand "Yahoo! would like to allow any tracker" and make a choice
... users have the right sort of choice. If a lot of sites ask site, * then that's ok.
... sites may make multiple API calls: *, or social widgets in a different call, all of these uses are legit
... to Ian's point: they can discover the status via API, and user may be prompted
<laurengelman> I have to hop but most sites do not know all their third parties
Ian: don't think that's accurate. Realistically, a priori want to know to serve appropriate content
<WileyS> Agree with Ian - there is no way to know BEFORE serving content with the current draft implementation
Ian: don't want to figure out client side what your page should look like
<ifette> Jonathan, I said *before* the page loads :)
<vincent> I think that site-specific exceptions would be an opportunity for publisher to know which 3rd parties are distrusted
jmayer: very specific - how do we make sure 1st party knows status for 3rd parties. could do: 1. browser API only exposed to 1st party. 2. first and third party work it out asynch
... not hard web engineering. first party learning about third a prior is technically possible, we can make it easier.
<WileyS> If user consents to "*", are we agreed that DNT:0 should be sent to all 3rd parties on that publisher's site?
<WileyS> If yes, then I'm fine.
<npdoty> I'm not sure I can add as much
schunter: thinks there's no fundamental difference suggested. Want different proposals.
<npdoty> if user consents to publisher,*, yes, the user agent will send DNT:0 to all 3rd parties, including after redirects, yes.
schunter: anyone want an action to draft a different proposal?
<WileyS> Nick, Thank you - then I believe there is no issue here
schunter: API doesn't need to be changed from what I've learned
<tl> Behold, the queue is empty!
schunter: API looks sound, no need for changes
<tl> WileyS: Yes, if the user accepts {thissite,*} that's exactly what's going on.
Nick: if publisher asks for *, then sends DNT:0 to all parties after redirects
<schunter> User may choose to only say ´yes´ for a specified list of third parties.
Shane: if user can convey that to all parties, then we're fine.
tl: that's exactly what * means
Ian: not subsequent requests
<WileyS> Correct - first request fails
<ninjamarnau> how can a user trust a first party, when we assume that this first party does not know all of its third parties in a complex chain of multiple redirects
<jmayer> Don't think that's an issue.
(cross-talk)
<npdoty> ninjamarnau, I agree, I'm not sure "trust" is necessarily the right concept here, but if this is clear to the user, then I think it's acceptable
schunter: Google sends a page asking for G and all 3rd parties in response to DNT:1
tl: also DNT:0.
<WileyS> Ninja, they trust the 1st party to only work with the appropriate 3rd parties
<vincent> wasn't the issue on the granularity of site specific exception?
<npdoty> WileyS, even though the 1st party doesn't know the 3rd parties that it works with?
tl: if you are a publisher, you send everyone DNT:0 except one social network, and you are a publisher and ask for *, I'm going to say no.
<WileyS> 1st party takes on the onus of ensuring only appropriate 3rd parties appears on their site and can manage this proactively via their ad networks and exchanges
schunter: it's sort of black listing, if I don't like a widget everywhere, I need to say no to all * requests
... if site doesn't tell me all third parties, I have to say no
Ian: site has no idea which parts of content are getting 1 or 0
tl: can ask self, 3rd party -- on JS request at a time
Ian: I have to know every ad network I might redirect to, right?
<ifette> this seems problematic to me
tl: yes, but might be sensible to go for common options first. Exposes one thing missing: ability to request * except for {foo, bar}
ifette: but I don't know who I should be excepting
<ninjamarnau> WileyS, I agree. But I am concerned that this is not the case. Though this is not an issue DNT can solve.
<ifette> ACTION: ifette to enumerate scenarios in which requesting exception[mysite,*] might not work, e.g. user says no, then how do you figure out what you can or cannot get exceptions for, such as if user is only saying no to facebook but you don't know which, if any, of their ad networks the user is objecting to [recorded in http://www.w3.org/2012/03/14-dnt-minutes.html#action02]
<trackbot> Created ACTION-147 - Enumerate scenarios in which requesting exception[mysite,*] might not work, e.g. user says no, then how do you figure out what you can or cannot get exceptions for, such as if user is only saying no to facebook but you don't know which, if any, of their ad networks the user is objecting to [on Ian Fette - due 2012-03-21].
<WileyS> Ninja, the existance of DNT and AdChoices are bringing increased awareness and focus across publishers to "care" about this situation and take more proactive steps to manage the quality of the 3rd parties on their site.
<WileyS> Okay - I can help explain the corner cases
<ninjamarnau> hopefully :-)
<schunter> The fact that a user agent says ´no´ to ¨thissite, *¨ if a user does not like a third party is complicated.
jeff: how does this affect real-time ad exchange model
<npdoty> WileyS, if the first parties are taking that onus to audit, then wouldn't they know the list of 3rd-parties to request for?
<aleecia_> (so basically Ian's point...)
jmayer: concerns from "corner cases" assume a polling-based rather than list-based API.
... not sure fingerprinting concerns are a problem
<dsinger> you should not be able to ask questions about other than yourself and in your own status
<npdoty> I don't think that works, but can we take that discussion offline.
jmayer: could have APIs in browser that a 3rd party could abuse for tracking, since we have countless examples already.
<dsinger> 'what are my exceptions?' is the question (where 'my' is the script origin, as defined by cross-site scripting)
<WileyS> Agree - I've been asking for that on the chain :-)
<schunter> ACTION schunter to restructure and clarify ISSUE-111
<trackbot> Created ACTION-148 - Restructure and clarify ISSUE-111 [on Matthias Schunter - due 2012-03-21].
jmayer: given there are technical ways to limit scope of API to browser, we should open the discussion on fingerprinting again, since marginal privacy risk may be slight and there may be gains
<npdoty> I'm not sure I agree with Jonathan's interpretation of the implementation risk, but I'm perfectly happy to open that for more discussion
tl: are you taking an action, Jonathan?
<WileyS> Please add me to the action item for the deeper exploration on this topic.
jmayer: already have a proposal.
<schunter> ISSUE revive Javascript API for obtaining exceptions as a list (only for 1st parties; 3rd parties cannot call it)
dsinger: we can take script origin so you can only find out about yourself
ian: first party wasn't origin based?
<npdoty> I suggest one of us take an action to start a thread between jmayer and the browser vendors (at least Mozilla + Microsoft who had the fingerprinting concern) to investigate that risk
tl: jquery from CDN, half my stuff wrapped up in jquery, how is browser knowing which things are who?
jmayer: Ian, thinks first parties might span multiple domains, but using domains for technical implementations
... Tom's question, how do we know who can call the API, not as concerned since browser already has top level origin for reasons on the dlist (Sid) - if your origin is the same as the top level, API does useful things.
tl: can you write that to compare?
<schunter> ACTION jmayer to write alternate API
<trackbot> Created ACTION-149 - Write alternate API [on Jonathan Mayer - due 2012-03-21].
jmayer: sure, sending email now
schunter: other actions here?
... if not, would like to have a look at status on the header + well known URI
tl: status is, writing now, will send out by tuesday.
... must have tracking status resource. response header only when something changes within cache duration
... may send response header the rest of the time
<npdoty> thanks for the summary, though
schunter: full discussion next call
... discussion about opt-in globally and EU law?
<WileyS> Sounds good
ninja: not disagreeing over law but maybe over mechanism with Shane and will take off-line, have discussion, then get back to the group
<npdoty> +1, thanks to Ninja and Shane for doing so
action here?
<ninjamarnau> yes, I do think we are NOT disagreeing. I am optimistic :-)
schunter: didn't rip API apart, can improve it, but not wholesale shift. Use cases help
<tl> Thanks for scribing, aleecia!
<johnsimpson> bye
<tl> It's great when we finish early.
<schunter> ACTION nmarnau to analyse EU legal implications of exceptions to (thissite, *)
<trackbot> Created ACTION-150 - Analyse EU legal implications of exceptions to (thissite, *) [on Ninja Marnau - due 2012-03-21].