Allow limiting information in URLs exposed in NEL

[polcak]

This issue was originally raised in #136 and I was asked to open a separate issue.

The original NEL paper claims in Section 3.4 that "NEL reports include basic information about the request: URL (with user credentials and fragment identifiers removed)" and "NEL reports also do not include details about HTTP requests that are immaterial to diagnosing reachability problems. For example, user agents exclude cookies and URL parameters from reports". However, the current draft does not exclude URL parameters so the credentials may be a part of the reported URL. During the work on our SECRYPT 2023 paper we tested current Chrome/Chromium and it reported full URLs.

Moreover, the original NEL paper states: "A NEL report does include the full path that a request was issued for, not just the hostname to
which the request was issued. We have not found much use for this information so far, but it may prove useful to an operator whose service configuration varies across different path names under the same origin."

Additionally, there might be other reasons for services not wanting to share full URLs with NEL collectors like law requirements (see the SECRYPT 2023 paper), trade secrets, data minimisation principles.

We argue that the NEL standard should allow to fine tune the URL reported in NEL. For example, we suggest to include at least the following three options:

• The default policy reports only the domain. We propose this as the default due to the minimisation principle. The most deployment would use such option and if they desire, they can opt for more information in the reported URLs.
• Report the path but omit URL parameters (and fragments).
• Report full URLs as is in the current proposal.

[clelland]

Allowing the site owner to configure URL reporting seems reasonable; we should discuss the threat model to ensure that it actually addresses the issue.

I'll see about getting some time at TPAC to discuss this with the group.

[clelland]

Discussed at TPAC, and this seems like a really good idea that requires some syntax bikeshedding. Participants expressed that the path is very useful for debugging issues, as different paths on large sites are usually the responsibility of different teams.

[valenting]

I just want to note that the fragment should never be reported. It's never actually sent over the wire, so it should have no impact on whether the request errors out our not.