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 done in good faith (even though I strongly disagree), but other users will not be so understanding.
Edit: s/advertiser-driven/corporate-driven I think there are a lot of big companies, particularly social media, that have a huge vested interest in suppressing web-based peer-to-peer networks. Not claiming that's what's happening here, but the threat posed by WebRTC to those companies is very real. At present, a peer-to-peer Twitter would not be impossible to pull off technically with WebRTC, a DHT, and a modest number of STUN servers. The hard part is convincing users it's in their best interest to switch, but if that could be accomplished...
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).
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?
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)
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.
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.
> 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.
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
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.
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.
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.
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?
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.
> 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 hypotheses and probabilities. Who are "they" and what do you think they are doing?
If adtech companies cared whether you're behind a VPN, they would make or buy a list of IP's that are provide VPN services and match that list. That's a ton easier than implementing a STUN server that scales to handle traffic from every single person who views one of their ads.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
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.
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.
>> 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.
Note: this is a simplified explanation. Some details are glossed-over/wrong. But it will give you the basic idea. In order for someone to be able to talk to your machine they need to know your IP address. In general, this if fine because you can just tell people your IP address. However if you are on an internal LAN then you have the same external IP address as everybody else on the LAN. There needs to be a way to route packets to you.
A P2P application needs to have some way of telling the outside world, "If you want to send packets to me, this is how to do it". Of course, LANs are designed to stop people from being able to randomly send packets from outside the LAN to machines inside the LAN for obvious security reasons. So if you do this, then you are compromising the security of your LAN to a certain degree.
As I said, P2P apps need the ability to advertise how to connect to you or else you can only connect outwards. In other words, if it were a telephone, you could make outgoing calls, but couldn't receive incoming calls because nobody knows where you are. So when you start up Skype or Bittorrent, etc, it usually uses some tricks to figure out how people can contact you and advertises it.
The problem with WebRTC is not so much that it has this capability -- it needs it. The problem is that it is accessible remotely and doesn't ask for permission. You can go to a website that will jam some javascript at you that gets this information.
You can't even turn it off in the case that you don't want to use WebRTC. Requests to change the functionality to prompt the user (or at least have an option to prompt the user) when this functionality is used has been turned down. Not a lot of coherent reasoning has been given (as far as I can tell), but I imagine that the implementation is difficult and they don't think the majority of users will care.
I suppose as a middle-ground they have offered this plugin. I have my own strongly held beliefs on this topic (which may be evident from what I wrote), but hopefully this is neutral enough that you can understand the issue, do some reading and form your own opinion.
Considering your emphasis, that's a bold claim. Simple to disprove with a single counter-example: Bittorrent does not communicate your internal IP to do its job
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.
As someone who's implemented a P2P feature for an application: UPnP works great... if you have a router that supports it. Many in the wild do not. If yours doesn't, you have to manually port forward, which, even disregarding the newbie user issue, isn't possible if you're connected to someone else's network. Otherwise, as I assume you know, you can only initiate connections, not receive them, which means you can't talk to anyone with the same limitation - which might not be fatal to your BitTorrent download, albeit limiting your speed, but kinda sucks in something like a one-on-one video chat or game session.
AFAIK, all major video chat applications use some variant of STUN, on which ICE is based, along with some proxying mechanism for users who truly can't connect directly to each other, which corresponds to the rest of ICE.
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.
Advantages are better chance of connection success for a multihomed device and finding more direct connections (e.g. if you are in the same network as your peer, a direct connection likely is quicker than one which has to go through your internet gateway, and can be established more reliably if you are behind NAT towards the internet)
The recent moves to turn the browser into its own OS are worrying. The problem I see is that no one seems to care. Its full steam ahead and its only later do we realize that these new feature and standards are trivial to abuse. I really wish there was some kind of web mission statement on where browsers are going instead of this kitchen sink approach.
I have no idea what the W3C is thinking. I don't think even the W3C knows what its thinking. Its just being reactionary; trying to turn HTML5 into a "flash killer" and shoving feature after feature into the spec. I don't want to piss on progress, but I think privacy and security concerns get a backseat with W3C members, especially Google, whose very existence is dependent on finding information about users to sell to advertisers. Soon we'll need sandboxing and privacy apps to wrap our browsers in. I really hope Mozilla leads the way to pushing back on this recent mad push of thoughtless progress. A more moderate approach would be very much welcome and having more "off by default" options for easily abused features like P2P in the browser, which is what webrtc really is, makes sense.
Right now I had no idea what my browser is capable of. Can it silently turn on my camera and microphone? Probably. Can it make all sorts of crazy p2p connections to various servers/clients silently? Probably. Its all a little scary.
This situation will become 10x worse when WebAssembly is available and everybody can bypass the usual browser features by uploading their own DRMed/obscured version of freetype. I seriously cannot think of a feature more pathological to the open web.
I normally rely on Hanlon's razor and assume this is the work of a bunch of short-sighted nerds that are only looking at the fun-and-shiny features. In light of stuff like BULLRUN and the methods described in PHK's amazing "Operation Orchestra"[1], I am forced to wonder who is pushing this crap - because someone is obviously trying to create a digital imprimatur[2].
People do care about this stuff. Maybe not enough people, and maybe not the right people to do anything about it. But there are people right here on HN who do care about this stuff.
uBlock is an adblocker, uMatrix has finely grained matrix controls for which http requests are even allowed to go through and requires tuning for most sites. I like having both :)
This addon does as you suggest but with a simple click as opposed to having to go into about:config. Better if you think you might use webrtc from time to time.
I can actually see WebRTC becoming very useful... I actually miss the days where the likes of IRC, AOL and Yahoo group chats were more common... I wouldn't even know where to begin if I just wanted to chat with random people who are relatively local to me today.
Not just voice/video but text. That said, I'm not sure how useful the P2P aspects of text are, but being able to send files directly would be a nice ability.
What the fuck, this leaked your real IP behind VPN since January 2014 and this isn't fixed yet? This sure looks like a Heartbleed-tier high-priority security hole to me. How is this not bigger news?
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.
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 extreme edge case at best for them.
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.
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.
They leak the internal IP assigned to you by a VPN, which is not the same IP as the one seen by the websites you browse, nor is it the same as the IP assigned to you by your ISP.
Yes, the internal IP is leaked. But, also the IP assigned to you by your ISP is leaked (just tested with http://net.ipcalf.com/ & a vpn).
Though, I did test this on a college campus, so the network might just be leaking my internal ip, which ends up being my external ip also because of how they have the network setup. Which in hindsight is actually even scarier.
Approximately nobody outside the tech industry uses VPNs to hide their real IPs (the number of people using VPNs, period, is relatively tiny compared to the overall population of the internet); approximately everybody who uses the internet uses HTTPS.
By nobody you of course mean "nobody in the US". You're forgetting about the people of China and other states with widespread Internet censorship for whom this leak might not only be critical, but possibly life-threatening.
Most IPv6 implementations these days use a randomly-generated address which is periodically rotated to avoid this problem. Unfortunately, I'm pretty sure WebRTC renders this useless because it leaks all the IPv6 addresses, including link-local ones containing the hardware MAC address.
I hope Mozilla takes a quick decision on this based on its own principles.
This sentence saying "we are considering adding an extension" seems to be in stark contrast with the way Pocket was added into the main browser instead of being an ad or recommendation on the new tab page.
Why can't they just disable WebRTC by default and ask the user for permission like they do with location and so on, without revealing the IP before the user accepts the connection? Also, maybe the user could easily whitelist some connections/WebRTC IDs?
I'm not sure asking permission really helps. With things like location and video end users at least know what it means, and can make a somewhat educated choice. How do you properly ask an uneducated user the question "Should this site be allowed to open an arbitrary data connection?" - sites that want to will think of some vaguely plausible reason and users will click away.
How about not disabling it, but merely making use of it visible? (e.g. an icon or a notice in the addressbar)
It would discourage reputable sites from abusing it, because users would start asking questions why a news site wants a p2p/videoconference connection.
Because if you really need to be anonymous, it's not good enough to catch it being used after the fact.
Notifying the user after the fact sometimes works for things that are nuisances, but isn't good for privacy/security (imagine if your browser would execute unsandboxed JS and show you an icon each time it did it).
It wouldn't have to be after the fact. Firefox already has a little pop-up when sites want to get your location. The options are yes/no/never for this site.
If there's security concerns then it should prompt the user to allow/deny as well as whitelist the site for the future with a setting that lets people disable WebRTC easily (not in some obscure area).
Is there another problem besides leaking your IP address(es)? It sure sounds like that could pretty easily be solved by just sending hashes of the IP addresses along with the salt used to make the hashes. Then the receiver could compare it's own hash and know if it's on the same network.
I suppose there might be a problem with IPv4 since there are so few IP addresses, so you'd still be vulnerable to targeted attacks, but it would solve the ad network problem.
Am I missing something or just underestimating the usefulness of hashing?
Your network interface still has information about your regular internet connection, even when connected through a VPN. Local apps can query this information. Webrtc clients do this in order to assist setting up direct connections -- it doesn't know you're using a VPN, and will happily hand over info about your network interface to any site.
This only happens if you're using windows as administrator and your VPN runs directly on your box. If you're running OpenVPN on your router your real external IP won't leak.
If Mozilla is really concerned with leaking user information, then the extension should extend the use of WebRTC with a default to restrict the use of WebRTC
Plug-ins and extensions are, like, mostly non-existent entities, when released under circumstances without any actual demand for them. (compare/contrast: Java to AdBlock)
> But-but-but evil corporate overlords!
So what? They can do whatever they want on their core networks, so long as it doesn't bleed outside their edge.
If they restrict WebRTC then they restrict decentralization and that would move Mozilla out of the Freedom column and into the Fascism column with Microsoft.
The external IP is leaked, too! Clearly this peer to peer encrypted video protocol needs to be restricted, for the good of privacy and security, of course.
Sarcasm aside, what good can 192.168.1.4 possibly be to anyone?
Knowing the local area IP lets advertising companies and other "less liked" parties distinguish the devices behind your public IP, without having to use e.g. cookies. At the very least, it's another data source for helping with browser fingerprinting.
So we're willing to destroy the web's big shot at peer-to-peer networking out of concern that this adds one more data point for fingerprinting, out of dozens?
Let's keep the big picture in mind here, people. Peer-to-peer networking is the web's big chance to weaken these huge personal data-scarfing companies. Please let's not kill it while it's just starting to grow.
I simply stated facts, I did not say WebRTC should be dropped or restricted because of IP address leaks.
With that said, now let me express an opinion (not a fact): for every technological innovation there are downsides and upsides, and it's up to people to decide if the greatness makes up for the (potential) problems. With cell phones for instance, most people accept potentially having their location disclosed to the accuracy cell towers and triangulation allow, because it's super damn convenient to be able to place and receive calls and text from just about anywhere. Of course, there's a minority that is not comfortable with this and refuses to use cell phones or takes extra precautions.
Similarly, people may be willing to accept the problems of WebRTC because its applications are enough to make up for the disadvantages. People who don't accept will find ways to not use it. If the majority of users ends up blocking it, we can conclude that people don't want a peer-to-peer web, but a more sensible conclusion will be that people were not OK with that particular implementation of peer-to-peer networking, and a different implementation is in order, or that at least patches to the current implementation are needed.
> Peer-to-peer networking is the web's big chance to weaken these huge personal data-scarfing companies.
I think that most likely, these data-scarfing companies (and other parties) will learn to use WebRTC (as it is now) for nefarious purposes, before it hurts a tiny bit of their bottom line. I bet it's much easier and there is much more immediate monetary support for developing the pieces necessary to track users with WebRTC, than to implement an actual peer-to-peer application with it.
No, just make sure the web's big shot at peer-to-peer networking doesn't poke yet another hole in the already shabby privacy of today's average web user.
I won't even go into the debate of whether or not we want "the web" to be the support for the p2p network of the future.
> Peer-to-peer networking is the web's big chance to weaken these huge personal data-scarfing companies.
On the other hand, this particular problem is another ace in the hands of those huge personal data-scarfing companies.
> So we're willing to destroy the web's big shot at peer-to-peer networking
IPv6 with its built in true end-to-end connectivity just called and wants to have a word with you, but you were stuck behind some inferior IPv4 NAT blockade.
I'm pretty sure that ship has sailed. Users (and perhaps more important, companies) do, in fact, want web browsers to do everything. Even traditionally heavyweight applications like Microsoft Office and Adobe Photoshop are shifting to the web.
Whether that's a good idea or not is certainly open to debate, but pretending that it's not happening isn't the answer.
It's more of an abstraction layer over operating systems than an operating system. Crippling APIs (try opening a datagram socket. or send icmp pings). No gpu-compute, no shared-state multithreading.
It doesn't manage hardware or anything like that.
People use browsers as if they were an operating system. That does not make it one.
It's like calling a java virtual machine an operating system.
Good point re: VPN [0]. The example you point to is not a tracker, though.
Looks like the Tor bundle disabled WebRTC about two years ago [1] [2]. I think a VPN user would expect the WebRTC connection to be routed via a VPN, as well, but I'm still figuring out how those work, exactly :)
"Somewhat" is kind of important here. In practice you can easily just test 10 or so most common router ip addresses in under 5 seconds.
And probably get a 95% hit ratio:
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 <form> that makes modifications to their router settings. This is more like CSRF than XSS though.
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.
I think this is a legitimate question. If people are saying knowledge of specific computer addresses is harmful it's the same as saying IPv6 is harmful, which would be a shame.
I also understand the proxy / vpn IP leaking issue. But since firefox is self reporting here, surely it would be possible to have a plugin to mask the actual IP or report garbage for those who have privacy concerns? It's overkill to disable or lobotomize the whole feature because of that one use case.
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 done in good faith (even though I strongly disagree), but other users will not be so understanding.
Edit: s/advertiser-driven/corporate-driven I think there are a lot of big companies, particularly social media, that have a huge vested interest in suppressing web-based peer-to-peer networks. Not claiming that's what's happening here, but the threat posed by WebRTC to those companies is very real. At present, a peer-to-peer Twitter would not be impossible to pull off technically with WebRTC, a DHT, and a modest number of STUN servers. The hard part is convincing users it's in their best interest to switch, but if that could be accomplished...