Same procedure and same solution for me! I also mentioned Yunohost so that they can update their phishing models 
1 Like
give it timeā¦ itād get flagged in again in 1 week to a month.
- i stopped doing the review ā¦ i dont care any moreā¦ anything i want seen i dont put behind the SSO.
If that happens again, then I donāt care. I finally disabled safe browsing stuff from my browsers, pretty useless feature to me. And since this is my personal server, I donāt give a f about what Google thinks this server is.
I added robots.txt though (if thatās gonna help, even if it doesnāt, I donāt want my server to be indexed on Google or other search engines) with these instructions: Best way for disallowing robots with robots.txt from everything?
3 Likes
We now know that several recent Mastodon instances had the same misadventure.
It seems that several similar authentication pages on a lot of IP is considered as a phishing botnet.
Do you know any workaround to this problem??
Applying a custom theme to login page can mitigate this problem, it worked for me
Ah I get the same exact issue for one of my Mastodon instances.
Can you give us more info about this? What do you mean more exactly and why would this solve the issue?
What I realized is that some Mastodon pages have an SSO redirect like security=ae917efeb1d0450a48667a989608191230206534 - why? Can we disable that?
Basically the Mastodon āaboutā page wants to redirect to security=ae917efeb1d0450a48667a989608191230206534
This keeps happening to me as well. All of the domains I have added in Yunohost have a default app, theyāre not all static HTML. There is no domain that you can visit, which is attached to my yunohost server, which directs to anything but an app that was installed via the yunohost admin. I would have to remove some of them to create a static HTML page at ā/siteā so thatās kind of not a solution.
I would love to pay for development on this. If I donate $500, can this be addressed on the development side? Anyone want to sweeten the pot with me and add to that number?
5 Likes
I donāt claim to have a solution but I am just throwing here my 2cents solutionsā¦probably not a perfect one.
But since this had happen to me twice and both time I got it solved almost fine following below procedure.
First of all, make sure you know that your server has not be compromised.
Then you need a gmail account.
Log in
Go to postmaster console
Add your domain
It will give you a unique code that you will use to create a TXT DNS entry at your provider.
Go to you DNS provider add the TXT DNS field and click back on verify domain ownership at google postmaster tool.
Then go to āGoogle Search Consoleā and add your domain, it shall be already recognized as yours because of previsous step.
Then you shall see a warning telling you about the security issue. Eventually you might get details specific to why it is considered as dangerous.
There you can fill up a request for review where you explain a bit that everything is fine and you are a responsible admin and very aware of security practices and proactive in taking great care of your server etcā¦
It did work for me and both cases I found out why.
The first time it was a cryptocurrency related project that I was hosting for a hackathon
The second time was a wierd sub-domain I created with an hashā¦but funnily enough I kept some hash domains for quite long and no issue.
At the end I think avoiding google is good but you cant help if other you share your server link does avoid google too. That is exactly when I got issues, if I donāt share my server url around then I donāt get flaggedā¦
(class action sound like a great great idea, who is in ?)
I put your question in the contributor meeting of this evening Instance Etherpad Publique de La Quadrature Du Net
1 Like
As simple as being able to display a message on the login screen as a declaration on who is operating the website would be fantastic. Seems to be the baseline requirement that Google wants.
Specifically on the /admin and /sso login pages.
1 Like
What are you basing this on? Google published something?
here
2 Likes
Hi there, i was flagged few days ago.
My server is installed at my home (laptop with Debian OS), with static public IP and my own domain with CloudFlare SSL
I use some apps in subdomains, like:
- excalidraw to collaborate with my team (i could post links to this in gmail)
- Drupal to test migrations from Worpdress
- AdGuard as home DNS
for now iāve used āReport incorrect phishing warningā form and waiting for response. Maybe iāll try to use some advice from this topic (like static app, robots.txt, theming login form etc).
But ultimately i can live with this for now (i use this rather for my own apps only)
There are some posts here already about the bright-red warning in every browser about the ādeceptive websiteā warning. I have a few instances which are running for a while - the oldest was installed in Jan 2021.
First of all, I assume this is an āupstreamā problem, which means that without fundamentally altering YunoHost configuration I cannot fix this. The fix for this will come from the YunoHost upstream, and itās very likely that the YunoHost upstream is waiting on PhP, its framework, and on others.
I post this because I read a lot of guesses about the cause and a fix, and none of them make more sense than mine above. I am hoping to save folks here a lot of frustration trying to fix this issue - which is pretty detrimental to us, node operators. No use to tell your users that fresh nodes, built an hour ago were not online long enough to be hijacked, people are freaking out and will not use your node.
On the upside, YunoHost is a phenomenal service stack, I am able to build fully RFC-compliant networks for DNSSEC, SSL, DKIM, DMARC, SPF, just to mention a few. I would like to see an upgrade ASAP for the issue with the Google API - and then the issue documented so we can shame Google.
Calling an entire community ādeceptiveā, for not being able to separate criminal intent from technical causes is a pathetic behavior from Google, a technology expert. This show just how arrogant Google has become, and how scared people are of everything they do not understand.
Thanks for reading, and hope to see an explanation soon for what is exactly failing the Google API here: Google Safe Browsing
2 Likes
I took the liberty to merge your post with the original one. 
1 Like
I own the YunoHost stack at w3pbs.us, with subdomains fediverse.w3pbs.us, zot.fediverse.w3pbs.us and a few others. Everything is RFC-compliant, the apex is even registered with Googleās Postmaster. There is no creepware of any sort on my network, and the last subdomain was flagged as soon as it came online. The apex is on a different VPS from the subdomains, and I use my own BIND on three separate VPS. Even when I have a fully configured, fully controlled and independent stack, I am still a ādeceptive websiteā.
My only explanation that the Google API was changed, and that triggered the issue. YunoHost must deal with this because Google not even going to acknowledge anything.
1 Like
Google changed something the way they inspect web pages and now they are embarrassing themselves. Mistaking technical issues with criminal behavior is nothing short of spectacular self-own.
2 Likes
I updated to Yunohost 11.0.11 this morning after having my ynh.fr domain reset so I could re-use it after a fresh install, and I have also just started getting these red warning pages appearing on my main domain and subdomainā¦ but only when I use stock Chromium or other Google-linked services.
When I use Ungoogled Chromium on my laptop, or Mull or Bromite on my de-Googled Android smartphone, I can view my domains with no warnings.
I have submitted a review request here: Report Incorrect Phishing Warning
ā¦so will wait and see what happens, if anything.
If there is no change, I will try adding a MyWebapp page as the default app for the domain and see if that fixes it.
Itās so strange that some of us have been getting this immediately after a Yunohost update.