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

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

bugzilla.mozilla.org

Post reply on HN
Print view View original

141–150 of 159 posts

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

#141

Post by jnbiche »

mikeash wrote: post #135
lallysingh wrote: post #111

Earlier quoted context omitted.

Because IP addresses feel private. Even though you send one with every packet. Even though the extra one sent by webrtc is the one behind your NAT, and probably just 192.168.[0,1].

They can actually be private. What if you set up a proxy or a VPN with the express purpose of masking your real IP address, and then WebRTC barfs it out on demand anyway?

Again, WebRTC does not "barf" out your real IP in a VPN situation -- it barfs out the VPN's internal IP, which is meaningless to anyone except for the VPN's operator (and they have that data anyway).

Your actual, ISP-assigned IP remains hidden to any site you visit.

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

#142

Post by cpeterso »

manigandham wrote: post #128
GrinningFool wrote: post #124

Earlier quoted context omitted.

> I have nothing but contempt for the developers that are writing these JS I have nothing but contempt for the companies that accept advertising from untrusted third parties who can offer no assurance as to the security or even the content of the code their platforms allow to run on client browsers. That doesn't even get into the tracking that the advertising platforms themselves have access to. Host your advertising…

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?

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

#143

Post by mikeash »

jnbiche wrote: post #141
mikeash wrote: post #135

Earlier quoted context omitted.

They can actually be private. What if you set up a proxy or a VPN with the express purpose of masking your real IP address, and then WebRTC barfs it out on demand anyway?

Again, WebRTC does not "barf" out your real IP in a VPN situation -- it barfs out the VPN's internal IP, which is meaningless to anyone except for the VPN's operator (and they have that data anyway). Your actual, ISP-assigned IP remains hidden to any site you visit.

I thought it would provide every IP address held by the system, which would include both the internal VPN IP address and your actual ISP-provided IP address.

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

#144

Post by bsder »

madeofpalk wrote: post #56
kuschku wrote: 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/

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…

> The WebRTC 'tracking' was from a script from an ad network[1] used by at least Ars Technica and The Washington Post.

And then they wonder why we run AdBlock.

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

#145

Post by calbear81 »

mikeash wrote: post #134
madeofpalk wrote: post #56

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…

Why are you even running scripts from a third party on your own site? If the ad is a static image, use an tag. If it's text, show the text. If it's a video, use . If they want to run custom code, tell them to get lost. Yeah, it's ultimately the ad networks' fault, but what did you expect?

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.

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

#146

Post by makomk »

MichaelGG wrote: post #122
jnbiche wrote: post #74

Earlier quoted context omitted.

No, it's not rare. This is something all peer-to-peer networks running over IPv4 must do. WebRTC video, audio, or data wouldn't work without this.

Things worked fine before ICE. In fact, stuff like Bittorrent still works fine. If they were truly concerned with connectivity, they'd use upnp. But since that wasn't a standard from a friendly body, they added this ICE hack to try to make things work.

I don't think upnp is actually an adequate replacement for this even on routers that support it, because many of the older ones don't support NAT hairpinning so even if you open a port on the public IP address using upnp other nodes on the LAN can't connect to it.

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

#147

Post by CamperBob2 »

calbear81 wrote: post #145
mikeash wrote: post #134

Earlier quoted context omitted.

Why are you even running scripts from a third party on your own site? If the ad is a static image, use an tag. If it's text, show the text. If it's a video, use . If they want to run custom code, tell them to get lost. Yeah, it's ultimately the ad networks' fault, but what did you expect?

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

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

#148

Post by madeofpalk »

GrinningFool wrote: post #124
madeofpalk wrote: post #56

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…

> I have nothing but contempt for the developers that are writing these JS I have nothing but contempt for the companies that accept advertising from untrusted third parties who can offer no assurance as to the security or even the content of the code their platforms allow to run on client browsers. That doesn't even get into the tracking that the advertising platforms themselves have access to. Host your advertising…

I'm not a fan of it, nor all the variations of invasive ads that are sold[1]. I get the sentiment of what you're saying, but reality is a bit more nuanced than that, and there's a lot of legacy and business reasons why it happens.

Using ad exchanges means that you always have ads available to make money from. When our ads team doesn't sell an ad directly, it'll go out to the ad exchange and get traded algorithmically.

If you're going to use display ads, you have little choice but to use an ad exchange, and no ad exchange is set up to not have content run from a third party - they simple haven't or don't care about the disadvantages that you or I see from running third party content. That industry just isn't as 'progressive' or modern.

Thankfully though, media and publishing companies (or at least the one I work at) are starting to become more away of the problems of relying on display advertising, and are starting to rely on them less and use other forms such as sponsorship deals or video ads[2]

[1]: Like this obnoxious wallpaper ad http://i.imgur.com/IPVAVwx.jpg although this is actually one of the better ones. [2]: A 'new' tech is 'server side ad insertion, where the video is inserted into the video stream on demand on the server. Pretty cool stuff https://www.brightcove.com/en/once

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

#149

Post by madeofpalk »

mikeash wrote: post #134
madeofpalk wrote: post #56

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…

Why are you even running scripts from a third party on your own site? If the ad is a static image, use an tag. If it's text, show the text. If it's a video, use . If they want to run custom code, tell them to get lost. Yeah, it's ultimately the ad networks' fault, but what did you expect?

The way it usually works (or at does at least for 'us', at Australia's largest media orgs) is we have our own ads library, we'll communicate with our trusted ads network, and it'll find an ad 'provider' who might have about 10 possible ads for that spot. We'll insert an iFrame into the page and then insert their JS into the iFrame, which will then load the one ad to display.

This way it's a little bit more than just dumping a random script into the body. However, I don't do much with ad serving so I'm not sure exactly what there is technically to curb the iFrame interacting with the parent site (apart from extra console.log statements)

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

#150

Post by madeofpalk »

CamperBob2 wrote: post #147
calbear81 wrote: post #145

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

Usually the script (and ad) is in an iFrame, so that makes it slightly better.
Post reply on HN