Serious Discussion A warning and a bit worried: uBO and uBOL users investigate this

Web Extensions
53 Replies 914 Views
LinuxFan58

LinuxFan58

Level 23
Verified
Top Poster
Well-known
uBO and uBOL both use a trusted variant of the scriptlet: json-edit.js

First issue I have with this scriptlet (which has a trusted and non-trusted variant) is that it is 1,575 lines of code!
That is not a scriptlet, that is rewriting functionality of the browser.

Second issue I have with the trusted variant is that it is used to strip out specific fields from a site's own data — an ad-slot config buried in a JSON blob, a tracking flag in an API response, a consent-popup trigger baked into a page's initial state object — without touching the rest of the object.

In plain terms: the non-trusted version can only delete a piece of data. The trusted version can also replace it with something else entirely — and it can do that to data flowing both ways, not just what you see on screen.

A few concrete pictures of what that difference means:
  • A price on a checkout page. The non-trusted version could hide a "you've been shown this ad" flag. The trusted version could rewrite the price itself — or, since it also works on the actual data a page sends to its server (via fetch/XHR), rewrite the order amount in the request before it ever leaves your browser.
  • A login or account page. It could quietly change a field being submitted — an account number, a permission setting, a quantity — without anything visibly different on the page you're looking at.
  • A "you have new messages" flag, or similar state. The non-trusted version can only remove that flag. The trusted version could set it to whatever value someone wants, on a site that trusts its own JSON blindly.
The core danger is that this isn't limited to cosmetic changes to what you see — it can tamper with the actual data your browser sends out and receives, silently, mid-flight. A filter list that's careless or malicious could use that to redirect money, falsify a submitted value, or make a page believe something false came from its own server, and you'd have no visual cue that anything happened.

USE AT YOUR OWN RISK!

I am also afraid Mv4 will forbid this (mis)usage and will limit use of scriptlet (is javascript injection) further (and make it harder for adblockers to block ads).


@Sampei.Nihira thanks for challenging me to add some more scritplets in uBS, investigating how I could implement extra scriptlets without reducing security is why I stumbled on this madness.
 
Last edited:
Jan Willy said:
How does Raymond Hill think about it?
Click to expand...
Ask him (you can also ask ChatGPT when you don´t believe me).

Filter list maintainers are all using nick name. I was adviced to not use my own Google account, because when something is under investigation, your data might be frozen during the investigation (so I could lose acces to stuff I have on Google drive). You asked me about using the nick name Lenny Fox (which showed in Firefox because it is directly puled from Github). This shows that there is little to no check on the person requesting a Github account.

So it is not Mr Hill which is the Achilles heel, but the many uBO assets maintainers which are a huge risk factor. We have seen it before that extensions turned roque and for handover of an extension there are more safetynet mechanisms in place than me providing you my Github login via mail and receiving a bitcoin token in return.
 
Last edited:
LinuxFan58 said:
uBO and uBOL use a trusted variant of `json-edit.js`. I am concerned that it can replace JSON values in incoming and outgoing data, allowing a careless or malicious filter list to alter prices, account fields, or other submitted values without a visible sign. I also worry that Manifest V4 may furthe […]
Click to expand...


Hi LinuxFan58, the concern about privileged scriptlets deserves scrutiny, but the checkout and account examples do not yet establish that uBO or uBOL can silently alter arbitrary outgoing requests. The decisive questions are where `json-edit.js` runs, what APIs it intercepts, and who is permitted to invoke its trusted form—not its line count.

What the warning proves—and what it does not​

A 1,575-line file is worth auditing, but size is not a security boundary. Scriptlets often include parsing, validation, matching, logging, wrappers for several web APIs, and defensive handling. Calling that “browser functionality” does not demonstrate a vulnerability.

Likewise, modifying a JavaScript object or the body exposed to page code is not automatically the same as rewriting bytes transmitted on the network. To support the outgoing-order example, the implementation would need to intercept the relevant `fetch`/XHR request before transmission, parse that request body, match the configured path, replace its value, and pass the modified body onward. Response-side interception alone cannot do that.

Even if request bodies can be changed, a properly designed checkout must calculate the payable amount server-side from product IDs, quantities, discounts and the authenticated account. A merchant accepting a client-supplied total would have a serious application flaw independent of an ad blocker. Other client fields—such as a delivery choice or quantity—could still matter, so the capability should not be waved away; it simply needs to be demonstrated accurately.

The real trust boundary​

“Trusted” normally means a capability is reserved for extension-controlled or explicitly trusted filter sources, not that every subscribed third-party list may invoke it. That distinction decides whether this is ordinary privileged extension machinery or a broad filter-list risk.

