Comment by afavour
6 days ago
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.
Today there's no way to disable it, I searched through my Firefox Mobile settings. So I'd say it's for very "power" users.
And why enable it by default, why not disable by default?
Also, sibling comments say iOS is already asking for the permission, why not just copy it?
4 replies →
Why not? How is this different than, say, location access, or microphone access?
I want to be able to configure this per web site, and a permission prompt is a better interface than having an allow/deny list hidden in settings.
4 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?
It's only "profitable" if people don't bounce at being asked to trust a random news article, or something-embarassing.com, with their personal information. Same as why native Android apps don't just ask for every single permission. People in general do care about their security, they just lack tools to effectively protect it.
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.
You would because there'll be context:
1- You'd be in a page where you'll be enrolling your YubiKey or WebAuthn device. You'll be having your key at hand, or recently plugged in.
2- Your device's LED would be flashing, and you'll be pressing to the button on your device.
3- The warning will pop-up at that moment, asking that question to you. This means the website probably querying for something like the serial number of your key, which increases the security, but reduces your privacy.
With the context at hand, you'd understand that instantly, because the place you are and the thing you're doing perfectly completes the picture, and you're in control of every step during the procedure.
4 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.
> That's asshole behavior, and worth naming, shaming, and ostracizing over.
These exploits are being developed, distributed and orchestrated by Meta. The ”millions of websites” are just hummus recipe content farms using their ad SDKs, and are downstream Zuck in every meaningful interpretation of the term.
Meta has been named and shamed for decades. Shame only works in a society where bad actors are punished by the masses of people that constitute Meta’s products. Doesn’t mean we should stop, only that it’s not enough.
More than that, talking about TURN or WebRTC is really missing the issue. If you lock everything down so that no one can do anything you wouldn't want a malicious actor to be able to do, then no one can do anything.
The real issue is, why are we putting up with having these apps on our devices? Why do we have laws that prohibit you from e.g. using a third party app from a trusted party or with published source code in order to access the Facebook service, instead of the untrustworthy official app which is evidently actual malware?
4 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.
There are already permissions dialogs for using the camera/microphone. I don't think it'd be absurd to implicitly grant WebRTC permissions alongside that.
The nessage only makes sense when the remote ist localhost
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.
Pardon my ignorance, but modern browsers won't even load assets or iframes over plain http within an SSL page. So under normal circumstances you cannot open so much as an iframe to "localhost" from an https url unless you've configured https locally. Regardless of crossdomain perms. Wouldn't you want to require a special security permission from an app that was trying to setup a local server, AND require confirmation from a browser that was trying to connect to a local server?
1 reply →
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.