Tom, do you mind if I punt this one on over to you?

dcheng for a second pair of eyes.

if you are ok with the audit, can you flip the bit for security here: https://bugs.chromium.org/p/chromium/issues/detail?id=880460 

No blocking issues from the security side.

For the browser process: networking itself ran here at the highest privilege level. We’ve added a (still) privileged interface between browser and network service to control various behaviors, and the browser process now relies on the network service to make network requests. Security-wise, this is at worst a neutral change, and at best, an improvement, since we’re no longer running this code in the browser process.

From a renderer perspective, the network service restricts access by using capability-based security. Loading privileged URLs (such as webui and extensions) is gated on having a corresponding URLLoaderFactory interface pointer: without the interface pointer, the request simply won’t be allowed. Assuming everything is correctly written, this seems pretty robust to me. The main catch is that a bug that passes a URLLoaderFactory for loading a privileged URL to an unprivileged renderer will leak that privilege. Fundamentally though, this is not much different than if the pre-network service code had a bug in access checks.

One final note is that the network service itself currently can’t kill unprivileged child processes. For things like cookie kills, the renderer must go through the browser process to enforce the kill. For a few other things (such as spoofing the origin header:  issue 862176 ), the kills were removed since security benefit was marginal. We should keep a careful eye on kills (and developers should ensure that things that *do* require kills are covered by tests).

Further sandboxing of the network process on Windows in being tracked in issue 841001.