Chrome displaying RED screen saying "Deceptive site ahead"

Just had this same thing.
New server. It had only been tracking visits for 30mins, then went red.

Removed tracking code, and the tracked sites were fine, but the site hoisting Matomo still red. Have submitted report.

Out of interest, was anyone else running the Google analytics import plugin at the time?
I noticed on the report in search console. It listed the root domain, but also matomo/index.php?module=GoogleAnalyticsImporter&action=processAuthCode.

From reading around, lots of people have had similar issue running apps with login pages.

Has anyone tried putting the whole install behind a firewall, restricting access to all but your own ip, but allowing the api through?

Après un mois sans soucis sur une installation sur serveur, la RED Page Google est arrivée, bloquant 10 sites connectés à Matomo.
Après désactivation de Matomo sur les 10 sites, plus d’analytics.
Le serveur ou seul est installé matomo est bloqué par Google même après validation du non fishing…
Toute solution bienvenue.

Did you try ? Sounds good…

same issue here as well. :ambulance:

Hey Sion2, yep same here - I’m running the google analytics import plugin.

I think I un-did all the changes that I made today, yet my website still shows the red screen of death. I’ll wait until tomorrow and then contact google support. I’ll be re-adding pieces slowly to figure out exactly which piece caused this.

1 Like

And I had the same problem. Is it google getting rid of competitors?:smiley:

2 Likes

Thank you for the solution.

Worked fine, except that if I go in maintenance mode I can’t access the admin console and I can’t see the tracked data.

If I may ask, what was your robots.txt configuration that didn’t work?

I don’t have the issue that you guys are mentioning but I am using Matomo self-hosted on a domain to track multiple domains.

None of the domains I am tracking is showing the deceptive error message.

But as per what @heurteph-ei said:

I checked the github page above:

Findus23 commented Jan 21, 2023

This looks a lot like your Matomo domain is on the google safe browsing list.
You can check here:
https://transparencyreport.google.com/safe-browsing/search

And report an incorrectly blocked site here:
https://safebrowsing.google.com/safebrowsing/report_error/?hl=en

and ran my site(s) through https://transparencyreport.google.com/safe-browsing/search and got no error status back on them.

Maybe this is also a way to check if the flag error went away after submitting the review to Google.

From the looks of it, at least from my point of view, seems to be a server IP issue, maybe the IP was flagged (if you are using shared hosting I’d exclude for the IP to be flagged).

1 Like

Same issue here. Interested to find out why Google flags these as deceptive.

Is it because of something in the Matomo web interface, and therefore all instances are likely to get flagged? (Google Search Console reported that the index.php URL was flagged)

Or is it because the tracking code tracks sensitive information?

If it’s very common, maybe it should be part of the installation / setup instructions to set up Google Search Console to monitor it.

HI there,
I have the same probleme of the red page with my matomo sub domain
So finally what is the solution please ? I have already reported the problem on this page a few hours ago https://safebrowsing.google.com/safebrowsing/report_error/?hl=en but with no effect
Tks for your help.

What do you mean by “Google Search Console reported that the index.php URL was flagged”? Do you mean Google Search Console shows a flagged URL index.php as a notification or where in GSC?

How would you add in Google Search Console a single URL? do you mean adding it in the xml sitemap?

Do 2 Tests if possible:

  1. on a separate second domain, same hosting, with matomo as your subdomain for that separate second domain.

If you are getting flagged on this second domain as well, maybe it is the hosting IP that gets flagged - just my hutch.

  1. on a separate third domain, Different hosting, with matomo as your subdomain for that third domain.

If you are getting flagged on this one as well, then Matomo might be the issue.
If you are not getting flagged on this third domain, then it means it is your Hosting server IP getting flagged (as you’d prove that the only difference between them is the separate hosting).

Please let us know how you go : )

I’ll show you with some screenshots attached. Google specifically indicates that it detected social engineering content at the / and /index.php URLs.

My point about setting up monitoring is this: If a site owner already has Google Search Console set up for their site, Google notifies them by email when it detects a security issue, and the owner can respond faster. So if many Matomo installations are being flagged as deceptive it makes sense to provide some advice about it during installation.

Thanks for providing these screenshots, they are helpful.

I just re-read all the thread starting from the beginning and I see (I think) why I got even more confused:

  • thread started with Matomo being flagged as a subdomain
  • other users report Matomo server used on multiple domains being flagged (all seem to be Wordpress domains)

In your case @Liam_Hennessy you are using a domain that has Matomo JS code on it, but that Matomo is on a separate server and domain right? (you are not using a subdomain on the same domain for Matomo correct?)

You are correct about this, a site owner would be able to see this faster if the Matomo installations are being flagged.

Once I get a bit of spare time, I am gonna do some tests on this to see if I get the same error like you guys.

Correct me if I am wrong, but as I asked before, but in your screenshot you are using Matomo on a separate domain and server than the domain that has Google Search Console, correct?

Thanks!

Yes, my site and my Matomo are on separate domains. The site loads the tracking JS from the Matomo domain. When Google flags a domain as dangerous, it can take many hours to fix. My site’s domain was not flagged, and my matomo domain was, so I was able to remove the tracking code from the site, and my site loaded ok for everyone immediately.

1 Like

Just to give you some confidence, we had a user with this same problem this week. They reported the false positive to Google Safe Browsing and Matomo was safelisted later that same day. Malware no more.

Speaking only for myself, it doesn’t seem unreasonable for G to be cautious on this: a file called “matomo.js”, full of JS listeners sending data to an API could look more or less suspicious depending on what the API looks like on your server setup. And G takes things into account like the holistic reputation of your server and even your IP address neighborhood (adjacent IP addresses to yours).

Glad that the safelisting is a fast and, based on emails, more or less permanent fix.

Links for safelisting:
The google safe browsing list. You can check here:
https://transparencyreport.google.com/safe-browsing/search

And report an incorrectly blocked site here:
https://safebrowsing.google.com/safebrowsing/report_error/?hl=en

1 Like

Thanks for the explanation and details Liam!

Hii, I’m sorry, but this issue hasn’t been resolved yet, and we can only address it retroactively. We are planning to transition some customers to Matomo soon, and we’re concerned that this might lead to a customer’s main domain being flagged on the phishing list, which would be quite embarrassing for all of us.

I’ve discovered that it’s possible for crawlers to ignore the robots.txt file, crawl the Matomo instances, and classify them as potential phishing threats. As a result, we are implementing a proxy in front of our Matomo instances. This proxy allows us to override the default Matomo robots.txt with “User-Agent: *
Disallow: /” and also directly block (returning a 404) certain crawlers that we’re familiar with. This way, we aim to ensure that these crawlers won’t crawl Matomo.

Does anyone have experience if this approach can help prevent the domains from being flagged?

I’ve also noticed that this issue tends to occur with customers whose domains are relatively new (around 2 years old). With customers that have been established for a long time, we’ve been fortunate enough to avoid this problem.

Thanks!

Hi @2A005D
Don’t hesitate to post any finding or new question to the related GitHub topic:

1 Like