New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to block websockets #956

Closed
Aranjedeath opened this Issue Nov 21, 2015 · 13 comments

Comments

Projects
None yet
6 participants
@Aranjedeath

Aranjedeath commented Nov 21, 2015

(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

This comment has been minimized.

Show comment
Hide comment
Owner

gorhill commented Nov 21, 2015

@gorhill gorhill added the browser bug label Nov 21, 2015

@gorhill gorhill closed this Nov 21, 2015

@gorhill

This comment has been minimized.

Show comment
Hide comment
@gorhill

gorhill Nov 21, 2015

Owner

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

Owner

gorhill commented Nov 21, 2015

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

@Aranjedeath

This comment has been minimized.

Show comment
Hide comment
@Aranjedeath

Aranjedeath Nov 21, 2015

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

Aranjedeath commented Nov 21, 2015

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

@gorhill

This comment has been minimized.

Show comment
Hide comment
@gorhill

gorhill Apr 20, 2016

Owner

Fixed with 2d26d1d.

Owner

gorhill commented Apr 20, 2016

Fixed with 2d26d1d.

gorhill added a commit that referenced this issue Apr 21, 2016

gorhill added a commit that referenced this issue Apr 21, 2016

gorhill added a commit that referenced this issue Apr 21, 2016

@fuzzyroddis

This comment has been minimized.

Show comment
Hide comment
@fuzzyroddis

fuzzyroddis Apr 24, 2016

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

fuzzyroddis commented Apr 24, 2016

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

@dungsaga

This comment has been minimized.

Show comment
Hide comment
@dungsaga

dungsaga Apr 26, 2016

@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 ?

dungsaga commented Apr 26, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@gorhill

gorhill Apr 26, 2016

Owner

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.

Owner

gorhill commented Apr 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@joepie91

joepie91 Apr 26, 2016

@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.

joepie91 commented Apr 26, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@gorhill

gorhill Apr 26, 2016

Owner

Other performance-critical libraries like Bluebird do something similar.

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

Owner

gorhill commented Apr 26, 2016

Other performance-critical libraries like Bluebird do something similar.

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

gorhill added a commit that referenced this issue Apr 26, 2016

@dungsaga

This comment has been minimized.

Show comment
Hide comment
@dungsaga

dungsaga Apr 27, 2016

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.

dungsaga commented Apr 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gorhill

gorhill Apr 27, 2016

Owner

we should

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

Owner

gorhill commented Apr 27, 2016

we should

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

bountyx pushed a commit to apozy/cortado that referenced this issue Mar 2, 2017

@Ryan-Goldstein

This comment has been minimized.

Show comment
Hide comment
@Ryan-Goldstein

Ryan-Goldstein commented Mar 3, 2017

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

@dungsaga

This comment has been minimized.

Show comment
Hide comment
@dungsaga

dungsaga Mar 7, 2017

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

dungsaga commented Mar 7, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment