feat(YouTube / YT Music): Remove share sheet copy-link tracking

[SodaWithoutSparkles]

Application

Youtube / YouTube Music

Issue

Youtube and YouTube Music now has a mysterious si string after the link you copied. I suspect it is used for tracking since it can be removed safely w/o affecting the link.

Steps to reproduce:

1. watch a video
2. use the share button next to the like/dislike button
3. click copy link
4. paste it somewhere
5. notice the si string
6. remove the si string, it still goes to the same video

Example: https://youtu.be/dQw4w9WgXcQ?si=-UhfzBGGTwpm5Hzi

Patch

Remove the ?si=XXXXXX string after copying

Motivation

This increased user's privacy, and saves the planet by sending less characters over the internet therefore reducing energy usage and carbon emissions.

Also there is a equivalent patch for reddit (sanitize-sharing-links).

Acknowledgements

• [X] I have searched the existing issues and this is a new and no duplicate or related to another open issue.
• [X] I have written a short but informative title.
• [X] I filled out all of the requested information in this issue properly.

[LisoUseInAIKyrios]

It also affects shared playlists.

The ReVanced copy url player buttons do not have the tracking parameter. The tracking parameters only affect the built in share function.

[xDARKxDEVILx]

I love the motivation lmao

[oSumAtrIX]

Hardly any motivation provided considering that users privacy is unchanged as tracking affects the person the link was shared to, no who sends it, which at this point the sender can already remove the query parameter from the link already. Please add a sufficient motivation.

[SodaWithoutSparkles]

We don't actually know what information is included in the si parm as it is obfuscated. It could be client information, or location info (sender's location), or whatever.

The same argument can be made for reddit's sanitize sharing links patch, just that reddit is more clear on what is actually tracked, but youtube obfuscates them.

If the equivalent patch for reddit is implemented, there's no reason this shouldn't be.

The ReVanced copy url player buttons does not have...

People may wish not to include it as it cluttered the UI.

And the only way to share playlist is by the stock (with tracking) button.

[oSumAtrIX]

Just because the feature already exists for Reddit, does not justify it having to exist for anything else. Neither is it important, what the si parameter means, my previous points remain unanswered.

[SodaWithoutSparkles]

Hardly any motivation provided considering that users privacy is unchanged as tracking affects the person the link was shared to, no[t] who sends it

The tracking affects the sender as it is information collected from the sender not the reciever.

which at this point the sender can already remove the query parameter from the link already.

Increased effort

[oSumAtrIX]

The increased effort is negligible

[SodaWithoutSparkles]

The increased effort is negligible

The increased effort for adding/removing the timestamp is also negligible but people still demanded it.

Most people dont know what it is, thought it was necessary, and keep it there, not even knowing that they were tracked.

[oSumAtrIX]

If the user does not know what it is, then the patch is not useful to them to begin with. And yes, removing the timestamp is negligible, but not adding it because you don't remember what to add.

[geominorai]

The tracking parameter also got added to sharing links to user profile pages.

[geominorai]

I would imagine this could affect link embeds as well, such as on Discord. The embedded player normally would play not logged in but if one expands the video by it by clicking on the title, related videos, etc. the resulting browser popup could associate the video sharing with whichever account was logged in at the time.

[ego-lay-atman-bay]

I think the best reason is because if there are url parameters that are not necessary, it takes up more space than needed. People love short urls. I mean, why put extra text in urls if they don't do anything to change where the url goes to?

Yes, the tracking part is a good reason, but it's not immediately obvious (due to the fact that oSumAtrIX can't seem to understand why this is important).

[oSumAtrIX]

Space does not matter, especially not, if its just a couple of characters.

[ego-lay-atman-bay]

And by a couple, you mean 20 characters? Also space does matter, especially on websites that have a limited comment / post size.

[oSumAtrIX]

And by a couple, you mean 20 characters?

Absolutely.

[oSumAtrIX]

Also space does matter, especially on websites that have a limited comment / post size.

