Google has a creative new way to kill SaaS startups
Back in the old days, when Google (or any of its poorly tuned AIs) wanted to kill your business, it usually denied you access to some of its services, and it worked. You've probably heard horror stories: Websites disappear from Google search and go into oblivion YouTube videos are demonetized , and creators lose a source of income Android applications disappear from Google Play and cannot contact their users APIs become more expensive or simply out of date Last but not least less important, personal analogue to all of the above: people lose access to their Gmail accounts and their entire digital life I swear I read the FAQ!
What happened nextDuring the week following the incident, we continued to receive periodic reports of access issues from customers. Google Safe Browsing provides two different APIs for use in commercial and non-commercial products. In our case, the problem was reproducible in at least some Firefox users, as well as in some antivirus and network security devices. They tagged our site and blocked access to it many days later . We continued to migrate all clients from the old CDN to the new one, and so we ended up fixing the problem forever. We never really found out the reason and blamed it on some stoned AI at Google headquarters.
How to prevent Google Safe Browsing from tagging your siteIf you run a SaaS business and promise customers guaranteed availability, then listing in Google Safe Browsing for no specific reason is a very real business risk. Unfortunately, given the purely Google opaque mechanism for tagging and viewing sites, this is unlikely to be guaranteed to be avoided. But you can certainly design your application and processes to minimize the chances of this happening, reduce the impact of actual blacklisting, and minimize the time it takes to resolve the issue. Here are the steps we take ourselves that I can recommend: Don't keep all your eggs on the same domain . Apparently GSB tags entire domains or subdomains. Therefore, it is better to distribute applications across multiple domains, as this will reduce the damage from losing any of them. For example, company.сom for the site, app.company.net for the application, eucdn.company.nеt for customers in Europe, useastcdn.company.nеt for customers in the US East Coast, etc. Do not host customer data on primary domains . Domains are often blacklisted because SaaS clients unknowingly uploaded malicious files to the server. These files are harmless to systems, but their very existence can lead to the fact that the entire domain will be blacklisted. Anything your users upload to apps must be hosted outside of the main domains. For example, use companyusercontent.cоm to store client files. Actively claim domain ownership in Google Search Console . This will not prevent the site from being blacklisted, but you will receive an email that will allow you to quickly respond to the problem. It takes some time to respond to such incidents, and this is precious time for your customers to suffer. Be prepared to change your domain if needed . This is the hardest thing to do, but it is the only effective anti-blacklisting tool: design systems so that service domain names can be easily changed (via scripts or orchestration tools). For example, suppose eucdn.company2.net has a CNAME record for eucdn.company.net, and if the former is blocked, update the application configuration to load resources from an alternate domain.
What to do if your SaaS application or website is blacklisted by Google Safe BrowsingHere's what I would recommend: If you can easily and quickly switch your application to another domain, this is the only way to reliably, quickly and supposedly resolve the incident . If you can, do so. That's all. Otherwise, once you identify a blocked domain, review the reports in Google Search Console. If you still have not claimed ownership of the domain, you will have to do it right now, which will take some time. If the site is indeed hacked, fix the problem (for example, remove offensive content or hacked pages) and then request a security check. If the site is not hacked or the Safe Browsing report is meaningless, request a security check anyway and state that the report is incomplete. Then, instead of rushing about in agony, presenting the amount of damage for the waiting time, proceed with the transition to the new domain anyway. Verification may take several weeks.
Cherry on the cakeSeveral months after the first incident, we received an email from Search Console informing us that one of our domains was blacklisted again. A few hours later, as a G Suite domain administrator, I received another interesting email, which you can read below. The "sc" in [email protected] stands for Search Console. Let me explain in my own words what it is, because it's just mind-blowing. This is an email warning from Search Console about being blacklisted. This second email says that the G Suite automatic phishing email filter considers this email from Google Search Console to be bogus . Of course, this is not the case , since our domain was indeed blacklisted. So Google ca n't even decide if its own phishing alerts are phishing . (Lol?)
Some unpleasant thoughts about the future of the internetTo anyone in the tech industry, it's pretty clear that the big tech giants are pretty much the guardians of the Internet. But before, I interpreted it in a free, metaphorical sense. The Safe Browsing incident described here made it very clear that Google literally controls who can access your site, no matter where or how you operate it. Since Chrome has about 70% of the market, and Firefox and Safari to some extent use the GSB database, Google can make any site virtually inaccessible on the Internet with one flick of a finger.
|Vote for this post
Bring it to the Main Page