Why YSK: Trackers don't do good for anyone except the platform, and they're not necessary to view the content in the URL.
It's courteous to not subject the recipient (most likely your friends and family) to this tracking. You're already sending them to the platform, which is tracking them in other ways. But you can help reduce that tracking by removing everything after the ampersand in the URL. Here are some examples.
Twitter example
URL: https://x.com/CookieSlayers/status/1623712884902567937?s=20
The s=20 is a Twitter-specific parameter to show that the tweet was copied from the web app. s=46 is iOS, and I can't remember what Android's code is. This is a relatively clean link, but there are some links that'll concatenate unique identifiers, like: https://x.com/CookieSlayers/status/1623712884902567937?s=20&t=Fn47fnSDJUD74bd9.
In this case, you'll notice there's also a &t= parameter, which is a unique identifier to the person who shared it.
The only part of the URL you need is https://x.com/CookieSlayers/status/1623712884902567937.
Instagram example:
URL: https://www.instagram.com/reel/CzP877du2EB/?igshid=MzRlODCFWFlZA==
The only part of the URL you need is https://www.instagram.com/reel/CzP877du2EB.
TikTok example
You'll notice TikTok's is a lot more readable in terms of what the URL contains.
The is_from_webapp parameter is self-explanatory, as is the sender_device, and then there's the identifier that's unique to you. In this case, 7302915057791436331.
The only part of the URL you need is https://www.tiktok.com/@inthepaintcrew/video/7301348328602717482.
The best route^1^ would be to use privacy-respecting frontends, but if you don't, simply deleting everything after the ampersand goes a long way.
^1^The best route would actually be to not use/reward platforms that are literally destroying humanity, but we're not there yet, so... in the meantime, let's just try to decrease the tracking and stop subjecting our friends and family to it as much as possible.
Not always, but it's a good rule of thumb.
It's getting worse too. Recently I've noticed Reddit links from friends looking like:
reddit.com/r/example/s/1234567Which then redirects to the actual
reddit.com/r/example/post/comments/1938473I believe Spotify and Tiktok do short tracker-filled links like that too. If you're on android, URLCheck can wrangle those links to find the actual content without the trackers. I've set it to intercept all clicked links so I can modify as needed.
On web / iOS, I'm not sure
I haven't checked how reddit does this but just from the example it seems like there is no anti tracking from the use of urlcheck that you're describing.
reddit appears to generate tracking link with a specific numeric identifier in their database, so instead of attaching a bunch of removable url parameters they instead do a lookup in their database and then redirect to the original destination.
this also means your app checking the redirect will need to fetch the url to determine the destination, which means their tracking still works just fine.
edit: a word
I've been meaning to look into how the URL expansion works. If it happened on the device then I guess it doesn't help much, but if it happens elsewhere it might fix the tracking?
It might also limit how much identifying information is attached to it. If the original link opens in my app, then they can tie accounts together. If it's wrangled by a third party app, then I open the clean link, they just get my IP address
If the goal is to share clean links, getting the url after the redirect accomplishes it. The tracking that's done isn't on your friends/whoever you share the link with, but done on the app. Which does generally defeat the purpose of their tracking.
true, my comment was primarily from the perspective of the recipient of tracking links
No, this applies to these specific parameters. Removing question marks and ampersands from urls will often break the pages if you don't know what you're doing or don't know what the parameters are for.
On YouTube, adding "&t=37s" starts the video at 37 seconds. It is pretty useful.
That is the full extent of my coding knowledge.
I don't know why "amp;" appeared. I didn't write it and it is not necessary. It's just the and symbol. Followed by t=__s
&is just the HTML entity for &.Not true on every site. Try it in your browser without the query string first before assuming that's the case. The app I work on, for instance, uses the query string to set date/time ranges and filter data.
Except when it's not.
Though I've always wondered if that's always consistently the case, and when that's not the case is there any mostly consistent way to identify the separator symbol in the URL text strings :/