`utm_*` parameters are not stripped - making extension useless in some cases

[scraunt]

Tracking Token Stripper 2.10 / Firefox 130.0 / Windows 10

When navigating to https://www.plex.tv/blog/plex-pro-week-24-does-your-server-suck-energy/?utm_internal=pro_week_tim_blog_24 the UTM parameter is not stripped.

From having a quick glance it looks to be the same issue as in #62 & #64

Those issues were just closed (would be helpful to have included the reason) - are there any plans to fix / investigate this?

I think on balance it is fair game to strip anything with ?utm_*=. I see the #63 Custom parameters issue exists, this would solve this problem. Are there any plans to implement this feature? What would be the limitation on this feature being added?

If the feature is not / cannot be implemented then there should be some sort of note to alert users to the fact that this extension does not block all kinds of UTM parameters - whether this is a technical limitation or not.

Finally, thank you for creating this extension in the first place.

[jparise]

When navigating to plex.tv/blog/plex-pro-week-24-does-your-server-suck-energy?utm_internal=pro_week_tim_blog_24 the UTM parameter is not stripped.

I made the choice to only remove an explicit list of parameters (i.e. not the pattern utm_*) to avoid unintentionally breaking sites. (I agree it's unlikely that a site would name a functional parameter something like utm_payment_confirmation, but better safe than sorry.)

I hadn't seen the utm_internal parameter before, but support for removing it could be added.

The full list of utm_-prefixed parameters this extension strips is listed in the README. I'll repeat them here:

• utm_source
• utm_medium
• utm_term
• utm_campaign
• utm_content
• utm_cid
• utm_reader
• utm_referrer
• utm_name
• utm_social
• utm_social-type

From having a quick glance it looks to be the same issue as in #62 & #64

Those issues were just closed (would be helpful to have included the reason) - are there any plans to fix / investigate this?

• utm_id not stripped from URI; New token discovered: utm_klaviyo_id #62 was closed as a duplicate of Doesn't apply to the links in Gmail #55, which is still open.
• Strip utm_klaviyo_id #64 is a pull request that added support for stripping utm_klaviyo_id (which I missed adding to the above list) and was closed once that code was merged.

I think on balance it is fair game to strip anything with ?utm_*=. I see the #63 Custom parameters issue exists, this would solve this problem. Are there any plans to implement this feature? What would be the limitation on this feature being added?

I have no plans to implement #63 myself. There are other, similar extensions that offer that level of customization. I've listed some of them in the README.

If the feature is not / cannot be implemented then there should be some sort of note to alert users to the fact that this extension does not block all kinds of UTM parameters - whether this is a technical limitation or not.

I think the README is pretty clear about which parameters are stripped.

Finally, thank you for creating this extension in the first place.

You're welcome!

[jparise]

I added support for stripping utm_internal in d05004c.

[scraunt]

Thank you for such a detailed response, and for addressing each of my points. I really appreciate it. All the best to you!