See also: IRC log
<aleecia> Hi!
*/*sorry for getting the syntax wrong, thanks Nick
<yianni> Zakin, 2025874870 is yianni
<AdamTurkel> 646-827-XXXX is adam turkel
<dan_auerbach> 301 is me
<Chris_IAB> Peter Swire, Lou Mastria and Chris Mejia dialing in from 212-380... together
<moneill2> zaqkim. [ipcaller] is me
<npdoty> schunter: welcome all back from the holidays
<npdoty> volunteer to scribe?
<npdoty> scribe: susanisrael
mattias: one change= caller id to be done in background; try to get on irc and tell nick who you are
<rvaneijk> Hi, I will not be able to attend the call unfortunately..
<eberkower> aavv=eberkower
mattias: welcome-looking forward to a couple productive months to finish both specs
<rvaneijk> Success !
mattias: had productive 2012,
identified issue, shouldn't be a big deal finishing this
year
... peter would like to spend a couple min on compliance doc
then i will discuss tpe. comments on agenda?
Peter Swire: Happy new year. I will talk for a while to give people background of what will happen next week. ....
scribe: my goal is to be inclusive.
Wanted to get to know as many stakeholders as possible. IN those conversations was trying to identify a path forward. More than 30 meetings so far.
Peter: have responded to all messages and have told people when I would be in various cities. want to build confidence and get to know people. If i have not responded to you I apologize
ping me again if you want and we'll try to have a good discusison.
Peter: in those meetings the area of de-identification or de-linking seemed quite promising. another topic was default settings and I don't expect to address that soon. But ,,,,
<tedleung> zakim bbaa is tedleung
de-identification is an area where people of different views think it would be helpful to work on this. advertising industry says they don't use pii and ngo's/advocates also interested.
It's important on compliance side. If it's not linked, you are not tracked, roughly speaking. So working on de-identification is somewhat like defining what tracking is. Not exact, but similar....
so not surprising that what counts as not tracked/de-identified will be important.
peter: there may some win-wins that can happen here. de-linking may improve privacy but permit better utility for data. Could see wins for people who want to use data and people who don't want to be identified.
<ifette> i get a busy signal when trying to call in
<ifette> (3x)
turns out to be related to permissible uses.
<bryan> i cant dial in either
peter: with that as background we
can see why this set of issues is important and will have to be
addressed in any spec.seems a necessary step to any eventual
standard
... beyond that these issues of de-identifiication are
important in their own right. have been the focus of a lot of
attention--in uk and through hhs in us, and canada on
healthcare side has done work on this
<aleecia> Uk, health & human services, Canada, FTC - sources of other thoughts on identification
<ifette> ty
<aleecia> (wow, irc lag)
peter: a lot of technical people who have done good work on this turn out to be in the w3c process. It may be we have some meetings and do work on this, produce some white papers for people working on this.
this is an area where policy makers have been confused, debates contentious, maybe we can help
peter: if good work to do here,
what is our path?
... there was a sense, in meetings that one challenge is that
people some times talk past each other, use different
definitions, have different threat models, don't have common
vocabulary
... so this sort of technical descriptive side seems to be
something where it s positive to get conversation moving.
<npdoty> if you're calling in from one of these numbers, please identify via IRC: +1.202.331.aall, +1.202.639.aarr, +1.202.296.aass, +1.408.349.aazz
peter: one goal i had was to make sure i had some good technical folks from different perspectives working on this, for example, EFF, and Ed Felten. IAB chris, david wainberg will be there in person, with shane wiley on phone
<jchester2> Peter: You should have presented this first to the entire group, explain your plan then move forward. That it would make it legitimate. Instead of cherry-picking people.
not intended to exclude others, but wanted to make sure we have the key people in the room. This weekend got enough yeses to make sure we have range of views in room to make this worthwhile.
peter: Khalid El Ahmid phd with book on subject will be in dc on that date, and morning of 17th avoids conflict with NTIA that afternoon. CDT will host. 9-12:30/12:45 EDT
<ifette> Is this a short notice f2f? Sorry, just dialing in now...
<aleecia> 6 am pacific. Spiffy
<npdoty> if you're calling in from one of these Washington DC numbers, please identify: +1.202.331.aall, +1.202.639.aarr, +1.202.296.aass
peter: we will scribe and have call in and open invitation for people to come physically. room holds 30-35 maybe 40. If you want to come pls send email to yanni lagos ylagos@futureofprivacy.org.
<bryan> we will attend remotely
peter: that's just to get a sense of the numbers. IF too many will figure out a good way to proceed. Maybe limit it to 1 person/organization, but may try other things.
<ifette> Object to the flurry of short-notice meetings here...
peter: separately, have been working with thomas roessler about meeting in brussels when i am there jan 23-35. Not grand meeting for decisions, maybe tech meeting on de-identification. include people who will be in brussels then for dpdp or otherwise.
<aleecia> So Ian was not deemed a technical expert?
peter: this is an informal
auxiliary meeting so does not need 8 weeks notice, but will try
to have a call.
... now lets talk about how i think 17th meeting will go.
... for meeting on 17th, ground rules would be to focus on
descriptive discussions. focus on what de-identification is,
how it works.
... i will consider it out of order to discuss what w3c
standard should include
... this is intended to be technical clearing of brush around
technical issues.
mattias: quick question. so do i understand that prupose is to make tech proposals but not put anything in spec?
<fielding> aleecia, apparently neither am I
<Joanne> is this meeting to work through different technical use cases?
peter: even more careful than that. having watched debate, it's not right now to draft tech specs but a step prior to that --getting understanding of common vocabulary/use cases.
<BillScannell> The 17th will be a great trust-building exercise.
<aleecia> Well, I guess Google and Adobe are small players :-) I'm sure this will all work out differently next time.
<ifette> am I the only one who finds the irony of proposing to have the tech meeting in Europe when many of our technical participants (most browser participants, roy, etc) are in the US?
peter: ability of people to talk past each other in this area is great, but there is more agreement than it seems
<npdoty> I think peter's suggestion was not that he found a time that worked with all technical experts, but that there was some minimum that were available, and so it would be useful to have them meet
<Keith> 202.296.1883 is Keith Scarborough with ANA
<ifette> nick, with a small subset not including any of the browsers i'd be surprised if we saved any time
peter: thought would be this is a step towards face to face in mid february. i don't have text or extra pieces in my own mind. when we hvae quality people talking about de-identification we can move toward tech drafting
<schunter> Yes
peter: hope is on feb 11-13 we can try to see how far we can get in mit. responsive mattias?
<ifette> npdoty, it's being referred to as "The Brussles technical meeting"
<fielding> at 6am ;-)
peter: shifting to list of some
topics. Talking to Khalid about possible topics.
... what are incentives to do de-idnetification now: privacy
policy, worrry about breach, etc.
<npdoty> ifette, Peter had suggested that it might also be useful for those attending CPDP to talk about technology in late January in Brussels (in addition to next week in DC)
peter: what are measures of risk
of re-identification
... what are roles of tech safeguards vs administrative
safeguards. privacy act from 70s talks about tech, admin,
physical safegurads
<aleecia> It might be helpful to have a reading list to level-set prior to the focused meeting
peter: hashing. discussion of what anybody means by magic term of persistent identifiers.
<npdoty> +1 on reading list
that is a potential list of things that might occupy us for 3 1/2 hr meeting.
<fielding> and a wiki
<npdoty> if we'd like a wiki for our WG on the home page, I can set that up
<aleecia> Because to fly coast to coast for 3.5 hours, and pay full fare, I'd like to make damn sure it's useful
peter: this work on de-identification arose from meetings with a lot of groups including jeff chester's privacy group
<npdoty> ... in fact, we have that set up for Privacy in general, and could set up some pages there
<jchester2> That's not true, Peter. You asked for a general meeting with US NGOs. That's what the Privacy Coalition meeting in DC was about. You should have done this differently.
<aleecia> + 1 nick
peter: now public discussions that start next thursday. still in remedial state of seeing how to get chat to work.
<efelten> It would also be useful to know who the technical experts are who will be there.
peter: i apologize that i talk better than mulitask and my irc channel went dead.
<aleecia> Request reading list by Saturday
<schunter> thx for the help for me (I guess I forgot all about Zakim over the holidays).
<aleecia> (on bus, so not going to speak)
jmayer: had a question about attendance. I understand that many members of group might be there but can organizations bring in software engineers and tech staff.
<bryan> limited to W3C member organizations, right?
peter: want more phds and fewer jds, so yes. not trade secrets of companies but work through issues that concern companies.
<aleecia> Are press invited or barred?
<justin_> We don't have room for press :)
<bryan> IPR policy would be a concern otherwise - as technical solutions are being discussed
<aleecia> You don't have room for participants
peter: is it limited to w3 member organizations? staff might help but i think it could be someone there on behalf of an organization
<jchester2> It needs a larger venue that CDT.
<aleecia> I'm fine with that
peter: press? i would have expected it to be on same basis as other calls.
<justin_> As am I, we were just trying to help!
<npdoty> ACTION: doty to set up wiki page for sharing reading list / technical papers on deidentification [recorded in http://www.w3.org/2013/01/09-dnt-minutes.html#action01]
<trackbot> Created ACTION-347 - Set up wiki page for sharing reading list / technical papers on deidentification [on Nick Doty - due 2013-01-16].
<aleecia> Just wanted clarity (fine with no press, that is. Also fine with larger venue)
peter: if count gets to 50 in
next few days will look for another venue
... other questions?
<aleecia> Reading?
Peter: if no other questions or comments, turn this over to Mattias.
<aleecia> Could someone raise that?
mattias: when you post you should describe goals and initial definitions would be helpful
<aleecia> Thanks, Matthias -- if we could get a list of reading by sat
<jmayer> Would be great to hear who the technical experts in attendance will be. Would be a shame if it's the same cast of policy and law characters. Would enjoy a deep engineering chat.
justin: there was agreement on irc that agenda and reading in advance would help
<aleecia> That would help us all start with uniformly higher clue
peter: a couple of initial docs would be hhs guidance and ico guidance that i mentioned and i will send around links
<aleecia> & nick, thanks for adding them to the wiki
mattias: what do we do with open items on compliance spec. Pause and push again?
<justin_> Can we deal with this on the next call?
<aleecia> Please do not close & recreate, but Peter dropped
<jmayer> Off to Admin Law. Until next week...
mattias. we need to decide soon what to do with open items on compliance spec-can discuss offline
peter: yes, offline
mattias: overdue action items
next on agenda, will ignore compliance items and review
others
... action (343?) on nick. item 102.
npdoty: since i wrote up summary
there has been active thread so i am not sure my summary on
issue 112 matches what group thinks now
... can write up and see if there are changes. can do mine
within week
mattias: close action, open issue bc no agreed on text
npdoty: just push my action out a week and i will have a proposal. not sure if only proposal
<aleecia> (do we have minutes to review?)
<fielding> http://www.w3.org/2011/tracking-protection/track/actions/overdue?sort=owner
<npdoty> action-340?
<trackbot> ACTION-340 -- Joanne Furtsch to update on audits field proposal and any normative requirements as necessary -- due 2012-12-05 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/340
Mattias: ok. next action 340, update on audit fields on joanne furtsch. any news
joanne: iwill need a little bit of...actually thought we closed this bc fine with language in current draft of tpe
mattias: ok.
... next one is 342. on me. ask for objections to new ex
ception model. i will mark this as closed bc will discuss new
model in a min. does not mean we agree just doesn't make sense
to discuss now
... on david action 345.
<npdoty> apologies, I have responding to dsinger on my to-do list
<npdoty> action-345?
<trackbot> ACTION-345 -- David Singer to condense non-norm examples on non-JS third parties and integrate into spec -- due 2012-12-12 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/345
dsinger: i wrote email but did not get feedback. ought to get that before close. will put it up again.
mattias: david resent text once. my suggestion is to put in text and can then fine tune. is non-normative text
dsinger: ok will integrate into text
mattias: action 332 on dwainberg.
<npdoty> action-332?
<trackbot> ACTION-332 -- David Wainberg to review TPE spec to ensure iframes are fine for exception API; if not, propose text changes -- due 2012-12-05 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/332
dwainberg: i did spend time on this but was a while ago. if we could push another week, i will review notes and follow up
mattias: ok so i think this is all the tpe related actions
mattias: revised approach on exeptions. david has integrated into text. browser responsible for getting user preference than puts in browser for storage and may check with user if it wants
<ifette> link?
<ifette> to what david put in?
mattias: so push for later, david said we need addtional functionality and on agenda item 5 we need feedback on what david put in spec
<ifette> can we get a link to the specific changed text?
adrianba: i think i mentioned before but 3 points on which i have feedback. 1. need api to be able to understand whether exception granted....important bc asking owner of site to be responsible for informed consent....
<npdoty> http://www.w3.org/mid/DD4C0887-F30F-42AD-BD75-01AFEEC02968@apple.com
adrianba: they need to know if they must ask or have already asked and been granted exception
* cab someone else take over scribing for a while?
<npdoty> scribenick: npdoty
<susanisrael> adrianba: 2nd point re subdomains
adrian: regarding subdomains, implicit parameter of the current document origin
<susanisrael> *thanks nick
adrianba: as much as I'd like
that we wouldn't have to deal with subdomains, I think we will
have to
... have to deal with subdomains
<susanisrael> npdoty: if you want me to take it back after a while i can scribe again after a few min
adrianba: common out-of-band mechanism would be a cookie, which can be stored across sub-domains
<WileyS> Exceptions persistence is preferred as it is at parity with the persistence of the DNT signal
adrianba: if we don't have that
capability for the exception API, then either sites will have
to use both, or choose between them
... making the exception API work in exactly the same way as
cookies is going to be necessary
<aleecia> Full domain will inadvertently pull in some third parties
<WileyS> Aleecia - do you have examples?
<aleecia> E.g. Analytics.acme.com
adrianba: 3) today we have the ability to provide an array of domain strings
<WileyS> That doesn't exist in the real-world. Do you have a real-world example?
adrianba: when I request an exception, I can say that it's for a certain domain
<aleecia> It does -- apple
adrianba: currently optional, has a huge amount of complexity
<ifette> +1 to adrianba
adrianba: Microsoft, since it's optional, would ignore
<rigo> aleecia, all outreach measuring in Germany is done by ivwbox.journalxyz.de that reports to a common third party. So the third party uses a subdomain of the content provider
<WileyS> Aleecia, are you saying there are locations where apple is being captured as a sub-domain on another 1st party site?
adrianba: when your list changes,
do you have to call it again with the full list? requires the
site to manage complexity
... would prefer to remove it completely
<dsinger> hm, to adrian, it's optional on both sides, so if it's too complex for you on either side, don't use it. can you post your questions to the list?
<aleecia> *.apple.com can cover third parties like google or adobe, who provide analytics
adrianba: otherwise like the direction we're moving in
<aleecia> We've covered this in compliance
<WileyS> Aleecia, so are you saying there is a "google.apple.com" domain in the real-world?
<aleecia> Yes
<WileyS> David Singer - can you comment on Aleecia's claim? Is there a "google.apple.com" domain that your company current supports?
<dsinger> I think anything that is x.apple.com is under a legal SP relationship with apple (I don't actually know for certain)
<Zakim> npdoty, you wanted to note that it's good that there are no UI requirements (but sync/async)
<susanisrael> scribenick: susanisrael
<rigo> WileyS: see my example, this is the way outreach is measured in Germany
<schunter> Questions that are open:
<schunter> - exact set of JS APIs
<WileyS> Aleecia, so if its a service provider, is that okay to you that exceptions to the host domain cover their service providers as well?
<schunter> - Sync vs async APIs
npdoty: i appreciated that when david integrated this he eliminated ui requirements, but making api synchronous demands that user not show interactive ui and don't know why we would foreclose
<schunter> - Handling of subdomains
<WileyS> Rigo, I'm very familar with Germany's approach - but I don't believe that's what is being discussed here.
<aleecia> What I'm saying is, let's not break that as possible, and also not rely on *.foo.com all being foo
<dsinger> the user agent is no longer *required* to confirm; it still may
npdoty: i think this is worse
than old approach since user will no longer be confirning that
user wants to send dnt 0.
... i think it would cast doubt on what dnt 0 means
<WileyS> Aleecia, as a company that would like to actually implement the W3C's version of DNT, I believe *.domain.com is going to be necessary.
<fielding> aleecia, if service providers are considered third parties, there is no incentive for siloing data by first party
*nick should i continue or are you scribing again?
ifette: agree with adrian's 3
points...
... there is a general trend in new apis to try to get away
from asynchronous apis which are more complex to
implement
... if site is confirming, browser should store, no reason to
be asynchronous.
<WileyS> +1 to Ian on site driven exception process (default)
ifette: think we need to keep it as model where site asks on its own real estate and explains why it is asking exception. no tsaying browsers can't confirm but don' thave to. synchronous api makes more sense
<schunter> Opinion/Question: The DNT header is the only normative transmission mechanism for DNT;0 (i.e., the values returned by JS are only indicative)
<rigo> I agree with Nick that a specification should not foreclose the browser confirming the storage of an exception
<npdoty> it wouldn't just be the default though, it would make it impractical to implement a UI that confirmed
<aleecia> I'm not sure we ought ask for reimplementations, Roy, but if you think your customers are up for it, you'd know better than I do. Is google also in? If we add "everything under *.acme must be acme," I'm fine
mattias: i think whatever comes back from javascript just responses on whether script was received. permission management is only about values you may or may not send.
<aleecia> That would simplify a lot of problems
<tlr> I'd expect objections against that from a lot of corners.
mattias: i would go for synchronous too
<aleecia> Then expect me to object to treating *.acme as axiomatically first party
<fielding> aleccia, ownership is irrelevant to privacy controls; I cannot even confirm your assumption regarding adobe and apple
dsinger: i think synchronous ok but harder for UA to confirm what user wants to do.
<aleecia> (cannot understand david)
dsinger: if really anal about it could hold request while confirms with user but doesn't mean api must be aynchronous.
<WileyS> David - are you speaking on a speaker phone? Hard to hear you clearly...
<fielding> s/aleccia/aleecia/
<aleecia> We've discussed this at length, months ago. My info comes from this grou
dsinger: leads to complication for browser
<schunter> David says that user agent can reconfirm with user before actually acting on a JS request from a site. Thus sync API should be OK.
* thanks schunter
<dwainberg> I'm having a very hard time understanding david
dsinger: if too complicated for browser to implement don't do it
hard to understand dsinger--voice is muffled
<aleecia> And I'm not sure why you think ownership is irrelevant... But I suspect we're into a very different discussion there
<schunter> [this comment was for aiming at the explicit/explicit lists: they are optional on both sides]
<aleecia> If *.foo is not always foo, but we treat it as if it is, we're failing
dsinger: could lead to users declining. understand caution about requiring browser confirmation but should permit it
<johnsimpson> Cannot understand David
npdoty: will try to respond to dsinger and repeat some
<aleecia> The only way out of that is to put all liability on the first party, but that's not going to happen.
<ifette> ?!?!?!
npdoty: 1> synchronous version of api ok bc if browser wants to confirm could do after and revoke if necessary
<ifette> so you lie to the site?
<ifette> that's nuts
<WileyS> Aleecia, if a domain holder claims *.domain.com as their own, then I think we're on the same page. A domain holder should not request a full *.domain.com exception if they don't manage all the sub-domains associated with the core domain.
<aleecia> What?
npdoty: preferable
<ifette> "Yes, I have stored your request, but not really"
<schunter> semantics: "Yes, I received your request and I started processing it".
<schunter> "once the processing is completed, I will act on the outcome"
npdoty: other reason for specific
lists is that user might not approve request that would cover
all trackers.
... this was way to get more users to grant exceptions.
... if ua not the one requesting exception then maybe thats not
relevant
<fielding> aleecia, control is the relevant issue -- the domain ownership has no relation to the companies that touch data via that domain. The only thing ownership states is who can map the address to a new destination.
<tlr> fielding has it exactly right
<npdoty> the http cookie spec doesn't demand that the UA store every cookie, does it?
schunter: would like to close this discuss, feeling we may have consensus. no strong objection to synchronous API. Nick should also check whether his semantics covered in spec. May create issue, post resolution then close again.
<dsinger> suggest (a) make sure the spec. does not preclude 'pending' the request while getting confirmation (b) adding the 'does my exception stand' APIs
<ifette> npdoty, if the cookie isn't stored then we see sites using other fingerprinting which is not really a practice we want to encourage
<dan_auerbach> I'm still inclined to prefer async for reasons Nick notes, though as I understand David's point, that strikes me as a reasonable alternative
schunter: explicit/explicit. should have explicit. if browsers find too complext don't need to implement (david's point)
<npdoty> ifette, do you think that's a reason for IETF to update the cookie spec to demand that all cookies be stored, even if the user/UA doesn't want them?
<ifette> I've yet to hear any UA say that they intend to implement the specific-specific
dsinger: i should take action to make sure UA not precluded from confirming request.
<fielding> npdoty, RFC6265 has a MAY ignore the Set-Cookie
<ifette> npdoty frankly yes, i think cookie blocking has gotten us into a far worse state from the stance of transparency and user control
<dsinger> ACTION: dsinger to ensure that the exception APIs do not preclude the UA from pending the set to get user approval [recorded in http://www.w3.org/2013/01/09-dnt-minutes.html#action02]
<trackbot> Created ACTION-348 - Ensure that the exception APIs do not preclude the UA from pending the set to get user approval [on David Singer - due 2013-01-16].
schunter: jscript api --will discuss in a minute. all on item 5 on agenda.
<npdoty> ifette, well, that's a good thing for us to take up with Adam Barth and others, eh?
<ifette> npdoty i have to pick my battles
<dsinger> ACTION: dsinger to propose 'does my exception stand' APIs for both site and web exceptions [recorded in http://www.w3.org/2013/01/09-dnt-minutes.html#action03]
<trackbot> Created ACTION-349 - Propose 'does my exception stand' APIs for both site and web exceptions [on David Singer - due 2013-01-16].
schunter: keep new approach, people can generally live with it.
<aleecia> We have an unsolved
issue that I will object strongly to
.....schunter: item 6--multiple parties on site.
<ifette> aleecia, which?
can roy recap?
<aleecia> (and I just got 2 pages of irc lag. Catching up)
fielding: original qu was how do
we indicate in response protocol that there are multiple 1st
parties on a site or page. Can we? answer was not in current
spec
... proposal was to give an array of links that answers who
first party is.
<npdoty> as I understand it, the new issue would be a correspondence to issue-181, regarding multiple first parties in the Compliance doc
fielding: david asked when this
would occur. think this is us getting rusty over break. many
co-branded promotional sites.
... in these cases more than one real first party receives data
entered on site.
solution fairly simple. haven't heard complaints re needing identifier for site.
scribe: for service provider this is no harder ...
schunter: my impression also is that this was fairly uncontested.
<fielding> http://lists.w3.org/Archives/Public/public-tracking/2012Nov/0004.html
schunter: who likes/dislikes?
npdoty: does this replace policy representation? or have both first party and policy and have them mean different things?
fielding: latter. Like creative commons. 1st party link would simply identify first party
<schunter> Basically this untangles policy and first party (that used to be intermingled9.
<schunter> ).
npdoty: thanks, understand now.
<npdoty> right, I now see why we want to untangle those two.
schunter: other feedback? no? so
suggest roy update spec with issue 190 next to text in spec
then i will ask if there are objections, ok?
... if no objections we will close issue 190
<npdoty> ACTION: fielding to update tpe regarding multiple first parties, per proposal in action-328 [recorded in http://www.w3.org/2013/01/09-dnt-minutes.html#action04]
<trackbot> Created ACTION-350 - Update tpe regarding multiple first parties, per proposal in action-328 [on Roy Fielding - due 2013-01-16].
schunter: closes item no 6 on
agenda. No 7 is update to jscript API. couple of changes, first
to move dnt property to window from navigator
... no one objected. 2nd point from nick was to remove "DNT
status?" since it was redundant
npdoty: could call on navigator to see if will get dnt for site. now jscript should know if it has exception now without asking
<npdoty> that is, it should know by checking the window.doNotTrack property what the value is for my iframe
dsinger: to summarize, 2 current
APIs. one asks what is user preference. Other: what header
would i get?
... different questions. we may not need to answer both.
... ok to discuss both
<npdoty> right, I was suggesting that we don't need to be able to ask about the general preference, which I'm not sure will be a consistent concept
schunter: don't have notion of general preference. have header and that is preference. don't care how finegrained preference management.
<npdoty> I thought fielding thought was that we did have a general preference
dsinger: do we delete old API and just keep one that just asks what header would i get?
fielding: i don't know if necessary but other API i don't understand
dsinger: let's take offline, thought it was fully fleshed out
fielding: not in the draft
... have APIs from amsterdam been reflected in spec?
dsinger: 6.6. that's the one script should be using
fielding: possible it's not relevant any more i have not reviewed
<npdoty> dsinger, I thought the proposal was to move doNotTrack from navigator to window and drop requestDNTStatus?
schunter: simpler=better, and no one pushing to keep it
npdoty: is proposal to remove request dnt status?
<npdoty> fine with me
schunter: yes. will have to debug anyway, and better done in implementation than on paper
dsinger: not request dnt status we want to drop....navigator do not track (prompted by fielding
<npdoty> is there a difference between window.doNotTrack and navigator.requestDNTStatus() ?
schunter: move jscript dnt status to window, remove navigator dnt
<fielding> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#js-dom
schunter: nick and david can you work on proposal and just do it?
<npdoty> ACTION: singer to make updates to window/navigator version of doNotTrack (with Nick) [recorded in http://www.w3.org/2013/01/09-dnt-minutes.html#action05]
<trackbot> Created ACTION-351 - Make updates to window/navigator version of doNotTrack (with Nick) [on David Singer - due 2013-01-16].
schunter: second half of item 7 is while writing text david found two quesitons not answered by current api text. elaborate?
dsinger: api may want to respond to response re: user preference/exception grant or refusal
<fielding> http://lists.w3.org/Archives/Public/public-tracking/2013Jan/0026.html
dsinger: not possible generally to find out does my exception still stand. think this is uncontroversial
<WileyS> David - what is your proposal to answer those questions?
<WileyS> +q
schunter: suggest david update spec to answer those 2 questions
<npdoty> I'm not sure I see the value in a separate API to answer those questions (separate from whether I have a DNT:0)
shane wiley: david, how were you expecting to answer those questions, which i think are valid
dsinger: want to write api that answers with simple yes/no
<schunter> setter + getter
dsinger: confirm webwide exception, confirm site exception.....
<fielding> I think it would be best if we get the current state (as believed by David and Nick and whoever else has proposals for the API) in the draft and then ask for a review of editors draft
schunter: david and/or nick can
you update to include this change?
... then we can debug
<npdoty> ACTION: singer to write a confirm-exception-still-exists api [recorded in http://www.w3.org/2013/01/09-dnt-minutes.html#action06]
<trackbot> Created ACTION-352 - Write a confirm-exception-still-exists api [on David Singer - due 2013-01-16].
<dsinger> ACTION: dsinger to design the 'confirm exceptions' APIs [recorded in http://www.w3.org/2013/01/09-dnt-minutes.html#action07]
<trackbot> Created ACTION-353 - Design the 'confirm exceptions' APIs [on David Singer - due 2013-01-16].
<npdoty> close action-352
<trackbot> Closed ACTION-352 Write a confirm-exception-still-exists api.
<npdoty> action-352: duplicate, see action-353
<trackbot> Notes added to ACTION-352 Write a confirm-exception-still-exists api.
<fielding> Note that first-party array will change this text.
schunter: would like to spend 4 min max on item 8. had many discussions on service providers, discussed that sp often not visible. does david's text make sense?
schunter: roy would you update to include first party array
<npdoty> agree that we need that update
schunter: if you like direction, just account for first party array, we can take up updated text
fielding: don't necessarily like direction, but can do it
<WileyS> Makes sense - will be important that there be a single first party array that all entries in the array can reference (even if across domain origin boundaries)
<npdoty> ACTION: fielding to update Service Providers proposal to incorporate first-party array [recorded in http://www.w3.org/2013/01/09-dnt-minutes.html#action08]
<trackbot> Created ACTION-354 - Update Service Providers proposal to incorporate first-party array [on Roy Fielding - due 2013-01-16].
<npdoty> issue-112?
<trackbot> ISSUE-112 -- How are sub-domains handled for site-specific exceptions? -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/112
schunter: what are next steps on
subdomains (don't want to take up agenda items 9/10
... opinions on subdomains?
<aleecia> Thank you, Shane
wileys: active discussion on list/irc. subdomains must be supported in wildcard and other(?) context
<aleecia> (trying to keep up here through lag)
dsinger: aware there was side conversation in irc today but did not follow
wileys: will work with david
<WileyS> Sounds good
schunter: suggest david makes proposal, sends to shane and aleecia see what comes back, ok?
<aleecia> Happy to work with Shane & david
<fielding> http://lists.w3.org/Archives/Public/public-tracking/2013Jan/0007.html
dsinger: posted jan 7
schunter: repost pls?
npdoty: i thought there was not agreement and people did not want to use cookie model
<dsinger> see http://lists.w3.org/Archives/Public/public-tracking/2013Jan/0007.html
<WileyS> Nick - what do you mean by "the cookie model"? That sub-domains be supported in exception recordings?
schunter: i think opinion has changed. adrian pointed out people feel they must use cookie model though they don't like it
npdoty: will take offline. will take my action on 112 to write up model not like cookies.
<tlr> I suggest to pick either cookie model or same-origin model. Most importantly, don't add another model.
<npdoty> WileyS, sorry, "cookie model" is too brief
<tlr> Among the two, I'd recommend against the cookie model. But that's just me.
<dsinger> the cookie model has the ugly problem of public suffixes
schunter: thanks, we did more than i expected. let's keep this pace. peter and i will synch and post agenda, happy new year.
<npdoty> I thought there was support for the document origin model, which wouldn't automatically include all subdomains
<aleecia> Nick, I think so
<tlr> dsinger, I *hope* that's where we end up...
<tlr> just from a technical sanity perspective :)
<WileyS> Nick - I'm open in either direction. If origin model, then wildcards will need to be supported.
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/browse/browser/ FAILED: s/aleccia/aleecia/ Found Scribe: susanisrael Inferring ScribeNick: susanisrael Found ScribeNick: npdoty Found ScribeNick: susanisrael ScribeNicks: susanisrael, npdoty WARNING: No "Present: ... " found! Possibly Present: AdamTurkel AnnaLong BillScannell BrendanIAB Brooks Bryan_Sullivan CDT Chapell ChrisPedigo_OPA Chris_IAB Chris_Pedigo Craig_Spiezle Cyril_Concolato David Google IAB IPcaller JC Jonathan_Mayer Keith KeithScarborough Lia Lmastria_DAA Mattias Microsoft P54 Peder_Magee Rigo Ted_Leung aaaa aabb aacc aadd aaee aaff aagg aahh aaii aajj aakk aall aamm aann aaoo aapp aaqq aarr aass aatt aauu aavv aaww aaxx aayy aazz action-352 adrian adrianba aleecia aleecia_ bbaa bbbb bbcc being bryan dan_auerbach disconnected dsinger dwainberg eberkower efelten efelten_ fielding hefferjr hober ifette inserted is jchester2 jeffwilson jmayer joanne johnsimpson justin justin_ kj mecallahan moneill2 npdoty pedermagee peter peter-4As peterswire richardweaver rvaneijk samsilberman schunter scribenick semantics susanisrael tedleung tlr trackbot vinay vincent wileys yianni You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Regrets: rvaneijk Got date from IRC log name: 09 Jan 2013 Guessing minutes URL: http://www.w3.org/2013/01/09-dnt-minutes.html People with action items: doty dsinger fielding singer[End of scribe.perl diagnostic output]