Releases: gorhill/uBlock
0.9.9.2
New:
Imported @AlexVallat's work for support for Firefox pre-Australis.
A new uBlock filter list, "uBlock -- Badware risks", dedicated to sites which are documented to be a risk of badware. Since uBlock now reports the filter list(s) from where a filter originates (since 0.9.9.0), having a dedicated filter list with a self-explanatory name will help users understand better why a given URL is blocked.
Closed as fixed
Core
0.9.9.1
Closed as fixed:
Firefox:
Core:
0.9.9.0
New
UI in the logger to assist in creating static filters.
Related issue: uBlock-LLC/uBlock#68.
A new per-site switch to disable remote fonts
"Side-effect" is to fix issue #15:
- Simply add the rule
no-remote-fonts: * trueto "My rules", and remote fonts from everywhere will be blocked by default -- yet uBlock will still be able to use its FontAwesome font from its package. - As a opposed to using a browser setting to disable remote fonts, you can enable remote fonts on a per-site basis -- so disabling remote fonts is no longer an all or nothing choice.
The number of times a page did or did try to download remote fonts appears as a badge aside the switch.
Caveat: Chromium's webRequest API does not specifically report requests of type font, fonts are reported as type other. Whether a request is for a font resource is inferred by uBlock using the "extension" of the path part of a URL. However a URL can be anything really, regardless of request type, so for Chromium-based browsers, uBlock may have to block a font after the request is made, when the response headers are received from the remote server -- as the response headers allow to identify for sure the type of a resource.
Ability to find out from which filter lists a static filter originates:
Related issue: #58.
Can be accessed from the logger: if a static filter is present in the 3rd-column of a row, clicking on the cell will show the filter list(s) in which the filter can be found.
There is a resource cost to reverse lookup filter lists from a filter, but this is mitigated by implementing the reverse lookup as a standalone "service", which is launched if and only if an actual reverse lookup is requested.
Since reverse lookup is potentially CPU intensive (depending on number of lists, size of lists), the lookup is performed from within a Worker, i.e. its own dedicated thread:
Resource cost while reverse lookup service is alive: 6.5 MB on Nightly. It's because all the stored compiled version of filter lists in use must be kept in live memory to perform the lookup efficiently.
The reverse lookup "service" will shutdown itself after being idle for a set time (currently 11 minutes), so that the extra resources used are freed.
Strict blocking will now show you which filter list(s) caused a document to be blocked:
Related issue: #298.
This is accomplished by using the reverse lookup feature described above.
Filter lists with special instructions for proper usage
Related issue: #312.
Some filter lists require extra steps for proper usage. Those filter lists are now identified with a special icon, which links to instructions on how to use the filter list:
Changes
Issue #59 was fixed as a side-effect of some specific re-factoring related to how the static filtering engine returns results -- a necessary step toward fixing other future issues. The effect of this specific re-factoring:
- The logger will now report accurately the static (atomic) filter which affects a network request. For examples:
- The
third-partyfilter option is now reported if present (it wasn't before). - If a filter applies to a specific request type, this is now reported (it wasn't before).
- If a filter applies to a specific domain, this is now always reported (it wasn't always before).
- The
- Some overhead removed from the static filtering engine for when the logger is not opened.
- Previously, uBlock was returning a string representation of a filter in case of match, even if that (inaccurate) string representation was not going to be used in the logger. This does not happen anymore.
Closed as fixed:
Core
- uBlock Origin do not update title filter when filter edited
- Anti-Adblock Killer | Reek 8.1 needs a userscript in order to fully work
- Suggestion for strict blocking
- URLs displayed right after the filter lists redirect to nothing
- A link to a support site, if any, is now used.
- Static filter improperly reported in logger
- Suggestion - list which content is blocked
- Original issue: uBlock-LLC/uBlock#43.
0.9.8.6
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-schemeis 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
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.comin the links offered as result (I get one tobestbuy.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
- Unchecking uBlock's Hyperlink-Auditing option enables pings even though browser default is false
- Tab selection (eg. from element picker in network log) not working
Core
0.9.8.3
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:
- Performance issues in Firefox 39 beta.
- Need someone to test, I do not have a test case readily available (100s of tabs).
- Maybe will also fix #252?
- Tab selector list error?
Chromium:
- Allow advanced users to turn prefetching back on
- The new setting is in the Settings pane. Pre-fetching is disabled by default. It is suggested you leave it disabled. I am skeptical of the advertised benefits when using a blocker.
0.9.8.2
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".
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:
- addons.mozilla.org version, layout issue
- Image being blocked/hidden, shows as behind-the-scene request even when directly navigated to
Core:
0.9.8.1
0.9.8.0
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
- Regular expression does not work in the filter of logger since 0.9.7.0
- Filter expression parser was rewritten in the new unified logger, and as a result, it no longer supports regular expression (the new parser is more flexible and doesn't really need regex support).
- The fix here has been to add support for or'ing filter expressions together, using double-pipe,
||. - Documentation has been updated to explain how this works.
- "Undo" and "Save" buttons in the popup should not scroll
0.9.7.5
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
- Many network requests wrongly categorized as behind-the-scene
- Blocks addons that use the sidebar
- This is a case where uBlock shines: uBlock will report in the logger the requests also made by other extensions.
- In the current instance, it is possible to ask uBlock to act on these network requests, by opening the popup from within the logger.