7 ms·

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 underst

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.

afavour 1y 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?
- codedokode 1y ago
  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.
  - afavour 1y ago
    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.
  - gruez 1y ago
    >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.
    - noduerme 1y ago
      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?
      - AnthonyMouse 1y ago
        HTTP isn't allowed on secure pages because the security of HTTP is known to be non-existent. WebRTC uses datagram TLS, which is approximately on par with HTTPS. The thing that's happening here isn't really a problem with WebRTC. Compare this to having an app on your phone that listens on an arbitrary port and spits out a unique tracking ID to anything that connects. Does it matter if the connection is made using HTTP or HTTPS or WebRTC or something else? Not really. The actual problem is that you installed malware on your phone.
- deepsun 1y ago
  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.
  - afavour 1y ago
    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.
    - deepsun 1y ago
      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?
      - n2h4 1y ago
        it does exist in `about:config`, which could be made as a UI setting instead: `media.peerconnectin.enabled`. on cromite[1], a hardened chromium fork, there is such a setting, both in the settings page, as well as when you click on the lock icon in the address bar. [1]: https://cromite.org https://cromite.org
        _Algernon_ 1y ago
        IIRC the standard mobile firefox version no longer makes about:config available. You need to be on a beta or nightly build to access it.
        cyberax 1y ago
        It is still enabled, just a bit hidden: chrome://geckoview/content/config.xhtml
- account42 1y ago
  TFA list tens of thousands of websites using WebRTC for deanonymization. How many websites using it for P2P data transfer can you list?
  - salawat 1y ago
    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.
    - AnthonyMouse 1y ago
      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?
      - salawat 1y ago
        What laws are you referring to other than Terms of Service which are entirely artificial constructs whisked into existence by service/platform providers? Which will, admittedly, be as draconian and onesided as the courts will allow. Agree on your first point at a practical level, but from the normative standpoint, it's unforgivable to cross those streams. At the point we're talking about with a service provider desperately wanting to leak IP info for marketability applications of an underlying dataset and using completely unrelated to the task at hand technical primitives to do it, you very clearly have the device doing something the end user doesn't want or intend. The problem is that FAANG have turned the concept of general computing on it's head by making every bloody handset a playground for the programmer with no easily grokkable interface to the user to curtail the worst behavior of technically savvy bad actors. A connection to a TURN server or use of parts of the RTC stack should explain to the user they are about to engage programming intended for real-time communication when it's happening not just once at the beginning when most users would just accept it and ignore it from then on. 10 or so TURN call making notifications in a context where synchronous RTC isn't involved should make it obvious that something nefarious is going on, and would actually give the user insight into what is running on the phone. Something modern devs seem to be allergic to, because it would cause them to have to confront the sketchiness of what they are implementing instead of being transparent with the principle of least surprise. Modern businesses though would crumble under such a model because they want to hide as much about what they are doing as possible from the customer base/competitors/regulators. >
- mindslight 1y ago
  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.
  - charcircuit 1y ago
    If it's more profitable for a page to be an app why would people make pages?
    - mindslight 1y ago
      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.
- hulitu 1y ago
  > The main application for WebRTC is peer to peer data transfer. But not for the user.
- n_plus_1_acc 1y ago
  What about "This website would like to connect to the Instagram App and may share your browsing history and other personal details."
  - iforgotpassword 1y ago
    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.
    - xmodem 1y ago
      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.
    - n_plus_1_acc 1y ago
      The nessage only makes sense when the remote ist localhost
- bayindirh 1y ago
  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.
  - 1718627440 1y ago
    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.
    - bayindirh 1y ago
      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.
      - 1718627440 1y ago
        > probably querying for ... Exactly. You need to infer that, it isn't stated directly. Same like you need to guess, that "Unable to connect" means connection refused, while "We can’t connect to the server at a" means the DNS request failed. Or does it mean no route to host? Network is unreachable? I would argue, that (sometimes) the user would be fine to distinguish whether he wants to approve something, but can't because both dialogs state the same wishy-washy message. Even non-technical users (might) eventually learn the proper terms, but they can't if they only get shown meaningless statements.
miloignis 1y ago
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.
- account42 1y ago
  You mean just like a million other "user-positive" browser features pushed by the biggest tracking company there is.
  - zdragnar 1y ago
    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.
NoahZuniga 1y ago
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
- codedokode 1y ago
  The browser could refuse to connect to localhost. I think there are browsers that refuse (i.e. to prevent attacking a router config interface).
  - iforgotpassword 1y ago
    I doubt anyone is running a browser on their router. But still, you could do the same for stun, turn, sdp. Disallow local host.
    - jeroenhd 1y ago
      That's literally what browsers have done (for STUN) and are working on (for TURN).