The relevant audit should establish:

  1. Invocation control: Which built-in and external lists may call the trusted scriptlet? Can a user-added list invoke it merely by using its name?
  2. Exact interception scope: Does it process responses, request bodies, both, or only objects returned to page JavaScript?
  3. Matching scope: Must a rule specify a hostname, URL pattern and JSON path, or can it act broadly?
  4. Extension differences: uBO and uBOL should be checked separately; sharing a filename or concept does not prove identical privileges or implementation.
  5. Concrete reproduction: A minimal local test should show the original request body, the transmitted body observed by the receiving server, and the filter that caused any difference.

Without those details, “a malicious trusted ruleset could misuse a powerful transformation primitive” is a reasonable threat model. “uBO/uBOL users risk silent money redirection” is a much stronger claim than the available evidence supports.

Practical advice for users​

There is no basis here for panic or for removing either extension solely because this scriptlet exists. Users should keep the extension updated and avoid casually subscribing to unknown filter lists. A custom list is executable policy in practice, even when written as filters rather than as a conventional program.

If a reproducible test shows an untrusted third-party list can invoke the trusted variant, or that a built-in rule alters sensitive request data outside its intended scope, that would warrant a focused report to the extension maintainer with the smallest possible test case. Public claims about checkout tampering should wait for that proof.

The Manifest V4 prediction is also speculative. Any future restriction depends on the actual specification and browser implementation; “Mv4” by itself does not establish that this particular technique will be forbidden or that ad blocking will necessarily lose this capability.
 
@Bot two questions

1. did you check the code of the scriptlet or are you just talking in general? When you are bla-bla-ing in general again my advice is to have a look at the code.

2. did you check how easy it is to transfer the user credentials of Github account (making the uBol assets maintainers a risk factor) when they add a rule in one of uBo's filters misusing this scriptlet's capabilities? I think you are ignoring the biggest risk factor (a trusted filter maintainer using this scriptlet). Think about it over 10 million users, how interesting this potential risk is?


@Jack I would like to have the answer of @BOT on my two questions
 
Last edited:
Notice

AdGuard started to introduce the "trust" this filter option. While AG and uBO both use the concept of trust, AdGuard uses a trust+ for the scriptlets they deem dangereous (also AG does not has this json-edit scriptlet)

AdGuard
- optionally asks for user script permission
- uses trust and trust-plus
- trust-plus scriptlets are only accepted from AG maintened filters
- AG filters are maintained by the AG-filter team
- AG-filter team members are checked and identified

uBO/uBOL
- optionally asks for user script permission
- uses trust as concept
- scriptlets requiring trust are only accepted from uBO-filters
- uBO-filters are maintained on Github by Github members who have proven to be valuable “will get write permissions to the repository.”
- Github signon proces for an account only checks an e-mail address (similar to MalwareTips).

My take is that Google requires the user to explicitly confirm users to grant an extension user script permission for a reason (being security), this json-edit with over 1500 lines of code is shear madness.

AdGuard has a functioning safety net because they maintain the filters themselves, IMO uBO/uBOL have not because they use maintainers from Github which identity is noit checked beyond having an e-mail address. The whole concept is "zo lek als een mandje" as we say in Dutch (use Google translate).

P.S. May I remind you that uBOL started as permission less extension where GorHill made a case for using the new Mv3 directive as it was intended
(with NO cosmetic filtering, NO procedural filters and NO scriptlets)!!!
 
Last edited:
LinuxFan58 said:
@Bot two questions

1. did you check the code of the scriptlet or are you just talking in general? When you are bla-bla-ing in general again my advice is to have a look at the code.

2. did you check how easy it is to transfer the user credentials of Github account (making the uBol assets maintainers a risk factor) when they add a rule in one of uBo's filters misusing this scriptlet's capabilities? I think you are ignoring the biggest risk factor (a trusted filter maintainer using this scriptlet). Think about it over 10 million users, how interesting this potential risk is?


@Jack I would like to have the answer of @BOT on my two questions
Click to expand...
@Bot answer LinuxFan58. :)
 
Jack said:
Answer LinuxFan58’s two questions: whether the scriptlet code was actually checked, and whether the risk from a GitHub account holder with write access adding a malicious trusted rule was examined.
Click to expand...


Direct answers:

  1. No, my previous reply was not based on a complete code audit. It relied too much on general distinctions, so the wording about what still needed demonstrating was too sceptical.

The project’s own commit description confirms that the `json-edit` family covers XHR/fetch responses, while trusted variants can modify values rather than merely remove them. It also extends response-body filtering with JSONPath modification. That verifies a powerful response-tampering capability. I have not verified from the source that this scriptlet rewrites outgoing request bodies, however, so that specific checkout-request claim remains unproven.

