Skip to content

Releases: gorhill/uBlock

0.9.8.6

05 Jun 17:40
Compare
Choose a tag to compare

Notes:

  • Approved in Opera store.
  • Approved in Chrome store.
  • Not published to AMO: the one fix affected most likely only Chromium-based browsers.

Closed as fixed:

  • Tab For a Cause ads not loading after whitelist in Chrome
    • Tab For a Cause is an extension which overrides the new tab in Chromium/Chrome.
    • If newtab.chrome-scheme is whitelisted (which it is by default), the Tab For a Cause should work fine now, with no further whitelist directive or special filter needed.
    • This was a regression bug from fix to #248.

0.9.8.5

05 Jun 10:58
Compare
Choose a tag to compare

Changes:

Firefox support for browser settings has been added, so now the new privacy settings in the Settings pane are also effective in Firefox.

A new privacy setting has been added:

[ ] Disable hyperlink auditing/beacon

Checked by default. Background information regarding hyperlink auditing.

Note that with Chromium, hyperlink auditing is enabled by default, and there is no UI in the browser setting pages to disable it. Now there is with uBlock. (edit: ok, there is a sort of UI, not exactly user friendly and upfront though.)

With the following steps I can have Google generate a ping request, so I use these to validate that the disabling of hyperlink auditing works:

  • Open the logger, select Behind the scene scope.
  • In Google, search buy iphone.
  • Find a link to bestbuy.com in the links offered as result (I get one to bestbuy.ca).
  • Click that link.
  • If hyperlink auditing is not disabled, you should see a behind-the-scene request to google.*.

