Comment by safeshare | Hacker News Reader

Comment by safeshare | Hacker News Reader

I built a tiny browser-based tool called SafeShare. You paste a URL, it removes common tracking parameters (utm_source, gclid, fbclid, etc.), tries to unwrap obvious redirect parameters (url=, redirect=, u=…), and shows you a cleaner link to share.

There is no login, no accounts, no tracking cookies – it runs as a simple web app on GitHub Pages and processes links locally in the browser.

It’s intentionally limited to “link hygiene” and transparency: – It’s not a full security scanner. – It does not follow every redirect hop across the network. – It focuses on cleaning links you want to share (mail, messenger, newsletter, social), not on doing deep inspection. App: https://j-ai-71.github.io/Supersystem/app.html Code: https://github.com/j-ai-71/Supersystem

I’d be happy about feedback from this crowd: – Would you actually use a tool like this in your own workflow? – Which parameters or patterns would you expect it to handle that it doesn’t yet? – Is the UX clear enough, or is something confusing/over-engineered?

Any comments, criticism or “this is useless, but here’s what would be useful instead” are welcome.

Neat, I remove all POST strings as a habit; I probably mistakenly assume most intermediate skill users would also. Using a webpage to do so would be helpful for more complicated links where the url POST data includes the content ID in one of the strings

I would imagine what you have would be far more useful to HN folks if you add some type of attribution system - meaning parse the URL, identity the tracking strings, and then tell the user what each string one does.

Then let the use check a radio box to re-appeand the desired tracking string to the url(. Maybe add the option to edit the string?

Thanks a lot for the thoughtful comment.

You’re right that for many HN folks the interesting part is not just “make the URL shorter”, but understanding what is being removed and being able to keep / edit specific bits. Right now SafeShare is deliberately “dumb & small”: it only sees the URL string in the address bar and strips parameters that match a simple list/heuristic (UTM, gclid, fbclid, some obvious redirect params etc.). It doesn’t look at the request method – so it’s really working on query strings, not HTTP POST bodies.

I like your idea of an attribution / explanation layer, e.g.: • parse the URL and list detected tracking params, • show a short label for each (utm_source → source, campaign attribution, etc.), • let the user tick which ones to keep/remove, maybe even edit values, • then regenerate the final URL.

That would probably live as an “advanced” or “details” view so that the default flow stays as simple as: paste → clean → copy/open.

I’ll experiment with a prototype of that – even just a “show what was removed and why” panel would already be a useful first step. Thanks again for pushing me in that direction.

If you have a few real-world URLs where you’d want to keep/edit specific params, I’d be happy to use them as test cases.

Reply on news.ycombinator.com