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
Move action_name
query parameter off first position so requests do not get ad-blocked
#14207
Comments
Correct, the EasyPrivacy list used by ublock and others is blocking the .php?action_name string. So there is no bug in Matomo and everything is working as intended :slightly_smiling: |
Agreed that is not a bug. But is being blocked by an adblocker intended? Can we somehow work around this? I set up matomo with the specific purpose of not being blocked by privacy addins. |
action_name
query parameter configurable so it does not get ad-blocked
action_name
query parameter configurable so it does not get ad-blockedaction_name
query parameter configurable / rename it so it does not get ad-blocked
Maybe moving it to the second position in the query string would suffice. |
action_name
query parameter configurable / rename it so it does not get ad-blockedaction_name
query parameter to second position so requests to not get ad-blocked
action_name
query parameter to second position so requests to not get ad-blockedaction_name
query parameter to second position so requests do not get ad-blocked
action_name
query parameter to second position so requests do not get ad-blockedaction_name
query parameter off first position so requests do not get ad-blocked
I think there's not too much point cause ad blockers will eventually just find a different way to detect it. It would maybe work for a few weeks and then fail again. |
EasyPrivacy list still does not block matomo(js|php), so there is hope. |
Yes but it is quite sensitive to I ended up working around this by letting the client send tracking calls to
|
Let's leave the ticket opened as it is a valid request (at least for some of our users, not all would agree) 👌 |
btw you can also just POST instead of using GET requests and the action_name will be gone. Something like You won't be able to use log analytics to replay tracking requests with that, but most people don't do this anyway. I would say this issue is pretty much resolved and any further solutions would probably need to be developed in some plugin as we likely won't change it anyway. |
Thanks @tsteur I tried that but it turns out POST requests to this URL are blocked (by Brave) as well. |
If there's one thing I've learned is that blockers will block you. Their goal is to block analytics and tracking on client-side, so if you try to trick them, they'll just find a workaround. The people who put out the lists do no want to be tracked online. It all started with annoying ads, then when remarketing showed up, now all analytics suffer as well. |
my thinking too 👍 |
Unfortunately the POC issue was closed because "we don't really want to work around ad blockers / privacy lists in such a way at this stage". Leaving us with blocked requests, severely limiting the reliability of analytics data. |
I'll repeat my comment: the more sneaky ways analytics try to track users, the more ad blockers will push back. You don't seem to understand this. Grab server side tracking data and combine it into your analytics. For now, since they'll start to scramble that data as well. |
@Shirkit Totally agree with the sneaky argument. I tried to be not-sneaky by self-hosting an open-source analytics solution on my own domain. I did not expect to be defeated by an ad-blocker while tracking my own authenticated users. |
that's completely false. you just need to obfuscate based on some seed that is unique to each mamoto user. ad blockers can only block file names and urls, things that are easily regexable. anything else is too much overhead for an adblocker. it's extremely trivial to get around ad blockers for analytics purposes and mamoto should make it easy to do so, because that's one of the main reason to use it. |
@dave-dm you can simply force the tracking to use POST requests. So no ad blocker will be able to block the requests based on GET parameters |
thanks that works, I couldn't find anything about how to solve it on google. |
Blockers like PrivacyBadger block POST requests as well... |
fortunately it's not that popular yet, POST seems to bypass the most popular ones. I think mamoto should add optional random obfuscation of the 'request' variable with a custom seed initialized at installation. as well as custom obfuscation of mamoto.js. that would make it forever ad blocker proof, and really wouldn't be that hard. |
Despite being on the exact same domain as the website uBlock still blocks calls to matomo. It seems to block based on the phrase
.php?action_name=
The text was updated successfully, but these errors were encountered: