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