See also: IRC log
<trackbot> Date: 24 September 2014
<justin> Let's give everyone 1-2 more minutes, then we'll go through the Last Call changes.
<npdoty> scribenick: npdoty
justin: want to talk about
changes to TPE in the last couple weeks
... few remaining issues in compliance
fielding: make DOM API attribute
nullable in WebIDL description ("?")
... only change to the document; editorial.
<fielding> issue-240?
<trackbot> issue-240 -- Do we need to define context? -- closed
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/240
<fielding> issue-254?
<trackbot> issue-254 -- public access devices in intermediaries text -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/254
this list of pending review may be helpful: https://www.w3.org/2011/tracking-protection/track/products/6
fielding: comment was about
adding requirements to an example
... existing example was about a kiosk environment that might
have defaults outside of our control. but if a user brings in
their own device, we don't expect the network to change their
preferences
... suggestion was a clarification for a kiosk environment
where users log in and establish a profile, including a DNT
setting
<eberkower> it could be Ronan Heffernan from Nielsen. He isn't on IRC so he can't respond
<Zakim> dsinger, you wanted to ask about policies for sites
dsinger: do we need a section to
talk about sites that have a policy?
... like a first-party site that wants all visitors to have DNT
set for their visitors
fielding: can set a header field where it's under the user's control. don't need to specify ever possible way.
<dsinger> “An HTTP intermediary must not add, delete, or modify a tracking preference expression in a request forwarded through that intermediary unless the intermediary has been specifically installed or configured to do so by the user making the request. For example, an Internet Service Provider must not inject DNT:1 on behalf of all users who have not expressed a preference.”
fielding: there was a debate about institutional setting, but conclusion was that it wasn't a user preference.
dsinger: rather, I mean for the site being visited. should a site be able to say that there's a policy of only visiting with DNT?
fielding: no great objection, but probably raises more problems than it solves.
dsinger: probably right, just raising it as a possibility.
<fielding> issuse-258?
issue-258?
<trackbot> issue-258 -- automatic expiration of a tracking preference -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/258
justin: automatic expiration of the DNT signal or exceptions to it
fielding: TPE would specify a
mechanism, requiring automatic expiration
... 1) we don't really require how it's set in the first place.
2) always under control of the user agent, so the user can
control it, demand it of their user agent rather than have it
be set by a server
justin: or the site itself could self-impose an expiration based on the user's own preferences
fielding: right, it just wouldn't be visible to the protocol
<rvaneijk> I am fine with a seperate issue.
fielding: rob had suggested a
separate parameter when asking for an exception, which could be
raised as a separate issue
... could be useful if where the server is located requires a
specific time (via a law, say)
... but normally we would implement that with an expiring
cookie
<moneill2> +q
fielding: have a user-granted exception and a cookie telling you how long to maintain that preference
<Zakim> dsinger, you wanted to ask why would a site need automatic expiration?
dsinger: not hard to add an
optional parameter. but not clear why the site would need to
detail the expiration
... user agents might handle and might want to handle
expiration
fielding: could be a regulatory requirement
<rvaneijk> the requirement is not set in stone, it is rather: no longer than necessary
justin: article 29 or similar could say that exceptions are only valid for a certain time
dsinger: could just add a cookie as well
moneill2: don't want it to be a
cookie because it would also need to be communicated to all
your third parties
... API is controllable by the JavaScript on the server
... makes sense to store in the database a duration
... wouldn't cause a lot of trouble
<moneill2> +q
npdoty: have a
cancel/removeException method for this purpose. gives
flexibility about when you cancel
... useful for when sites need to cancel, whether after a
duration or for any other reason
<fielding> I suggest we make it a new issue and then request specific proposal for changes to spec.
moneill2: what about web-wide exception?
npdoty: have removeWebWideTrackingException as well
<rvaneijk> give users the opportunity to reconsider their choice and change settings after the initial decision and at any time; let the user examine the (automated) choices that have been made with regards to Web Tracking in an easy way; and remind the user that choices regarding the (automated) settings for Web Tracking can be revoked at any time and make sure that a revision of any such choices is technically possible in an easy way that does not put any undue bur[CUT]
<rvaneijk> individual
npdoty: can accomplish with existing functionality, would increase testing costs
<rvaneijk> <copy past from the berlin group paper web tracking and privacy http://www.datenschutz-berlin.de/attachments/949/675.46.13.pdf
moneill2: but could increase transparency to have that duration in the same place, so that users can review it
<moneill2> ok
justin: seems agreement that expiration is something we might want. unclear whether existing functionality or whether we want something new
<fielding> rvaneijk, I believe those are all controlled by the UA rather than the protocol
<scribe> ACTION: o'neill to propose specific language for expiration in the user-granted exception API parameters [recorded in http://www.w3.org/2014/09/24-dnt-minutes.html#action01]
<trackbot> Created ACTION-458 - Propose specific language for expiration in the user-granted exception api parameters [on Mike O'Neill - due 2014-10-01].
<dsinger> if someone could propose specific changes, that might help
<rvaneijk> @fielding, you may be right, I will discuss with moneill2
fielding: one remaining assigned to me is whether we should describe JSON as ABNF or prose or non-standard formal annotations of JSON -- purely editorial issue but might result in a change
issue-260?
<trackbot> issue-260 -- method for validating DNT signal from user -- raised
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/260
fielding: added more of the comments to issue-260, to better document that issue
<dsinger> on Shane, see <http://lists.w3.org/Archives/Public/public-tracking/2014Feb/0045.html>
justin: related to an older
proposal about signing or otherwise verifying DNT
signals.
... followed up with editors about possible responses (143 and
260 addressed at once)
... reasonable way to move forward?
fielding: yep. regrets for this coming week.
justin: dsinger update?
dsinger: converging, but waiting
for feedback from Microsoft, who I know have implemented the
exceptions
... want to get their feedback; they have concrete
experience
... 4 or 5 proposed by Anne van K, about exceptions API
changes
justin: anything else?
dsinger: need to double-check that we have all the issues covered
<fielding> https://www.w3.org/2011/tracking-protection/track/products/6
<fielding> PENDING REVIEW means the editor is "done" and awaiting WG decision
npdoty: summary about CR transition process. respond to all Last Call comments, try to get feedback. transition meeting with Director, based on those responses
justin: sent out the Call for
Objections on Audience Measurement
... discussion on the list. please make sure those requirements
end up in the CfO questionnaire
... outstanding CfO on de-identification
... options are language worked out by a lot of us on the
calls, and the safe harbor proposal from Jack
... please give us your feedback on that in the next couple of
days
... one CfO closed, only a couple responses, on link
shorteners
... only comments were opposed to silence, wanted to add
language. so we'll go ahead with adding that language (that
nick had worked out with some)
<scribe> ACTION: doty to add shortened URL language to Compliance [recorded in http://www.w3.org/2014/09/24-dnt-minutes.html#action02]
<trackbot> Created ACTION-459 - Add shortened url language to compliance [on Nick Doty - due 2014-10-01].
<kulick> http://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Tracking_Third_Party_Compliance
justin: dsinger proposal was just changing to refer to "tracking" in the existing requirements
<rvaneijk> npdoty, this is still M1 status, right?
justin: fielding had a proposal
on prohibiting tracking, remove 1st/3rd party distinction
... but that might avoid our past discussions on first/third
party distinction
... fielding had additional proposal on a first-party permitted
use to recognize the distinction
<rvaneijk> justin, npdoty, this is still M1 status, right?
justin: not sure how to narrow down these proposals to consensus now
ChrisPedigoOPA: my concern about proposal 3 is well-known
<justin> rvaneijk, yes, I think so . . . don't think we're quite close enough to firm options.
ChrisPedigoOPA: think proposal 4
from fielding is essentially just re-wording what we've already
agreed to
... can we get a summary of dsinger's proposal?
dsinger: proposed this before in
order to use defined terms
... but tracking as more tunnel-vision proposal from before
ChrisPedigoOPA: think there might be less dispute on this one
<Zakim> npdoty, you wanted to comment on "tracking data"
justin: don't intend to use CfO
<justin> FYI, npdoty's email summarizing the four proposals: http://lists.w3.org/Archives/Public/public-tracking/2014Sep/0016.html
<justin> scribenick: mecallahan
mecallahan to scribe
npdoty: two isues. 1) dont want
to change the structure
... 2) first party permitted use defintion. this does not see
to track "purpose" this recommendation is more of a
"status".
<dsinger> the permitted use would be a ‘referal permitted use’ which would only be available to first parties
inpdoty: it is strange to have this use as a purpose
<dsinger> ‘I am the first party and claim the referal permitted use’
jnpdoty: 3) how would we handle downstream data?
justin: under roy's proposal, a party cannot retain third party data if stored with other third party data. why is that a problem?
npdoty: if a third party collects but does not track, it doesnt seem fair to let the third party collect and share third party data (and allow other third parties to track?)
justin: i thought you couldnt send data downstream? Roy: yes,
npdoty: you have to put a prohibition on downstream in other sections
justin: is there a substantive difference between the two? which framework less confusing to implementers?
<rvaneijk> I need more time to review the two proposals.
fielding: a brief caution. the
statement "this is what we agreed to earlier" is not yet a
group decision.
... not everything is a working group decision.
Justin: i dont care.
... if the group thinks fieliding's version is better, we
should go with that.
<npdoty> I'm not suggesting that the structure of the document is a past WG decision. I was referring to the general prohibition against collecting, retaining, using data collected as a third-party.
justin: i think the major
objections with fielding's proposal (major questions on
obligations on first parties) may have been addressed.
... do folks need more time to consider the options? justin
views the options as the same.
<Zakim> npdoty, you wanted to ask if we are down to two proposals
npdoty: question on which version do people want to go with? if the proposals are 1 and 4 in the wiki, we can also consider Roy's proposal 3
justin: does David singer still support option 2?
<fielding> I can drop option 3 in the interests of time.
<npdoty> yeah, I support "Proposal 1" (an iteration on dsinger's proposal)
<dsinger> …needs to think.
<kulick> we've always left the editor's draft with the options to see the deltas easily if nothing else
<npdoty> (I prefer it over the editor's draft text, I think)
<dsinger> whatever we do has to be harmonious with, and use, our definition of tracking, IMHO
Justin: does anyone support the existing language in editor's draft? if not, presumption going with one of the alternatives. folks should review other optiosn. which one would be more understandable?
<npdoty> kulick, yeah, we can leave the text in the wiki, but still useful to know which proposals we're pursuing
justin: there is agreement on
what we are trying to accomplish, open question on which one is
more understandable/useful?
... not sure what else there is for discussion.
justin; e.g., graduated response in the security language. anything else?
justin: let justin know.
<fielding> npdoty, I am absolutely certain that we did not decide on any general prohibition against collecting data as a third party
justin: anything else to discuss before closing call?
<npdoty> fielding, that's a high level of certainty :)
Justin: next week focus? no Singer and Fielding. maybe a short call, depeding on TCS.
bye.
<npdoty> thanks, mecallahan, for filling in as scribe
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found ScribeNick: npdoty Found ScribeNick: mecallahan Inferring Scribes: npdoty, mecallahan Scribes: npdoty, mecallahan ScribeNicks: npdoty, mecallahan Default Present: npdoty, Fielding, RichardWeaver, [FTC], justin, eberkower, ChrisPedigoOPA, dsinger, moneill2, +1.813.907.aaaa, heffernan?, rvaneijk, MECallahan, Brooks, Jeff, kulick Present: npdoty Fielding RichardWeaver [FTC] justin eberkower ChrisPedigoOPA dsinger moneill2 +1.813.907.aaaa heffernan? rvaneijk MECallahan Brooks Jeff kulick Regrets: cargill sidstamm WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 24 Sep 2014 Guessing minutes URL: http://www.w3.org/2014/09/24-dnt-minutes.html People with action items: doty neill o[End of scribe.perl diagnostic output]