Hacker News Reader

WebRTC is being singled out as it leaks user information that wasn't leaking before.

AFAIK, the conspiracy-minded people are claiming that this is a move by 'advertisers' to collect more user-identifying data.

Well, websockets introduced a massive new opportunity for advertisers to exfiltrate user data that wasn't even subject to the normal cross-site restrictions until recently in most browsers. But nobody proposed eliminating Websockets, or requiring explicit user approval for connections. Instead, they fixed the problem.

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

Doesn't matter. Privacy is not about right or wrong, it is about privacy.

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

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 developers that are writing these JS. I've lost count of all the JS errors they cause (currently I see a lot of `Can't find variable: _body`), or just errant console.log messages (one on every browser scroll or resize was fun).

[1]: Edit: Amusingly I found a developer arguing for this WebRTC-punching, who says he's from White Ops (whiteops.com) working on anti-bot tools https://github.com/EFForg/privacybadgerchrome/issues/431#iss...

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.

And this, everyone, is why using pay-per-view or pay-per-click ads online is so destructive.

> 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 yourself and I let it through with very little exception. If it comes from another server, it's blocked.

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

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.

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

They aren't written for the user experience, they're written by low-level techs usually (because the JS part isn't as "cool/exciting/important" as the backend part) to just get the ad on the page somehow.

It's probably the worst of the worst in JS engineering sadly.

Probably so... maybe if the browsers put limits as to the amount of JS content can go into a given iframe (including child frames) to say 80KB, that would cut a lot of it out. It would still allow for a LOT of code, but not nearly the kitchen sink + the kitchen.

Then again between Ghostery and uBlock, I don't see most of it.

Why are you even running scripts from a third party on your own site?

If the ad is a static image, use an <img> tag. If it's text, show the text. If it's a video, use <video>. 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.)

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

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.

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)

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

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.

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.

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

Those are about the Abmahnungen, no mention of honeypots.

To get the required log files, they have to seed the files themselves. No other (legal) way to do it.

Swarm information is not enough as it doesn't prove that any data has been transfered.

You could easily download a few chunks from the clients to verify that they are sharing copyrighted works without ever uploading anything to them.

Nothing to do with WebRTC but it's (allegedly) a tactic that has been used by a US-based LLC known as Prenda via torrents:

http://arstechnica.com/tech-policy/2013/06/pirate-bay-data-s...

Earlier this week, Prenda faced a new and serious allegation: that it had actually put some pornography on BitTorrent itself, intending for it to be downloaded so that it could start a campaign of lawsuits and threat letters.

The Pirate Bay gave the data to TorrentFreak, which says that the IP address 75.72.88.156, which uploaded some porn files that Prenda has litigated over, "was previously used by someone with access to John Steele’s GoDaddy account."

http://arstechnica.com/tech-policy/2015/07/pirate-bay-founde...

That is one (alleged) example. I was looking for proof of the widespread use of honeypots yAnonymous mentioned.

If we're talking about instances where "Courts usually believe their 'proof', no matter how bad it is," Prenda Law is not one I'd bring up.

http://arstechnica.com/tech-policy/2015/06/judge-finds-prend...

I'd expect the honey pots to require at least consent before incriminating someone. Successfully incriminating people based on an action that the "damaged" party forced them to do without even their consentiment is a bit too much to expect.

But then, I'm not completely insane. Laws often are.

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.

That's pure FUD. Regular HTTP can do all that now.

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.

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.

If a million people suddenly want to participate in a single hashtag, you necessarily also have a million devices able to contribute to the distribution of the content. It's far from intractable. It's bittorrent for tweets.

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.

> I don't understand why a peer-to-peer network connection is different from Ajax

Ajax is one-way

Hardly. One direction's "packet" size is just limited by URL encoding/length restrictions. :)

Look at it this way - if Tor (which is based on Firefox) allowed WebRTC by default, it would be useless for its intended privacy purpose.

TorBrowser might be a reskinned and customized Firefox, but the Tor network is not.

From my understanding of how this works that's mostly a consequence of the Tor browser trying to achieve network privacy and anonymity at the wrong layer.

The right way would be to route all the requests through Tor, not just those from the engine of the browser.

I used to be of this opinion, but [1] changed my mind.

The problem is that there's a huge potential to deanonymize the user at an exit node because of all sorts of traffic other than web browsing. Do all of your chat programs encrypt everything? How about your email client? What about every daemon on your system that accesses the Internet?

At the very least, all of these can be used to fingerprint you.

WebRTC is a great example of why the user-agent turns out to be the right level to think about anonymity over Tor.

[1]: http://www.wired.com/2014/10/anonymity-routers/

I agree that Tor is a special case, but who uses Tor without Tor Button, Tor Browser, or something similar? It's easy to disable WebRTC in those instances.

Regarding internal VPN IPs, I don't understand how this would help an attacker. If someone has broken into a VPN network and is in a position where they could make use of that data, then it's game over anyway. Otherwise, what do you want with an internal IP, besides fingerprinting?

By the way, fingerprinting no doubt is an issue, along with a dozen or so other JavaScript APIs that leak data. If you don't want to be fingerprinted, use something like NoScript. Advertisers can already uniquely identify you based on various other data leaked by JS, don't know why WebRTC has been singled out for this reason.

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.

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.