There's definitely been interest in exposing HTTPS-related metadata to webRequest, as part of extending the HAR format, in the same manner that request/response headers are exposed.

Further, there's been interest in adding a distinct intermediate event between onSendHeaders and onHeadersReceived (or the asynchronous, non-cancelling onResponseStarted), which would execute when a socket had been assigned to the request (since we perform late-binding of sockets), but before the request itself had been written. For example, this would allow the blocking of particular Certificate Authorities, or the enforcement of additional trust mechanisms (without allowing extensions to override distrust)

I had closed out some of the older bugs because they became too muddled, but overall, I'm supportive of this, and think that Emily & Lucas' work on the Security Panel / DevTools would facilitate exposing more of this to the renderer.

There's some new privacy risks here, but they may already be subsumed into the overall risk of the webRequest API. However, care must be taken, given <webview>'s exposure of webRequest, to make sure we've got everything balanced.

Ryan, to make I follow, would you want to tie this together with a new "onSocketAllocated" event and expose this information only there?

No

Marking as Available to get out of our triage queue (I don't think anyone on the extensions team proper would be implementing this, but if net folks are supportive we'd be happy to have them or someone else contribute a patch). 

If you have a suggestion for where in the code builds the JS object that's passed to the callback, I might take a pass at figuring this out (no promises though).

The closest approximation is https://cs.chromium.org/chromium/src/extensions/browser/api/web_request/web_request_api.cc?rcl=0&l=724

That's after the connection is made (onSendHeaders is before), but also after the header information is received.

The JS object is constructed at https://cs.chromium.org/chromium/src/extensions/browser/api/web_request/web_request_event_details.h?rcl=1469215596&l=25

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

palmer@/rsleevi@, can we dupe this into Roland's work on issue 628819?