András Veres-Szentkirályi

> Ignoring `enabled` in the Protobuf implementation: why not, so that both parsers work in a same way. But we would loose the possibility to load enabled-by-default configs (that's not...

Maybe I didn't make myself clear enough: by _won't break anything_ I meant not doing anything unexpected for the user, this covers * modifying requests silently * modifying responses silently...

> we enable scripts on one load path but not on another, which I think is inconsistent and goes against your stated concerns Inconsistent? Maybe. Against my concerns? I don't...

> clicking buttons is a "weaker" consent than setting environment variables Thanks, that's exactly my point. Although the use-cases of GUI and environment variables overlap somewhat, I feel that *...

It could work, especially on firewalled hosts in an internal network. First of all, I'd recommend more tests to see how Burp's [`makeHttpRequest`](https://portswigger.net/burp/extender/api/burp/IBurpExtenderCallbacks.html#makeHttpRequest(burp.IHttpService,%20byte[])) handles timeouts. The next step would entail...

And of course, there's still the option to do response analysis like Backslash Powered Scanner does; just because DNS-based detection fits so damn well for this vulnerability, it doesn't mean...

Thanks! Why not a pull request? :)

> Although TCPSources give us a lot flexibility in trying new Sources, I don't think they are strictly required for a production use. We use TCP sources in production for...

Unfortunately, [Websocket is off-limits for Burp extensions](https://forum.portswigger.net/thread/extension-api-for-websocket-2f3889be) right now.

> I can see some positive progress in the new Montoya API: https://github.com/PortSwigger/burp-extensions-montoya-api/tree/main/api/src/main/java/burp/api/montoya/websocket Unfortunately all I can see in the linked parts is a single entry point where you can...