Intent to Ship: Reporting and Network Error Logging

272 views
Skip to first unread message

Douglas Creager

unread,
May 18, 2018, 12:27:45 PM5/18/18
to blin...@chromium.org

Contact emails

dcre...@chromium.org, julia...@chromium.org


Explainer

https://github.com/WICG/reporting/blob/master/EXPLAINER.md


Spec

https://wicg.github.io/reporting/

https://wicg.github.io/network-error-logging/


Note that for Reporting, this Intent to Ship only covers report delivery (§1-4), not the JavaScript ReportingObserver.


Tag review

https://github.com/w3ctag/design-reviews/issues/195

https://github.com/w3ctag/design-reviews/issues/24


Summary

Network Error Logging allows user agents to generate reports about the reliability of HTTPS requests to a particular origin.  This data mimics what is available in server logs; however, by being collected client-side, it has visibility into outages that prevent users' requests from reaching the origin's serving infrastructure.


Reporting is the delivery mechanism that Network Error Logging uses to upload the reliability reports to collectors designated by the origin servers.


Link to “Intent to Implement”

https://groups.google.com/a/chromium.org/d/topic/blink-dev/V38Q47CxTIY/discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/4VNY6Hf_ZB8/discussion


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Debuggability

New Reporting tab in chrome://net-internals to show current state of Reporting/NEL caches [tracking bug]


Risks


Interoperability and Compatibility

Medium: This is a new feature, and Chrome is the only current implementation


Microsoft, Mozilla: Interested and supportive of the idea, but no immediate plans to implement.

Apple: No public signals.


Ergonomics

Other downstream specs are planning on using Reporting for delivery of reports


Activation

This is activated purely by headers in HTTPS responses from origins that want to have NEL reports collected.  Users can opt out on a per-domain basis via the Background Sync permission.


Is this feature fully tested by web-platform-tests?

Reporting API tested here: https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/reporting-api

NEL tests pending: https://github.com/WICG/network-error-logging/issues/70


Entry on the feature dashboard

https://www.chromestatus.com/features/5391249376804864


Rick Byers

unread,
May 18, 2018, 5:37:24 PM5/18/18
to dcre...@chromium.org, blink-dev
Thanks Doug, I'm excited to see this ship ASAP!  Reporting API unblocks a whole bunch of urgent use cases (Eg. Facebook folks were just telling me about their urgent need to get reports for out-of-memory crashes).

As we discussed off-thread, there are at least a couple open spec issues which could lead to significant breaking changes.  I've marked them with a "breaking-change" label but haven't reviewed all the issues in both repros.  Are there others?  What's your thoughts on these?  In particular, what's the risk that we ship with the current implementation, then decide to change the API based on one of these issues and find some adoption has made that difficult?

Note that for Reporting, this Intent to Ship only covers report delivery (§1-4), not the JavaScript ReportingObserver.


Yep, I think Paul plans to send an i2s for that very soon as well :-)
Several of these issues are still open.  In general for each tag review issue we aim to agree to one of the following prior to approving ship:
  • issue is non-blocking (future enhancement, editorial, minor change without compat impact, etc.)
  • resolve the issue (either by accepting or rejecting the suggestion with some justification and record of the level of support for the decision from other potential implementors)
Can you take a pass through the issues and suggest where they fall?

Summary

Network Error Logging allows user agents to generate reports about the reliability of HTTPS requests to a particular origin.  This data mimics what is available in server logs; however, by being collected client-side, it has visibility into outages that prevent users' requests from reaching the origin's serving infrastructure.


Reporting is the delivery mechanism that Network Error Logging uses to upload the reliability reports to collectors designated by the origin servers.


Link to “Intent to Implement”

https://groups.google.com/a/chromium.org/d/topic/blink-dev/V38Q47CxTIY/discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/4VNY6Hf_ZB8/discussion


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Debuggability

New Reporting tab in chrome://net-internals to show current state of Reporting/NEL caches [tracking bug]


Risks


Interoperability and Compatibility

Medium: This is a new feature, and Chrome is the only current implementation


Microsoft, Mozilla: Interested and supportive of the idea, but no immediate plans to implement.


Any links you can provide for this?
 

Apple: No public signals.


Ergonomics

Other downstream specs are planning on using Reporting for delivery of reports


Activation

This is activated purely by headers in HTTPS responses from origins that want to have NEL reports collected.  Users can opt out on a per-domain basis via the Background Sync permission.


Is there anything you can share about specific customers who want to use this API?  "Activation" is really asking: what will we need to do to encourage adoption of this API to ensure shipping it actually delivers significant value to the web community.  In particular we tend to be more concerned with this when there aren't strong implementation intentions from the other vendors (we've been burned by shipping a number of APIs which remain Chrome-only with very little real-world usage).

Is this feature fully tested by web-platform-tests?

Reporting API tested here: https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/reporting-api


