4 ms·

> 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.

> 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/ 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 as third-party cookies and just block it entirely.

Semaphor 4y ago
Well, the big non-adtech browser is not vulnerable, so there’s that.
- amenghra 4y ago
  https://bugzilla.mozilla.org/show_bug.cgi?id=959893 https://bugzilla.mozilla.org/show_bug.cgi?id=959893 is a fun read... Firefox used to also leak the internal IP circa 2015.
  - codedokode 4y ago
    Yes it is interesting how developers race to push new features allowing deanonimization of VPN users and better fingerprinting. There is also WebGL whose main purpose is to provide user's videocard model to advertising companies and governemnt institutions.
MomoXenosaga 4y ago
If memory serves Ublock origin does just that.
- Semaphor 4y ago
  Not anymore on Desktop: https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-leaking-local-IP-address https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-l...
londons_explore 4y ago
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.
- codedokode 4y ago
  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. But as a result the browser has to support Apple DNS protocol which can potentially increase attack surface. I would prefer to disable this feature completely by default and let the minority who needs it enable it via settings.
  - helloooooooo 4y ago
    Corporate networks…
  - bawolff 4y ago
    > This shows how browser developers race to push new features without proper estimation of privacy concerns. Settling on a different trade-off then you would like is not the same thing as doing it without consideration.
    - coldtea 4y ago
      In this case, it is blatant disregard.
  - rollcat 4y ago
    > But as a result the browser has to support Apple DNS protocol which can potentially increase attack surface. The "Apple" DNS protocol is standard DNS, over a multicast IP address, on port 5353. You can literally use plain old dig to perform mDNS lookups: $ dig @224.0.0.251 -p 5353 +short hello.local 192.168.123.45 If DNS lookups considerably increase your attack surface, something is very, very wrong with your architecture.
geocar 4y ago
> 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/ https://coveryourtracks.eff.org/> 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-browser-to-use-a-specific-network-interface https://askubuntu.com/questions/1313755/forcing-chrome-brows... This should be easier, like maybe a button in the VPN software.
lxgr 4y ago
> just block [WebRTC] entirely I think an opt-in permission seems like the way to go, like the one we already have for microphone/camera permissions, and possibly just merged with these (i.e. grant WebRTC permissions together with A/V permissions). There are quite a few interesting non-A/V WebRTC applications around – these could be handled via an explicit prompt, similarly to how newer iOS versions handle local network permissions.

Semaphor 4y ago

Well, the big non-adtech browser is not vulnerable, so there’s that.

amenghra 4y ago
https://bugzilla.mozilla.org/show_bug.cgi?id=959893 https://bugzilla.mozilla.org/show_bug.cgi?id=959893 is a fun read... Firefox used to also leak the internal IP circa 2015.
- codedokode 4y ago
  Yes it is interesting how developers race to push new features allowing deanonimization of VPN users and better fingerprinting. There is also WebGL whose main purpose is to provide user's videocard model to advertising companies and governemnt institutions.

MomoXenosaga 4y ago

If memory serves Ublock origin does just that.

Semaphor 4y ago
Not anymore on Desktop: https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-leaking-local-IP-address https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-l...

londons_explore 4y ago

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.

codedokode 4y ago
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. But as a result the browser has to support Apple DNS protocol which can potentially increase attack surface. I would prefer to disable this feature completely by default and let the minority who needs it enable it via settings.
- helloooooooo 4y ago
  Corporate networks…
- bawolff 4y ago
  > This shows how browser developers race to push new features without proper estimation of privacy concerns. Settling on a different trade-off then you would like is not the same thing as doing it without consideration.
  - coldtea 4y ago
    In this case, it is blatant disregard.
- rollcat 4y ago
  > But as a result the browser has to support Apple DNS protocol which can potentially increase attack surface. The "Apple" DNS protocol is standard DNS, over a multicast IP address, on port 5353. You can literally use plain old dig to perform mDNS lookups: $ dig @224.0.0.251 -p 5353 +short hello.local 192.168.123.45 If DNS lookups considerably increase your attack surface, something is very, very wrong with your architecture.

geocar 4y ago

> 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/ https://coveryourtracks.eff.org/> 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-browser-to-use-a-specific-network-interface https://askubuntu.com/questions/1313755/forcing-chrome-brows... This should be easier, like maybe a button in the VPN software.

lxgr 4y ago

> just block [WebRTC] entirely I think an opt-in permission seems like the way to go, like the one we already have for microphone/camera permissions, and possibly just merged with these (i.e. grant WebRTC permissions together with A/V permissions). There are quite a few interesting non-A/V WebRTC applications around – these could be handled via an explicit prompt, similarly to how newer iOS versions handle local network permissions.