W3C

- DRAFT -

Tracking Protection Working Group Teleconference

03 Sep 2014

See also: IRC log

Attendees

Present
Fielding, +1.408.260.aaaa, sidstamm, Jack_Hobaugh, npdoty, RichardWeaver, [FTC], walter, rvaneijk, hefferjr, Carl_Cargill, Jeff, WileyS, dsinger, ChrisPedigoOPA, justin, +1.917.934.aabb, vinay, kulick, vincent, adrianba, moneill2
Regrets
schunter
Chair
SV_MEETING_CHAIR
Scribe
npdoty

Contents


<trackbot> Date: 03 September 2014

<sidstamm> Zakim aaaa is me

<rvaneijk> Nick, I am not identified yet, calling through skype

volunteer to scribe?

<Richard_comScore> Sorry - I can't

<walter> npdoty: I'm on Skype

<walter> npdoty: that usually isn't good enough to be scribing

<scribe> scribenick: npdoty

justin: Roy will walk us through a series of Last Call comments so far

<justin> https://www.w3.org/2011/tracking-protection/track/products/6

justin: divided into issues, between David and Roy
... Roy had at my urging spent some time at Compliance, but now want to spend more time on TPE Last Call comments
... could go to Candidate Recommendation separately
... in particularly, seeing some implementations, like EFF Privacy Badger and Disconnect.me extension
... had heard from advertising industry about their own definitions of Do Not Track
... interest in experimenting with their own, good idea to prioritize TPE Last Call comments
... Roy has sent his initial responses to maybe half of the Last Call comments so far
... let's talk them over on the call, if no disagreements, send an email to the list with an announcement about any objections to Roy's or David's responses

<fielding> Basically, an email response with a link to the issue tracker which explains the WG decision regarding their comment.

npdoty: WG just needs to respond (email is fine) to the commenter, and hopefully that resolves the commenter's issue

<dsinger> apologizes for his lateness but has been studying the comments and will have a proposal for some/most/all of them soon

fielding: a reply from the WG rather than a reply from me

justin: walk through rationales for each issue, and then people can raise feedback on the call as necessary

fielding: +1

TPE Last Call comments

<fielding> https://www.w3.org/2011/tracking-protection/track/issues/244

fielding: comment from Article 29 working party about not overriding regulation
... obviously, this standard can't overturn regulatory language or regulation
... understandable, but not the kind of thing we put in standards

npdoty: we have a relevant section in Compliance, would that be sufficient to address the comment?

fielding: no harm in it in TCS

rvaneijk: doesn't matter whether clarifying text ends up in TPE or TCS, but want to avoid view of a data controller that ePrivacy Directive or other requirements are satisfied
... could be confusion about how a data controller should respond technically
... if it's a different issue on the TCS, maybe we should raise a separate issue and link it

justin: also a FAQ sort of page we'd talked about, dsinger has done a lot of work, that might be the logical place for it to reside

<sidstamm> is the ask for an advisory note? "By the way, this doesn't mean you satisfy any laws"? I can see how it would be helpful to implementors, but I'm not convinced anyone would rely only on TPE to satisfy any regulations (or any spec implementation for that)

<sidstamm> but +1 to adding this to a FAQ

justin: as with self-regulatory schemes

<sidstamm> don't think it should be in TPE

<dsinger> given that TPE is a protocol, it

<fielding> https://www.w3.org/2011/tracking-protection/track/issues/245

<dsinger> is hardly likely to conform to laws. TCS (if anywhere) is the right place

npd: +1 to adding explanation to FAQ

<sidstamm> exactly dsinger

<rvaneijk> prefer adding to TCS instead of FAQ.

fielding: true (about not discriminating), but we don't define a user interface
... if it were, we should reference the W3C's guidelines on user interface/acessibility (WCAG)
... don't know of a place in the TPE where that reference/addition would be appropriate

<justin> rvaneijk, Yes, since there is already language in TCS, could easily be revised to expand a bit.

justin: is this the same concern about not being excused from local law requirements?