Do we pass all the tests currently (we're still working to get a chrome dev channel with experimental features enabled up on wpt.fyi)?  Anything you can say about the coverage of this set of tests?  Eg. if Firefox passes all the test, is it likely to be highly interoperable with Chrome?
Do you anticipate any trouble getting tests landed in WPT?  Seems potentially a little tricky to test the error cases, right?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0YUhDQ5Gquava3%3DRudd9rAP0%2BEhnU4HqnG%3Dte8u27nkjronA%40mail.gmail.com.

est...@chromium.org

unread,
May 20, 2018, 11:45:36 AM5/20/18
to blink-dev, dcre...@chromium.org
Hi, I have a couple security/privacy-related questions about this:
- The Reporting spec has an open issue about dropping reports when switching networks. Was that ever resolved/implemented?
- Will Chrome allow users to clear the report cache as required by the Reporting spec? If so, how do they do that?
- To disable reporting using the Background Sync permission, do users block the origin receiving the reports or the origin that generated them?
Thanks!
Emily

travis....@gmail.com

unread,
May 22, 2018, 11:51:04 AM5/22/18
to blink-dev, dcre...@chromium.org
Also, the TAG review still has pending feedback issues that have not yet been addressed. Would love to see some movement there before this Intent to Ship is approved  :)

Douglas Creager

unread,
May 25, 2018, 2:42:13 PM5/25/18
to est...@chromium.org, blin...@chromium.org
Answers inline:

On Sun, May 20, 2018 at 11:45 AM <est...@chromium.org> wrote:
Hi, I have a couple security/privacy-related questions about this:
- The Reporting spec has an open issue about dropping reports when switching networks. Was that ever resolved/implemented?

The Chrome implementation drops reports when switching networks, but not the configuration about which origins to collect reports about.
  
- Will Chrome allow users to clear the report cache as required by the Reporting spec? If so, how do they do that?

Yep!  Reports are covered by clearing history; the configuration headers are covered by clearing cookies.
 
- To disable reporting using the Background Sync permission, do users block the origin receiving the reports or the origin that generated them?

The origin that generates them

Douglas Creager

unread,
May 25, 2018, 2:43:12 PM5/25/18
to travis....@gmail.com, blin...@chromium.org
Thanks for the feedback, everyone!

Given the number of open issues in the spec repos, we're going to pause this I2S for now, and revisit it once the open spec issues have been addressed.  I'll re-ping this thread at that point.

minami...@gmail.com

unread,
May 29, 2018, 1:17:55 PM5/29/18
to blink-dev


Hi, Douglas Creager and Chromium Security team

I also have comments on the security of the network error logging implementation.
I think NEL is able to scan the user's localhost or private networks.

for example,
example.com uses NEL(include-subdomains) and prepares a subdomain with a private IP address like 127-0-0-1.example.com (resolved to 127.0.0.1 ).
...

some port shows tcp.refused, other port shows abandoned or tcp.timeout

I tried experiments (I set /etc/hosts for subdomain with private ip address ). 
The report shows a different network error for each port for private IP.

Is this a security issue?
Sorry if it's wrong.

thank you

