Generally, it's not an additional risk over how screwed you generally are. If you're taking precautions against existing attacks, then yeah.
Question is, can it be fixed? The WebRTC SDP's for getting a peer-to-peer connection, so the general case seems to need to share IP addresses..
But that's not really needed, if you're normally behind a NAT, you're going to be behind a NAT this time, and don't need to share your real IPs -- just STUN/ICE data. If you're not behind a NAT, they already have your IP address.
I am under the assumption that most APs/Routers use 192.168.1.0/24 as the default network? I think it wouldn't be unique enough for use in fingerprinting.
Actually, the block in question is 192.168.0.0/16. But, yes, in my experience, the router is almost always at 192.168.0.1. So, your observation about fingerprinting usefulness is correct.
However, if a rogue script can exploit an XSS vulnerability, it's likely in a lot of cases the user has not set a password on the router's LAN admin interface. So, the script can run through a short list of guesses, get lucky, and poke a hole in the user's firewall from the inside.
This vulnerability exists independent of WebRTC. WebRTC just makes it easier to scope out more unusual LAN setups, such as the article's example involving a 10.0.0.0/8 network.
Bottom line: use passwords on your LAN even if it's just you and two or three computers. And, for good measure, pick an unusual subnet out of the 10.0.0.0/8 net.
Generally, it's not an additional risk over how screwed you generally are. If you're taking precautions against existing attacks, then yeah.
Question is, can it be fixed? The WebRTC SDP's for getting a peer-to-peer connection, so the general case seems to need to share IP addresses..
But that's not really needed, if you're normally behind a NAT, you're going to be behind a NAT this time, and don't need to share your real IPs -- just STUN/ICE data. If you're not behind a NAT, they already have your IP address.