This is missing some fundamental ones: gclid and dclid. Those are the parameters that identify a specific click from a specific user on a specific ad placement. They are the keys that Google uses on the back-end to join Google Analytics data with Google Ads (formerly AdWords) and DV360 (formerly DoubleClick) data.
The utm_ parameters are tame. They are very coarse-grained, usually representing "which budget did this ad come from" rather than anything about a user. They're ugly, which is enough reason to strip them, but gclid is also ugly, and much more identifying.
This is a bit of a fringe opinion, but I actually consider tools that block utm_ but leave gclid to actually be a decrease in privacy. A lot of people misconfigure their Google Analytics so that _utm params break the gclid. Stripping utms allows that join to happen.
I always preferred CleanURLs as it has an autoupdate feature, which pulls down this json file https://gitlab.com/KevinRoebert/ClearUrls/raw/master/data/da...
CleanURLs does include both gclid and dclid. From memory the other url cleaning addons required a new version of the addon.
You leave in the unique identifier, and then publish it under your real name, allowing all of those clicks to be attributed to your actual identity.
So here's a feature suggestion: instead of removing URL parameters, replace them with a randomly-generated value. Be careful to use the same length and character set (e.g. replace a hex id with only hex digits).
And also, set DNT=1.
That gives the digital marketing people an incentive to respect the DNT header, and an easy way to maintain data quality.
I think that this is a better strategy than blocking trackers and "cleaning" URLs. It shifts the economics of web tracking, which short of legislation, is the only way things are going to change.
Do you know of any other parameters like those, that can be safely removed? Maybe someone else here can list a few?
As much as I enjoy privacy, IMO it's a much bigger violation / risk to give my complete browsing history to some extension, especially since it can "read all your data". That means it can look at the HTML response of any page you visit which means access to your banking details, email account and everything you ever browse. That's all personally identifiable data.
I wouldn't even consider utm tags a privacy violation since it's really nothing more than a slightly more useful referrer header that's completely anonymous.
Any plugin that rewrites URLs can do all that. It so happens that ublock origin also needs this capability in order for it to function. So essentially, it boils down to a matter of trust. If I trust the extension developer enough, I would gladly install the plugin rather than doing nothing to stop the rampant privacy abuses.
> As much as I enjoy privacy, IMO it's a much bigger violation / risk to give my complete browsing history to some extension, especially since it can "read all your data".
That's some serious allegation. I just hope you had enough proof before you started pointing fingers.
> I wouldn't even consider utm tags a privacy violation since it's really nothing more than a slightly more useful referrer header that's completely anonymous.
How are referrer headers not a privacy violation?
It being open source doesn't guarantee what you see on GitHub is the code that the extension uses.
I'm not saying this author is acting maliciously but a very common attack is to say something is open source, point to the repo but in reality the code running in the extension is unrelated to that repo.
This often happens with packages installed by popular package managers. The home page of the package will be linked to GitHub so it appears to be open source but the package itself has different code because most of these package hosting sites don't pull in code directly from GitHub. The package author can publish code from a private closed source copy of the code sitting on their dev box and no one would ever know unless they looked at the source code after installing the package.
Now, when it comes to Chrome extensions I do believe there's ways to check out the source code of any extension you use, so you could double check it there but then you have to worry about the extension getting updated too.
The extension is small enough that you can inspect it yourself. Also, AMO addons are code-inspected by reviewers, unlike the chrome store.
>Now, when it comes to Chrome extensions I do believe there's ways to check out the source code of any extension you use, so you could double check it there but then you have to worry about the extension getting updated too.
That's why I disable addon updates for "uncommon" addons.
Are they still? Last I remember they started auto-accepting addons which passed the automatic tests and just maybe review them at a later point. Which could happen anytime between tommorow and next year. In the meanwhile the unsecure addon is floating around, endangering users.
There now is also this message:
"This is not a Recommended Extension. Make sure you trust it before installing."
This kinda indicates the user is on it's own with such extensions, and there is no review at all?
I've never been involved with performing code reviews for Chrome or FF extensions but I'm not sure this type of attack would be detected by a reviewer.
Because if all they do is take the HTML response and send it over to some web back-end with an ajax request, that looks innocent enough to any reviewer. For example, under what grounds would a reviewer flag that ajax request as malicious and prevent the extension from being published? It's not possible for them to know what purpose that data has for the extension unless they are really doing a deep dive on each review and take the extension's purpose into account based on their opinion of what it "should" do based on its description.
I'd love to hear back from anyone who happens to review extensions for either browser.
I think you're giving the reviewers too little credit. There's no plausible reason why you'd need to send urls to a server to perform such a trivial transformation. Also, a search of BMO shows that addons are regularly being found to breach these policies and blacklisted.
 https://bugzilla.mozilla.org/buglist.cgi?product=Toolkit&com... control-f for "Add-ons collecting ancillary data".
This extension does not do that. Most extensions with the "Access your data for all websites" permission also do not do that. The permission is required to scan data (in this case, links) in the websites visited by the browser, and does not mean that the data in the website would necessarily be sent to a server. Neat URL processes the links locally.
You can inspect the source code of any WebExtension you have installed by downloading the package, renaming it to the .zip extension, and unzipping it (as .xpi files are equivalent to .zip files). For Firefox add-ons, right-click the "Add to Firefox" button on the extension listing, and click "Save Link As...". The code is not minified or obfuscated.
That's extremely not innocent for ANY browser extension.
What if it got a list of every link on a page and sent that and then claimed it did that to better improve the extension by figuring out which query params aren't necessary and claimed that these links help train their app / extension.
That seems reasonable on paper, but it's a wildly over the top violation of your privacy and is only slightly less invasive than an entire page response.
I don't think the above example would get denied by a reviewer and it still uses the same "can read and modify" permissions as the current extension in its current form.
We really only ever notice the permission setting because the browser puts that in front of us before agreeing to install it and it's usually a 1 liner like "hey, this extension can access everything about your browsing history".
What is this? A CLI tool? A website? A browser extension?
Had to look in the comments to tell – what a desaster.
On the other hand, Neat URL's rules apply to all domain, so it won't make short Amazon links, but you can add your own rules.
I've shared instructions for inspecting the source code of a Firefox add-on elsewhere in this discussion:
WebExtensions like Neat URL continue to work even if you don't update it. You only have to inspect the extension code once (no developer mode needed) if you are skeptical, and you don't have to update it if you don't want to.
Removing those pesky get-parameters aint enough to keep a BOM link list in line
I really like Stack Overflow's URLs because of how flexible they are. You can put anything in the title slug, since only the ID is used. When self-documenting links aren't useful, then you can omit the title slug completely.
For example, these four links all point to the same page (in a code block so they don't get truncated):
I've had a few occasions to use this to good effect
My solution is to use uBlock Origin and block tracking altogether.
This still allows GA to track you, it just removes some information from the tracking beacon.