In what way do you believe this mechanism would be useful to an attacker?

I believe this would be useful to steal information (login credentials, bank details etc) in a clandestine fashion. This data exfiltration method leaves no evidence in Chrome that this data has been sent, packet inspection would be useless if the data was encrypted and then encoded. 

As a developer if I was looking at devtools I would not see any evidence of information leaking out, and in a large codebase it would be very easy to conceal the exfiltration code. 

https://blogs.akamai.com/2017/09/introduction-to-dns-data-exfiltration.html & https://blog.talosintelligence.com/2016/06/detecting-dns-data-exfiltration.html give some example use cases for this kind of data exfiltration. 

It would be very easy for someone to conceal this in a chrome extension for example, and only activate it for specific targets, leaking their credentials in an almost undetectable fashion.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Ah, so the scenarios described here presume that either the user's browser or the victim website have already been compromised. That would put this squarely outside of the threat model meaning that this shouldn't be tracked as a security vulnerability.

An attacker in a position to introduce clandestine code to a site has many different opportunities to egress data in an unnoticed manner. They can encrypt their outbound traffic. They can create a side-channel that leaks data using the timing or order of innocuous requests. They can hide data within other data using steganographic techniques. 

It might be a good idea for Chrome's Developer Tools to clearly indicate which DNS domains have been resolved (for a number of purposes) although I'm skeptical about the overall utility of such a mechanism for reverse-engineering compromised sites or browsers.  

That's fair, it's not a vulnerability. I would propose though that it would still be a security improvement to fix this issue. 

The other methods you have described for exfiltrating data - encrypting traffic, side channels using timing / ordering & steganography all leave traces in chrome that can be viewed in the network monitor or console. Even using DNS exfiltration using another means leaves a trace in the network monitor, which is why I'm only interested in this specific case.

I would really like to have some way of viewing which DNS queries chrome has requested, but that's obviously quite an addition to devtools, which why my proposed solution was to ignore these elements when they are dynamically added. Another solution would be to log these as failed connection attempts in network monitor.

Keeping this open as a feature request to show the preconnects in DevTools, removing security view restictions.

Thanks!

pfeldman@ this is still a feature request for devtools instrumentation for preconnects. Unclear why the component was removed.

I think this bug should not be repurposed as a feature request. It has been bringing up something that was considered as not important (comment #5). We should probably file a new request for devtools instrumentation for preconnects. Which is likely to not be addressed due to the lack of resources on the devtools side...