Blocking blob: request in uBO - xda-developers.com

[gotitbro]

I am facing an issue whereby blob: initiators are creating data:image/jpeg image ads on http://forum.xda-developers.com/. Can anyone tell me how to block these requests from being created and stopping these ads.

More info about this issue: https://forums.lanik.us/viewtopic.php?p=107575#p107575

Error URL: http://forum.xda-developers.com/android/apps-games/adguard-ad-blocker-doesnt-require-root-t2958895

Screenshot of the image ads created by the blob initiator: https://i.imgur.com/x270y3y.png
Screenshot of the network requests tab: https://i.imgur.com/wsjEfxH.png

Using Chrome 54 & uBO v1.9.16.

[gorhill]

blob:-based URI are only created through javascript using createObjectURL, and they are not network-based request, so they are not reported to uBO through its webRequest handler -- just like data:-based URI.

In the current case, the blob:-based URI is created using what is being pulled from a WebRTC connection. Thus, try:

xda-developers.com##script:inject(nowebrtc.js)

The site is nasty, in that it overrides console.log with noop functions. Usually uBO's nowebrtc.js scriptlet will output details of attempts to use WebRTC connections -- but the output to the console is foiled by scripts from that site. I modified uBO's scriptlet to ensure uBO can still output at the console to inform users of the attempts to use WebRTC.

[lewisje]

it overrides console.log with noop functions

What about console.info and friends? (Still, your approach, caching the native console.log ahead of time, is more robust than just picking a different console method.)

[gorhill]

What about console.info and friends?

I think they were all noop'ed, I hovered over a couple of them and Chromium showed function(){}.

[gotitbro]

@gorhill the WebRTC connections are now shown in the Console as: Document tried to create an RTCPeerConnection
Edit: Just realized it was already in the console just the functions weren't defined.

Will disabling WebRTC from uBlock settings also block these connections?

[lewisje]

In general that will do it, but I believe this scriptlet blocks the connections for the sites it's injected in, and then it logs a message saying that the site tried to make the connection.

[gotitbro]

You're right the scriptlet infact just does this, it logs the requests in the console.

I would like to ask what would be the adverse effects of completely blocking all websocket & WebRTC connections as a lot of sites seem to be using these for inserting ads escpecially websockets.

[uBlock-user]

^^ There's no such thing as adverse effects, at the worst, some parts of the website will go broke that's all. I'm using ||$websocket blanket blocking filter for websockets connections since months and I don't have to worry about a thing. All ws connections have done so far is pull those nasty clickbait ads for desperate website owners who think they can exploit chromium's webrequest api bug and force us to see those nasty ads, which will get patched soon as the patch has already been written and is being run through the developers as we speak.

In regards to completely blocking WebRTC, some apps which make use of webRTC connections won't run as expected, that's all, It's not the end of the world scenario, so don't bother yourself about it. Some web browsers based on Chromium can disable WebRTC completely, but chromium itself can't as there's no explicit setting provided. uBlock merely stops the leak of local IP address if a WebRTC connection was to be made by the browser itself, it doesn't disable WebRTC as you would think.

[lewisje]

WebSockets have legitimate uses for Web apps, when low latency between client and server is essential (main use-case is chat); it's an improvement over polling the server for new responses.

Still, I don't think it will do much harm to disable WebSockets entirely.

[uBlock-user]

Something like this - https://www.sanwebe.com/2013/05/chat-using-websocket-php-socket ? Well, I don't chat, so in the end it's up-to the user. Besides, you can always create an exception for a website which has a legitimate use of WebSockets.

[okiehsch]

Yes the live chat on a site like twitch.tv will not work with a blanket block
||$websocket but you can still watch the streams so no big deal if you don't chat.

[gotitbro]

All ws connections have done so far is pull those nasty clickbait ads for desperate website owners who think they can exploit chromium's webrequest api bug and force us to see those nasty ads

I completely agree with you on this part @uBlock-user , hope the bug is fixed soon atleast that will put an end to this.

[uBlock-user]

The site is nasty, in that it overrides console.log with noop functions. Usually uBO's nowebrtc.js scriptlet will output details of attempts to use WebRTC connections -- but the output to the console is foiled by scripts from that site. I modified uBO's scriptlet to ensure uBO can still output at the console to inform users of the attempts to use WebRTC.

@gorhill This is still happening at technobuffalo.com. Use technobuffalo.com##script:inject(nowebrtc.js), that will patch the WebRTC ads, but the console won't output anything about it. I suppose they found a way to foil the output again.

[gorhill]

Did you verify with chrome://webrtc-internals/ that no connection is created?

[uBlock-user]

Well, This is what happens at the console - https://i.gyazo.com/d0a666b363fd1d443cab32c7d48b10f6.png
and at chrome://webrtc-internals/ - https://i.gyazo.com/f506700682557a6000f9dd021797d6a4.png

I don't see any sponsored ads after I add that filter, on the technobuffalo.com page, but those logs in chrome://webrtc-internals say otherwise. That's what I conclude.