The original version of the protocol was already pretty strict. It required exact responses, played in exactly the correct order in order for a connection to be

The original version of the protocol was already pretty strict. It required exact responses, played in exactly the correct order in order for a connection to be established. All the new version does, is send over some obscure challenge data (generate a random number, then insert random characters into it????). Then it expects a response from the server with the value md5(challenge). That does indeed get rid of a class of cross protocol attacks, but it's a ridiculous edge case as far as I can see. Previously you may have been able to find some server (non HTTP), that you could connect to, somehow get it to respond with the correct HTTP headers in exactly the right order, and continue. Then exploit it - send spam email, etc etc That's pretty unlikely. Now, you'd have to get that server to respond with the md5 response, which is fairly impossible. BUT. The security here is in Browser->"Some non HTTP server being tricked" - eg something I don't care about too much. Make your "non HTTP server" more secure. For example see the recent exploit against freenode earlier this year, where they allowed connections from an automated HTTP POST in the Firefox browser - the ircd just ignored any HTTP stuff and happily connected users to spam away. The fix wasn't to update the HTTP protocol or firefox, it was to patch the ircd so it actually checks what protocol the client is speaking (And also PING/PONG checks etc) So, your premise that the original spec is somehow insecure to use within a browser->webserver context, is completely incorrect.