$removeparam can not prevent the generation of specific param

[MkQtS]

Prerequisites

• I verified that this is not a filter issue (MUST be reported at filter issue tracker)
• This is not a support issue or a question
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• The issue is not present after wholly disabling uBlock Origin ("uBO") in the browser
• I checked the documentation to understand that the issue I report is not a normal behavior

I tried to reproduce the issue when...

• uBO is the only extension
• uBO with default lists/settings
• using a new, unmodified browser profile

Description

I've seen relevant issues #1767 and #1704. This is more a feature request, not actually a bug. I am not familiar with Reddit, so I post it here and sorry about that.

$removeparam didn't work in some cases when the page didn't reload. As for me, Bilibili video page (the link below) would generate a vd_source param when opening a clean link. The param value looks like a hash and was believed to track who shared the video. A rule like ||bilibili.com^$removeparam=vd_source cannot remove it in fact.

To prevent users from tracking, we can manual add a invalid value, like https://www.bilibili.com/video/BV1uV4y1W7Es?vd_source=stop_tracking, then the site would not change the param.

So, is it possible to add a new operator which allows a rule to preset/replace a param to prevent tracking? Maybe like ||bilibili.com^$replaceparam=vd_source&stop_tracking in my case.

A specific URL where the issue occurs

https://www.bilibili.com/video/BV1uV4y1W7Es

Steps to Reproduce

1. Add a custom rule ||bilibili.com^$removeparam=vd_source
2. Open the URL

Expected behavior

vd_source in url disappear.

Actual behavior

vd_source was removed but then regenerated by the site.

uBlock Origin version

1.44.0

Browser name and version

Chrome 104

Operating System and version

Windows 10

[gwarser]

I see ?spm_id_from= after navigating to different video. Nothing "regenerated", no hashes (which uBO does not touch).

[MkQtS]

I see ?spm_id_from= after navigating to different video. Nothing "regenerated", no hashes (which uBO does not touch).

It seems vd_source only generated for logged in users. I just tried in incognito window and vd_source didn't appear. It appears when I log in to Bilibili, just after opening the page about 1 second.

[gorhill]

Do you see in the logger any outgoing network requests with the vd_source parameter in it?

removed but then regenerated by the site

This makes the case the site is not using vd_source for tracking if a new value is assigned every time uBO removes it.

In any case, I decline the ability to assign specific value to existing parameter, this opens the door to security issues through filter crafting. The key part here is that with the mentioned filter, there are no outgoing network requests with vd_source query parameter as per logger.

[MkQtS]

Do you see in the logger any outgoing network requests with the vd_source parameter in it?

No, I didn't find such links in logger after it was removed.

If there is already a vd_source value, it will not change anymore. Bilibili may get the value through data packages. The way they can track users is, when A shares a video to B by copy and paste the current url, B would open the page with A's vd_source value, then Bilibili knows B is watch the specific video because A shared it to B.

Another condition is, when a controversial video is supposed to be shared publicly and anonymously, the one who wants to share actually expose to Bilibili if there is vd_source.

I got your point about security issues, it seems not wise to add such potential hazard ability.