RE: [navigation-error-logging] new draft proposal

I think the core issue is going to go back the requirement to relay the telemetry over HTTPS, as the policy enforces during registration. If that is the case, the consensus that HTTPS is required, then most of the other issues are not worth discussing as you can’t enforce HTTPS transmission of the data to a telemetry endpoint if there is .js access to the array of NEL objects.

On the issue of not being able to deliver policy to HTTP-only endpoints, just want it recognized that it is a limitation of the design and will exclude that set of sites. Whether sites should operate like that is a separate conversation, they exist, and this service will not work for them as currently described.

Aaron


From: Ilya Grigorik [mailto:igrigorik@google.com]
Sent: Tuesday, January 13, 2015 2:54 PM
To: Aaron Heady (BING AVAILABILITY)
Cc: public-web-perf; Mark Nottingham
Subject: Re: [navigation-error-logging] new draft proposal



On Tue, Jan 13, 2015 at 11:26 AM, Aaron Heady (BING AVAILABILITY) <aheady@microsoft.com<mailto:aheady@microsoft.com>> wrote:
My points would then be:

1.       Using policy isn’t mutually exclusive of .js access.
Agreed. I'm just not convinced that the JS interface is necessary either, as it delivers a crippled view:
(1) you can't use it to detect and report a huge class of errors (misconfigured networks, blocking, attacks, etc)
(2) it relies on the user successfully loading your site at some point after a navigation error (huge assumption)

Given that you're completely blind to (1) and that you may be completely missing users who fail to meet (2) even for intermittent and/or transient errors, the JS interface is at best crippled, and at its worst.. misleading.

2.       I don’t understand what NEL .js access is risking/exposing such that it can’t exist.
It's yet another vector for exposing more data about the user:
https://cdn.rawgit.com/w3c/navigation-error-logging/new/index.html#sample-navigation-error-report


Which server IP you were routed to, how long ago did the error happen, type of error, referrer, and so on.. This is data that the destination needs to know (and would have known if connection succeeded), but there is no need to expose that to third parties. That, plus the limitations cited above, make a poor case for a JS interface in my books.

3.       The secure channel problem for HTTP-only hosts. ((There are simply cases where having SSL isn’t an option, it’s a cost model thing. HTTP only servers don’t have to be in secure cages to meet industry compliance requirements for doing things like credit card processing. By restricting a host to HTTP-only, you don’t have to worry about what kind of transactions they spin up on your less-secure* network, so it costs less to operate. You can configure clients that require HTTPS, thus higher security infrastructure, onto a different network that meets those requirements. This is one reason why the payment portions of sites are on a different hostname than, let’s say the marketplace portion.))
I understand all of your points, but the fact remains that we're exposing a new mechanism that provides sensitive data about the user+their network that should be protected. The guidance ([1], [2]) is to require HTTPS for such things, and for Chrome we'd only ship such a thing with HTTPS registration+delivery restriction.

That said, I'd love to hear mnot's and others feedback on this.

[1] https://w3ctag.github.io/web-https/

[2] https://w3c.github.io/webappsec/specs/powerfulfeatures/