@kdekooter opened this Issue on March 15th 2019

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=

image

@Findus23 commented on March 15th 2019 Member

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:

@kdekooter commented on March 15th 2019

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.

@kdekooter commented on March 15th 2019

Maybe moving it to the second position in the query string would suffice.

@tsteur commented on March 16th 2019 Member

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.

@fdellwing commented on March 16th 2019 Contributor

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.

@kdekooter commented on March 16th 2019

Yes but it is quite sensitive to .php extensions.

I ended up working around this by letting the client send tracking calls to /mtm instead of /matomo.php and rewriting this back on the server side with nginx:

location /mtm { 
   rewrite ^/mtm(.*)$ /matomo.php$1 break; 
}
@mattab commented on March 18th 2019 Member

Let's leave the ticket opened as it is a valid request (at least for some of our users, not all would agree) :ok_hand:

@tsteur commented on March 19th 2019 Member

btw you can also just POST instead of using GET requests and the action_name will be gone. Something like _paq.push(['setRequestMethod', 'POST']);.

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.

@kdekooter commented on March 19th 2019

Thanks @tsteur I tried that but it turns out POST requests to this URL are blocked (by Brave) as well.

@Shirkit commented on March 21st 2019

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.

@tsteur commented on March 21st 2019 Member

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 👍

@negreanucalin commented on October 3rd 2019

I think a more general approach should be made. For example the POC made for this covers all parameters, ad-blocking softwares are changing and more rules are being made.
For example uBlock Origin (v 1.22.4) matches idSite, send_image etc see here
I think this should be closed in favor of the POC.

Powered by GitHub Issue Mirror