Releases: gorhill/uBlock
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-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
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 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.
Core
0.9.7.0
0.9.6.0
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:
- Non-recommended: Use http://gnuzilla.gnu.org/filters/blacklist.txt as custom filter list.
- 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.
- This will be even much more strict than the
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.
- Fixed regression bug: Console error when you clear request log and try to reload
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 fromabout:loopconversation
). - Whitelist only
about:blank
:blank.about-scheme
(derived fromabout:blank
). - Whitelist uBlock's own pages (Firefox):
ublock0.chrome-scheme
(derived fromchrome://ublock0/[...]
). - Whitelist uBlock's own pages (Chromium):
cjpalhdlnbpafiamejdnhcphjbkeiagm.chrome-extension-scheme
(derived fromchrome-extension://cjpalhdlnbpafiamejdnhcphjbkeiagm/[...]
). - Whitelist all extensions' pages (Chromium):
chrome-extension-scheme
(derived fromchrome-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 whitelistabout-scheme
in the Whitelist pane.
- Firefox Hello widget is embedded in a tab which URL is
Core
- Cosmetic filters not always applied on specific website http://honyaku.yahoo.co.jp/
- Filter misinterpretation?
- Strange bug with specific website
- Definitely a bad bug which was still lingering in uBlock.
- The bug surfaced only for when a user created custom filters using the element picker.
- It was only a runtime bug, i.e. it disappeared when reloading the filter lists or rebooting uBlock.
0.9.5.0
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:
- Frisian translation by fryskefirefox.
- Not available in Chromium, only Firefox.
- Color-blind mode (longstanding issue #467).
- Research and solution provided by WyohKnott.
- A new button to remove temporary rules in the dynamic filtering pane.
Closed as fixed:
Chromium
Firefox
- Add cleanup task to remove local storage settings when uninstalling
- Panel bug when icon in Firefox panel