I've toyed with the idea of writing a simple webserver to do this - I don't expect it would be too difficult.

 Issue 893281  has been merged into this issue.

I'd love to have this functionality again!

 Issue 915276  has been merged into this issue.

Can I ask, what were the drivers in the first place behind moving from the existing realtime workflow to this capture-then-load workflow utilising chrome://net-export/ and the netlog viewer? I found this statement from https://bugs.chromium.org/p/chromium/issues/detail?id=472699. Please advise if this is it:

"...it would streamline the amount of javascript included in Chrome distribution, and also give more opportunities to develop the net-internals log viewing app outside of Chrome.

In the long term I think the log viewer would benefit from this split since there would be a much lower bar for throwing features or code into it, and developing a suite of tools around analysing logs.

One difficulty with this transition will be how to preserve realtime event stream viewing. Perhaps we will kill this feature in favor of a capture-then-view model like what about:tracing uses."

Also, "Proxy" is still listed under chrome://net-internals/ in Chrome 71 but it does not report the proxy/PAC URL now, although "re-apply settings" and "clear bad proxies" buttons remain.  Is this expected? This is a very useful feature given in IE we restrict our user's ability to see/change the PAC URL. Can we at least get this back please? Thanks!

The quoted motivation is accurate.

The JavaScript we were shipping for chrome://net-internals was old code in need of modernization. While it got the job done, it was never a fully supported UI with an internationalized or polished UI meant for widespread usage. It is great to see that it was useful for others.

The problem with the old architecture, is we would ship all this legacy JavaScript with the Chrome installer, which both increased binary size for all users, and worse increased the security attack surface. Modernizing this code would have meant adding even more code, which runs contrary to our non-bloat and security goals.

To put things in perspective, the net-internals JavaScript runs with higher privileges than an ordinary webpage, which makes it a juicy target for security attacks. This has been leveraged by past attacks, see for instance [1].

Another limitation with the old architecture (where the viewing capabilities are versioned and shipped with Chrome) is that it did not generalize to non-Chrome usages of the //net code. For instance cronet embedders would have no means of viewing live logging information, and viewing postmortem dumps would also require a Chrome browser. Similarly, other Chromium-based browsers would need to duplicate net-internals and ship that or similar code.

Focusing on the file-based architectures makes it simpler to de-couple the functionality to separate tools (webapps/extensions/native apps), and not have their development be constrained by Chrome's binary size or JavaScript development paradigms.

While that sounds good in principle, you are correct that the transition would have gone smoother if we had implemented an equivalent realtime support with the new architecture. While it is technically possible, it hasn't been implemented yet, and was a known point of friction. Also as you point out, the current visual stylings of the chrome://net-internals/ are confusing and need to be updated.

In terms of priority, completing the architectural switchover became more important with the Network Service refactor. More changes would have been needed to port the old architecture to work under Network Service. Given that we have wanted to change this anyway, this became the final straw that prompted pulling the plug.

I am optimistic that in the long run we can end up with better and more sophisticated tooling from this de-coupling, and it will be a better tradeoff for the majority of Chrome users.

[1] https://blog.chromium.org/2012/06/tale-of-two-pwnies-part-2.html

For me chrome://net-internals/ was the most commonly used tool other than developer tools. It was tremendously helpful to troubleshoot low-level network related issues (socket setup, TLS etc) as it is happening (testing with different network/server parameters).

chrome://net-export is good for sharing the logs for postmortem. But without live viewing (great filtering support), it can take much longer to figure out what to look for.

+1 to what legendm stated.

Wrote up a detailed comment for 892454, then saw this looks to be the better place of discussion for it. Useful (job-made-significantly-easier) features I've found and grew to love that were removed:

(1) Being able to see the current DNS table for Chrome. There are times when testing load-balanced web servers during a code deployment that this feature proved critical. i.e. Am I hitting the load-balancer, the server we just deployed code too, or the server we last deployed code too?

(2) QUIC connections - specifically seeing what sites are actively using them among your open tabs. We have had an isolated incident or two in recent times where YouTube wouldn't stream better than 480p, despite that never being a problem. The QUIC table was essential in helping to determine the root cause for this. Turns out various firewall/anti-virus vendors like to turn on UDP flood protection when there is a lot ( > 2Mbps) of simultaneous QUIC network connections.

While I think I better understand the reason for it's removal with this Issue, I believe I will be keeping a slightly older version of Chrome lying around for when the net-internals that I've used over the past 3 years is needed. It will be easier than going back to Wireshark...

In the meantime, I do hope some/all of these features can be re-introduced over time as code can be modernized for it. Thanks Chromium team!

 Issue 923057  has been merged into this issue.

I understand the desire to not include these features for normal users since so many of the people on the internet don't use them, but for pro-users, their removal is absolutely awful. I know this seems like not a big deal with such a small % of people who use them, but the individual people who do use them are often using it to manage other systems used by thousands or millions of users which DOES make their removal a widespread problem, even if indirectly.  

Is there any way these features could continue to be supported until a viable replacement exists, or would that conflict too heavily with other development currently happening in the browser's internals?

The timing of the removal is because the network stack was moved out of process, so the old codepath wouldn't even work any more.

And for the record, it's pretty annoying when debugging Chrome network issues, too, which provides us with quite a bit of incentive to write an app sooner rather than later, though no one is currently working on it.