
UBlock Origin 1.17.4 released - ronjouch
https://github.com/gorhill/uBlock/releases/tag/1.17.4
======
nathcd
One third-party filter list for uBO that I absolutely love is Web Annoyances
Ultralist:
[https://github.com/yourduskquibbles/webannoyances](https://github.com/yourduskquibbles/webannoyances),
for unsticking fixed headers, floating boxes, and elements like that.

I also use uBO for injecting my own styles on pages, like adding an absolute
timestamp to github:
[https://news.ycombinator.com/item?id=15743008](https://news.ycombinator.com/item?id=15743008)

~~~
mapl
I wonder if we see it on mobile platforms someday. Not having a norootneeded
adblocker on android or ios is very sad

~~~
yourduskquibble
> I wonder if we see it on mobile platforms someday. Not having a norootneeded
> adblocker on android or ios is very sad

Not sure if this is what you mean exactly, but uBlock Origin (as well as a lot
of other Firefox extensions) can be installed[1] on Firefox for Android.[2]

[1] [https://addons.mozilla.org/en-US/android/addon/ublock-
origin...](https://addons.mozilla.org/en-US/android/addon/ublock-origin/)

[2] [https://www.mozilla.org/en-
US/firefox/mobile/](https://www.mozilla.org/en-US/firefox/mobile/)

~~~
mapl
Thx! Didn't notice that Mozilla introduced Add-On support on their mobile
Browser. I guess extensions support for Chrome Mobile is not coming in the
near future, but who knows.

------
WeAreGoingIn
The first plugin I install on a freshly installed system with Firefox is uBO.
After that I harden the browser by changing stuff in about:config.

Chrome has never been an option for us with privacy in focus.

The guys behind uBO should get some price or something.

~~~
mamcx
One thing that block my migration to firefox is the zoom thing. In chrome I
can zoom pages and it stick (I need bigger fonts everywhere). Can't replicate
the same with safari or firefox.

~~~
kovach
In Firefox the zoom levels are saved per website. It has had that feature for
a long time. Or do you want to zoom once and have it zoomed on all websites
you visit?

~~~
mamcx
Yes, I wanna a option for all

------
sundar4344
UBlock Origin is more than an ad-blocker. Some usecases other than being ad-
blocker

1\. Hide Quora notification icon

2\. Hide YouTube notification icon

3\. Hide stackoverflow questions you might be interested section(right bottom
section)

How do you use other than ad-blocker?

~~~
neuronic
4\. Hide humongous Wikipedia donation element after having donated.

~~~
lunchables
It is really annoying to get that even after donating. I have never signed up
for a wikipedia account (which, now that I think about it, is kind of
amazing?) but if I had one, would the donation dialog disappear after
donating? Maybe I will sign up to find out.

~~~
lloeki
At the very least for me it didn't last time I donated: the donation seems to
be completely untied to your account.

~~~
casefields
Reminder: Wikipedia has Cancer.

[https://en.m.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost...](https://en.m.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2017-02-27/Op-
ed)

------
aiNohY6g
Thank you so much gorhill. So much, for making the web a better place.

------
tpush
I wish gorhill would make a Safari content-blocker version of ublock. None of
the existing blockers (who mostly just package existing block lists and charge
money for it..) work as well as uBlock IME.

~~~
grawlinson
Unfortunately, all Safari releases going forward (12 onwards) are removing
APIs that allow uBlock Origin to do what it does.

Apple are basically neutering _all_ blockers, unfortunately. I don't know if
they're planning on filling the void though.

~~~
happybuy
The reason these APIs are being removed are to improve the privacy of users.

Apple recommends all adblock extensions now use the content blocking API which
is superior from a user privacy perspective. When using the content blocker
apis, the extension cannot view or read which web pages are visited. Prior
extension APIs had full access to browsing history (which obviously can be
easily abused).

The content blocker API is different but does allow full featured and
sophisticated adblockers. I know because I create one which is very efficient,
effective and free - Magic Lasso Adblock
([https://www.magiclasso.co/](https://www.magiclasso.co/))

~~~
Karunamon
Except that API kills one of the main use cases - live blocking annoying stuff
that's already on the page. Apple's gimped API, as far as I can tell, offers
no way with the user to interact with the plugin.

Meaning that if the blocker misses something (and it will), I have no way to
deal with it.

This "privacy" canard is just Apple being Apple and punishing users in the
name of full control. The #1 and #2 most used adblockers by everyone have no
legitimate privacy concerns.

~~~
snaky
That's Apple's model - users cannot make their own decisions.

------
vanderZwan
> _The original prototype was to develop an idea I had about using jump
> indices in a TypedArray for quickly matching hostnames (or more generally
> strings)[1]. Once I had a working, un-optimized prototype, I realized I had
> ended up with something formally named a "trie":
> <[https://en.wikipedia.org/wiki/Trie>](https://en.wikipedia.org/wiki/Trie>),
> hence the name. I have no idea whether the implementation here or one
> resembling it has been done elsewhere._

So I heavily experimented with squeezing performance out of a JS-based trie-
implementation for LZString[0]. Back then some early experimentation suggested
that using TypedArrays was likely to be slower than using objects with
numerical keys, and for non-degenerate input using a trie based on plain
arrays and indexOf calls was the fastest[1]. However, it's been a while since
I looked at those numbers (and I suspect that with uBlock's use case look-up
performance matters more than insertion performance, which makes it very
different from LZString's).

But it should be obvious that HNTrie's implementation[2] is something I'm
_very_ interested in ;).

[0] [https://github.com/pieroxy/lz-
string/pull/98](https://github.com/pieroxy/lz-string/pull/98)

[1] [https://github.com/pieroxy/lz-
string/blob/ba8988028d78962eba...](https://github.com/pieroxy/lz-
string/blob/ba8988028d78962ebadee42cc6d4b17581605e2d/lz-string-unsafe.js)

[2]
[https://github.com/gorhill/uBlock/blob/2a91a685ce3d2dae5d3c2...](https://github.com/gorhill/uBlock/blob/2a91a685ce3d2dae5d3c285cff1bc74a1982be74/src/js/hntrie.js)

~~~
gorhill
> So I heavily experimented with squeezing performance out of a JS-based trie-
> implementation for LZString.

Incidentally, I did write a JS/WASM version of LZ4 block encoding[1] (also
used in uBO). I do wonder if it could be of interest for the LZString project.

My understanding is that the output of LZ4 compression would need to be
further processed to make it JS string-friendly (for localStorage purpose).

Maybe worth exploring if even with that extra step[2], the performance gain if
any is worth it?

[1] [https://github.com/gorhill/lz4-wasm](https://github.com/gorhill/lz4-wasm)

[2] Encode 7 bytes into 8 valid ASCII characters?

~~~
vanderZwan
Dman. So how many awesome things do you casually do on the side just in the
name of improving uBlock?

~~~
vanderZwan
*Damn.

------
Twirrim
I'm a sucker for random benchmarks, and seeing there was a benchmark against
the hostname-lookup stuff, I took a quick shot (2015 MacBook Pro, running High
Sierra)

Anyone know why regex performance on Safari is so diabolically bad?

    
    
        Safari 12.0.1 on OS X 10.13.6.
        
        Test 100 needles against 16 dictionaries of hostnames
          -                 Set-based x 3,149 ops/sec ±0.75% (59 runs sampled)
          -               Regex-based x 281 ops/sec ±0.78% (61 runs sampled)
          -      Trie-based (1st-gen) x 14,118 ops/sec ±1.66% (66 runs sampled)
          -   Trie-based JS (2nd-gen) x 12,349 ops/sec ±0.58% (61 runs sampled)
    
    
        Chrome 70.0.3538.110 on OS X 10.13.6 64-bit.
    
        Test 100 needles against 16 dictionaries of hostnames
          -                 Set-based x 3,376 ops/sec ±1.95% (61 runs sampled)
          -               Regex-based x 4,492 ops/sec ±1.66% (27 runs sampled)
          -      Trie-based (1st-gen) x 9,431 ops/sec ±0.69% (51 runs sampled)
          -   Trie-based JS (2nd-gen) x 8,627 ops/sec ±0.63% (47 runs sampled)
          - Trie-based WASM (2nd-gen) x 12,169 ops/sec ±0.58% (64 runs sampled)
        Done.

------
amanzi
Since the last major Firefox update, I haven't needed to run an adblocker. I
set Firefox to block trackers always (not just in private mode) and I hardly
ever see ads, or I don't notice them at least.

~~~
gtyras2mrs
Despite built in options for ad-block, uBlock Origin is still essential for
me.

There is too much junk on sites, poorly designed elements that take up half my
screen, social media elements, video elements - I tend to block those elements
freely.

------
__s
Good to see wat being used over bringing in emscripten baggage:
[https://github.com/gorhill/uBlock/tree/master/src/js/wasm](https://github.com/gorhill/uBlock/tree/master/src/js/wasm)

~~~
vanderZwan
I wonder if this wouldn't be a good use-case for Walt. It's close enough to
the metal to avoid bringing in unwanted baggage, but still a lot more
convenient to write in than the .wat format.

[0] [https://github.com/ballercat/walt](https://github.com/ballercat/walt)

------
andrepd
I've been using uBO in advanced (dynamic filtering) mode for a few weeks now.
I strongly recommend everyone wary of privacy to start doing that now. It's
surprisingly not so difficult at all!

------
raverbashing
I've been having a lot of cosmetic filtering issues with UBlock lately, not
sure if it's an issue with the lists or with UBO itself.

Sites that load but stay "blank" until you disable filtering

~~~
castis
some websites out there will detect that no ad code was allowed to run and
then refuse to show you a page.

~~~
grossdm
This is widely known. It's also why uBlock replaces ad scripts with "neutered"
scripts to make the page render anyway. It's good stuff!

------
suyash
What is a good ad blocker like this for Safari?

~~~
fragebogen
uBlock exists also for Safari, however you need to download it through the App
Store these days.
[https://www.ublock.org/safari/](https://www.ublock.org/safari/)

~~~
Klover
That’s not uBlock Origin, that’s the icky one. I use the AdGuard extension for
desktop Safari, and the app for mobile Safari, which use the content blocking
feature of Safari itself.

~~~
fragebogen
My bad, thanks for the clarification. As @heartbreak pointed out, this seems
to be the real deal [https://safari-
extensions.apple.com/details/?id=com.el1t.uBl...](https://safari-
extensions.apple.com/details/?id=com.el1t.uBlock-3NU33NW2M3)

~~~
Klover
That's.. also not exactly the real deal. It's a community fork of uBlock
Origin with some patches and then became unmaintained. That's why I use
AdGuard for Safari.

[https://itunes.apple.com/app/adguard-for-
safari/id1440147259](https://itunes.apple.com/app/adguard-for-
safari/id1440147259)

[https://itunes.apple.com/app/apple-
store/id1047223162](https://itunes.apple.com/app/apple-store/id1047223162)

These two.

------
lvs
Keep on fighting the good fight, gorhill.

------
jonssen
1.17.4 not functioning with Firefox 52.9.0 (32-bit) Reverting to 1.17.2 it
works again.

------
wnevets
the most important browser extension

------
vtesucks
Are there benchmarks where the wasm engine of a browser beats the Js engine of
the same browser in compute heavy code?

~~~
adonese
they attached a benchmark,
[https://raw.githack.com/gorhill/uBlock/master/docs/tests/hns...](https://raw.githack.com/gorhill/uBlock/master/docs/tests/hnset-
benchmark.html)

~~~
hornetblack
Results on mine:

    
    
        Benchmarking, the higher ops/sec the better.
        Firefox 63.0 on Windows 10 64-bit.
    
        Test 100 needles against 16 dictionaries of hostnames
          -                 Set-based x 1,443 ops/sec ±3.46% (54 runs sampled)
          -               Regex-based x 4,093 ops/sec ±1.18% (25 runs sampled)
          -      Trie-based (1st-gen) x 8,993 ops/sec ±1.92% (59 runs sampled)
          -   Trie-based JS (2nd-gen) x 7,923 ops/sec ±2.81% (44 runs sampled)
          - Trie-based WASM (2nd-gen) x 10,100 ops/sec ±1.75% (54 runs sampled)
        Done.

~~~
pietroglyph
Interestingly, my numbers are completely different relative to each other when
compared with yours... I wonder how the number of runs is determined and if
this affects the results.

    
    
      Benchmarking, the higher ops/sec the better.
      Firefox 63.0 on Fedora 64-bit.
      
      Test 100 needles against 16 dictionaries of hostnames
        -                 Set-based x 1,707 ops/sec ±1.93% (60 runs sampled)
        -               Regex-based x 4,078 ops/sec ±0.88% (25 runs sampled)
        -      Trie-based (1st-gen) x 10,038 ops/sec ±1.41% (64 runs sampled)
        -   Trie-based JS (2nd-gen) x 7,258 ops/sec ±1.03% (40 runs sampled)
        - Trie-based WASM (2nd-gen) x 8,033 ops/sec ±1.08% (44 runs sampled)
      Done.

~~~
Nullabillity
That's what I got too:

    
    
        Benchmarking, the higher ops/sec the better.
        Firefox 63.0 on Linux 64-bit.
    
        Test 100 needles against 16 dictionaries of hostnames
          -                 Set-based x 1,992 ops/sec ±0.71% (15 runs sampled)
          -               Regex-based x 5,148 ops/sec ±0.18% (30 runs sampled)
          -      Trie-based (1st-gen) x 11,797 ops/sec ±0.49% (63 runs sampled)
          -   Trie-based JS (2nd-gen) x 8,471 ops/sec ±0.50% (47 runs sampled)
          - Trie-based WASM (2nd-gen) x 9,543 ops/sec ±0.48% (52 runs sampled)
        Done.
    

I don't see why trie matching performance would depend on the host OS...
Unless WASM runs out of process and requires some form of IPC, I guess?

~~~
wcdolphin
Interesting that an iPhone XS is the fastest of all the benchmarks above.

Benchmarking, the higher ops/sec the better. Safari 12.0 on Apple iPhone (iOS
12.1).

Test 100 needles against 16 dictionaries of hostnames \- Set-based x 3,763
ops/sec ±0.19% (68 runs sampled) \- Regex-based x 392 ops/sec ±0.16% (66 runs
sampled) \- Trie-based (1st-gen) x 20,669 ops/sec ±0.15% (69 runs sampled) \-
Trie-based JS (2nd-gen) x 16,926 ops/sec ±0.71% (69 runs sampled) Done.

~~~
X-Istence
Safari is also a lot faster than Firefox/Chrome on the Trie-based versions
(non-wasm)

------
thefounder
I wonder how long will take until they ban/remove this as well using DCMA

