Live data from Hacker News

µBlock for Firefox

github.com

181–190 of 273 posts

Re: µBlock for Firefox

#181
post #126

Earlier quoted context omitted.

Blocking at the DNS level produces a lot of requests to 127.0.0.1, which can be quite annoying e.g. if you are using a local webserver for development. Also if you do not have a local webserver on 127.0.0.1 the browser still will wait for answers to your request, what can be an annoying experience. Would be interesting to measure how much CPU and memory actually is wasted with many tabs waitung for elements from 127.…

DNS blocking works quite well. It's also very effective if you can set it up on your gateway so that it blocks ads/malware for all devices (PCs, phones, tablets ... even your guests will get adblocking for free!). However, while the /etc/hosts trick works I don't think it's the best way. The reason is that while parsing a plaintext file is easy and generally fast, it doesn't scale well especially when you have to tra…

Am I reading right - serving data for responses on localhost is "cheaper" (for some value of cheap) than letting those requests fail? Or does it just return faster, is it faster than using firewall rules?

Why serve a gif, why not a single byte or something? Does the browser require the data to be parseable?

Sorry, lots of questions.

http://proger.i-forge.net/The_smallest_transparent_pixel/eBQ gives info on smallest gif/png/jpeg files which might be useful.

Re: µBlock for Firefox

#182
post #175

I decided to dump extension-based privacy stuff and installed Privoxy instead. I used to have Ghostery, Disconnect, ABP, and some other things running simultaneously. When you think about it, that's a lot of JS running and iterating the DOM multiple times every time you load a page. Now there's a single, purpose-built, standalone process written in C doing it. Not going back.

I've used Privoxy & friends (Glitterblocker on OS X) since the days of junkbusters.com, but with SSL on the rise this no longer works very well for me.

Anyone looking to follow up on this comment should search for "GlimmerBlocker", not GlitterBlocker.

Useful stuff, though, thanks!

Re: µBlock for Firefox

#183

Earlier quoted context omitted.

Counter opinion: I like the number because if there's a website working not quite right, I can easily see the number and disable uBlock to test out if that's the cause.

But you can't, though. uBlock shows the total number of blocked items since you started Firefox. Not the number for a given page or site. Making it a basically superfluous mostly useless datapoint.

On Safari and Chrome, it displays the number of filters applied on the current site. This is (super) useful. If on Firefox you're getting a global count then that's a bug (so please report it on Github).

Perhaps changing the color from red to something more "off" (grey?) would help distract less.

Re: µBlock for Firefox

#184

Earlier quoted context omitted.

But you can't, though. uBlock shows the total number of blocked items since you started Firefox. Not the number for a given page or site. Making it a basically superfluous mostly useless datapoint.

This is not the behavior I observe; in my case, it shows only the number blocked on the current page. Perhaps you have encountered a bug?

After turning it off and turning it back on, it's now per-page. Odd. Still, annoying and pointless for my purposes.

Re: µBlock for Firefox

#185
post #175

I decided to dump extension-based privacy stuff and installed Privoxy instead. I used to have Ghostery, Disconnect, ABP, and some other things running simultaneously. When you think about it, that's a lot of JS running and iterating the DOM multiple times every time you load a page. Now there's a single, purpose-built, standalone process written in C doing it. Not going back.

I've used Privoxy & friends (Glitterblocker on OS X) since the days of junkbusters.com, but with SSL on the rise this no longer works very well for me.

For anyone searching for a blocking solution on OSX, the name is actually Glimmerblocker. It still works on Yosemite.

Re: µBlock for Firefox

#186
post #47

Use /etc/hosts blocking if you are worried about CPU and memory. It also works on rooted Android devices.

Blocking at the DNS level produces a lot of requests to 127.0.0.1, which can be quite annoying e.g. if you are using a local webserver for development. Also if you do not have a local webserver on 127.0.0.1 the browser still will wait for answers to your request, what can be an annoying experience. Would be interesting to measure how much CPU and memory actually is wasted with many tabs waitung for elements from 127.…

Use 0.0.0.0 instead of 127.0.0.1, it won't make requests to localhost.

https://en.wikipedia.org/wiki/0.0.0.0

Re: µBlock for Firefox

#187
post #158

Earlier quoted context omitted.

The obnoxious and spying nature of ads.

... I'm not asking about why you'd want one. - I'm asking about why you'd make a new one and who would pay for your work on a new one when others already exist?

But that is the same question. Not everyone is trying to maximize their wealth all the time.

Do you ask "why did Linus write Linux when there were other operating systems available at the time and no one was paying him for it?" or similarly the Atheos.cx guy? Gnome when there was KDE? Gimp when there was Photoshop? Facebook when there was MySpace?

Re: µBlock for Firefox

#189
post #170
post #89

Earlier quoted context omitted.

https://github.com/gorhill/uBlock/wiki/Firefox-version:-benc...

How is that even possible? Firefox with blocker uses less RAM than without? Does it block elements from issuing requests?

One would expect any ad blocker that actually blocks ads to reduce memory consumption significantly. Ad blockers that merely hide ads exist and have succeeded in earning reputations as ad blockers despite only doing half the job.

Re: µBlock for Firefox

#190

It seems like, if one were an evil web developer, one could thwart blockers like these with a few nasty tricks. Server-side: on each request of a resource, salt all linked resource URIs and encrypt (after the host name) before sending the final document to the client. The resources can still be fetched, because the server can decrypt any requests, but the client has no way of knowing whether a particular resource is…

TPB mirrors used to do something similar and I swear I had adBlock filter that efficiently blocked them.
Post reply on HN