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

On Tue, Jan 13, 2015 at 11:26 AM, Aaron Heady (BING AVAILABILITY) <
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/