Opened 4 years ago

Last modified 14 months ago

#4455 closed change

WebRTC circumvention — at Version 32

Reported by: kzar Assignee: kzar
Priority: P2 Milestone: Adblock-Plus-1.13.3-for-Chrome-Opera
Module: Platform Keywords:
Cc: sebastian, trev, mapx, ameshkov, fhd, greiner, fanboy, Lain_13, dzr156, SMed79, IsraeliAdblocker, Ross Blocked By: #5087, #5092
Blocking: Platform: Chrome
Ready: yes Confidential: no
Tester: Ross Verified working: yes
Review URL(s):

https://codereview.adblockplus.org/29401590/
https://codereview.adblockplus.org/29420555/

Description (last modified by kzar)

Background

Some websites have begun using WebRTC as a way to serve advertising. Neither Firefox nor Chrome allow these connections to be blocked with their extension APIs.

The AdGuard guys have found some example code in the wild, it appears to be using RTCPeerConnection specifically:

new (window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection)({
  iceServers: [{url: "stun:1755001826:443"}]
},{
  optional: [{RtpDataChannels: !0}]
});

It looks like Content Security Policies can't be used to block these connections and that in Chrome WebRTC can't be disabled at all!

Resources

What to change

Wrap RTCPeerConnection like we did for WebSocket.

Change History (33)

comment:1 Changed 4 years ago by trev

For reference, 1755001826 is another way of writing 104.155.51.226 - an IP address assigned to Google, presumably App Engine.

comment:2 Changed 4 years ago by trev

Ok, I looked a bit closer into the code in question. This code doesn't actually create a WebRTC connection - transmitting data over one would be a fairly complicated affair. It merely consults a STUN server which is usually being done to determine the host's external IP address. There is currently a known side-effect of deanonymizing users (bug 959893) but that doesn't seem to be what this script is after. Instead, it receives an IP address from the STUN server that doesn't belong to the client - and it uses this IP address to build the pop-up address, something like http://130.211.198.219/MzEyNzQ5MDYxMDk4LzMxMjc1MDQzNzc1OS8wcjRkZWI5bjky (the path here is merely two weirdly encoded random numbers). This doesn't happen for me in Firefox but their code is working in Chrome. So at the moment this contributes to significant obfuscation but blocking isn't too challenging.

This doesn't change the fact that connections to STUN servers should go through content policies and this was already proposed under https://bugzilla.mozilla.org/show_bug.cgi?id=1126187#c4 (not sure why they chose to discuss this in a bug that was resolved as duplicate). We might want to implement a patch for that.

comment:3 Changed 4 years ago by mapx

  • Cc fanboy added

comment:4 Changed 4 years ago by mapx

  • Cc Lain_13 added

comment:5 Changed 4 years ago by fanboy

