I authored http://jsfiddle.net/alokmenghrajani/0qo4kq7x/ over 3 years ago...
VPN leaks users’ IPs via WebRTC
141–150 of 172 posts
Re: VPN leaks users’ IPs via WebRTC
#142this is old news tho, I was aware of this for ages. If you check privacy websites thats one of the first thing they say, turn off webRTC in your browser.
Re: VPN leaks users’ IPs via WebRTC
#143I don't use VPNs. For me, the more alarming information here is that SOCKS and Tor proxies are also leaking IP addresses. If a SOCKS proxy is configured in browser, isn't it the browser's responsibility to ensure all outgoing traffic - including WebRTC - goes via the proxy? Are these browser bugs? Update: Can confirm Firefox Quantum with SOCKS proxy leaks the address. Oh dear! Update 2: I didn't realize this is how W…
It seems Firefox has resigned to some sort of role as 'token' competition to Chrome.
Most of its actions seem inexplicable and counterproductive when strong privacy and user protection should be their reason to exist and keep a dedicated user base.
The bigger problem is exploding complexity in many areas is a huge concern for open source as it's becoming increasingly impossible for small teams to implement or come up with alternatives. This is going to reduce meaningful choice and leave users at the mercy of a mix of corporate or vested interests.
Re: VPN leaks users’ IPs via WebRTC
#144Heh, this webrtc story is at least few years old and everyone privacy / security aware is blocking it.
For testing webrtc and other leaks including fingerprinting rather use https://browserleaks.com/
(and it is unable to capture any exposing data for my browsers on any of my devices)
Re: VPN leaks users’ IPs via WebRTC
#145BTW I think I would love a "VPN" (the term itself is misused massively, oftentimes it is just a proxy) accessed via WebRTC so it would be harder for the men in the middle to tell whether I am using a "VPN" or just calling somebody. Perhaps people in countries like China could make great use of such a thing too.
Re: VPN leaks users’ IPs via WebRTC
#146Earlier quoted context omitted.
Just wait till you get a load of content rendering engines being written in (dynamicly re-obfuscated) web assembly and rendered via canvas, so users are totally locked out of modifying content loaded into them or blocking ads. This is already being worked on.
It's being fought before it's even fully grown. Computer vision adblockers are also being worked on.
A sad and stupid zero-sum game wasting both talent and electricity.
Re: VPN leaks users’ IPs via WebRTC
#147Earlier quoted context omitted.
>You have to disable WebRTC in the browser Incorrect. An easy and foolproof way of using VPNs is with network namespaces. You start the VPN in your init network namespace and then move the created device into a dedicated VPN namespace. OpenVPN has support for this because it allows you to execute a shell script after the VPN device has been created. Then you simply start your browser, torrent client, whatever in this…
>DNS leaks can be prevented by using a generic DNS provider such as 8.8.8.8 You mean leaking to Google doesn't count as leaking? Your namespaces suggestion is interesting, but easy and foolproof?
Your parent said:
"DNS leaks can be prevented by using a generic DNS provider such as 8.8.8.8."
... and you replied:
"You mean leaking to Google doesn't count as leaking?"
But I don't understand where the DNS leaks would be coming from if you are using an actual VPN for your entire network stack - wouldn't that tunnel all traffic (TCP and UDP) to your endpoint ?
How are you leaking DNS in that scenario ?
Re: VPN leaks users’ IPs via WebRTC
#148Earlier quoted context omitted.
I'm only going off some in-person dealing with folks behind WebRTC and they know that permissions suck and would hurt adoption and hence fight to make sure they don't happen. They dismiss all privacy concerns with "you can't have privacy in a browser" and "fingerprinting will work anyways so we can't make it worse". It's head-in-sand approach to privacy and it's bad. Even then, Firefox is simply wrong to tell people…
Lots of people in webrtc are critically concerned with the safety and privacy of their users.
I'm not sure what that means. It was obvious this would be used for fingerprinting and leaks. The explained reasons for proceeding was that permission prompts for data channels would hurt usage, despite not having clear cases where we need P2P without letting users know.
And none of this excuses overriding the user's expressed network connectivity.
When this was brought up, they immediately jumped to the excuses that fingerprinting can't be helped. And many jumped to saying hey you should use Tor Browser anyway. Total capitulation.
Maybe someone cared, but it's not the official stance from webrtc groups or browsers.
Re: VPN leaks users’ IPs via WebRTC
#149Every browser should have settings to disable WebRTC and it should arguably be disabled by default.
It can be very useful, but can also cause a lot of problems.
Re: VPN leaks users’ IPs via WebRTC
#150Earlier quoted context omitted.
Oh it gets better. I have implemented SIP software (written, from scratch). On the SIP implementors mailing list, one of the authors defends the insane parsing rules by saying that C and Java allow you to be flexible with syntax, so why not SIP? They are totally detached from actually implementing elegant or high performance software. Actual engineers achieve this despite of SIP's terrible decisions. Granted, many of…
I'm not sure binary protocols are any better, unless you make the first two bytes of every message a version number. FWIW, I consider the canonical implementation of SIP at this point to be asterisk. I work on a SIP derived protocol, P25 CSSI - it has all the issues of SIP, and more!
> I'm not sure binary protocols are any better, unless you make the first two bytes of every message a version number.
Actually we've seen people manage to fuck that up royally, too. Examples: Routers confusing MAC addresses starting with "6" with IPv6 packets. Various TLS implementations in proxies falling completely apart when they see an unknown version. Various TLS proxies falling apart when seeing an unknown extension. Far too many instances of "assert version==1" to list.