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

81–88 of 88 posts

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

#81

Post by BeefWellington »

jovial_cavalier wrote: post #66
bearjaws wrote: post #49

Earlier quoted context omitted.

Yeah we don't need privacy, especially to third party extensions loaded by sites, we should just set our user agent to our full name, address and phone number.

Your full name is not the same as your local IP. Since your NAT subnet is almost always /24, there really are only 256 local IP addresses. Which one you happen to be using at the time is not really important. There are 10,000 other things about your browser that could be used to uniquely identify you. This is a feature of WebRTC that allows it to do what it does, not a bug. If you are worried about 3rd party web apps…

If it leaks local ipv6 there may not even be NAT involved. This would unmask the user on the other end of a VPN or Proxy, for example.

While this generation is done only for IPv4 space someone with sufficient time, resources, and inclination (say a large Ad conglomerate) could similarly start generating these for IPv6 address spaces.

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

#83

Post by whatismybrowser »

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.

It used to be available to detect, but they changed it a long time ago.

It made it easy to help someone find their local ip address, without having to click around in settings or the command line:

https://www.whatismybrowser.com/detect/what-is-my-local-ip-a...

But I understand the fingerprinting/privacy concerns, so it's for the best that it's not available.

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

#84

Post by jackewiehose »

jackewiehose wrote: post #52
lelandfe wrote: post #31

Earlier quoted context omitted.

Damned if you do, damned if you don’t. Disabling WebRTC would make your Firefox instance extremely unique and thus easily fingerprinted.

Yes, but as far as I understand, the fight against fingerprinting is lost anyway. Having WebRTC enabled can be dangerous for other reasons. You could be seeding a torrent unknowingly just by visiting a website. This can turn into a freaking disaster if you live in country like Germany. It's a shame that browsers don't ask you for WebRTC like they do with webcams.

Was I wrong about the torrent stuff or did the downvotes come from web-developers who want WebRTC to be always available by default?

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

#85

Post by x-complexity »

Eisenstein wrote: post #30

This can be disabled in Brave by turning "WebRTC IP handling policy" to "Disable non-Proxied UDP" in "settings - > Privacy and Security".

> This can be disabled in Brave by turning "WebRTC IP handling policy" to "Disable non-Proxied UDP"

Not advised if you want to use WebTorrent, since it relies on WebRTC.

Setting it to "Default public interface only" still allows WebTorrent & WebRTC-reliant tools to be used, whilst still only broadcasting your public IP (which is already known anyway).

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

#86

Post by Dylan16807 »

jackewiehose wrote: post #84
jackewiehose wrote: post #52

Earlier quoted context omitted.

Yes, but as far as I understand, the fight against fingerprinting is lost anyway. Having WebRTC enabled can be dangerous for other reasons. You could be seeding a torrent unknowingly just by visiting a website. This can turn into a freaking disaster if you live in country like Germany. It's a shame that browsers don't ask you for WebRTC like they do with webcams.

Was I wrong about the torrent stuff or did the downvotes come from web-developers who want WebRTC to be always available by default?

Well for one a website can make you secretly upload copyrighted content with plain old javascript. And it's going to be hard to hold you liable for data uploads that someone else initiated and you didn't know about.

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

#87

Post by jackewiehose »

Dylan16807 wrote: post #86
jackewiehose wrote: post #84

Earlier quoted context omitted.

Was I wrong about the torrent stuff or did the downvotes come from web-developers who want WebRTC to be always available by default?

Well for one a website can make you secretly upload copyrighted content with plain old javascript. And it's going to be hard to hold you liable for data uploads that someone else initiated and you didn't know about.

> Well for one a website can make you secretly upload copyrighted content with plain old javascript

Only to a webserver and thanks to CORS not to any webserver. There is no benefit for a website doing that - unlike with sharing a torrent to other internet users.

The problem with torrents is that they are actively watched by "Abmahnanwälte" (lawyers who make a living by suing copyright offenders).

> And it's going to be hard to hold you liable for data uploads that someone else initiated and you didn't know about

yeah good luck with that. All they see is your IP and then you can try to explain how this happened and how you are totally innocent.

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

#88

Post by capitainenemo »

jackewiehose wrote: post #54
capitainenemo wrote: post #32

Earlier quoted context omitted.

Yeah, that one was as annoying as what they did to extensions, but at least the Fennec build in F-Droid has it enabled. https://f-droid.org/en/packages/org.mozilla.fennec_fdroid/

Thank you, I will try that. Although I hope that for critical security updates they will be faster... Right now it is lagging behind (105.1.0 vs. current 106.1.0)

I was wondering about that myself: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11924

Looks like they ran out of space on their build machine.

Post reply on HN