New incidents reported on crackberry.com (Reported here: https://forums.lanik.us/viewtopic.php?p=111045#p111045)

So many Chrome Anti-adblock loopholes lately :(

comment:6 follow-up: Changed 4 years ago by mapx

it seems gorhill fixed it using the same CSP.
A lot of sites are migrating from websocket to webrtc trick.

comment:7 follow-up: Changed 4 years ago by fanboy

Maybe we should have a $webrtc filter option?

comment:8 in reply to: ↑ 6 Changed 4 years ago by kzar

Replying to mapx:

it seems gorhill fixed it using the same CSP.

So I just took a look at his code and unfortunately it's not as simple as adding another CSP. He's actually wrapping RTCPeerConnection to create a dummy WebSocket connection before opening the WebRTC connections. If the dummy WebSocket connection is blocked by the CSP the WebRTC connection won't be allowed either.

We could also probably wrap the WebRTC API like we're doing for the WebSocket API but it we'd have to be careful about it. I've not looked into this in more detail yet.

Replying to fanboy:

Maybe we should have a $webrtc filter option?

If WebRTC is an increasing privacy + circumvention problem like you guys suggest I wouldn't be against adding a webrtc request type. We could then add wrapper(s) for the WebRTC APIs which used that request type and in turn filters with $webrtc could be written.

Any opinion Wladimir / Sebastian?

comment:9 in reply to: ↑ 7 ; follow-up: Changed 4 years ago by mapx

Replying to fanboy:

Maybe we should have a $webrtc filter option?

why another option ? better keeping websocket for all this crap and will use the filters already in easylist.

however, the users are complaining why ABP is doing ...nothing (and ubo already patched it)
https://forums.lanik.us/viewtopic.php?p=111399#p111399

comment:10 in reply to: ↑ 9 Changed 4 years ago by kzar

Replying to mapx:

Replying to fanboy:

Maybe we should have a $webrtc filter option?

why another option ? better keeping websocket for all this crap and will use the filters already in easylist.

Well because webrtc connections are not the same as websocket connections. (Remember that with Firefox the extension API allows us to intercept websocket connections without the wrapper and hopefully Chrome will in the future too.)

comment:11 Changed 4 years ago by fanboy

So can we can temp fix for webrtc or something (anything to combat it). Waiting on X and Y won't help the enduser, all they see is ads and in-action.

comment:12 Changed 4 years ago by kzar

Well I need to check with Wladimir and Sebastian before beginning work to wrap the WebRTC APIs. (Since we will likely need to consider those connections as a new webrtc type core changes will be required.) It will probably be quite a bit of work and if we don't agree on an approach before I start it'll end up wasting a bunch of my time. I'll update the issue(s) when I've heard back from them about it.

comment:13 Changed 4 years ago by fanboy

From the current (growing) list of sites using the webrtc circumvention (seen from uBlock-Origin

britannica.com
businessnewsdaily.com
collegehumor.com
dorkly.com
investopedia.com
laptopmag.com
lifeandstylemag.com
mashable.com
newsarama.com
phonearena.com
space.com
theberry.com
thechive.com
thepoliticalinsider.com
tomsguide.com

comment:14 Changed 3 years ago by mapx

pm message:

webRTC ads (huge adoption)
Sent: Mon Feb 13, 2017 10:46 am	
From: dzr156	
To: mapx 

Hey mapx, 

recently we see huge adoption of webRTC ads in the top 5 websites in Israel, for example: 

mako.co.il
jpost.com
walla.co.il
bizportal.co.il
calcalist.co.il

You guys must do something with that, people uninstall Adblock or moving to ubo. And the guys from the company that provides this solution claims that the "ad blocking is dead". 

please keep me posted. 

thnks

comment:15 Changed 3 years ago by mapx

  • Cc dzr156 added

comment:16 Changed 3 years ago by kzar

I also received a similar PM, seems like this WebRTC circumvention is increasingly becoming a problem.

Wladimir / Sebastian what do you think to my earlier suggestion?

If WebRTC is an increasing privacy + circumvention problem like you guys suggest I
wouldn't be against adding a webrtc request type. We could then add wrapper(s) for the
WebRTC APIs which used that request type and in turn filters with $webrtc could be
written.

comment:17 Changed 3 years ago by sebastian

So you are talking about comment:8, where you suggest to wrap the Web RTC API, like we did for the WebSocket API, but with a different request type? IIRC, as we did that for WebSockets, it didn't take long until people discovered a way to bypass our wrapper, by initiating the connection from a document loaded through a data: URL, web workers and alike. Won't we have the same problem with Web RTC? Is it possible to leverage CSP to address that?

Also, is there any reason the webRequest API cannot intercept Web RTC connections, other than they just forgot to implement it like they did for WebSockets? It might be worth filing a Chromium bug.

Last edited 3 years ago by sebastian (previous) (diff)

comment:18 Changed 3 years ago by fanboy

Maybe we have a working around in ABP, until which Chromium can fix it. Chromium bugs tend to be slower to get fixed?

comment:19 Changed 3 years ago by sebastian

I'm not against implementing a workaround in Adblock Plus per se. But we should still bring that issue up to the Chromium team, so that they will hopefully lift the limitations on their end, so that we can eventually get rid of the workaround, since using the webRequest API would be more powerful, reliable, maintainable and efficient than any workaround we could implement.

comment:20 follow-up: Changed 3 years ago by fanboy

Not to push the point, but are we getting a fix or not?

comment:21 in reply to: ↑ 20 Changed 3 years ago by kzar

Replying to fanboy:

Not to push the point, but are we getting a fix or not?

I know this is an important issue for you guys, I see read all your replies here, the private messages and emails I receive about it. I want to start working on this when I have the time, but until then please be patient.

comment:22 Changed 3 years ago by dzr156

Guys, this issue starting to be very urgent. IMO - its putting ABP in a bad light.
Here in Israel, all the big sites (ynet.co.il, walla.co.il, mako.co.il) using webRTC, and the Heb list fourm is officially recommended on ubo (example: https://github.com/easylist/EasyListHebrew/issues/233)

Last edited 3 years ago by dzr156 (previous) (diff)

comment:23 Changed 3 years ago by kzar

  • Owner set to kzar

Time allowing I hope to start with this next week. I'll keep you all posted.

comment:24 Changed 3 years ago by mapx

  • Cc SMed79 added

comment:25 Changed 3 years ago by dzr156

Hi, just update - I find the Extension WebRTC Leak Prevent useful here. https://chrome.google.com/webstore/detail/webrtc-leak-prevent/eiadekoaikejlgdbkbdfeijglgfdalml
maybe we can take some piece of code from this.

comment:26 Changed 3 years ago by kzar

  • Description modified (diff)

comment:27 Changed 3 years ago by kzar

  • Blocked By 5087 added

comment:28 Changed 3 years ago by kzar

  • Description modified (diff)

comment:29 Changed 3 years ago by kzar

  • Blocked By 5092 added

Changed 3 years ago by kzar

comment:30 Changed 3 years ago by kzar

Good news, I finally got some time to work on this today! Better news this wasn't too hard, since a lot of the code and lessons learned wrapping WebSocket could be reused here. Even better news I have a (very rough) patch that seems to be working nicely.

The devil is in the details though, so I have some work to do to tidy up my patch and to test everything really does work correctly. I'll keep you posted, and in the mean time I've uploaded a teaser screenshot.

comment:31 Changed 3 years ago by mapx

  • Cc IsraeliAdblocker added

comment:32 Changed 3 years ago by kzar

  • Component changed from Unknown to Platform
  • Description modified (diff)
  • Priority changed from Unknown to P2
  • Ready set
  • Review URL(s) modified (diff)
  • Status changed from new to reviewing
Note: See TracTickets for help on using tickets.