rvaneijk: consultation was done when status of TCS was uncertain, answer written in that context

<sidstamm> it's up to the user agent to determine how to best interact with users given their environment's constraints, right? Accessibility is something software makers must take on no matter the protocol behind it (TPE)

rvaneijk: that some users may need special assistance is a generic comment

npd: I would think section 4 of TPE is more relevant than 7.7

rvaneijk: I could see TCS being appropriate, but this is a normative suggestion, not just an explanatory comment

justin: sounds like people are okay with revisiting section 7 of TCS regarding legal requirements

<fielding> https://www.w3.org/2011/tracking-protection/track/issues/246

fielding: comment from Mike, actually discussed before Last Call
... response we heard from IE team that this was already implemented/shipped

<rvaneijk> npdoty, we could redraft to make it non-normative. The standard would gain a lot in my view if users with special needs get accommodated.

fielding: don't have a particular concern about the terminology, but already have implementation

<dsinger> this is a long-standing frustration; I guess we should check, apart from the implementation issue, WOULD the WG like to change the names?

fielding: already heard concerns from Adrian beforehand

<dsinger> ok, so we can respond that we agree but we feel it’s too late to change

npdoty: +1

adrianba: might have a slight preference for "permission" terminology, but only slight, and had been using this name and this implementation for some time

<WileyS> I'm in the same spot - I like "permission" over "exception" but its been SOOOO long it would difficult to make the change now.

justin: sounds like momentum is similar, that we shouldn't change it at this point, even if there's a slight difference in preference over terminology

moneill2: stick with what we've got now

issue-247?

<trackbot> issue-247 -- update HTTP draft references (httpbis) -- pending review

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

fielding: needed to update the HTTP draft references in the spec, and yes, I did that

issue-248?

<trackbot> issue-248 -- using Unicode notation in ABNF -- pending review

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

fielding: had been using %31 and %30 in quotes, but really don't think it's necessary
... also don't need additional Unicode representation of it, no ambiguity

justin: not sure of the details, but sounds like an editorial decision

issue-249?

<trackbot> issue-249 -- DNT-extension excludes should spell out control, space, double quote (or use Unicode code points) -- pending review

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

<dsinger> see http://tools.ietf.org/html/rfc5234#appendix-B.1

fielding: similarly, a comment about where we exclude control characters, but using ABNF

npdoty: do we have a reference to the ABNF / RFC?

fielding: yes.

issue-250?

<trackbot> issue-250 -- Non-ASCII not permitted in extensions -- pending review

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

<dsinger> yes http://www.w3.org/TR/tracking-dnt/#bib-ABNF

fielding: limited to ASCII, intentionally to discourage human-readable text
... comment from Addison was about using Unicode, assuming that it's human readable text

justin: why don't we want human-readable?

fielding: extension syntax, things that would be added to every outgoing HTTP request in the header
... not sure we need the extension syntax at all
... the design intention was to use a minimal number of characters
... simple characters, rather than names

<dsinger> I think we’re fine where we are…and I think we should say what the requirements are on extensions or explicitly forbid them, and that’s a change

<dsinger> we could mark as ‘at risk’ as unused/unimplemented

fielding: should decide whether we want this at all, discussed at very first meeting in cambridge

npd: +1 for "at risk"

fielding: currently we don't really mention the extensions at all

<sidstamm> if nobody implements extensions during CR, we drop it from the spec

<fielding> issue-251?

<trackbot> issue-251 -- Section title for 6.2.7 doesn't match earlier description -- pending review

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

npdoty: "at risk" is a decision that we make about features that might or might not be implemented, that they would be dropped if the CR / Call for Implementations phase doesn't see any implementations of the feature

justin: all okay with "at risk"?

fielding: sure.
... "Potential Consent" title versus the description "tracking only if consented"
... I don't think they need to be the same. seems editorial

<fielding> https://www.w3.org/2011/tracking-protection/track/issues/252