In edge-case scenarios that happen almost never you can freely trim the string off the query parameter yourself. Size as an argument does not work here.

[ego-lay-atman-bay]

Personally I think this is a needed patch, regardless of who is going to use it.

[SodaWithoutSparkles]

It is hilarious to see youtube using shorterned URLs (youtu.be/videoid instead of youtube.com/watch?v=) to reduce the length of the URL, then adding a tracking parm back to inflate it again.

[Joshix-1]

Shouldn't it be enough motivation that it's annoying and useless? My reasoning why I hate the si parameter and want my youtube app to auto remove it:

• I'm lazy, why should I take the time to remove it?
• it's ugly
• it probably tracks both me and the receiver (youtube will know that we know each other)
• it wastes space
• it makes the url less readable
• it makes messages containing the link more cluttered
• while manually removing, removing one char to many breaks the url
• there's no good reason to have it there

I mean, I get that it is probably annoying to implement and maintain, but that's not a good reason against the feature. Just don't implement it yourself, and wait for someone else to do it.

[ego-lay-atman-bay]

Exactly!

[oSumAtrIX]

Shouldn't it be enough motivation that it's annoying and useless?

No, the effort of implementation requires good motivation, it doesn't disturb the process of sharing a link, which greatly argues against putting effort into it without any counter motivation

Half of your points are invalid such as space or readibility, or duplicate such as readability and clutter. Links serve the purpose of sharing a connection not to look good. So far no good points from your side

[ego-lay-atman-bay]

It takes more time to continuously keep removing the parameter when you share a link than creating a patch to remove it automatically.

[oSumAtrIX]

If the effort is not worth the tracking mitigation you can simply not trim it

[ego-lay-atman-bay]

So far no good points from your side

I have also not heard any good points on your side either. They're just, "your reasons are invalid", which is an invalid reason.

[oSumAtrIX]

Ive explained why they are invalid previously but i will not repeat myself. Check my previous comments for why as well as good points

[Joshix-1]

it doesn't disturb the process of sharing a link

for me it does

Links serve the purpose of sharing a connection not to look good.

I hate seeing links with useless query parameters, it just looks unprofessional.

If the effort is not worth the tracking mitigation you can simply not trim it

It's worth the effort to remove the param. But it's really annoying to do it all the time. One hero that implements it here could save many others much time.

You don't think it's worth it, but that doesn't make the issue invalid for others. You don't need to implement it, but I don't get why you argue against it.

[oSumAtrIX]

Explain in detail how it disturbs the process of sharing a link.

Once again links aren't meant to look pretty, the same ways horses aren't meant to fly.

You can not assess the effort of removal, and remains unexplained too, so still no. I am not sure where I said the issue is invalid. If it were, I'd already closed it. This remains a patch request that I can deny or accept. I am arguing against it for the reasons I have mentioned above.

[Joshix-1]

Everytime I share a link I have to manually remove a tracking param. That disturbs the process of sharing a link. Everytime it takes a few seconds as I have to be careful to not remove too much of the link. I want my links to look pretty. Why should they not look pretty? Some people make their horses pretty, I want to have my links short and pretty.

But the most important reason is the tracking. I don't want google to know which persons I send video links and which services these people use. When I share a tracking link on github and people click on it, google will know I probably use github as the browser of the receiver sends a Referer header

[oSumAtrIX]

No, removing the tracking param disturbs the process of mitigating tracking, not sharing links. The purpose of links are to share content, not to look pretty; And horses are not your personal play toy to look pretty for your personal interest.

If tracking is your problem refer to my previous comment: https://github.com/ReVanced/revanced-patches-template/issues/414

[Joshix-1]

No, removing the tracking param disturbs the process of mitigating tracking, not sharing links.

What? Removing the tracking param is the process of mitigating tracking. Mitigating tracking (removing the tracking param) disturbs the process of sharing links.

If the effort is not worth the tracking mitigation you can simply not trim it

it's worth it, but still annyoing

And horses are not your personal play toy to look pretty for your personal interest.

I agree, but it's off-topic and some people still treat them like that.

