Live data from Hacker News

“We are considering adding an extension to restrict the use of WebRTC”

bugzilla.mozilla.org

151–159 of 159 posts

Re: “We are considering adding an extension to restrict the use of WebRTC”

#151
post #138
post #9

I don't understand why a peer-to-peer network connection is different from Ajax. Browsers don't require user approval for 3rd-party XMLHttpRequest connections. WebSockets are even more permissive. Why is WebRTC being singled out here? If I were a conspiracy-minded person (I'm not), I'd have to wonder if this was some kind of corporate-driven attempt to suppress peer-to-peer networks. In fact, I do think this is being…

Yeah, it seems like the issue is running unverified third-party javascript on your webpage. This is part of the reason why I use privacy badger because many sites seem to do this. If you want to prevent data from being sent to servers about you, you pretty much have to disable javascript completely though.

It's ultimately impossible to prevent tracking of all types. Pixel tracking doesn't use JavaScript, so it persists even if JS is disabled. Actually, I can think of a few ways that don't require JS.

Re: “We are considering adding an extension to restrict the use of WebRTC”

#152

Earlier quoted context omitted.

Leaking a client IP address is not even near the same universe of severity as remotely obtaining a web servers private TLS key. Given the lack of perfect forward secrecy used by web servers at the time, Heartbleed was a "read any encrypted traffic sent by the server, ever" issue.

WebRTC doesn't just leak the client IP address, it also leaks the public IP address of all network interfaces on the machine. If you're on a VPN, it can mean you leak your real IP address, too. Many Chinese use VPNs to circumvent censorship or participate in speech, so leaking your real IP address is potentially life threatening.

It's not a leak. It's integral to the way WebRTC works. The purpose is to implement a highly-secure, multiplexed audio/video/data channel on top of IP. To do that, you must exchange publicly addressable IP addresses.

There are already forced opt-ins for accessing the microphones and cameras, this should probably be fully extended to require the user to opt-in when any WebRTC feature is used.

Re: “We are considering adding an extension to restrict the use of WebRTC”

#153
post #93

Earlier quoted context omitted.

> a random guy on the internet says something and you think it is true? Yes, if they identify themselves and their company and what they say aligns with my personal experience. > You don't have the foggiest idea what they are really doing with the data. All we know is that they are collecting the data without user's consent. You never have any absolute certainty what anyone does with your data - all you have are hypo…

It's not only about the VPN leak. WebRTC also leaks internal IP addresses which provide additional entropy that can be used for fingerprinting.

Entropy that changes when your local IP does? That's worse than useless for ad targeting. Even if it were useful, I don't think there's much of a chance that adtech companies will build out STUN servers to handle the kind of traffic they do just track down the 0.001% of users who do not accept third-party cookies. Can you even do WebRTC from an iframe?

Browser fingerprinting is absolute FUD. It makes no sense for advertisers, and it's pretty useless for anyone else, too. Every time I visit the EFF site that checks my fingerprint, it tells me I'm still unique. That's perfect anonymity!

Revealing a user's personal IP when they're using a VPN is a real problem, though, where the computer isn't doing what an even an experienced user would expect.

Re: “We are considering adding an extension to restrict the use of WebRTC”

#154

Earlier quoted context omitted.

WebRTC doesn't just leak the client IP address, it also leaks the public IP address of all network interfaces on the machine. If you're on a VPN, it can mean you leak your real IP address, too. Many Chinese use VPNs to circumvent censorship or participate in speech, so leaking your real IP address is potentially life threatening.

Yes, and Java can leak your real IP address and Flash can leak your real IP address. If you attack scenario is trying to circumvent authoritative governments, don't use a web browser with extra features or plugins like WebRTC turned on. "Hiding a users 's true IP at all costs who are using a VPN" is not a reasonable design expectation for mainstream browsers. They are fixing bugs and adding features. This is an extre…

You listed two things that are optional plugins and are being aggressively deprecated.

The vast majority of Chinese users who use VPNs aren't technologically savvy and just want to read the NYTimes or watch Netflix. Now any embedded ad or tracker can rat them out[1]. We shouldn't ask them to jump through 15 hoops or deal with the the slowness of Tor. A VPN offers a very good compromise of ease vs. security for casual users.

[1]: https://webrtchacks.com/dear-ny-times/

Re: “We are considering adding an extension to restrict the use of WebRTC”

#155

Chrome users, look here: https://chrome.google.com/webstore/detail/webrtc-block/nphkk... or https://chrome.google.com/webstore/detail/webrtc-leak-preven...

New official Chrome extension to control this: https://goo.gl/74pT1m

Re: “We are considering adding an extension to restrict the use of WebRTC”

#156

Earlier quoted context omitted.

As someone who works on ad networks, I agree. While they put a lot of work into the backend stack, the frontend is usually written in the worst possible way. Tons of document.write, loading dozens of more tags, everyone has their own copy of jquery, etc. The industry just doesn't have any technical leadership in the governing bodies so there's no accountability or any expertise to check that the networks are built ri…

Ads are blamed for bloated pages, slow load times, JavaScript errors flooding console.log, and mixed content HTTP/HTTPS problems. I'm surprised that ad networks are not super optimized. For programmatic advertising, wouldn't serving ads faster allow for better/more/longer ad views?

Yea our network has put a lot of work into what actually runs in the browser for this exact reason.

However most networks go for the volume game so it just isn't that important to focus on JS performance. When you can spend time on jamming more expanding units and video into an ad that for the most part still works, that's better ROI than trying to optimize. Things are finally changing now with adblock and mobile usage but there are lots of long-tail shady networks who aren't legit with business practices in the first place (let alone dev) and the big companies just don't care because they're already big and engineering is a committee based process. Part of it is also the fact that there's no accountability in the industry, especially with tech.

I've been pushing for a technical certification process for ad networks (along with data/privacy handling) but it's a long road and won't happen anytime soon.

Re: “We are considering adding an extension to restrict the use of WebRTC”

#157

Earlier quoted context omitted.

Because it's an ad network and a script tag is how you pull the creative into the page. The whole point of using an ad network is that you are letting a 3rd party handle the management of your inventory, the ad creative is unknown until when the call is made.

Gee, that sounds like a brilliant idea. I can't think of anything that could go wrong with this scheme. (And yes, I know, this battle was lost in 1996 or thereabouts.)

It just isn't practical once there were millions of websites that you would negotiate media buys with them individually and send them some image assets or text ads that they would then have to host as a 1st party.

You also have to factor in all the things ad servers are designed to do like control the number of impressions shown, track views, clicks, and interactions, as well as allow advertisers to rotate new creative in on-the-fly.

Re: “We are considering adding an extension to restrict the use of WebRTC”

#158
post #86

Earlier quoted context omitted.

Privacy is not an absolute to be maximized at all costs. Do you have blacked out windows, or do you concede that the practical day-to-day infringement of your privacy is so minuscule and so easily mitigated by window shades that it's not worth the trade-off?

no, but I have windows with curtains on the inside. Not the outside. The distinction is both important, and blatantly obvious. Privacy control must remain with the one whose privacy is at stake.

And sometimes you have these curtains open? But what about privacy? Do you agree that sometimes people being able to look into your living room is not a big deal, even if it decreases your privacy by some definition? Great, then you agree that maximizing privacy at all costs isn't your or people's tradeoff point. Same with WebRTC - your internal network's IP is not the kind of privacy most people care about, nor should they.

That said, WebRTC from behind a VPN exposing your personal IP is a bit different. That's kind of like a light you installed rendering your curtains translucent. I'm not sure if it's the curtain's fault, or the light's, but it's certainly not what anyone had expected!

Given that OpenVPN somehow works in a way that doesn't expose your personal IP [1], I'd blame the VPN providers for saying that their VPN anonymizes web traffic when it actually doesn't.

1. https://tlog.anfedorov.com/vpns-webrtc

Re: “We are considering adding an extension to restrict the use of WebRTC”

#159
post #9

I don't understand why a peer-to-peer network connection is different from Ajax. Browsers don't require user approval for 3rd-party XMLHttpRequest connections. WebSockets are even more permissive. Why is WebRTC being singled out here? If I were a conspiracy-minded person (I'm not), I'd have to wonder if this was some kind of corporate-driven attempt to suppress peer-to-peer networks. In fact, I do think this is being…

But they should. Most mal-ads are from third party connections. Layers and layers of junk javascript all come from third party connections.

Web developers have been shown to be incapable of acting maturely (see http://blog.lmorchard.com/2015/07/22/the-verge-web-sucks/). They should be locked down until they can grow up.

Post reply on HN