2. Yes, a compromised or malicious uAssets maintainer is a genuine supply-chain threat. uBO deliberately trusts its own lists by default; random lists and “My filters” are untrusted by default. Therefore, write access to a trusted uBO list is a security-sensitive privilege.

But “GitHub only checks an email address” does not establish that anybody can obtain uAssets write access, nor that one maintainer can publish an unnoticed malicious change. Account authentication, repository authorization, review practice, branch protection and release/update handling are separate controls. Selling or stealing credentials would bypass identity vetting in either a pseudonymous or identified team; identification mainly improves accountability, not technical prevention.

So the defensible conclusion is: the capability and maintainer trust boundary deserve a responsible security review. The current evidence does not yet justify presenting silent payment redirection as an established uBO/uBOL risk. Jan Willy’s suggestion is the right next step: send Raymond Hill a minimal rule and reproducible demonstration first, especially if outgoing request modification can actually be shown.

Sources
 
Jan Willy said:
The question is not if I believe you or not. It's the way you publish your findings. I expected you would have submitted them first to the developer. We are not talking about bread crumbs but about putting a bomb under two popular and effective extensions.
Click to expand...
Three reasons

1. It is not a vulnability, it is designed this way

2. Mr Hill never reacted on this: Subject: Question about a TODO comment in AstFilterParser's constructor (static-filtering-parser.js) · Issue #731 · uBlockOrigin/uBOL-home

3. When I asked stopping adding features to uBol which would have an impact on the security model, I was told to go !@#$-myself and develop my own extension


And it is not a bomb, when you never enable the "allow user-script" permission in uBOL
 
@Bot,

You forgot to mention two strongholds in the weakness (Yes, a compromised or malicious uAssets maintainer is a genuine supply-chain threat), making this not a bom, but a spicy discussion :ROFLMAO:

1. Never enable allow user script permission in uBOL
2. The clan around Mr Hill has a Comodo-like emotion towards Mr Hill (they worship him), so like any other religion the chances of one of mr Hill's followers selling their Github login for a bitcoin token is very very low.

Other question (@Jack and @Bot)

Now we are passed the spicy discussion and sort of agree in the topics discussed, what is you opinion about developing a 1500+ LoC extension with these capabilities in the first place?
 
LinuxFan58 said:
What is your opinion of developing a 1,500-plus-line extension component with these capabilities in the first place? I think uBOL users are protected if they never enable “Allow user scripts,” while the likelihood of a trusted maintainer selling a GitHub account is very low.
Click to expand...


Developing it is not inherently reckless. Powerful scriptlets are a predictable response to sites moving advertising and anti-blocking logic into structured data. The problem is not “1,500 lines”; security cannot be measured with a tape measure.

What matters is whether the power is proportionately contained:

  • trusted rules must have a narrow, auditable source;
  • repository access should require strong authentication and preferably hardware-backed 2FA;
  • sensitive rule changes should receive independent review;
  • releases and list updates should have integrity controls and useful audit trails;
  • trusted request/response modification should be split into smaller capabilities where practical.

The source confirms that this family contains separate trusted scriptlets, including fetch/XHR response variants, and that trusted mode permits JSON replacement rather than deletion alone. That makes the trust boundary important, but it does not make the feature itself a vulnerability.

One correction: “Never enable Allow user scripts” is not a complete safeguard against bundled trusted rules. Raymond Hill stated that this setting enables custom scriptlet filters and “doesn’t affect any bundled lists.” It reduces exposure from custom and imported scriptlet rules, not necessarily from uBOL’s packaged rules.

And maintainer devotion is not a security control—colourful, perhaps, but unavailable in GitHub’s branch-protection settings. The appropriate conclusion is that this is legitimate high-risk functionality that deserves stronger governance and review than an ordinary cosmetic filter, not that its line count makes it madness.

Sources
 
Bot said:
One correction: “Never enable Allow user scripts” is not a complete safeguard against bundled trusted rules. Raymond Hill stated that this setting enables custom scriptlet filters and “doesn’t affect any bundled lists.” It reduces exposure from custom and imported scriptlet rules, not necessarily from uBOL’s packaged rules.

And maintainer devotion is not a security control—colourful, perhaps, but unavailable in GitHub’s branch-protection settings. The appropriate conclusion is that this is legitimate high-risk functionality that deserves stronger governance and review than an ordinary cosmetic filter, not that its line count makes it madness.
Click to expand...
Thanks for the addition, but injecting 1,500 lines of JavaScript into a website from an external extension is madness. Ask website developers what they think about it. One stone through a window is bad; 1,500 stones feels like hooligans attacking a shopping hall.
 
LinuxFan58 said:
Thanks for the addition, but injecting 1,500 lines of JavaScript into a website from an external extension is madness. Ask website developers what they think about it. One stone through a window is bad; 1,500 stones feels like hooligans attacking a shopping hall.
Click to expand...


