41–50 of 88 posts
What does "Used 0 keys for lookups" mean?
So in this case it means you're not vulnerable.
What’s the issue there? How is knowing the local IP a security issue? And FWIW, the local IP does not get leaked when using a VPN. (edit: Or rather, the VPN local IP gets leaked. Same question, no idea if that’s security relevant in some way?) edit: Thanks everyone, I completely forgot about fingerprinting.
> How is knowing the local IP a security issue? It's a privacy issue. You can use it to fingerprint a user, local IP will give you quite many bits of entropy. https://coveryourtracks.eff.org/ > Honestly I'm not even sure if I'm surprised, but it's 2022 and we've been having this problem basically since the day WebRTC was introduced. At this point, if you care about privacy, you should probably put it in the same bag…
I don't buy it: You have to block IPv6 as well, and that's becoming harder to do.
If the user is trying to protect their "privacy" from their ISP by using a VPN (for example), and are attempting to prevent the application-level leak of providing a list of all the local interfaces, they really need to configure their system to restrict e.g. their web browsers and other sensitive tools to those specific interfaces, e.g.
https://askubuntu.com/questions/1313755/forcing-chrome-brows...
This should be easier, like maybe a button in the VPN software.
Earlier quoted context omitted.
> How is knowing the local IP a security issue? It's a privacy issue. You can use it to fingerprint a user, local IP will give you quite many bits of entropy. https://coveryourtracks.eff.org/ > Honestly I'm not even sure if I'm surprised, but it's 2022 and we've been having this problem basically since the day WebRTC was introduced. At this point, if you care about privacy, you should probably put it in the same bag…
It's because if you don't leak the local IP, then webRTC calls will typically fail between people on the same LAN. And, if they don't fail, then they will usually have to go via a TURN server on the internet adding a lot of latency. It's a privacy/functionality tradeoff. But most people consider not being able to videocall or do online gaming with someone in the same building to not be acceptable.
The security impact, as others are pointing out, is pretty minimal. Knowing a local IP address behind a NAT isn't "not" a privacy issue (e.g. I can see things like gaming anti-abuse using tricks like this to discriminate users who need to be blocked vs. normal players), but it's not much of one.
The issue is about leaking the local IP in the foundation which is supposed to be some sort of opaque UUID - the local IP isn't supported to be in there at all, whether you want LAN connections or not.
Is this correct?
This can be disabled in Brave by turning "WebRTC IP handling policy" to "Disable non-Proxied UDP" in "settings - > Privacy and Security".
[1] https://chrome.google.com/webstore/detail/webrtc-network-lim...
Earlier quoted context omitted.
It's because if you don't leak the local IP, then webRTC calls will typically fail between people on the same LAN. And, if they don't fail, then they will usually have to go via a TURN server on the internet adding a lot of latency. It's a privacy/functionality tradeoff. But most people consider not being able to videocall or do online gaming with someone in the same building to not be acceptable.
I don't think that there are many people using WebRTC especially within the same LAN, but fingerprinting is used by almost every commercial site. So I can assume that this "feature" was used in 99.99% cases for fingerprinting. This shows how browser developers race to push new features without proper estimation of privacy concerns. Luckily this was somewhat fixed by using randomized Apple mDNS names instead of IPs. B…
Zoom/Teams with people in the same office? That seems like a rather large user base
Almost all of the “sales/demo/cross company” video calls I’ve been on have been in this bucket
It gets "leaked" to a web app that I'm choosing to connect to? Why do I care?
Earlier quoted context omitted.
I just tried a clean FF profile with resistFingerprinting enabled. No dice. Everything adds only very few bits of identifying information (unlike my main profile which is already almost unique thanks to the accept header (English, then German)) yet it still results in 17.75 bits which according to EFF is unique. I’m agreeing with you, though I wonder, is there any way to not be unique? What would you have to do? Use…
I think a HTML-only browser without support for CSS and JS might help.