@sambuev opened this Issue on March 4th 2015

Hello, I have Piwik installed on my hosting with secret address: interes.site.com/sm/
and I have renamed piwik.php piwik.js to sm.php sm.js and I though it cannot by caught by AdBlock but unfortunately AdBlock on my Safari browser easily blocking Piwik and many other users with their Adblock (on Chrome, Firefox) out of my view :(

screen shot 2015-03-04 at 18 21 38

What can I do to avoid blocking Piwik?
Is it possible to avoid it?

@MESWEB commented on September 13th 2015

I got this same error but I think this is difficulty for dev piwik

@kylekatarnls commented on September 13th 2015 Contributor

I use rewriting and replace /piwik.php with juste /p. Works like a charm.

@MESWEB commented on September 13th 2015

Can You give any solution? I trying this but without success with uBlock - https://www.codelibrary.me/tag/ad-block/

@kylekatarnls commented on September 15th 2015 Contributor

This is what I did (but with a proxy-pass in the same domain).

First remove "analytics" in the URL when you enter the rewrite rule and any word that can be seen as ads.

Then if it's not enough, use a proxypass (http://httpd.apache.org/docs/2.2/fr/mod/mod_proxy.html) on your own domain, so your URL to call Piwik will just look like "/p" and "/j"

(function() {
    _paq.push(['setTrackerUrl', '/p']);
    _paq.push(['setSiteId', 1]);
    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
    g.type='text/javascript'; g.async=true; g.defer=true; g.src='/j'; s.parentNode.insertBefore(g,s);
  })();
@Joey3000 commented on September 15th 2015 Contributor

Guys, have you tried just replacing "piwik.php" and "piwik.js" in the tracking code with "js/", as described in https://github.com/piwik/piwik/blob/master/js/README.md? No .htaccess rewriting, file renaming, etc. needed.

See also:
http://forum.piwik.org/read.php?2,83940,125929
http://forum.piwik.org/read.php?4,14971

I've been using that for years. Just make sure that the "piwik" string (or any other string blocked by the ABP) doesn't appear anywhere in the URL (i.e. domain name, directories). After coming across this issue report, I've just tried it again with ABP on Firefox and it doesn't block it. I checked the ABP "easyprivacy" list again, and it only checks for the "piwik" string anywhere in the URL.

P.S.: Another solution is in https://piwik.org/faq/how-to/#faq_132, but that would require the server being able to make outbound connections.

@MESWEB commented on September 15th 2015

Non of all solution what You give not working with uBlock! I think the uBlock is hard to defeat. Only solution is use any server-side tracker. Piwik should use server-side tracking by default.

@Joey3000 commented on September 15th 2015 Contributor

@MESWEB From https://addons.mozilla.org/en-us/firefox/addon/ublock-origin/:

Out of the box, these lists of filters are loaded and enforced:

- EasyList
- Peter Lowe’s Ad server list
- EasyPrivacy
- Malware domains

Any chance your Piwik URL doesn't pass any of those?

@Joey3000 commented on September 15th 2015 Contributor

There is following investigation necessary:

  • If the filter lists can include not just Piwik installation URL parts, but also URL parameters. (I tried the lists provided in the original issue post with ABP on Firefox and Piwik was not blocked. But I haven't checked if the "Peter Lowe’s Ad server list" also used by ublock includes URL parameters. Or if any other list could do that.)
  • If the ability by the plugin to check the parameters is browser dependent (e.g. due to some browser restrictions). Since the original issue post refers to Safari.

And if the block can be URL parameter based, it could be the time for a Piwik plugin where the user could freely change them. (I don't know how deep into the rabbit hole one would need to go to do that.)

@kylekatarnls commented on September 22nd 2015 Contributor

@MESWEB Piwik was using server-side (it was called phpMyVisites), but for many reasons (performances, security) it has been switched to client-side and it's a good thing. I use proxypass + url-rewriting (it's exactly equivalent to the solution mentionned by @Joey3000, but it is faster because it does not use PHP) and uBlock does not block this solution.

@MESWEB commented on September 30th 2015

Yes I know it and I try changing url or filenames and dynamic changed filenames with .htaccess with RewriteRuele but without effect. I saw something strange - Any of my browser (Opera, Chrome, Waterfox) hasn't be counted by piwik but when Author of the PIWIK goes on my site I see his log in PIWIK. So my question is WTF? I'm not only one with this strange bug.

@kylekatarnls commented on October 5th 2015 Contributor

Maybe you missclicked on uBlock and add a filter in your browser try to reset uBlock. Else, if all your stuff is on the same domain, it should not be blocked as uBlock does not search in the response body but only in request URLs.

@bdore commented on May 22nd 2017

Ok so I was able to go around Opera's built-in adblocker with some major changes to PiWik. I'm still testing to see if it holds together after deploy. This was tested only on a local server and PiWik self-hosted:

  • Opera has an option to send "do no track" requests which are respected by PiWik. I did not find a workaround for that but I figure if the user goes that far I might as well respect that.

Changes I made to the PiWik installation files:

  • rename installation directory to p
  • p/piwik.js renamed to p.js
  • p/piwik.php renamed to p.php
  • main script array _paq renamed to yourArray. Not sure if this is necessary, try without this first
    • find _paq, replace with yourArray in p.js
  • find all occurrences of action_name in files under p/ (action_name is a request parameter, this was being picked up by the blocker)
    • replace ocurrences with yourParameter in:
      • p.js
      • core/Tracker/ActionPageview.php
      • core/Tracker/Request.php
      • js/piwik.js
      • js/piwik.min.js
      • vendor/piwik/piwik-php-tracker/PiwikTracker.php

Do all this at your own risk, this is totally experimental. This probably breaks something in PiWik. Not thoroughly tested.

@novakin commented on May 24th 2017

@bdore would be great to be able to do that trough a plugin

@sboesch commented on June 19th 2017

Keep in mind, instead of renaming any files, you should also be able to create symlinks:

$ ln -s piwik.js p.js && ln -s piwik.php p.php

This is much cleaner and at least uBlock seems to allow these requests as far as I checked for now.

@FabriceSalvaire commented on July 26th 2017

A lot of things are wrong here !

EasyList contains these basic rules :

  • /piwik-$domain=~github.com|~piwik.org
  • /piwik.$script,domain=~piwik.org
  • /piwik.php /piwik/*$domain=~github.com|~piwik.org
  • /piwik1.
  • /piwik2.js
  • /piwik_
  • /piwikapi.js
  • /piwikC_
  • /piwikTracker.
  • .php?action_name=
  • .php?logRefer=
  • .php?logType=
  • .php?p=stats&
  • .php?ping=
  • .php?refcode=
  • .php?tracking=

Thus we have just to change in the tracking script

  • piwik.js to foo.js
  • piwik.php to foo

And a two URL rules in the webserver to map them to the original paths.

It will work until the parameter list doesn't contain evident keywords like stat, log, track ... Blockers can try to be clever, but they will never broke the www.

@arnowelzel commented on September 12th 2017

If you use the "proxy" script to hide the real URL of your Piwik server (see https://github.com/piwik/tracker-proxy) you can also use that to hide parameter names as well.

When sending the JavaScript, just do a str_replace for "action_name=" to something else, e.g. "aname=" and then rename the $_GET parameter back to the original name. You should also rename this proxy script from "piwik.php" to something else.

So - first replace "action_name" in the provided JavaScript from the Piwik server:

        if ($piwikJs = $content) {
            echo str_replace('"action_name="', '"aname="', $piwikJs); 
        } else {

And this to accept "aname" as parameter but forward it as "action_name" in the server side CURL request to the Piwik server:

if(isset($_GET['aname']) {
        $_GET['action_name'] = $_GET['aname'];
        unset($_GET['aname']);
}
foreach ($_GET as $key => $value) {
    $url .= urlencode($key ). '=' . urlencode($value) . '&';
}

But be aware, that even the new parameter name "aname" may once get into filter lists as well - so you may have to use something else.

@omarr1000 commented on October 15th 2017

@arnoweizel: where do place this code? In which file?
I tried in piwik.php (from tracker-proxy), but no success, nothing is replaced, still have "action_name"
thx for an advice in advance

@arnowelzel commented on October 15th 2017

@omarr1000: then you did something wrong. See the script here, which I use on my own server (https://arnowelzel.de):

https://arnowelzel.de/samples/piwik-tracker-proxy.txt

@omarr1000 commented on October 15th 2017

thx! now I got it, did write the code at the wrong line )-;

@londonuk371 commented on November 13th 2017

I had to do 2 things:
-First the symlinks $ ln -s piwik.js p.js && ln -s piwik.php p.php like proposed by @sboesch

  • Then modifiy piwik.js / piwik.php:
    piwik:js
    Rename "action_name=" to "_action_name"
    piwik.php
    Added in the first line of piwik.php:
    if(isset($_GET['_action_name'])) { $_GET['action_name'] = $_GET['_action_name']; }

ublocOrigin was blocking ?action_name=

@hparadiz commented on April 16th 2018

Matomo tracking information should be obfuscated both to avoid being picked up by ad blockers but also for the security of the person being tracked! The current tracking URL is obnoxious with it's GET variables being sent over HTTP in plaintext.

Here's an example:
https://domain/a.php?action_name=site&idsite=1&rec=1&r=058405&h=11&m=1&s=31&url=https%3A%2F%2Fdomain%2F&_id=9b550a96cfa8d490&_idts=1523890834&_idvc=1&_idn=0&_refts=0&_viewts=1523890834&send_image=1&pdf=1&qt=0&realp=0&wma=0&dir=0&fla=0&java=0&gears=0&ag=0&cookie=1&res=1920x1200&gt_ms=27&pv_id=Zf3r32

Matomo should generate a short random string and automatically create this .htaccess file if mod_rewrite is detected:

RewriteEngine On

RewriteRule ^a.js piwik.js [L,QSA]
RewriteRule ^a.php piwik.php [L,QSA]

and then when it provides you the code snippet should automatically have this url end point used.

Proposed Solution
$_GET variables can be json encoded and then encrypted with a key generated for each matomo install. You provide the key to the js tracking file. JavaScript then instead provides the data like so:
a.php?VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw==

On the PHP side you would simply base64 decode then json_decode then just array_merge with $_GET.

@arnowelzel commented on April 16th 2018

The key needs to be embedded in the JavaScript - otherwise it is not possible to encrypt anything on the client. So you don't gain any privacy, as anyone else could also send a request to the proxy script and find out, what key is used.

@select commented on August 22nd 2018

I managed to unblock uBlock by creating the symlinks for `piwik.(js|php) and changing pwik.js

"action_name=

to

"a=b&action_name=

no need to rename variables @arnowelzel @bdore @londonuk371

@select commented on August 22nd 2018

What also might work is creating a symlink like

mkdir foo
ln -s piwik.php foo/index.php

then point the tracking script to /foo, no need to mess with routes

@isopetalous commented on September 6th 2018

Do not use "piwik" as the folder name, rename it to something else.
No need to rename the files or make rewrite rules.
Just modify the tracking code and replace all entries of "piwik.php" and "piwik.js" with "js/".
js/index.php will serve both php and js files for you.

@BurninLeo commented on November 13th 2018

If you use the "proxy" script to hide the real URL of your Piwik server (see https://github.com/piwik/tracker-proxy) you can also use that to hide parameter names as well.

That's just a cool idea, thanks! It's even possible without creating a new URL, if you just use require('piwik.php') below setting the $_GET variable.

For those who are still searching, here are two PHP scripts to put in the piwik directory:

pi-js.php

<?php
$jsFile = file_get_contents('piwik.js');
echo strtr($jsFile, [
  '"action_name="' => '"myAC="',
  'piwik.php' => 'pi-php.php'  // Not sure, if this is really necessary
]);
?>

pi-php.php

<?php
if (isset($_GET['myAC'])) {
        $_GET['action_name'] = $_GET['myAC'];
        unset($_GET['myAC']);
}
require('piwik.php');
?>

Then just replace piwik.php in the Matomo code by pi-php.php and piwik.js by pi-js.php. No symlinks required, but you can use some to "hide" the name of the directory. This solution should even survive the next update of Matomo.

@johackim commented on April 29th 2019

This works for me :)

sed -i -e 's/action_name=/a=b\&action_name=/g' matomo.js
ln -s matomo.js m.js && ln -s matomo.php m.php
<script type="text/javascript">
  var _paq = window._paq || [];
  _paq.push(['trackPageView']);
  _paq.push(['enableLinkTracking']);
  (function() {
    var u="//stats.domain.com/";
    _paq.push(['setTrackerUrl', u+'m.php']);
    _paq.push(['setSiteId', '1']);
    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
    g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'m.js'; s.parentNode.insertBefore(g,s);
  })();
</script>

Thanks @select & @sboesch

@w-biggs commented on August 8th 2019

I found that the easiest thing to do overall is make two tiny changes:

  1. Run sed -i -e 's/action_name=/a=b\&action_name=/g' matomo.js in the directory Matomo is installed in.
  2. Replace the g.src=u+'m.js' in the tracking code with g.src=u+'js/'.

That's it - now Matomo works, even if uBlock is installed.

@timbowhite commented on August 15th 2019

@ston3o @w-biggs

  1. chmod 444 matomo.js or chattr +i matomo.js

The Auto-Archiving cron runs periodically (either from your browser or via crontab depending on your config) and regenerates matomo.js, wiping out any changes you've made to it. The above should lock it down.

@mattab commented on August 15th 2019 Member

regenerates matomo.js, wiping out any changes you've made to it. The above should lock it down.

To have your changes included in the regenerated matomo.js file, you can put the changes in the file matomo/js/piwik.min.js which is the "Source" file read to regenerate the minified file.

@aleksandar-todorovic commented on November 13th 2019

There's an additional rule in EasyPrivacy:

&idsite=*&send_image=$image

This makes it slightly trickier because doing a similar sed operation to the one mentioned by @ston3o and @w-biggs will not work thanks to that *.

I guess the alternative approach would be to either rename one of those two variables or to switch the order of send_image and idsite.

@45236 commented on December 2nd 2019

There's an additional rule in EasyPrivacy:

&idsite=*&send_image=$image

This makes it slightly trickier because doing a similar sed operation to the one mentioned by @ston3o and @w-biggs will not work thanks to that *.

I guess the alternative approach would be to either rename one of those two variables or to switch the order of send_image and idsite.

that is exactly my problem. How do I rename that or how do I change the order?

@sgiehl commented on December 2nd 2019 Member

@45236 you can use POST requests for tracking. That will make it impossible to replay tracking logs if something goes wrong with it, but should circumvent the rule. See https://developer.matomo.org/api-reference/tracking-javascript#advanced-uses

@arnowelzel commented on December 2nd 2019

JFTR: the modified proxy script still works. If you need to replace additional parameters, like "idsite" etc. - just go ahead and do it: https://arnowelzel.de/samples/piwik-tracker-proxy.txt

Live in action: https://arnowelzel.de

@ikmolbo commented on December 10th 2019

There's an additional rule in EasyPrivacy:

&idsite=*&send_image=$image

This makes it slightly trickier because doing a similar sed operation to the one mentioned by @ston3o and @w-biggs will not work thanks to that *.
I guess the alternative approach would be to either rename one of those two variables or to switch the order of send_image and idsite.

that is exactly my problem. How do I rename that or how do I change the order?

I managed to do this by chaining two search and replace commands as follows:

sed -i -e 's/&send_image=0/\&/g' js/piwik.min.js; sed -i -e 's/action_name=/send_image=0\&action_name=/g' js/piwik.min.js

This will reorder send_image=0 and also overcomes the filter on action_name. You will need to call ./console custom-matomo-js:update once you have done this to ensure these changes are picked up.

Having done this, I am now seeing visits recorded even when using ad blockers.

@45236 commented on December 10th 2019

@ikmolbo nice and in which file do I have to replace that?

@jb-ks commented on March 8th 2020

@arnowelzel
The proxy with your changes works like a charm, but I wonder how to get the opt-out working.

I know, that in your proxy-file (based on the old matomo-proxy) is no support für the opt-out frame.

So i tried to display the opt-out frame exactly as before using the proxy (accessing index.php in the matomo installation). The frame is displayed, you can opt-out and later opt-in again, but - even if it seems to be opted out - the tracking is running.

Note:

  • The same bahaviour with the "new" (and unmodified) proxy.
  • The opt out ist displayed also in the user settings in the matomo-backend ("your visits at ...are ignored), but the tracking is active even with the ignore-cookie
@arnowelzel commented on March 8th 2020

@jb-ks Opt-out can't work because the ignore-cookie is set for the Matomo URL and not for the website which hosts the proxy script. The proxy script has no chance at all to check wether there is a ignore-cookie set or not, because the idea of this script is not to call the Matomo URL ever using the browser to avoid getting blocked.

In my case I just don't offer opt-out since I use Matomo without any cookies at all on my website:

<script>
    var pkBaseURL = "https://arnowelzel.de/";
    document.write(unescape("%3Cscript src='" + pkBaseURL + "pwproxy.php' type='text/javascript'%3E%3C/script%3E"));
</script><script>
    try {
        var piwikTracker = Piwik.getTracker(pkBaseURL + "pwproxy.php", 1);
        piwikTracker.trackPageView();
        piwikTracker.enableLinkTracking();
        piwikTracker.disableCookies();
    } catch( err ) {}
</script><noscript><p><img src="https://arnowelzel.de/pwproxy.php?ids=1&amp;rec=1" style="border:0" alt="" /></p></noscript>

Without any tracking cookies Matomo won't recognize returning visitors - but this is not important for me anyway. It's enough to see how many visits and page views I got and from which external URL they come (which only requires the HTTP referrer but no tracking cookies) and link tracking inside the website still works as this only requires the IP address during a session (all requests from the same IP address within a certain time period are considered to be the same visitor).

And yes - of course IP addresses are anonymized in Matomo on my server (the last two bytes are set to 0). But even anonymized IP addresses are sufficient for link tracking without tracking cookies.

And from a privacy standpoint: yes, I thinks this is legitimate, since accessing a website requires an active connection from the visitor anyway. A visitor can't say "I want to see your website but I don't want the webserver to know about that".

@jb-ks commented on March 8th 2020

@arnowelzel
Thanks for your explanation.

I have therefore decided to include a local alternative. The solution by Clive Beckett at https://github.com/clivebeckett/matomo-opt-out works very well after some initial detail problems.

Powered by GitHub Issue Mirror