That analogy confuses source-code size with runtime impact. A 1,500-line scriptlet file is not equivalent to injecting 1,500 independent attacks, nor does it necessarily mean every line executes on every matched page. It may contain shared utilities, validation and several code paths.

A content blocker intentionally changes page behaviour. Website developers may dislike that—especially when it defeats ads or anti-blocking—but their disapproval does not establish that the implementation is unsafe.

The serious criticism is narrower and stronger: this component has privileged data-modification capabilities, so invoking it from remotely maintained trusted rules creates a consequential supply-chain boundary. That warrants least privilege, review, strong maintainer authentication and tightly scoped rules.

So I agree that the capability deserves more scrutiny than cosmetic filtering. I do not agree that “1,500 lines of injection” proves madness. Count reachable privileges and controls, not stones—or lines.
 
Bot said:
The serious criticism is narrower and stronger: this component has privileged data-modification capabilities, so invoking it from remotely maintained trusted rules creates a consequential supply-chain boundary. That warrants least privilege, review, strong maintainer authentication and tightly scoped rules.
Click to expand...
These are the Github members active on uBlock Assets repo

stephenhawk8054 = 803 commits
Yuki2718 = 258 commits
uBlock-user = 204 commiyts
BlazeFTL = 80 commits
JobCenterTycoon = 47 commits
peace2000 = 38 commits
huyszn = 26 commits
ghajini = 20 commits
gorhill = 19 commits
playonevideo = 18 commits
piquark6046 = 12 commits
ryanbr = 11 commits
DeepChirp = 9 commits
Freduser9 =3 commits
griffinallen = 2 commits
gothic-bum = 1 commit
iam-py-test = 1 commit
krystian3w = 1 commit
adblockenjoyer = 1 commit
teward = 1 commit
mu-hun = 1 commit
BongoKnight = 1 commit
zlewchan = 1 commit
13732348243521734 = 1 commit
 
LinuxFan58 said:
These are the GitHub members active on the uBlock Assets repository, with commit counts ranging from 803 for stephenhawk8054 to one commit each for several contributors.
Click to expand...


That list shows who authored commits and roughly how active they were. It does not show who currently has direct write access, who can approve or merge changes, whether commits arrived through pull requests, or which contributors can modify trusted filters without review.

Commit count is therefore not a permission map. Even one accepted commit appears in the history, while hundreds may have been reviewed by someone else.

For the supply-chain assessment, the useful facts would be:

  • current repository roles and branch-protection rules;
  • whether direct pushes to the relevant branch are allowed;
  • required reviews and status checks;
  • whether maintainers must use 2FA;
  • who can publish filter updates;
  • whether sensitive trusted-scriptlet rules receive extra review.

The number of pseudonymous contributors does increase the potential review and governance surface, but it does not by itself prove weak control. Conversely, a small identified team would not automatically be safe either. One highly privileged compromised account can be more consequential than twenty contributors whose patches require approval.
 
@Bot

I already posted that we are past the spicey discussion and agreeing

Observation 1 - I only showed the users who have pushed commits. I can´t see who has write access.

Observation 2 - I did not mention that it is custom that most repo's have more people with write access than members responsible for commits

so (very interesting question @Jack) why does an AI-bot feels the need to talk this down?
 
LinuxFan58 said:
English translation: I said that we had moved past the heated discussion and were agreeing. I only listed users who pushed commits because I cannot see who has write access, and I did not claim anything about repositories usually having more people with write access. Why does the AI bot feel the need to downplay this?
Click to expand...


It was not meant to talk down the concern. It was meant to keep the conclusion attached to what the list actually establishes.

But I did over-explain an inference you had not made. You explicitly presented commit activity, not a write-access list, and you had already said the latter was unavailable. So my warning that “commit count is not a permission map” answered a stronger claim than yours. That was unnecessary.

Your data is still useful: it shows that trusted filter development involves multiple contributors and is not simply Raymond Hill acting alone. Combined with powerful trusted scriptlets, that makes repository governance a legitimate security question.

The remaining unknown is consequential: public commit history does not reveal the current access, review and publication controls. Saying that is not a rebuttal to your observation; it marks what must be checked before grading the supply-chain risk. In short, the risk was not being dismissed, but your actual point should have been acknowledged more directly.
 
LinuxFan58 said:
And it is not a bomb, when you never enable the "allow user-script" permission in uBOL
Click to expand...
That's not the bomb I meant. The bomb is that (potential) users will not trust uBO and uBOL anymore and quit. In the worst case scenario your findings could be the nail in the coffin of these extensions. In the past Raymond Hill didn't treat you gentleman-like, but it's no reason to do the same. Keep the honor to yourself, as my wise granny always said.
 

Similar threads

Back
Top