dominicrose 1y ago
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.

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.

afavour 1y 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?

codedokode 1y ago
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.
- afavour 1y ago
  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.
- gruez 1y ago
  >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.
  - noduerme 1y ago
    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?
    - AnthonyMouse 1y ago
      HTTP isn't allowed on secure pages because the security of HTTP is known to be non-existent. WebRTC uses datagram TLS, which is approximately on par with HTTPS. The thing that's happening here isn't really a problem with WebRTC. Compare this to having an app on your phone that listens on an arbitrary port and spits out a unique tracking ID to anything that connects. Does it matter if the connection is made using HTTP or HTTPS or WebRTC or something else? Not really. The actual problem is that you installed malware on your phone.
deepsun 1y ago
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.
- afavour 1y ago
  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.
  - deepsun 1y ago
    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?
    - n2h4 1y ago
      it does exist in `about:config`, which could be made as a UI setting instead: `media.peerconnectin.enabled`. on cromite[1], a hardened chromium fork, there is such a setting, both in the settings page, as well as when you click on the lock icon in the address bar. [1]: https://cromite.org https://cromite.org
      - _Algernon_ 1y ago
        IIRC the standard mobile firefox version no longer makes about:config available. You need to be on a beta or nightly build to access it.
        cyberax 1y ago
        It is still enabled, just a bit hidden: chrome://geckoview/content/config.xhtml
account42 1y ago
TFA list tens of thousands of websites using WebRTC for deanonymization. How many websites using it for P2P data transfer can you list?
- salawat 1y ago
  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.
  - AnthonyMouse 1y ago
    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?
    - salawat 1y ago
      What laws are you referring to other than Terms of Service which are entirely artificial constructs whisked into existence by service/platform providers? Which will, admittedly, be as draconian and onesided as the courts will allow. Agree on your first point at a practical level, but from the normative standpoint, it's unforgivable to cross those streams. At the point we're talking about with a service provider desperately wanting to leak IP info for marketability applications of an underlying dataset and using completely unrelated to the task at hand technical primitives to do it, you very clearly have the device doing something the end user doesn't want or intend. The problem is that FAANG have turned the concept of general computing on it's head by making every bloody handset a playground for the programmer with no easily grokkable interface to the user to curtail the worst behavior of technically savvy bad actors. A connection to a TURN server or use of parts of the RTC stack should explain to the user they are about to engage programming intended for real-time communication when it's happening not just once at the beginning when most users would just accept it and ignore it from then on. 10 or so TURN call making notifications in a context where synchronous RTC isn't involved should make it obvious that something nefarious is going on, and would actually give the user insight into what is running on the phone. Something modern devs seem to be allergic to, because it would cause them to have to confront the sketchiness of what they are implementing instead of being transparent with the principle of least surprise. Modern businesses though would crumble under such a model because they want to hide as much about what they are doing as possible from the customer base/competitors/regulators. >
mindslight 1y ago
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.
- charcircuit 1y ago
  If it's more profitable for a page to be an app why would people make pages?
  - mindslight 1y ago
    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.
hulitu 1y ago
> The main application for WebRTC is peer to peer data transfer. But not for the user.
n_plus_1_acc 1y ago
What about "This website would like to connect to the Instagram App and may share your browsing history and other personal details."
- iforgotpassword 1y ago
  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.
  - xmodem 1y ago
    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.
  - n_plus_1_acc 1y ago
    The nessage only makes sense when the remote ist localhost
bayindirh 1y ago
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.
- 1718627440 1y ago
  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.
  - bayindirh 1y ago
    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.
    - 1718627440 1y ago
      > probably querying for ... Exactly. You need to infer that, it isn't stated directly. Same like you need to guess, that "Unable to connect" means connection refused, while "We can’t connect to the server at a" means the DNS request failed. Or does it mean no route to host? Network is unreachable? I would argue, that (sometimes) the user would be fine to distinguish whether he wants to approve something, but can't because both dialogs state the same wishy-washy message. Even non-technical users (might) eventually learn the proper terms, but they can't if they only get shown meaningless statements.

miloignis 1y ago

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.

account42 1y ago
You mean just like a million other "user-positive" browser features pushed by the biggest tracking company there is.
- zdragnar 1y ago
  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.

NoahZuniga 1y ago

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

codedokode 1y ago
The browser could refuse to connect to localhost. I think there are browsers that refuse (i.e. to prevent attacking a router config interface).
- iforgotpassword 1y ago
  I doubt anyone is running a browser on their router. But still, you could do the same for stun, turn, sdp. Disallow local host.
  - jeroenhd 1y ago
    That's literally what browsers have done (for STUN) and are working on (for TURN).

dominicrose 1y ago

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.