Live data from Hacker News

Chromium based browsers leak user local IP via WebRTC foundation attribute

niespodd.github.io

11–20 of 88 posts

Re: Chromium based browsers leak user local IP via WebRTC foundation attribute

#12
post #7
post #6

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…

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

https://bugzilla.mozilla.org/show_bug.cgi?id=959893 is a fun read... Firefox used to also leak the internal IP circa 2015.

Re: Chromium based browsers leak user local IP via WebRTC foundation attribute

#13

I seem to recall Fallon (based on Chromium) has a feature which disables that.

You appear to be correct. I just tried the test on Falkon and it failed. But since not many poeple use Falkon regularly... maybe that's a fingerprint all by itself.

Re: Chromium based browsers leak user local IP via WebRTC foundation attribute

#14
post #5

Earlier quoted context omitted.

Leaking any kind of data is yet another data point for fingerprinting. You only need a few to uniquely identify a user.

I've yet to see a normally configured browser _not_ be uniquely identifiable many times over through fingerprinting. At some point it feels like trying to drain the ocean with a cup. Maybe we just need to accept that anyone who really wants to fingerprint you _can_ fingerprint you unless you use a specialist browser. At that point the solution is fairly obvious, make it legally difficult to use unique fingerprinting…

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 Windows with no extra fonts, Chrome in English, on a FullHD monitor with webgl/canvas/audio fingerprinting protection extensions?

Re: Chromium based browsers leak user local IP via WebRTC foundation attribute

#15
post #6
post #2

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…

If memory serves Ublock origin does just that.

Re: Chromium based browsers leak user local IP via WebRTC foundation attribute

#16
post #13

I seem to recall Fallon (based on Chromium) has a feature which disables that.

You appear to be correct. I just tried the test on Falkon and it failed. But since not many poeple use Falkon regularly... maybe that's a fingerprint all by itself.

> But since not many poeple use Falkon regularly... maybe that's a fingerprint all by itself.

You can check here: https://coveryourtracks.eff.org

Re: Chromium based browsers leak user local IP via WebRTC foundation attribute

#17
post #6

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…

If memory serves Ublock origin does just that.

Not anymore on Desktop: https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-l...

Re: Chromium based browsers leak user local IP via WebRTC foundation attribute

#18
post #6
post #2

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…

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.

Re: Chromium based browsers leak user local IP via WebRTC foundation attribute

#19

Earlier quoted context omitted.

I've yet to see a normally configured browser _not_ be uniquely identifiable many times over through fingerprinting. At some point it feels like trying to drain the ocean with a cup. Maybe we just need to accept that anyone who really wants to fingerprint you _can_ fingerprint you unless you use a specialist browser. At that point the solution is fairly obvious, make it legally difficult to use unique fingerprinting…

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 believe the only feasible way without bending over backwards is to use the Tor Browser. But privacy and security always come at a price.

Re: Chromium based browsers leak user local IP via WebRTC foundation attribute

#20
post #6

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.

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.

Post reply on HN