The purpose of links are to share content, not to look pretty

Just repeating the same thing over and over doesn't help anybody. That's just a matter of opinion. Some care, you don't. I get it.

[oSumAtrIX]

It disturbs the process because it takes effort, and not the process of sharing links which was provided as an (invalid) argument.

No hs nothing to do with opinion, links are objectively not meant to look pretty, thats not their purpose.

[Joshix-1]

Are humans meant to be pretty? What even is meant to be pretty? I want my messages to look clean and that includes the links. If they are too long they take up too much space, making me scroll too much.

But most importantly I don't think that you provided good counter to the tracking argument.

[oSumAtrIX]

Yes they are, has evolutionary and biological reasons. If you want your messages to look clean a tracking param consisting out of couple characters can be removed with no additional considerable cost in effort.

This is why the issue is still open.

[LisoUseInAIKyrios]

I tried to find where the share sheet is used, and found what appeared to be the code that handled it (had the right text labels and everything). But after patching I found it's old dead code that's never used (not even when spoofing to 16.x).

The actual share sheet is handled entirely using litho components (which is a slightly bigger hassle).

Maybe it can be patched in one of the numerous methods that copy text to the clipboard. Or better, find the clipboard method that's used then trace it back so the url is sanitized for all share actions. It's just a matter of someone figuring it out (who wants to fire up JadX and start patching every possible location??)

[oSumAtrIX]

The API can be hooked, and then the caller can be found. It shouldn't be too difficult and certainly easier than reversing how Litho does it. Funnily, Litho is open source, but we struggle with it. I assume some handler is called from the Litho framework when a Litho component is clicked.

[ego-lay-atman-bay]

The guy who is working on uYouPlusExtra (fork of uYouPlus, which is the ios modified youtube app) has already found a solution. I don't know if it's similar on android, but it might point you in the right direction. https://github.com/arichorn/uYouPlusExtra/issues/96#issuecomment-1699863721

[heartlog]

I highly request the inclusion of a specific feature. There are notable privacy concerns surrounding the "si" parameter in YouTube links, as it changes every time a link is shared or a YouTube URL is accessed.

For example:

• Initial share: https://youtu.be/PkiEHuGx8ug?si=_PTH2fzKxvxviEYL
• Second share: https://youtu.be/PkiEHuGx8ug?si=E2wjGETZwUE43yao
• Third share: https://youtu.be/PkiEHuGx8ug?si=f2itBmhdbIFY1i4Q

To test this behavior, one can simply close and reopen the YouTube video several times.

Many users, like myself, rely on bookmarking applications such as Raindrop.io. These apps often prevent the addition of duplicate entries by comparing URLs. However, due to the changing "si" parameter, the same video may be added multiple times to a collection.

Therefore, I kindly request the addition of an option to share YouTube links without including the "si" parameter. This feature would save users time and reduce the occurrence of duplicates in their collections. Ultimately, the decision to implement this feature rests with the ReVanced development team, and we should respect their discretion in this matter. Thank you.👍

[heartlog]

@SodaWithoutBrain @ego-lay-atman-bay until the patche is added, you can try this solution. https://github.com/ReVanced/revanced-patches-template/issues/294

[SodaWithoutSparkles]

@oSumAtrIX actually why is the "waiting on author" tag still here, after the orginal question answered by multiple participant?

[oSumAtrIX]

It doesn't really matter, when I forget to remove it I usually remove it when I filter for the tag once in a while and see the tag can be removed, or close the issue

[KobeW50]

@SodaWithoutSparkles can you add YTM in the issue description as well?

[ghost]

+1 for the issue, I also think that since si serves no visible purpose for the user (and can be safely removed with the shared link still working), I don't see why ReVanced should keep it. At least there should be an option to strip those when sharing videos, even if it'll be disabled by default.

[geominorai]

The tracking parameter appears to be removed in the clipboard when tapping copy link but unfortunately still appears in links when selecting an app to share it directly to.

[oSumAtrIX]

Open a new issue