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.
* refactoring assets management code
* finalizing refactoring of assets management
* various code review of new assets management code
* fix#2281
* fix#1961
* fix#1293
* fix#1275
* fix update scheduler timing logic
* forward compatibility (to be removed once 1.11+ is widespread)
* more codereview; give admins ability to specify own assets.json
* "assetKey" is more accurate than "path"
* fix group count update when building dom incrementally
* reorganize content (order, added URLs, etc.)
* ability to customize updater through advanced settings
* better spinner icon
part of the package. The code here is to ensure a seamless transition from
local assets which have been converted to remote assets. The only side
effect to expect is that the selfie, if any, will be invalidated.
Chrome has getManifest(), Safari doesn't have anything, Firefox has an
asynchronous API...
So, instead of using extension APIs, store the common informations
(extension name, version, homepage url) in a file (vapi-appinfo.js), which
can be included when it's needed (its data will be available at vAPI.app.____).
The file's content is updated each time the extension is being built, so
it shouldn't be modified manually.
.jshintrc's otion-set is a personal choice, merely a suggestion.
Beside that, it includes some common globals for specific browsers, so
there's no need to set the globals in every .js file.
In order to force strict coding, "use strict" directive was added into
every .js file.
