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

Merged and live at: https://w3c.github.io/navigation-error-logging/

Let's take any outstanding (or new) NEL discussions into new threads and/or
GH issues.

ig

On Wed, Jan 21, 2015 at 12:41 PM, Aaron Heady (BING AVAILABILITY) <
aheady@microsoft.com> wrote:

>  No objections from me.
>
>
>
> *From:* Ilya Grigorik [mailto:igrigorik@google.com]
> *Sent:* Wednesday, January 21, 2015 10:46 AM
> *To:* public-web-perf
> *Cc:* Philippe Le Hégaret; Tobin Titus
>
> *Subject:* Re: [navigation-error-logging] new draft proposal
>
>
>
> Any objections to me merging the new draft [1] into the main spec branch?
> If no blockers pop up within the next week I'll hit the merge button. Once
> that's there we can iterate on refining the particular bits of the spec
> (e.g. some of the earlier feedback provided by Aaron).
>
>
>
> On a related note, we're planning to start implementation work of the new
> draft in Chrome.. any/all spec feedback is appreciated!
>
>
>
> ig
>
>
>
> [1] https://cdn.rawgit.com/w3c/navigation-error-logging/new/index.html
>
>
>
> On Thu, Jan 15, 2015 at 11:04 AM, Aaron Heady (BING AVAILABILITY) <
> aheady@microsoft.com> wrote:
>
>  Agree, it’s only the policy delivery origin that prevents this from
> working on HTTP-only sites. I’m trying to reach out to some folks I know
> that host this way and get their feedback.
>
>
>
> *From:* Ilya Grigorik [mailto:igrigorik@google.com]
> *Sent:* Thursday, January 15, 2015 9:41 AM
>
>
> *To:* Aaron Heady (BING AVAILABILITY)
> *Cc:* public-web-perf; Mark Nottingham
> *Subject:* 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/
>
>
>
>
>