windowsreport.com: ads

[3xploiton3]

Prerequisites

• This is NOT a YouTube, Facebook, Twitch 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 filter lists, or I have verified that the issue still occurs without enabling additional filter lists.
• I am not using uBO Lite along with other content blockers.
• I have verified that the issue still exists after using the Complete filtering mode.
• 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 verified that other extensions are not causing the issue.
• If this is about a breakage or detection, I have verified that it is caused by uBOL Lite and isn't a site or browser issue.
• I did not answer truthfully to ALL the above checkboxes.

URL address of the web page

https://windowsreport.com/how-to-stop-microsoft-edge-from-screenshots/

Category

ads

Description

ads

Other extensions used

no

Screenshot(s)

Screenshot(s)

Configuration

version: uBOL 2024.12.23.23
mode: complete / complete
rulesets:
 default
 annoyances-cookies
 annoyances-overlays
 annoyances-others
 urlhaus-full
 openphish-domains
 idn-0

[stephenhawk8054]

@gorhill Hmm... weird, this filter

/^https:\/\/[0-9a-f]{10}\.[0-9a-f]{10}\.com\/[0-9a-f]{32}\.js$/$script,3p,to=com

works in Firefox but somehow the regex not matched in chromium? Happens in uBO chromium as well

If I change the $ at the end to \b, it works

/^https:\/\/[0-9a-f]{10}\.[0-9a-f]{10}\.com\/[0-9a-f]{32}\.js\b/$script,3p,to=com

[gorhill]

Need to investigate. I stepped into the code and I can see the regex internally is ^https:\/\/[0-9a-f]{10}\.[0-9a-f]{10}\.com\/[0-9a-f]{32}\.js$, which matches https://577c231052.a91e9c75f8.com/1f73d9b08f0e105bc80ef1970dafe1db.js, but no match is found when using the following in uBO's dev tools page (after adding ||a91e9c75f8.com^$badfilter):

snfe?https://577c231052.a91e9c75f8.com/1f73d9b08f0e105bc80ef1970dafe1db.js
url: https://577c231052.a91e9c75f8.com/1f73d9b08f0e105bc80ef1970dafe1db.js
not blocked

---

Never mind, it is blocked when supplying the proper context:

snfe?https://577c231052.a91e9c75f8.com/1f73d9b08f0e105bc80ef1970dafe1db.js script example.com
url: https://577c231052.a91e9c75f8.com/1f73d9b08f0e105bc80ef1970dafe1db.js
type: script
context: example.com
blocked: /^https:\/\/[0-9a-f]{10}\.[0-9a-f]{10}\.com\/[0-9a-f]{32}\.js$/$script,3p,to=com

However it's not blocked as per logger.

---

Never mind again, it is blocked according to the logger:

So not sure why it didn't work on your side. In uBOL it might not work though because the regex might be rejected by the DNR API, it should be shown in the dev tools console if so.

[stephenhawk8054]

In uBOL it might not work though because the regex might be rejected by the DNR API

Hmm... When I checked the log.txt file in uBOL-home, I didn't see the filter being listed as rejected?

[gorhill]

The regex is a valid RE2 regex, so it passes the compile-time test and a rule is created for it. However there is a further test at run-time using isRegexSupported() before the rule is used and that test fails, and these are reported at the console. See uBlockOrigin/uBOL-home#15 (comment).

Unfortunately isRegexSupported() is browser-dependent and this cannot be used at rule compile-time, there is an open webextensions issue about this: w3c/webextensions#344.

[stephenhawk8054]

Ah I see, I always thought isRegexSupported is at compile-time.

About browser-dependent, is it different depending on users' machine power as well, or all chromium browsers would be the same? If it's the former, that would be really difficult to evaluate the filters.

[gorhill]

I expect all Chromium-based browsers would be the same, but since it's currently implementation-dependent and not API-dependent, there is no 100% guarantee.

It's the reason for the webextensions issue I linked above, to make it easier for extension authors to figure out at rule compile-time what is a valid regex and what is not, but beside a bit of talk about it in August 2023, nothing has moved forward.