The ability to redirect xmlhttprequest to binary
resources was lost when redirectable/injectable
resources became immutable in commit
152cea2dfe.
This commit restores the ability to redirect a
xmlhttprequest to a binary resource by making
it possible to derive a data: URI from the
content of binary resources such as images.
Addtionally a redirect to a data: URI can be
forced by prefixing the resource token with `%`.
This is a non-official feature at this point,
i.e. it could be removed at any time.
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/682#issuecomment-515197130
The following advanced setting has been added:
updateAssetBypassBrowserCache
Default to `false`. If set to `true`, uBO will ensure the
browser cache is bypassed when fetching a remote resource.
This is for the convenience of filter list maintainers who
may want to test the latest version of their lists when
fetched from their remote location.
Related issue:
- https://github.com/gorhill/uBlock/issues/2394
Additionally, I added a new advanced setting to control
how long after launch an auto-update session should be
started -- value is in seconds:
autoUpdateDelayAfterLaunch 180
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/409
By default `indexedDB` is used in Firefox for purpose of cache storage
backend.
This commit allows to force the use of `browser.storage.local` instead
as cache storage backend. For this to happen, set `cacheStorageAPI` to
`browser.storage.local` in advanced settings.
Additionally, should `indexedDB` not be available for whatever reason,
uBO will automatically fallback to `browser.storage.local`.
The motivation is to address the higher peak memory usage at launch
time with 3rd-gen HNTrie when a selfie was present.
The selfie generation prior to this change was to collect all
filtering data into a single data structure, and then to serialize
that whole structure at once into storage (using JSON.stringify).
However, HNTrie serialization requires that a large UintArray32 be
converted into a plain JS array, which itslef would be indirectly
converted into a JSON string. This was the main reason why peak
memory usage would be higher at launch from selfie, since the JSON
string would need to be wholly unserialized into JS objects, which
themselves would need to be converted into more specialized data
structures (like that Uint32Array one).
The solution to lower peak memory usage at launch is to refactor
selfie generation to allow a more piecemeal approach: each filtering
component is given the ability to serialize itself rather than to be
forced to be embedded in the master selfie. With this approach, the
HNTrie buffer can now serialize to its own storage by converting the
buffer data directly into a string which can be directly sent to
storage. This avoiding expensive intermediate steps such as
converting into a JS array and then to a JSON string.
As part of the refactoring, there was also opportunistic code
upgrade to ES6 and Promise (eventually all of uBO's code will be
proper ES6).
Additionally, the polyfill to bring getBytesInUse() to Firefox has
been revisited to replace the rather expensive previous
implementation with an implementation with virtually no overhead.
Related issue:
- https://github.com/NanoAdblocker/NanoCore/issues/239
The erroneous behavior was to compute the URL of a sublist as
relative to the URL of the root list, which may differ from the
URL of a parent list.
Performance-related work: the logger data has been decoupled
from the DOM -- inspired from CodeMirror's way of efficiently
handling large amout of text data.
This decoupling now makes the logger highly efficient CPU- and
memory-wise, and open the way to more possibilities.
Ability to configure some aspect of the logger behavior and
visuals:
- The hard-coded limit of 5000 entries has been
removed and is now replaced with a variety of
user-configurable settings to enforce the discarding of
logger entries.
- Some columns in the logger output can now be hidden.
The filter list look-up feature has been merged into the
existing overlay dialog used to create URL rules or static
filters, as an entry in a new "Details" pane.
Other issues addressed during refactoring:
- https://github.com/uBlockOrigin/uBlock-issues/issues/280
- https://github.com/gorhill/uBlock/issues/1999
The minimum version supported on Firefox has been bumped
up to 55.0.
Squashed commit of the following:
commit 6a8473822537636ac54d5dabdb14472114bb730b
Author: Raymond Hill <rhill@raymondhill.net>
Date: Mon Aug 6 10:56:44 2018 -0400
remove remnant of snappyjs and spurious instruction
commit 9a4b709bee97d3cc2235fab602359fa5953bdb46
Author: Raymond Hill <rhill@raymondhill.net>
Date: Mon Aug 6 09:48:58 2018 -0400
make cache storage compression optionally available on all platforms
New advanced setting: `cacheStorageCompression`. Default is `false`.
commit 22ee6547f2f7c9c5aefe25dea1262a1b31612155
Author: Raymond Hill <rhill@raymondhill.net>
Date: Sun Aug 5 19:16:26 2018 -0400
remove Chromium from lz4 experiment
commit ee3e201c45afe983508f70713a2d43af74737d8d
Author: Raymond Hill <rhill@raymondhill.net>
Date: Sun Aug 5 18:52:43 2018 -0400
import lz4-block-codec.wasm library
commit 883a3118efcfd749c82356fde7134754d6ae371d
Author: Raymond Hill <rhill@raymondhill.net>
Date: Sun Aug 5 18:50:46 2018 -0400
implement storage compression through lz4-wasm [draft]
commit 48d1ccaba407de447c2cd6747dc3a90839c260a7
Merge: 8ae77e6 b34c897
Author: Raymond Hill <rhill@raymondhill.net>
Date: Sat Aug 4 08:56:51 2018 -0400
Merge branch 'master' of github.com:gorhill/uBlock into lz4
commit 8ae77e6aeeaa85af335e664c2560d2afd37288c6
Author: Raymond Hill <rhill@raymondhill.net>
Date: Wed Jul 25 18:17:45 2018 -0400
experiment with compression
Only resources from within current directory will be allowed,
everything else will be silently rejected.
For example, this will forbid pulling lists from different repos
on GitHub, despite the lists being same origin.
A new filtering class has been created: "static extended filtering".
This new class is an umbrella class for more specialized filtering
engines:
- Cosmetic filtering
- Scriptlet filtering
- HTML filtering
HTML filtering is available only on platforms which support modifying
the response body on the fly, so only Firefox 57+ at the moment.
With the ability to modify the response body, HTML filtering has
been introduced: removing elements from the DOM before the source
data has been parsed by the browser.
A consequence of HTML filtering ability is to bring back script tag
filtering feature.
This is required as per Firefox extension reviewers. Mail exchange:
========
Reviewer:
> Do I read the code correctly that you are executing remote JS by
> downloading/updating from
> https://raw.githubusercontent.com/uBlockOrigin/uAssets/master/filters/resources.txt
> and injecting scripts in contentscripts.js?
Me:
> Yes, resources.txt contains scriptlets or other resources used to:
>
> - Minimize potential page breakage (e.g. google-analytics.com/ga.js);
> - Defuse anti-blockers (e.g. bab-defuser.js);
> - Defuse anti-blockers or minimize page breakage through redirection
> (e.g. 2x2-transparent.png)
>
> This is not a new feature -- this is also part of the legacy version,
> and I consider this is a major feature of uBO. Given how fast things can
> change out there, this allows me to quickly push fixes when a new issue
> is reported for a site without having to go through a full update of the
> extension.
Reviewer:
> I am aware that this is not a new feature. I am unclear why it has been
> allowed in the past, since it violates our policy about remote code
> execution. I assume it was missed due to the fairly complex codebase.
>
> I can approve this version so you are not blocked on the migration, but
> eventually, you cannot use functionality that executes remote code.
> Since we're moving to a more automated review process, you will be able
> to ship new versions without being blocked on a human review.
Me:
> Do I understand correctly that extensions such as TamperMonkey or
> ViolentMonkey won't be allowed on AMO?
>
> Those extensions are even more permissive than uBO given a user can
> import scripts from any source, while with uBO only scriptlets which are
> part of the project are allowed.
Reviewer:
> The key difference between add-ons like Tampermonkey and uBO is that in
> Tampermonkey, users are making an active and conscious decision to
> download and execute that specific code. In uBO, the user did not
> initiate that download/execution, nor are they even aware of it
> happening.
Me:
> So users of TamperMonkey -- tech-savvy or not -- can download & inject
> countless 3rd-party user scripts from countless authors, have them
> update on their own automatically at regular interval with no user
> intervention.
>
> On the other hand, it's not acceptable for me, the author of the
> extension, who users implicitly trusted when installing the extension,
> who is completely controlling and vouching for the content of
> "resources.txt", to have this one 1st-party resource file[1] to be
> updated at regular interval with no user intervention.
>
> So anyways, what is expected from me at this point? Do I need to remove
> scriptlet injection and resource redirection features? Do I need to
> remove only the updating part of resources.txt?
>
> [1] key to core features of uBO (counter anti-blockers + page breakage
> mitigations) and possibly an important factor in installing the
> extension.
========
Now about this commit: the purpose of the code change here is to
prevent "resources.txt" -- which is part of the package -- from being
updated -- this applies only to the Firefox webext[-hybrid] version
of uBO.
