
Loading…
Option to block WebRTC IP calls #624
Like the article says, those requests are not observable currently by the browsers' API. I confirm this when stepping through the code in Firefox.
Curious on what @chrisaljoudi is thinking here..
In addition to NoScript, uBlock also does prevent it by the blocking inline-scripting.
Note: If scripts are allowed in noscript, local IP is revealed.
uBlock does prevent it by the blocking inline-scripting
The behavior the article describes doesn't require inline scripting. Even if µBlock blocks inline scripting (I don't know why you mention this), it wouldn't prevent the IP address from being "revealed". Demonstrably, it doesn't. The page always might just have:
<script src = "homepage.js"></script>NoScript might be able to do it by blocking out the script completely. What are you suggesting µBlock does/should do?
@harshanvn what I mean is: while one might be able to configure µBlock to end up blocking the scripts that happen to do this, I'm not sure I get how that can be done programmatically to prevent the IP address reveal itself.
Until extensions can observe those requests to STUN servers specifically and block them, there's no meaningful way to identify and block scripts that are "going to" do this.
The behavior the article describes doesn't require inline scripting. Even if µBlock blocks inline scripting (I don't know why you mention this)
Yes, the article does not say about inline-scripting. It simply says NoScript was the only extension, which protects from revealing the ip address. However, what i found in my testing was noscript will fail to protect the identity if the scripts were allowed to execute.
Until extensions can observe those requests to STUN servers specifically and block them, there's no meaningful way to identify and block scripts that are "going to" do this.
Exactly, until they expose through some API, not sure if there is anything for extensions can/might do.
And what ever the way we have currently have (i.e., inline script blocking) is the only way one can protect themselves, unless one change the flags in their browser..
@harshanvn Right, NoScript isn't doing anything special about those WebRTC requests invoked by the script. NoScript disables the script, which means the script as a whole never gets to execute, regardless of what it does.
There's nothing special NoScript is doing, and there's nothing special µBlock can do that I can think of.
We're agreed that certain configurations of NoScript and/or µBlock will cause the issue to seemingly "not happen" — the ultimate generalization of this solution is completely disabling JavaScript.
I still think it's important to note
Disabling inline scripting does not solve the issue. It stops the demo page from working, but only because the demo page has the JavaScript inline. If they simply moved the JS to a file and did:
<script src = "someProgram.js"></script>that won't (and shouldn't) be affected by disabling inline scripting.
If we're on the same page and everybody's okay with understanding why this is not currently possible, I'll close the issue in a bit.
Yup, I am on the same page.
It would be any way to add an option to avoid to show our IP because of WebRTC? In this link is described the problem:
http://www.ghacks.net/2015/01/27/sites-may-detect-the-local-ip-address-in-browsers-supporting-webrtc/
"So how does it work?
WebRTC allows requests to be made to STUN servers (Session Traversal Utilities for NAT) which return local and public IP addresses for the system that is used by the user.
The results can be accessed using JavaScript which means that the only requirements for this to work are WebRTC support in the browser and JavaScript.
Protection
Ad-blockers such as Adblock Plus or Ghostery don't block these requests as they are made outside of the "normal XMLHttpRequest procedure".
The only extensions that block these look ups are JavaScript blocking extensions such as NoScript for Firefox. It is naturally also possible to disable JavaScript to prevent this from happening but this renders many websites unusable as well".