-
-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(YouTube / YT Music): Remove share sheet copy-link tracking #414
feat(YouTube / YT Music): Remove share sheet copy-link tracking #414
Comments
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. |
This comment was marked as off-topic.
This comment was marked as off-topic.
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. |
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.
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. |
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. |
The tracking affects the sender as it is information collected from the sender not the reciever.
Increased effort |
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. |
If the user does not know what it is, then the patch is not useful to them to begin with. |
The tracking parameter also got added to sharing links to user profile pages. |
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. |
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). |
Space does not matter, especially not, if its just a couple of characters. |
And by a couple, you mean 20 characters? Also space does matter, especially on websites that have a limited comment / post size. |
Absolutely. |
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. |
Personally I think this is a needed patch, regardless of who is going to use it. |
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. |
Shouldn't it be enough motivation that it's annoying and useless?
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. |
Exactly! |
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 |
It takes more time to continuously keep removing the parameter when you share a link than creating a patch to remove it automatically. |
If the effort is not worth the tracking mitigation you can simply not trim it |
I have also not heard any good points on your side either. They're just, "your reasons are invalid", which is an invalid reason. |
Ive explained why they are invalid previously but i will not repeat myself. Check my previous comments for why as well as good points |
for me it does
I hate seeing links with useless query parameters, it just looks unprofessional.
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. |
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. |
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 |
No, removing the tracking param disturbs the process of mitigating tracking, not sharing links. If tracking is your problem refer to my previous comment: |
What? Removing the tracking param is the process of mitigating tracking. Mitigating tracking (removing the tracking param) disturbs the process of sharing links.
it's worth it, but still annyoing
I agree, but it's off-topic and some people still treat them like that.
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. |
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. |
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. |
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. |
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??) |
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. |
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. arichornlover/uYouEnhanced#96 (comment) |
hmm. the code wasn’t finished and also the code was made with the iOS YouTube App. But it’s definitely possible on android if you find it on there |
This comment was marked as duplicate.
This comment was marked as duplicate.
@SodaWithoutBrain @ego-lay-atman-bay |
@oSumAtrIX actually why is the "waiting on author" tag still here, after the orginal question answered by multiple participant? |
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 |
@SodaWithoutSparkles can you add YTM in the issue description as well? |
This comment was marked as duplicate.
This comment was marked as duplicate.
The tracking parameter appears to be removed in the clipboard when tapping |
Open a new issue |
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:
Example: https://youtu.be/dQw4w9WgXcQ?si=-UhfzBGGTwpm5Hzi
Patch
Remove the
?si=XXXXXX
string after copyingMotivation
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
The text was updated successfully, but these errors were encountered: