Data protection and security issues with Network Error Logging

[polcak]

We are doing research on NEL. We have focused on data protection and security issues with Network Error Logging and have an accepted paper for SECRYPT'23. Our conclusion are:

• ePrivacy Directive regulates publicly available services and networks and applies to different technologies, not only cookies. NEL requires storing policies in the browser (W3C work in progress standard, Process policy headers, step 14). Hence, ePrivacy Directive applies. NEL is not strictly necessary: Principle 3 from the orginal NEL paper (users should be able to opt out), majority of servers does not deploy NEL. Hence, we consider that obtaining consent is necessary according to ePrivacy directive. However, the standard does not mandate obtaining consent.
• NEL SECURITY, PRIVACY, AND ETHICAL PRINCIPLES NOT FULFILLED:
  • (Burnett et al., 2020) and (W3C, 2021) do not consider the persistency of NEL policy. Necessary to consider when MitM are temporary able to inject code (during travels, connections through unknown networks).
  • Web Workers allow deploying long-term trackers as well. However, the scope of Service Workers is limited to subpaths. When content creators can inject their content, like blogs or personal web pages on shared server, NEL applies to all pages on the domain (and possibly subdomains) and allows that to track visitors on other parts of the server.
  • Some webextensions like NoScript Security Suite block Service Workers but do not alter NEL. Such users protected from MitM injecting Service Workers but not from those injecting NEL policies.
  • NEL keeps collecting data after a user deploys DNS firewall and signals the behaviour of the DNS firewall.
  • Users access services that they are not aware of (activities of European data protection authorities on online advertisement). NEL deployed in such scenarios does not track requests that users voluntarily make.

W3C should:

1. redesign the standard to give web sites the possibility to seek consent before the browser installs NEL policies.
2. redesign the standard to remove personal data from the reports: (A) allow a possibility not to report full URLs. Given the observations of (Burnett et al., 2020) that could be the default behaviour, (B) allow the possibility to report without revealing IP addresses.
3. Improve the privacy considerations: (A) highlight legal issues, (B) add examples how NEL can leak more data to adversaries compared to other web technologies.
4. instruct browsers to remove NEL policies in case the web server no longer inserts its own policy.
5. ensure that NEL does not report on requests that users do not make voluntarily. For example, NEL could report only on the availability of the domain currently displayed in the URL bar.

Please read the paper for more details. Do not hesitate to contact us for more information.

[yoavweiss]

Thanks for researching NEL’s privacy and for filing this issue. Your paper raises a few questions of legal nature, for which this and the WG in general are not the right forum. We don't have the needed legal expertise in this working group to include legal claims in our specifications, and because each jurisdiction has its own legal requirements, it’s impossible to be comprehensive in specifications that are meant to apply globally. At the same time, if an API somehow prevented sites from complying with their legal obligations, that would be a problem. I don't think that's the case here: a site can request whatever consents it needs before sending the NEL header, in the same way it does so before sending the Set-Cookie header.

At the same time, the paper seems to be raising a couple of valid points:

• The NEL cache needs to be partitioned similar to other browser caches, to avoid leaking state across origins. This is already done in the Chromium implementation, but the spec should definitely reflect that.
• Hijacked responses can persist NEL state in ways that can give them visibility into future traffic on the relevant site.

I’ve raised more specific issues (#138, #139) regarding the above points. Thanks again!!

I'm closing this issue, but let me know if you feel further discussion is required.

[polcak]

Hello @yoavweiss,

Thank you for your input. I agree that this WG in general is not the best forum to discuss legal questions. Nevertheless, I suggest improving privacy considerations with a text like:

"Related research highlighted potential issues with data protection regulations in some jurisdictions. For example, if your law requires to obtain consent before storing information in the end-user terminal device, you need to obtain such consent before signalling the NEL header."

At the same time I would like to highlight issues that are not legal and that you neither disputed nor acknowledged.

(A) NEL can leak more data to other parties compared to other technologies:

I suggest improving privacy considerations with a text like:

"NEL can leak more data to other parties compared to other technologies. For example, a party controlling a path on a web server (for example on some shared hosting site) can deploy a tracker that allows such party to receive information on accessed pages on paths on the same domain (or subdomains), provided that the tracked user first accesses a URL controlled by the adversary.

Another example considers users that modify their browser so that the browser does not execute ECMAScript. Such users are protected from trackers implemented in ECMAScript like Service Workers. However, NEL adds another possibility to workaround such settings.

Yet another example considers a user that deploys a DNS firewall. Suppose that such a user have visited a site that installs a NEL policy before the deployment. As the DNS firewall would block future access to that site by signalling invalid/unreachable IP addresses, the previously installed policy would generate NEL reports on the unreachability.

The limited time frame of the NEL policy (suggested in #139) lowers the impact of such threats as the policy is valid for a limited time."

(This suggestion is possibly more suited in #139. Feel free to move the suggestion there or reword the text if you think that is more appropriate.)

(B) Browsers should remove NEL policies in case the web server no longer inserts its own policy.

Such instruction would further mitigate the risk in the first scenario in point (A) - the shared hosting. It would remove the NEL policy immediately when the browser visits a path that is not controlled by the adversary. Hence, such solution is better than proposed #139 that signals the accessed URLs for a fixed time.

(C) Ensure that NEL does not report on requests that users do not make voluntarily.

I suggest improving privacy considerations with a text like:

"Web pages often contain content from multiple domains. As the NEL security, privacy, and ethical principles require to report on HTTP transfers that were willingly started by the users, browsers should consider limiting the parties that are able to insert NEL policies. For example, NEL could report only on the availability of the domain currently displayed in the URL bar."

(D) To limit the information exposed in NEL, I suggest to redesign the standard to allow web sites (A) not to report full URLs. Given the observations of (Burnett et al., 2020) that could be the default behaviour, (B) allow the possibility to report without revealing IP addresses.

Such suggestion would improve the privacy of the users in general, especially, if the web site operators do not need such data.

[yoavweiss]

a party controlling a path on a web server (for example on some shared hosting site) can deploy a tracker that allows such party to receive information on accessed pages on paths on the same domain (or subdomains), provided that the tracked user first accesses a URL controlled by the adversary.

I filed #140 to discuss mitigations for this one

[yoavweiss]

(B) Browsers should remove NEL policies in case the web server no longer inserts its own policy.

That would burden site operators and force them to send NEL on all requests. I think the mitigations I proposed on #139 solve this, but feel free to disagree there :)

(C) Ensure that NEL does not report on requests that users do not make voluntarily.

I don't think there's consensus on that point. Feel free to open a separate issue suggesting that, but I'd love to understand the threat model you are defending users against.

(D) To limit the information exposed in NEL, I suggest to redesign the standard to allow web sites (A) not to report full URLs.

I don't think there's consensus on that as well. Here too, I'd love to understand the threat model. (in a separate issue, if possible)

(B) allow the possibility to report without revealing IP addresses.

I think NEL is identical here to other request-triggering features, and would most likely benefit from the same IP protections (e.g. Chrome's IP protection proposal, or Apple's Private Relay)