Live data from Hacker News

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

bugzilla.mozilla.org

61–70 of 159 posts

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

#61
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…

a peer-to-peer Twitter would not be impossible

One of the key features of twitter, the global reach of hashtags, would be impossible. Twitter relies very heavily on being centralised. Anyone claiming to build a decentralised twitter needs a very careful numbers-based argument as to what the bandwidth consumption of being a popular user or hashtag might be.

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

#62

Earlier quoted context omitted.

Can they actually sue users when the copyright holders are the ones distributing the content?

In many European countries they can. They set up honey pots, log everything and then send costly C&Ds to thousands of people. Courts usually believe their "proof", no matter how bad it is. It's probably a billion dollar business by now.

Citation please.

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

#63

Earlier quoted context omitted.

For one, the way it's implemented now, it's only a matter of time until we see WebRTC torrent malware downloading copyrighted files to give copyright holders a reason to sue / C&D users. In a time where sharing an MP3 can cost thousands of dollars, having a protocol that can share data like that without the users' consent is crazy.

What is crazy is that “sharing an MP3 can cost thousands of dollars”, not any protocol.

Agreed, but it's not something that we can easily change.

Cases like the one I described could actually help by giving users plausible deniability, but that would just end with browser developers being pressured into disabling the feature.

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

#64
post #20
post #10

Earlier quoted context omitted.

Can you expand on this, please? How does it make it easier to XSS?

Well, I'm not sure about XSS, but imagine you know someone's home IP is: 192.168.1.10 Based on this, you can probably guess the router is 192.168.1.1 and maybe even have a clue about the vendor based on the IP assigning patterns. Then you can direct them to a page with an submitting POST that makes modifications to their router settings. This is more like CSRF than XSS though.

funny, of all the routers I used (all were provided by my ISP), their IP were 192.168.1.254

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

#65
post #10

Earlier quoted context omitted.

Can you expand on this, please? How does it make it easier to XSS?

It doesn't. All major browsers block connections to 192.168.XX.XX (and any other externally unroutable IP) from external (http on the Web, not localhost) web pages.

Just tested img and iframe and they work quite happily from the web to the local network.

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

#66
post #23

Earlier quoted context omitted.

The issue is that, for example, the New York Times actually used WebRTC to gather data for exactly that purpose. https://webrtchacks.com/dear-ny-times/

And by "exactly that purpose" you mean preventing ad fraud [1], right? They weren't using WebRTC to put you in a "VPN user" advertising segment. 1. https://www.reddit.com/r/netsec/comments/3dgwee/how_the_new_...

[deleted]

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

#67

Earlier quoted context omitted.

Although NYT shouldn't get off scott-free, I think it's worth pointing out that they probably had very little to do with this and more than likely had no idea about it. The WebRTC 'tracking' was from a script from an ad network[1] used by at least Ars Technica and The Washington Post. As someone who works on sites implementing display advertising using these sorts of networks, I have nothing but contempt for the deve…

There's quite a lot of case law that says that companies can be held responsible for their subcontractors. See e.g. Deepwater Horizon I am not a lawer. This is not legal advice.

Oh yes. I agree.

> Although NYT shouldn't get off scott-free

Legals aside, ultimately you're (where 'you' == 'the company') responsible for what ends up on your website.

What I'm saying that this is more nuanced in practice. If you look at the JS console on some sites I work on at my company, you could come to the conclusion that we're bad developers because of all the JS errors you would see. Unfortuantly, they're made by others and we (developers) get little choice in the matter.

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

#68
post #62

Earlier quoted context omitted.

In many European countries they can. They set up honey pots, log everything and then send costly C&Ds to thousands of people. Courts usually believe their "proof", no matter how bad it is. It's probably a billion dollar business by now.

Citation please.

>http://www.pcwelt.de/ratgeber/Die-Abmahnindustrie-Jeden-kann...

Estimates of 500,000 yearly C&Ds in Germany from 2011.

>http://www.wortfilter.de/news11Q1/news3945.html

C&D industry in Germany makes about 400 million a year.

Don't have numbers from other countries, but it's definitely a big business in Europe.

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

#69

Could somebody please explain whether it is a technical requirement to leak the internal IP address for this technology to succeed or, if not, what possible reasons could exist for this design decision?

It is a technical requirement, because the protocol attempts to connect over the local network if both peers are under the same NAT. The local IP is shared so that the peers can attempt to make a local connection.

I'd assume that this is a rather rare usecase in the world wide web, so why is it not disabled by default?

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

#70
post #29

I think the sensible solution (and this goes for anything where there's security or privacy concern like WebGL) is to block it by default however to prompt the user that the website wants to use WebRTC. The user can then choose to allow it for one time or to whitelist or blacklist the site.

> and this goes for anything where there's security or privacy concern

It would force web developers to think much harder about feature detection and being non-intrusive about their usage. If someone gets nagged to enable webrtc just to read some news article it might actually cause some head scratching.

cross domain cookies, local storage, video/audio playback (at least in background tabs), ...

You could even make an argument for cross-domain javascript.

Sometimes it's insane what crap shows up in µMatrix. More requests going to 3rd party sites than the actual content that I want to look at.

Post reply on HN