Unable to block websockets

[Aranjedeath]

(ublock origin 1.3.3, chrome 46.0.2490.86, custom blocklists, otherwise default settings)

Hi. I'm trying to craft a rule to block a websocket connection. I don't appear to be able to do so.
Putting even something terrible like |ws:// in a block list does not appear to work. Is this because ALL websockets are considered behind-the-scene connections and thus in the default whitelist?

I have also tried removing that line from the default whitelist, and it still fails to block the connection.

I enabled advanced user mode, which also did not appear to help.

There is an advert network (rev defender) which uses this technique. When the other ads on the page fail to display (as they are wont to do), it forms a websocket connection, over which it delivers the ads as a data: url to be written into the page. Blocking websockets generally (see above), and the domain the connection is made to, does not appear to work.

For a good example of this behavior, try any page on opensubtitles.org.

Is there any guidance you can provide, or are we SOL for blocking this technique?

[gorhill]

Browser bug: https://code.google.com/p/chromium/issues/detail?id=129353.

[gorhill]

Blocking inline script does get rid of the ad, if whatever side effects is acceptable to you.

[Aranjedeath]

Oh, okay. I'll star+hope for a fix. Thanks.

[gorhill]

Fixed with 2d26d1d.

[fuzzyroddis]

@gorhill thanks for fixing this, Did Chrome fix chrome.webRequest.onBeforeRequest?

[dungsaga]

@gorhill I appreciate your work here, but I have a question: why did you use stringified code in a602808 ? You choose to lose all the syntax checking of the JS compiler in exchange for a bit faster code ?

[gorhill]

You choose to lose all the syntax checking of the JS compiler in exchange for a bit faster code ?

Look at the latest version, the syntax checking is done in https://github.com/gorhill/uBlock/blob/master/platform/chromium/websocket.js. For the particular point "a bit faster", I don't know how much faster this was, what is 100% sure though, is this is needless overhead, one which can be avoided -- javascript which won't have to be executed needlessly in the content script world.

[joepie91]

@dungsaga Code generation (by which I mean running code without the context in which it was defined, eg. through stringification) can yield significant speed benefits in JS in some cases, although it's definitely something you'd have to measure on a per-case basis.

Other performance-critical libraries like Bluebird do something similar.

[gorhill]

Other performance-critical libraries like Bluebird do something similar.

I like their multi-lines solution, I think I will adopt it.

[dungsaga]

The multi-line string style (like Bluebird) looks much cleaner.
But I'm still think the speed benefit is significant only if we generate code multiple times. In that case, we should generate code once and store the stringified function somewhere.

[gorhill]

we should

Try it. I will accept a pull request if you actually implement your idea of how it should be made.

[Ryan-Goldstein]

FYI, this has been fixed starting in Chrome 58: https://bugs.chromium.org/p/chromium/issues/detail?id=129353#c87

[dungsaga]

It's great. We can say goodbye to uBlock Origin Extra soon.