fielding: status id to reference a resource-specific tracking status resource
... need a small number of characters to fit inside a URL
... comment was about internationalization, to include an IRI path in that value
... not a name connection, besides an origin server root

<justin> issue-253?

<trackbot> issue-253 -- Section 6.4.2: restriction to "URI-safe characters" -- pending review

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

npdoty: would that prevent a server administrator only using non-ascii character set paths from redirecting to them?

fielding: only applies to after /.well-known/dnt; so not to other pages on the site

issue-259?

<trackbot> issue-259 -- require public-facing statement of server response policy -- pending review

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

fielding: comment from EFF was about privacy-policy explanations of the tracking status values in response
... but actually the tracking status values are defined terms in this specification already

<ChrisPedigoOPA> +q

justin: thought might be about a mischievous server that would use "C" inappropriately, say

ChrisPedigoOPA: California law requires sites to explain whether or how they respond to Do Not Track
... we generally want to make privacy policies shorter

justin: regarding California law, many sites seem to be linking/referring to self-regulatory page explanations
... doesn't seem that this would conflict with the Californian law, might actually be along the same lines

fielding: if the FTC needs such a regulatory hook, they could add it themselves

<rvaneijk> http://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=201320140AB370

justin: could perhaps make the argument that an omission is unfair or deceptive
... will follow up with Lee to see if he has comments on the list

npd: I'm not sure we have an entirely accurate reading of the FTC/enforcement hook issue

<dsinger> issue-262?

<trackbot> issue-262 -- guidance regarding server responses and timing -- pending review

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

npd: given the results with nonsense P3P CPs

fielding: timing regarding ad bidding process

<dsinger> oh, is there a deadlock issue here?

fielding: only at the time of the winning bid does the bidding server know which server will be connected
... UAs are not required to check tracking status resource, DNT signal will just be sent to any resource that's loaded
... so the UA can actively verify before making the request, if it's configured to do so, which would be uncommon
... but covered by existing language in the spec already

rvaneijk: if the bidding server operates differently from the site that wins the bid

fielding: there may be regulatory regimes that apply to different sites that make the bid, but doesn't change how the spec applies

<fielding> What I included in my response was: " Note that the tracking status

<fielding> of the bid winner is separate from the tracking status of the bidding

<fielding> process if they are separate HTTP requests; if the market acts as a

<fielding> gateway and provides the bid winning response itself, then the market

<fielding> is responsible for the tracking status of itself and all downstream

<fielding> recipients (those it shared the request data with)."

rvaneijk: not sure how it plays out down the advertising bidding chain
... conveyance of the restrictions of DNT:1

<WileyS> I want to jump in on this one but have run out of time. Could we touch on this one again?

fielding: if the bidding server is the only server that responds to the request, then it needs to respond for itself and all the downstream servers; if it redirects, then each server can respond individually

dsinger: if a UA checks tracking status resource for new sites before it loads them, but the ad server doesn't respond to the tracking status resource until it knows the winner of the ad bidding process

justin: how would ad bidding server respond if it didn't know at the time?

fielding: server can respond that it doesn't respect DNT, or that it does respect DNT with the TCS compliance, but up to the server to confirm that that status is correct

npd: sounds like a server that handles down-stream server-to-server communication, would need to respond with the union of possible statuses

justin: will follow up in email
... timing for discussing the next batch of responses?

<dsinger> I can discuss 243, 255, 256 next week

dsinger: can discuss exceptions API issues for next week

<justin> next week ok

rvaneijk: any rough answers on TCS going to Last Call and scheduling?

justin: some open issues in the document, but not many left. close out the few remaining issues in the next month or two
... because there's been concern about implementation, take it to the group about proceeding to Last Call or not

<rvaneijk> ok, tnx

<dsinger> issue-243?

<trackbot> issue-243 -- origin/browsing context terminology -- raised

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

dsinger: I thought I had aligned, but experts assure me that I didn't sufficiently align with existing definitions
... intend for it to be editorial, just making the correct references

<dsinger> issue-255?

<trackbot> issue-255 -- comments on doNotTrack property -- raised

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

