Again, not an issue with local network vs Internet. You can do the same fingerprinting to check for connection ability against Internet sites too... If anythi

Again, not an issue with local network vs Internet. You can do the same fingerprinting to check for connection ability against Internet sites too... If anything this is a bug with WebSockets and its cross-origin implementation. The existing cross-origin request specs already specify that there should not be information being leaked about the target resource unless cross-origin was allowed. Iframes don't let you time how long the thing inside loads anymore, img also stopped making this available, same for things like AJAX, and so should it be for websockets too. If indeed the only information the scan is gleaning is based on timing then it's no different from the other JS timing attacks (some of the early ones could expose arbitrary slices of ram!)--- it's a bug and should be fixed as such. When you say doing private/public IP filtering is to fix this kind of issue, then what's really being said is "I still want websockets fingerprinting and port scanning to _work_, just not with any internal network IPs".