NEL registration should be based on origin & restricted to HTTPS

[igrigorik]

Feedback from Chrome security/privacy review:

1. Current policy storage mechanism is insufficient because it's not based on origin concept.
2. NEL qualifies as a powerful feature: persists state for an origin, provides access to sensitive data about users browsing behavior.

To address (1) we need to move to an origin-based registration, which would imply that http and https registrations would be treated separately. That said, to address (2), we also need to scope NEL to https-only -- i.e. registration must happen over https and NEL is only exposed to sites using https, ala Service Worker and other powerful features.

/cc @mikewest @slightlyoff @mnot @mcmanus @annevk

[mcmanus]

I support this as an https only feature. I'm not a big fan of trying to assess the powerfulness of features, but I do believe that all web level additions that don't have compatibility concerns should be restricted to https. And in this case both of those philosophies happily lead us to the same place - https only.

(I'm cool with origins too.)

[annevk]

It's not entirely clear to me what kind of errors would be logged and which would be ignored.

[yoavweiss]

Can we detail the risks of serving NEL over HTTP? What's the attack vector we're trying to protect users from?

[igrigorik]

In terms of risks and attack vectors (courtesy of Ryan Sleevi):

Privacy: NEL gives site operators a number of bits of information about the users' network, both transient state and long-term connection information that they didn't have access to before - e.g. attacker could abuse NEL error reporting to probe users state and network configuration.

Persistence: similar to the Service Worker setup (without HTTPS), this allows a transient HTTP MITM to pivot NEL into a persistent tracker for the user. Unlike SW, there isn't a requirement on policy refresh or the like, which thus allows even more permanence in access. Further, same attacker could customize a reporting URI (per-user), along with generalized fault injection at a later time, to enable high-resolution targeting/identification of users.

In short, we hit at least three categories for privileged contexts: access to sensitive data, persistent identifiers, state for an origin. Hence HTTPS.