dsinger: would welcome any help with that from experts on origin

<sidstamm> dsinger, anne vk might be willing to help with the browsing context stuff (I think he was the origin of the comment for issue 243)

dsinger: on 255, people I've talked to agree about navigator, rather than window
... shouldn't have a mixed enumeration
... should have an unspecified string

npdoty: we discussed window v navigator already, and even though we'd had concerns about window, saw that there were exceptions that might make the value different (and so navigator could be misleading)

<dsinger> OK, on the one hand we have the exceptions; on the other, window is a bad place for new properties, and navigator is automatically exposed in workers

dsinger: concern about polluting the window namespace, and about workers

npd: workers was a new issue to me

fielding: dev will in any case need to check that the value is defined
... null is used here whether the UA hasn't implemented DNT or has implemented DNT but no expressed preference

adrianba: torn about this one. agree that we talked about the issue earlier and that commenters weren't aware of the WG decision
... despite pollution of window, the value may vary by window and navigator value isn't consistent across the browser
... one piece of new information in mail thread was that there other things on navigator that vary by context
... we changed our implementation to match the spec when implemented exceptions

<fielding> issue-255?

<trackbot> issue-255 -- comments on doNotTrack property -- raised

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

<dsinger> issue-256?

<trackbot> issue-256 -- comments on exception APIs (asynchronous/promise/parameter names) -- raised

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

dsinger: comment was about returning a promise
... currently we return nothing
... could be an improvement to let the site know that the UA finally got an answer from the user

adrianba: core of the feedback is that this should be asynchronous API, and to do that you should use a promise
... when we changed the design of the exceptions, expect UI to be rare and didn't want to deal with event callbacks
... user might also approve and later (even immediately) revoke it
... don't preclude the use of the UI, but don't expect it to be typically implemented

npd: was going to make the same explanation that Adrian just did

<fielding> http://lists.w3.org/Archives/Public/public-tracking-comments/2014Apr/0001.html

dsinger: concerned about phishing uses of the explanation string

<moneill2> +q

npdoty: discussed the misleading/phishing issue previously, but this typically won't be used in interactive UIs, and phishing would be much less of a concern with retrospective review of a list of exceptions, for example

moneill2: would you need some way to explain to the user what the site/operator actually is?

adrianba: figure out the right balance between utility of having a string that can be recorded in the exceptions database for future auditing
... against the risk of a misleading string that could cause confusion to the user and the possible effects
... could add informative guidance that calls out the potential risk, not present the text to the user in a way that could lead to that confusion

+1

<dsinger> sure, don’t present the text as definitive but “the site claims that…”

<sidstamm> we've seen attacks in the browser's download pop-ups... some bad guys name files things like "INSTALL THIS ANTIVIRUS OR YOU WILL LOSE YOUR MONEY.exe"

npd: dsinger, or don't present the text for interactive decision-making, but only informative after-the-fact?

justin: timing?

fielding: some activity in HTTP, but still expect another batch ready by next week

justin: thank you all, especially to roy and david. keep pushing through these and have a similar call next week
... will send out an email about TCS issues
... thanks for staying a little late

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-09-03 17:22:13 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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
Inferring Scribes: npdoty
Default Present: Fielding, +1.408.260.aaaa, sidstamm, Jack_Hobaugh, npdoty, RichardWeaver, [FTC], walter, rvaneijk, hefferjr, Carl_Cargill, Jeff, WileyS, dsinger, ChrisPedigoOPA, justin, +1.917.934.aabb, vinay, kulick, vincent, adrianba, moneill2
Present: Fielding +1.408.260.aaaa sidstamm Jack_Hobaugh npdoty RichardWeaver [FTC] walter rvaneijk hefferjr Carl_Cargill Jeff WileyS dsinger ChrisPedigoOPA justin +1.917.934.aabb vinay kulick vincent adrianba moneill2
Regrets: schunter

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

Found Date: 03 Sep 2014
Guessing minutes URL: http://www.w3.org/2014/09/03-dnt-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]