I think it might be too easy to expose information we don't trust the renderer process with, unless we move devtools out of the renderer process.  A recent CL was sent me that makes sure we don't send raw headers for cross-origin requests to devtools, for instance.

We've tried to keep the network service unaware of devtools, since that's a higher-level product feature. Can the helpers be at the content/ level?

I was thinking of a callback for the network service to send errors into, completely abstracted from the devtools. Browser could provide such a callback and convert relevant errors into console messages, bypassing the renderer process altogether.

jam: Well, one way or another data needs to make its way out of the network service somehow. This is especially hampered by the SSLInfo being omitted most of the time, so I had to duplicate some data in a separate boolean and, along the way, compromise on the fidelity of the console warning.

The true TLS metadata is pretty small, so it'd be nice if we always sent that over and only conditioned the heavy stuff like the certificate. But I think a lot of code assumes that SSLInfos without certificates are invalid, so that would need to be tweaked, if folks are otherwise open to it. That alone would be an improvement.

Come to think of it, I'm not sure putting DevTools integration into the network service quite works. At the time the network service would trigger the warning, we haven't committed the navigation yet. So the navigation code have to queue up the warnings and replay them after commit. (Then again, that's effectively what we're doing by stashing the bits in ResourceResponseInfo and acting on it later.)

> is pretty small

To be precise, TLS metadata is just a handful of uint16s.