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

On Thu, Jan 15, 2015 at 8:50 AM, Aaron Heady (BING AVAILABILITY) <
aheady@microsoft.com> wrote:

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

Ah, great point, didn't consider that.


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

Hmm, so there are two independent bits here: registration and delivery of
reports.

- The registration must happen under the same origin and over HTTPS, but
only requires a single request which can even be done in the background
(e.g. XHR and/or anything similar after page is loaded.. the site itself
does not need to be on HTTPS).
- The delivery of reports must happen over HTTPS but can be routed to any
origin -- i.e. it doesn't have to be, and in fact probably shouldn't be the
same origin since if the user can't access your site.. they shouldn't be
trying to route the reports to same origin! You want to keep these as
independent as possible.

The latter means that you should keep the reporting origins independent and
that they can have their own IP, security policy, etc. The NEL host only
needs to handle a small number of HTTPS registration requests, which
doesn't seem like a high bar?

ig

p.s. thanks for all the great feedback!


>
> *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> 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/
>