See also: IRC log
<trackbot> Date: 24 April 2014
<christine> 1. Welcome and introductions 2. Navigation Error Logging  3. Web NFC API  (see ND's email at ) 4. Re-chartered Geolocation WG and privacy considerations 5. TPAC session? 6. Privacy guidance and process documents 7. AOB
<christine> We will be starting shortly.
<plh> From Web Performance, we have plh, Tobin Titus, Alois Reitbauer, Arvind Jain
<plh> Editor's draft for Navigation Error Logging: https://w3c.github.io/web-performance/specs/NavigationErrorLogging/Overview.html
<scribe> scribenick: npdoty
tara: welcome all new folks
Arvind: chair of the task force on this WG
christine: a fairly general
introduction is useful, as many of the PING folks aren't
subject matter experts
... and talk about any privacy questions that have already come up (existing text on privacy and security)
... and people can jump in with questions
Arvind: what the specification is
trying to do
... providing a way for a Web developer to track any navigation errors their users have experienced in the past going to these pages
... user visits CNN.com, but for some reason can't reach the page, will store the error
... later, the CNN.com developer can query on the client-side for those past errors (and if she wants, send those back to the server)
... making past errors available to a web page on the same origin
... currently a high-level type of error: network connection, dns resolution, http error
... no details within those categories yet, but may want to
Forbes Higman?: no concern with the behavior as you've described it, but what happens with what origin means in the mashup environment?
scribe: how strict is the origin? what flexibility is there in retrieving errors?
Arvind: as a web developer, you have access to navigations made to your origin (hostname-level) in the past
Arvind: server would have already had access to it when you tried to access the server before
forbes: might still have a spoofing-type scenario
Arvind: performance information, don't need to know user configuration
wseltzer: if the user wants to do some client-side transformation of the page (which might cause errors), the user might not want them sent back to the server, like proxy information
<wseltzer> [What would this reveal about a Tor browser user?]
Arvind: for transformation, the navigation would have succeeded anyway, right?
wseltzer: I might not be able to connect, because I explicitly tried to prevent connections for privacy purposes, like not loading scripts as a Tor browser bundle user -- it would be unfortunate if that were undone after I turned off that mode
Arvind: interesting. are there other use cases like that?
wseltzer: thanks for the introduction. how will this interact with Content Security Policy?
Arvind: we haven't talked about
CSP as much; others should feel free to jump in
... CSP takes effect after the page is successfully navigated to
wseltzer: will invite for some follow-up discussion. does this expand attack surfaces?
<tara> Q: does full URL get logged, or just domain?
<christine> Nick: Does the specification reveal the URL that failed to load?
<wseltzer> npdoty: three things; we talked about top-level navigation, you'd know the URL that failed to load?
<christine> (Thanks Wendy)
<christine> Arvind: yes
<christine> Nick: Cases where origin does not match up - possible attack
<christine> Arvind: Our assumption is to follow the standard origin concept
<christine> Nick: I don't have an answer yet, just raising the problem
<christine> Nick: Actively "phone-home" when an error occurs?
<christine> Arvind: Yes. Real-time is possible via the reporting mechanism. Follows the model of the CSP/same mechanism.
<christine> Nick: I could watch someone browsing pages
<christine> Nick: Is there a use case for a cofigurable URL?
<christine> Nick: /wellknown?
<christine> Arvind: can restrict the report URI to the specific report pattern
like under /.well-known
<christine> Arvind: Are there other examples where this has been done?
<christine> Arvind we send out an informal chairs summary - we'll include a link
https://tools.ietf.org/html/rfc5785 is the RFC for well-known
christine: in case of error, do you just learn the page that the error was on or other header information?
arvind: just the page and type of error, not the Referer, for example
[setting a reportUrl also allows you to include a unique number in order to re-identify a user on a future visit]
forbes: is anything revealed about the network configuration of the user agent?
arvind: currently just an enum of high-level types (ssl error, dns error) -- could we additionally include more detail about why the DNS failed, the error code, say
forbes: just wanted to confirm that that wasn't currently included. would be an interesting set of additional discussions
plh: anne reported specifically not giving more detailed error information on exit for privacy/security reasons, but not sure of the detailed reasoning
forbes: the conclusion we came to
was that's an involved discussion for each error type, in case
there was sensitive information in a particular error
... certainly something we would want to help with
arvind: only the root page
[also didn't understand that from the spec, so thanks for clarifying. I'm curious how "root page" is defined]
<plh> from this discussion, I raised two issues so far: https://www.w3.org/2010/webperf/track/products/12
christine: thanks Web Performance
folks for coming and talking
... just raising some questions here, but I think a lot of us would like to think more about it. what would be the best way to communicate going forward?
plh: raised a couple issues in
webperf tracker already, we can discuss in WG and come
... didn't raise one on CSP yet, but maybe after Wendy has more details
christine: Web Perf can discuss internally and come back, and we can think more in parallel and compare notes
<wseltzer> thanks Arvind and web-perf team
<tara> Yes, thanks very much!
rigo: numerous cases where error
reports have been included and the application phones home --
have been privacy/security incidents
... phoning home without user knowledge often causes pushback
... description or best practice on getting permission from the user to phone home with the error
<plh> isn't that issue 15 now: https://www.w3.org/2010/webperf/track/issues/15 ?
rigo: an API that doesn't have a way to ask for permission could create problems in legal areas
plh: similar to wseltzer earlier on giving a user a way to block error reporting; have an issue on that now
rigo: not just a user capability
of blocking, but in EU would have to make people aware that
... might be up to the UA implementer
... should at least give developers a hint that this is an issue
plh: will talk within Web Perf. already have the case where a UA loads a page and then subresources from around the Web
npdoty: just noting that this API exists and might have interesting privacy questions
christine: Hannes, have you been looking at NFC tech?
hannes: more interested in Bluetooth LE as it seems to have more uptake than NFC tags have had -- might be a place to focus our attention
christine: trying to find someone to be a champion
npdoty: could talk to sysapps group about what specifications are being worked on in that area
christine: didn't invite anyone yet, just asking what's the best next step
wseltzer: have just rechartered
the geolocation WG
... chair reached out to ask about working with PING on privacy considerations early on
... inviting the chair and others to a call would be a good way to start
<wseltzer> Geolocation WG Charter
christine: try to set it up for next call
tara: great to have the discussions early on!
<wseltzer> TPAC 2014
tara: we could meet at TPAC in Santa Clara in October
christine: either have a PING-sponsored session
wseltzer: TPAC is the last week of October. plenary day will have a Symposium (about anniversary) and open plenary discussions on Wednesday
<JoeHallCDT> I'm going to be looking at the guidance document in the next few weeks
tara: any urgent comments on documents?
<JoeHallCDT> I have to leave this call immediately though, so maybe Hannes and I can talk with others?
JoeHallCDT, Hannes -- I'm overdue in sending my comments on guidance as well
<JoeHallCDT> sry, g2g
<tara> Thanks, Joe!
christine: [relaying IRC
... add my hope to send some time in near future to review these documents. not forgotten!
... small group to work on it?
tara: any conflicts for Thursdays at the end of May?
<christine> 22 or 29 okay, 29 better
May 29th tentatively our next meeting, let us know of any conflicts
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) Succeeded: s/@@@/Forbes Higman?/ Found ScribeNick: npdoty Inferring Scribes: npdoty Default Present: tara, Wendy, Plh, tobint, christine, +1.408.203.aaaa, Rigo, [IPcaller], Arvind, npdoty, [Microsoft], terri, [CDT], +44.793.550.aabb, +1.650.253.aacc Present: tara Wendy Plh tobint christine +1.408.203.aaaa Rigo [IPcaller] Arvind npdoty [Microsoft] terri [CDT] +44.793.550.aabb +1.650.253.aacc Hannes Forbes Agenda: http://lists.w3.org/Archives/Public/public-privacy/2014AprJun/0005.html Found Date: 24 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/24-privacy-minutes.html People with action items:[End of scribe.perl diagnostic output]