( chrome://net-internals/#reporting on 68.0.3438.3 (Official Build) dev)




2018年5月19日土曜日 1時27分45秒 UTC+9 Douglas Creager:

Jochen Eisinger

unread,
Jun 1, 2018, 4:46:33 AM6/1/18
to minami...@gmail.com, rsl...@chromium.org, blink-dev
+Ryan Sleevi I just mentioned this to

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

dcre...@chromium.org

unread,
Jun 3, 2018, 6:29:08 PM6/3/18
to blink-dev
Thanks for noticing and reporting this!  I think you're right that this is a real concern.  At the very least we need to restrict NEL from reporting on any private addresses.  I've opened an issue on the spec repo to discuss this further.

Daniel Bratell

unread,
Jul 11, 2018, 10:55:23 AM7/11/18
to blink-dev, dcre...@chromium.org
The spec seems to have moved and the issues disappeared. dcreager, do you have an update on this intent? I believe there was a discussion about the use of json in the header for instance, and there was the security/privacy bug that I cannot find.

/Daniel
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a4afeb8-a57e-43c7-afe4-9ddc784ebe26%40chromium.org.



--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

Ian Clelland

unread,
Jul 11, 2018, 11:10:49 AM7/11/18
to bra...@opera.com, blink-dev, dcre...@chromium.org
Both of the specs are transitioning from WICG to W3C, I believe. The new locations are
The GitHub issues have been migrated with the repositories - https://github.com/w3c/reporting/issues and https://github.com/w3c/network-error-logging/issues

(Other doc links may or may not have been updated; changing URLs is hard)


Chris Harrelson

unread,
Jul 11, 2018, 1:34:59 PM7/11/18
to Ian Clelland, Daniel Bratell, blink-dev, dcre...@chromium.org
Ok, thanks. Is the intent still on hold, as dcreager@ mentioned on May 25?

Douglas Creager

unread,
Jul 12, 2018, 10:06:09 AM7/12/18
to chri...@chromium.org, icle...@chromium.org, bra...@opera.com, blin...@chromium.org
I'm on vacation this week, but my plan is to resurrect the intent to ship next week.  I believe all outstanding spec issues have been resolved, including the security issue raised upthread that would have allowed probing someone's internal network using NEL.  I'm going to do one last pass through the issue list to ensure that there's nothing blocking or that would require backwards-incompatible changes before official resurrecting the thread.

Douglas Creager

unread,
Jul 15, 2018, 7:40:46 PM7/15/18
to chri...@chromium.org, icle...@chromium.org, bra...@opera.com, blin...@chromium.org
I'm on vacation this week, but my plan is to resurrect the intent to ship next week.  I believe all outstanding spec issues have been resolved, including the security issue raised upthread that would have allowed probing someone's internal network using NEL.  I'm going to do one last pass through the issue list to ensure that there's nothing blocking or that would require backwards-incompatible changes before official resurrecting the thread.

On Wed, Jul 11, 2018 at 1:34 PM Chris Harrelson <chri...@chromium.org> wrote:

Douglas Creager

unread,
Jul 18, 2018, 11:54:46 AM7/18/18
to chri...@chromium.org, icle...@chromium.org, bra...@opera.com, blin...@chromium.org
Okay, we're ready to resurrect this Intent to Ship!  I'm re-instantiating the template; several of the links need updating since WebPerf has adopted the specs from WICG.

Note that the TAG review meta-bugs have been closed, and all sub-issues resolved.  There are still open issues for both specs, but none of them would require backwards-incompatible changes to either Reporting or NEL.


Note that for Reporting, this Intent to Ship only covers report delivery (§1-4), not the JavaScript ReportingObserver.


Tag review

https://github.com/w3ctag/design-reviews/issues/195

https://github.com/w3ctag/design-reviews/issues/24


Summary

Network Error Logging allows user agents to generate reports about the reliability of HTTPS requests to a particular origin.  This data mimics what is available in server logs; however, by being collected client-side, it has visibility into outages that prevent users' requests from reaching the origin's serving infrastructure.


Reporting is the delivery mechanism that Network Error Logging uses to upload the reliability reports to collectors designated by the origin servers.


Link to “Intent to Implement”

https://groups.google.com/a/chromium.org/d/topic/blink-dev/V38Q47CxTIY/discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/4VNY6Hf_ZB8/discussion


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Debuggability

New Reporting tab in chrome://net-internals to show current state of Reporting/NEL caches [tracking bug]


Risks


Interoperability and Compatibility

Medium: This is a new feature, and Chrome is the only current implementation


Microsoft, Mozilla: Interested and supportive of the idea, but no immediate plans to implement.

Apple: No public signals.


Ergonomics

Other downstream specs are planning on using Reporting for delivery of reports


Activation

This is activated purely by headers in HTTPS responses from origins that want to have NEL reports collected.  Users can opt out of collecting and uploading reports about individual domains via the Background Sync permission.


Is this feature fully tested by web-platform-tests?

Reporting API tested here: https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/reporting-api

NEL WPT tests out for review: network-error-logging#70crrev#1106518

Yoav Weiss

unread,
Jul 19, 2018, 11:36:42 AM7/19/18
to Douglas Creager, chri...@chromium.org, icle...@chromium.org, bra...@opera.com, blin...@chromium.org
Thanks for updating the intent! :)

Looking at https://github.com/w3c/network-error-logging/issues, I see there are still 10 open issues. Will the resolution of them result in syntax changes, or behavior changes which may result in breakage?

Douglas Creager

unread,
Jul 19, 2018, 4:01:54 PM7/19/18
to yo...@yoav.ws, chri...@chromium.org, icle...@chromium.org, bra...@opera.com, blin...@chromium.org
I've got that down to 6 issues, and explicitly labeled them all as being v2 (we're considering them for the future) or backwards-compatible (shouldn't require any backwards incompatible changes to syntax or behavior).

Daniel Bratell

unread,
Jul 20, 2018, 3:44:18 AM7/20/18
to yo...@yoav.ws, Douglas Creager, chri...@chromium.org, icle...@chromium.org, blin...@chromium.org
LGTM1

/Daniel

Yoav Weiss

unread,
Jul 20, 2018, 5:26:39 AM7/20/18
to Daniel Bratell, Douglas Creager, chri...@chromium.org, icle...@chromium.org, blin...@chromium.org
LGTM2

Philip Jägenstedt

unread,
Jul 20, 2018, 5:39:22 AM7/20/18
to Yoav Weiss, Daniel Bratell, dcre...@chromium.org, Chris Harrelson, Ian Clelland, blink-dev
Reply all
Reply to author
Forward
0 new messages