Comment by codedokode
5 days ago
So main application for WebRTC is de-anonymisation of users (for example getting their local IP address). Why it is not hidden behind permission I don't understand.
5 days ago
So main application for WebRTC is de-anonymisation of users (for example getting their local IP address). Why it is not hidden behind permission I don't understand.
The main application for WebRTC is peer to peer data transfer.
I think you can make the argument that it should be behind a permission prompt these days but it's difficult. What would the permission prompt actually say, in easy to understand layman's terms? "This web site would like to transfer data from your computer to another computer in a way that could potentially identify you"? How many users are going to be able to make an informed choice after reading that?
Let it show "Use WebRTC?".
If users don't understand, they click whatever. If the website really needs it to operate, it will explain why before requesting, just like apps do now.
Always aim for a little more knowledgeable users than you think they are.
And specifically, if you're on something-sensitive.com in a private browsing session, it would give you the choice of giving no optional permissions. That choice is better than no choice at all, especially in a world where Meta can be subpoenaed for this tracking data by actors who may be acting unconstitutionally without sufficient oversight.
That feels pretty useless. You might as well do what happens today: enable it by default and allow knowledgable power users to disable it. If it's disabled, show a message to the user explaining why it's needed.
10 replies →
Browser functionality needs a hard segmentation into disparate categories like "pages" and "apps". For example, Pages that you're merely intending to view don't need WebRTC (or really any sort of network access beyond the originating site, and even this is questionable). And you'd only give something App functionality if it was from a trustable source and the intent was to use it as general software. This would go a long way to solving the other fingerprinting security vulnerabilities, because Pages don't need to be using functionality like Canvas, USB, etc.
If it's more profitable for a page to be an app why would people make pages?
1 reply →
When enrolling Yubikeys and similar devices, Firefox sometimes warns "This website requires extra information about your security device which might affect your privacy. Do you want to give this information? Refusing might cause the process to fail."
You can use a similar language for WebRTC.
I wouldn't understand that. Is it getting a manufacturer address to block some devices? Does it use a key to encrypt something? Which "security device? /dev/urandom?
I see that non-technical users can be confused by too much information, but when you omit this even knowledgeable users can't make an informed decision.
5 replies →
TFA list tens of thousands of websites using WebRTC for deanonymization. How many websites using it for P2P data transfer can you list?
Any Jitsi deployment?
Let's be clear here. Meta/other sites are abusing the technology TURN/WebRTC for a purpose it was never intended for, way beyond the comfortable confines of innocent hackery, and we all know it.
That's asshole behavior, and worth naming, shaming, and ostracizing over.
6 replies →
What about "This website would like to connect to the Instagram App and may share your browsing history and other personal details."
Why should that message show up when I'm trying to make a video call in my browser? I'm just trying to call my nephew.
2 replies →
The website wants to connect to another computer|another app on your computer.
Most users probably will click "No" and this is a good choice.
>The website wants to connect to another computer|another app on your computer.
"website wants to connect to another computer" basically describes all websites. Do you really expect the average user to understand the difference? The exploit is also non-trivial either. SDP and TURN aren't privacy risks in and of themselves. They only pose risks when the server is set to localhost and with a cooperating app.
2 replies →
But that says nothing about the danger of identifying you.
> Most users probably will click "No"
Strong disagree. When I'm loading google.com is my computer not connecting to another computer? From a layman's perspective this is the basis of the internet doing what it does. Not to mention, the vast majority of users say yes to pretty much any permission prompt you put in front of them.
> The main application for WebRTC is peer to peer data transfer.
But not for the user.
The existing killer app for WebRTC is video chat without installing an app, which is huge.
Other P2P uses are very cool and interesting as well - abusing it for fingerprinting is just that, abusing a user-positive feature and twisting it for identification, just like a million other browser features.
You mean just like a million other "user-positive" browser features pushed by the biggest tracking company there is.
The technique doesn't actually rely on webrtc though, does it? Not showing up in the default view of chrome's network inspector obfuscates it a bit, but it's not like there aren't other ways to do what they're achieving here.
Because the decision makers don't care about privacy, they only want you to think that you have privacy, thus enabling even more spying. One solution is to not use the apps and websites from companies that are known to abuse WebRTC or something else.
This is not unique to WebRTC. The same result could be achieved by sending a http request to localhost. The only difference in this case is that using WebRTC doesn't log a http request
The browser could refuse to connect to localhost. I think there are browsers that refuse (i.e. to prevent attacking a router config interface).
I doubt anyone is running a browser on their router.
But still, you could do the same for stun, turn, sdp. Disallow local host.
1 reply →