The setting will also affect whether navigator.sendBeacon is enabled/disabled. You can see these behind-the-scene requests while navigating Gihub (https://www.google-analytics.com/collect). Unfortunately, it does not seem possible at this time to disable navigator.sendBeacon in Chromium.

Closed as fixed:

Fennec
Firefox
Core

0.9.8.3

02 Jun 04:24
Compare
Choose a tag to compare

Notes

Most of the work for this version are for Firefox, but I will publish this version only in the Chrome store, as the new setting:

[ ] Disable pre-fetching (to prevent any connection for blocked network requests)

... is only functional for the Chromium version. I need to read more to hook it properly for Firefox. That new setting is checked by default. It is suggested you read Chrome Help's Make webpages load faster:

If you turn this setting on in Chrome, websites (and any of their embedded resources) that are prerendered or prefetched may set and read their own cookies as if you had visited them before -- even if you don’t visit the prerendered or prefetched pages after all.

Note that pre-fetching is more of a crutch to speed up page load, using a blocker in the first place is what really improve page load time, without sacrificing privacy like pre-fetching does. Aside the privacy implication of pre-fetching, it certainly does not come for free either resource-wise (bandwidth, memory, cpu). In any case, your choice, so long as you can make an informed one (that pre-fetching setting, enabled be default, and its negative implication privacy-wise are not exactly disclosed upfront).

Closed as fixed:

Firefox:
Chromium:

0.9.8.2

30 May 18:20
Compare
Choose a tag to compare

Notes:

It's kind of fast for a new release but I want to keep the review process going.

Closed as fixed:

Chromium:
  • [Chrom*] connections not being blocked after reload (from uMatrix)
    • uBlock now requires a new permission, "Change your privacy-related settings": for uBlock to be able to disable the setting "Prefetch resources to load pages more quickly".
    • This will ensure no connection is opened at all for blocked requests: It's for your own protection privacy-wise.
    • Prefetching is under Privacy for good reasons: using prefetching has negative implications privacy-wise.
    • For pages with lots for blocked requests, this will actually remove overhead from page load (if you did not have the setting already disabled).
    • When uBlock blocks a network request, the expectation is that it blocks completely the connection, hence the new permission is necessary for uBlock to do truthfully what it says it does.

uBlock's primary purpose is to block network connections, not just data transfer. Not blocking the connection while just blocking the data transfer would mean uBlock is lying to users. So this permission will stay, and sorry for those who do not understand that it actually allows uBlock to do its intended job more thoroughly. A blocker which does not thoroughly prevent connections is not a real blocker.

Privacy Badger also requires exactly the same permissions. I want uBlock to also serve privacy-minded users first.

If prefetching had been disabled by default, this new permission would not be needed, but prefetching is unfortunately enabled by default, and under Privacy heading, which is itself hidden by default under "advanced settings".

c

Google on prefetching:

If you turn this setting on in Chrome, websites (and any of their embedded resources) that are prerendered or prefetched may set and read their own cookies as if you had visited them before -- even if you don’t visit the prerendered or prefetched pages after all.

Also, the benefits of prefetching are probably marginal, and in the context of a blocker, the benefits could be negative, since a lot of useless connections would be made, just to be discarded after the browser find out the requests won't be made anyway. So do not fall for the "lost of major performance boost" claim I read elsewhere, this is just a silly and baseless claim.

Edit: next release there will be a setting allowing you to re-enable prefetching. At least you will now use prefetching with an understanding of the negative consequences and in an informed consent manner.

More about the required permissions

Firefox:
Core:

0.9.8.1

28 May 00:52
Compare
Choose a tag to compare

0.9.8.0

27 May 23:49
Compare
Choose a tag to compare

New:

  • New language: Galician translation by Joe82
  • Dynamic URL filtering
    • Overrides dynamic filtering, static filtering: filtering overview updated accordingly.
    • Primary use case is for web page breakage diagnostic/remediation:
      • URL filtering rules can be easily set directly from the logger.
      • Creating/removing a URL filtering rules does not cause reload of static filter lists, hence it's virtually a no-op compared to adding/removing a static filter.
    • Further use cases: offers higher granularity to dynamic filtering if needed.
    • Available to non-advanced users, because of its usefulness as a tool to help diagnose/fix web page breakage:
      • UI accessible from the logger: click on the 4th cell of a network request log entry.
      • URL filtering rules can be edited from the "My rules" pane.
    • Work will continue on the unified logger to make it the hub to diagnose/fix page breakage, or to assist filter list maintainers in their work, so more to come.

Closed as fixed:

Firefox
  • Regression bug in facef0d, possibly preventing uBlock to perform optimally in a few areas.
    • For example, this was causing the count badge on uBlock's icon to refresh much more often than intended.
  • Work to fix issues outlined in feedback from AMO review process.
Core

0.9.7.5

19 May 11:28
Compare
Choose a tag to compare

New:

A new tab selector in the unified logger, to filter entries according to which tab they come from. It's not exactly like the previous tab selector that was in there with the older logger, as the current one won't wipe out existing entries which belong to other tabs. The refresh button aside the selector is to force a reload of the currently selected tab (so this takes care of uBlock-LLC/uBlock#484);

Closed as fixed:

Firefox
Core

0.9.7.0

10 May 16:31
Compare
Choose a tag to compare

0.9.6.0

30 Apr 10:52
Compare
Choose a tag to compare

Important:

The gnuzilla.org filter list "Block all well known privacy trackers" has been removed, due to it's high likelihood of breaking web pages. The filter list I learned is made from piecing together already existing filter lists, i.e. EasyList, EasyPrivacy, Fanboy Social, except that all exception filters to ensure no page breakage are removed.

Two alternatives for those who really want to use that list:

  1. Non-recommended: Use http://gnuzilla.gnu.org/filters/blacklist.txt as custom filter list.
  2. Recommended: if privacy is a top concern and you do not mind page breakage, use uBlock's dynamic filtering in default-deny mode.
    • This will be even much more strict than the gnuzilla.org filter list can ever be.
    • You gain the ability to very easily un-break web pages through simple point-and-click.

New:

Cosmetic filters are now reported in the logger (related long-standing issue: uBlock-LLC/uBlock#308).

  • Whatever added overhead incurred as a result of surveying active cosmetic filters exists if and only if the logger is opened, and only for whatever tab is being logged.

Tool added to logger: ability to manually evaluate static filters (related long-standing issue: uBlock-LLC/uBlock#10).

  • Mostly useful to advanced users for when trying to diagnose filtering issues.
  • Example: a user complained of non-blocked popups.
  • I could not reproduce the issue, as the web site was not serving me the specific popup which was reportedly not blocked.
  • However now I can enter manually the URL, and other relevant parameters.
  • Result: within seconds I could identify what was the issue.
  • No internationalization available yet (please do not file an issue).

Various other trivial improvements to the logger.

The derivation of synthetic hostnames for special pages has been extended to enable more specific rules. For examples:

  • Whitelist only Firefox Hello: loopconversation.about-scheme (derived from about:loopconversation).
  • Whitelist only about:blank: blank.about-scheme (derived from about:blank).
  • Whitelist uBlock's own pages (Firefox): ublock0.chrome-scheme (derived from chrome://ublock0/[...]).
  • Whitelist uBlock's own pages (Chromium): cjpalhdlnbpafiamejdnhcphjbkeiagm.chrome-extension-scheme (derived from chrome-extension://cjpalhdlnbpafiamejdnhcphjbkeiagm/[...]).
  • Whitelist all extensions' pages (Chromium): chrome-extension-scheme (derived from chrome-extension://[...]).
  • Etc.
  • All these synthetic hostnames can also be used in dynamic filtering rules.

Closed as fixed:

Chromium
Firefox
  • uBlock is blocking Firefox Hello
    • Firefox Hello widget is embedded in a tab which URL is about:loopconversation#[...], so this means you need to whitelist about-scheme in the Whitelist pane.
Core

0.9.5.0

24 Apr 23:51
Compare
Choose a tag to compare

Reminder: Chromium 41 (or browsers based on) still suffer from that ugly bug which causes a big chunk of memory leak each time a user opens the popup UI of an extension. Therefore, the more you use the popup UI in Chromium, the larger the memory footprint of uBlock (or any extension really) will grow. I've already seen feedback like "doesn't have a µ memory footprint at all for me. >250MB" (for µMatrix). This is important to keep this Chromium memory leak bug in mind if you make use of dynamic filtering, as this feature requires frequent access to the popup UI.

New:

Closed as fixed:

Chromium
Firefox
Core