Will this be automagically fixed when we require permission to access the initiator on the webRequest API?  (Since the initiator here should either be absent or the NTP, I'd hope?)

Currently they don't have an initiator. (I found these by logging requests without an initiator). So the fix is probably to add explicit initiators to these requests. We do already prevent extensions from intercepting requests with chrome://newtab as the initiator.

As regards to this getting fixed with the change to the web request api, yes and no. We do still need to add explicit initiators for that to work. But yeah blacklisting initiators like chrome://newtab would then not be necessary.

Are there cases in which network requests don't have initiators and we want to expose them to the webRequest API?  Or could we default to "no initiator == no access"?

This probably belongs in crbug.com/157736. One case is browser initiated main frame requests, but those can be special cased. I am not sure under what cases can renderer initiated requests not have an initiator. Other than that is the case of non-navigation browser initiated requests which don't have an initiator. Off the top of my head, I can't think of cases where an extension should want to intercept those.

Closing this. Will be tracked as part of  crbug.com/884932 .

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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