<trackbot> Date: 24 April 2014

<christine> 1. Welcome and introductions 2. Navigation Error Logging [1] 3. Web NFC API [2] (see ND's email at [3]) 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

<christine> http://www.w3.org/TR/2014/WD-navigation-error-logging-20140211/

Navigation Error Logging

<christine> +q

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

<christine> +q

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: If someone visits my webpage on the uni domain, use some javascript, I could have repots backs from anyone who visits a university webpage?

<christine> Nick: I could watch someone browsing pages

<christine> Nick: Is there a use case for a cofigurable URL?

<christine> Nick: /wellknown?

this could be mitigated if there were a single well-known reporting URL at the domain level, rather than configurable by JavaScript

<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?

rfc 5785

<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 type
... certainly something we would want to help with

tobint: errors just on the initial document, or also on subresources? like a CORS error in loading/not loading a javascript file

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 back
... 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 it's active;
... 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

NFC

http://www.w3.org/TR/2014/WD-nfc-20140114/

<christine> +q

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

Geolocation

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!

Next meetings

<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?

<christine> +q

<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 comments]
... 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: