Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chromium based browsers leak user local IP via WebRTC foundation attribute

niespodd.github.io

Post reply on HN
Print view View original

71–80 of 88 posts

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

#71

Post by CommitSyn »

Semaphor wrote: post #33
hdjjhhvvhga wrote: post #19

Earlier quoted context omitted.

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.

Actually, resistFingerprinting + switching to the user-agent string tor uses gets me 99% of the way there. All that’s missing is the weird window size (vertical taskbar), if I could get that to report a default size, I’d actually be better than Tor (they have a bunch of responses slightly more unique than FF with resistFingerprinting). But it’s academic for me anyway, I have Accept-Language en-US,en;q=0.7,de-DE;q=0.3…

> All that’s missing is the weird window size (vertical taskbar)

TBB actually adds a border at the bottom of the browser so the reported size isn't the actual size. If you change the size of your browser window to the tor-reported size then it should work.

Unless I'm misunderstanding and you mean something to do with the scrollbar?

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

#73

Post by wbl »

rollcat wrote: post #36
codedokode wrote: post #20

Earlier quoted context omitted.

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…

> 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 arch…

I remember old BIND versions

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

#74

Post by kornhole »

Fnoord wrote: post #57

WebRTC was already known to leak local IP. Which can be dangerous if you're behind a VPN. I use two browsers. One with WebRTC disabled (Firefox) and one with WebRTC enabled (Safari/Chromium). The former also runs a myriad of other addons which increase privacy. The latter I use to connect to PiKVM.

I also use similar browser isolation strategy. I use one browser for real-ID activity such as banks, domain registrars.. and avoid entering real creds in the private browser to keep an anonymous fingerprint. This is one of those gray areas though where I don't always want to share my IP over Jitsi.

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

#75

Post by cma »

nemothekid wrote: post #48
codedokode wrote: post #20

Earlier quoted context omitted.

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…

> I don't think that there are many people using WebRTC especially within the same LAN 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

> Almost all of the “sales/demo/cross company” video calls I’ve been on have been in this bucket

My understanding is Zoom only supports P2P for two person calls.

I can't quite tell from this answer if it is the default or not, but it sounds like it has to be manually enabled:

> Account owners and admins can enable one-on-one meetings to have data routed between two participants (peer-to-peer), rather than going through the cloud or server. Enabling this may improve the quality and connection of one-on-one meetings (depending on how your network prioritizes traffic) by directly sending video and audio between both parties.

https://support.zoom.us/hc/en-us/articles/360061410851-Enabl...

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

#77

Post by nequo »

codedokode wrote: post #24
Semaphor wrote: post #14

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.

The EFF has a website that illustrates why that doesn't help:

https://coveryourtracks.eff.org/

Like siblings are saying, they use all available information to fingerprint you.

You can cover your identity only to the extent that you can display the same characteristics to the web server as the largest group of users that have all the same characteristics. This includes whether you have JS disabled as well as your IP address, User-Agent, display resolution, etc.

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

#78

Post by sesm »

Is user IP leaked to another peer if there is a media server (like Kurento) between peers? I’ve worked in 2 WebRTC-based projects and in both cases the connection was not actually P2P, but had some kind of media server in between, either to mux multi-user conferences or to re-encode the media to a format supported by the other peer.

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

#79

Post by lxgr »

rollcat wrote: post #6
Semaphor wrote: 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…

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

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

#80

Post by lxgr »

Fnoord wrote: post #57

WebRTC was already known to leak local IP. Which can be dangerous if you're behind a VPN. I use two browsers. One with WebRTC disabled (Firefox) and one with WebRTC enabled (Safari/Chromium). The former also runs a myriad of other addons which increase privacy. The latter I use to connect to PiKVM.

> The former also runs a myriad of other addons which increase privacy.

Unfortunately, the more custom your browser behavior gets, the more finger-print-able you are :/

And that's not even considering potentially harmful plugins (either inherently so, or via browser store account takeovers).

Post reply on HN