Pastejacking filter needs clearer wording/possibly better design

[gitgizmo7]

Prerequisites

• This is NOT a YouTube, Facebook, Twitch, Spotify or a shortener/hosting site report. These sites MUST be reported by clicking their respective links.
• I read and understand the policy about what is a valid filter issue.
• I verified that this issue is not a duplicate. (Use this button to find out.). Comment in the old issue threads even when they are closed or even if you have a different problem.
• I did not remove any of the default filter lists, or I have verified that the issue was not caused by removing any of the default lists.
• I did not enable additional or non-default filter lists, or I have identified which specific stock list is causing the issue.
• I do not have custom filters/rules, or I have verified that the issue still occurs without custom filters/rules.
• I have verified that the web browser's built-in content blocker/tracking protection, network wide/DNS blocking, or my VPN is not causing the issue.
• I have turned off all other extensions and the issue still persists. (exception "Firefox Multi-Account Containers").
• If this is about a breakage or detection, I have verified that it is caused by uBlock Origin and isn't a site or browser issue.
• I have verified that the browser I am using is up to date with no pending updates.
• I did not answer truthfully to ALL the above checkboxes.

URL(s) where the issue occurs.

https://paaster.io/6a7de68ff8adec0f6a01bbd2#HfgbVCJy2CO-S4Y4VwwpLA-XBGyp9B5iE43nXU4mDTA

Description

Currently, the pastejacking filter (https://github.com/uBlockOrigin/uAssets/blob/master/filters/filters-general.txt#L3098) is somewhat intrusive, broken-looking (U+1F6C7 doesn't render on my Mac on latest Sequoia, in addition to the overall haphazard design), and doesn't clearly explain itself: where it comes from (I had to reverse-engineer this to pin down uBO as the culprit using the debugger in dev tools), why exactly a paste was blocked (for a non-technical user who doesn't understand pastejacking), or how you can disable it for a false positive (either by easily reporting a domain as safe or adding a custom exception filter). This is quite a bad experience for someone just trying to get work done by copying some harmless code from a forum: they may wrongly think the site or their browser is broken and not understand how to fix it.

Browser name and version

Brave 1.93.134

Other extensions used

none

Country

No response

Screenshot(s)

Screenshot(s)

Configuration

Details

uBlock Origin: 1.73.0
Chromium: 151
filterset (summary):
 network: 181066
 cosmetic: 43441
 scriptlet: 37381
 html: 0
listset (total-discarded, last-updated):
 default:
  user-filters: 0-0, never
  ublock-filters: 52886-85, 2m
  ublock-badware: 10136-17, 2m
  ublock-privacy: 4120-3, 2m
  ublock-unbreak: 2797-1, 2m
  ublock-quick-fixes: 519-0, 2m
  easylist: 84883-475, 2m
  easyprivacy: 56192-729, 2m
  urlhaus-1: 48285-11, 2m
  plowe-0: 3525-4, 2m
filterset (user): [empty]
userSettings: [none]
hiddenSettings: [none]
supportStats:
 allReadyAfter: 1135 ms
 maxAssetCacheWait: 7 ms
 cacheBackend: indexedDB

[gitgizmo7]

@uBlock-user could you explain why this was closed as outdated? Is there another discussion I didn’t see? I saw the fix for the broken character but my other concerns still stand about it being unclear where the prompt comes from, what it means or how to fix a false positive.

[uBlock-user]

Incomplete. Fill the template and the mention the filter you think is the issue.

[gorhill]

This has been addressed in internal discussion and some changes in the scriptlet: gorhill/uBlock@8a85e04

There is a plan to publish a revision in stable release channel.

[gorhill]

@gitgizmo7 We need to know where the false positive occurs so we can adjust the filter by excluding the site and possibly adjust the regex meant to detect the potentially malicious shell command.

[gitgizmo7]

@gorhill Thanks for chiming in, and apologies for the initially incomplete report. I've updated the discussion with a clear link to the filter and a link to a pastebin with a harmless trigger (osascript for a "Hello World" dialog as in my screenshot). That's a clear example of a false positive (the real one I encountered was a highly specific one-off LLM script, I can try to figure out why that triggered it but I doubt sharing the entire thing would be appropriate or useful). The web UI was hosted on a Tailscale serve domain (<machine-id>.<tailnet-id>.ts.net, sorta like personal dynamic DNS, likely safe but technically users can expose their machines to the wider internet with Tailscale funnel so it's possible a bad actor may use it as phishing infrastructure.

My larger concern has to do with the fact that the popup does not identify itself as coming from uBlock Origin and does not have an easy way to report or mitigate a false positive upon encountering it (in addition to why it even appeared, for a nontechnical user). It would be wonderful if every safe domain could be listed and the regex could catch every bad script without ever flagging a safe one, but given the somewhat brittle nature of doing it that way, false positives are likely to continue for the foreseeable future and it would be good if a user could learn what was going on without having to guess or reverse-engineer it like I did.

[stephenhawk8054]

every safe domain could be listed and the regex could catch every bad script without ever flagging a safe one

Never possible. No generic filters can assure no false positives 100% all the time, regardless of whatever methods being used. Anyone expecting that can use other tools that are willing to assure that.

---

The warning text will be changed so users can know it's from uBO. It's a new scriptlet against very widespread and complicated social engineering ClickFix attacks so false positives are always expected and we won't know how the situations would look like for larger user base. Hence currently it's only applied in MV2 first and we'll see how the reports look like.

[gitgizmo7]

Never possible. No generic filters can assure no false positives 100% all the time, regardless of whatever methods being used. Anyone expecting that can use other tools that are willing to assure that.

Yes, we’re in agreement :)
That was an illustrative statement to keep this thread on the topic of improving the presentation of the scriptlet rather than just whitelisting the one domain I had an issue with, as users will continue to encounter it in situations where it’s been triggered falsely. I’m glad this led to a productive solution, and this is awesome work overall!