- Les sites Web disparaissent de la recherche Google et disparaissent dans l'oubli
- Les vidéos YouTube sont démonétisées et les créateurs perdent des revenus
- Les applications Android disparaissent de Google Play et ne peuvent pas atteindre leurs utilisateurs
- Les API deviennent plus chères ou tout simplement obsolètes
- Dernier point mais non des moindres, une contrepartie personnelle à tout ce qui précède: les gens perdent l'accès à leurs comptes Gmail et à toute leur vie numérique.
Je jure que j'ai lu la FAQ!
Tout se passe selon un scénario. Au début, les entreprises utilisent délibérément les services Google d'une manière qui dépend entièrement d'eux pour leur survie. Ensuite, le géant automatisé de Google fait son travail: il change légèrement la position de son cul sur une chaise en cuir de la taille d'une planète et, sans le remarquer, détruit une myriade d'entreprises (relativement) petites de la taille d'une fourmi dans le processus. Et enfin, les entreprises de la taille d'une fourmi sont désespérées de dire à Google qu'elles sont écrasées, mais ne peuvent communiquer qu'avec un formulaire de suggestion automatisé.
Parfois, un PDG de la taille d'une fourmi connaît quelqu'un sur Google parce qu'il s'agissait de copains d'université, ou un CTO écrit un message qui se retrouve d'une manière ou d'une autre sur la première page de Hacker News. Ensuite, Google remarque le problème et le considère parfois comme digne d'une solution, généralement par crainte des implications réglementaires que la révolution des fourmis pourrait avoir.
Pour cette raison, la sagesse conventionnelle des fourmis vous oblige à ne pas trop vous fier aux services Google. Et si vous parvenez à éviter cette dépendance, tout devrait bien se passer.
Une telle surface bleue plate avec un toit rouge cool! Tellement pratique!
Quoi de neuf sous la lune
Dans la série d'aujourd'hui "Internet n'est pas ce qu'il était avant", nous allons parler d'une nouvelle façon dont Google peut par inadvertance submerger votre startup. Il ne vous oblige pas à utiliser les services Google de quelque manière (intentionnelle) .
Saviez-vous que vos domaines peuvent être mis sur liste noire par Google sans raison particulière et que cette liste noire est utilisée non seulement par Google Chrome, mais également par plusieurs autres fournisseurs de logiciels et de matériel? Saviez-vous que ces autres fournisseurs synchronisent la liste avec des horaires et des interprétations qui changent énormément, de sorte que la résolution de tout problème devient extrêmement stressante et imprévisible? Dans le même temps, les conditions de traitement des plaintes concernant la liste noire dans Google se mesurent en semaines?
Voici à quoi ressemble votre site ou votre application SaaS.
Cette "fonctionnalité" de la liste noire est appelée navigation sécurisée Google , et dans l'image ci-dessus, vous pouvez lire le message que les visiteurs de votre site voient si l'un des domaines est inclus dans la base de données de navigation sécurisée. Les textes d'avertissement vont de «Spoof site» à «Site contains malware» (liste complète ici ), mais ils sont tous placés sur un fond rouge tout aussi effrayant qui essaie d'empêcher l'utilisateur d'aller sur le site autant que possible.
La première fois que nous avons entendu parler du problème, c'était en raison d'un pic de plaintes de clients qui ont rencontré cet avertissement rouge en essayant d'utiliser notre application SaaS. La deuxième fois, nous sommes mieux préparés, nous avons donc déjà du temps libre pour rédiger cet article.
Notre société InvGate - est une plate-forme SaaS pour les départements informatiques travaillant sur AWS. Il sert plus de 1000 entreprises clientes et des millions d'utilisateurs finaux. Les entreprises utilisent le produit pour gérer les tickets et les demandes de leurs utilisateurs. Vous pouvez imaginer la réaction des responsables informatiques lorsque, tout à coup, leur système de tickets commence à montrer aux utilisateurs finaux de tels avertissements de sécurité inquiétants.
Lorsque nous avons rencontré ce problème pour la première fois, nous étions désespérés de comprendre ce qui se passait et de comprendre le fonctionnement de Google Safe Browsing (GSB), tandis que le support technique tentait de faire face au flux de demandes des clients. Nous nous sommes rapidement rendu compte que l'URL du CDN Amazon Cloudfront , à partir de laquelle nous servions des ressources statiques (CSS, Javascript, etc.), était entrée dans la base de données GSB , ce qui provoquait le blocage de l'application entière pour les clients utilisant ce CDN particulier. Un rapide coup d'œil sur le système étiqueté a montré que tout allait bien.
Alors que l'équipe Devops travaillait à la hâte pour configurer un nouveau CDN et se préparer à déplacer les clients vers un nouveau domaine, j'ai trouvé dans la documentation Google que via Google Search Console(GSC), vous pouvez obtenir des explications supplémentaires sur les raisons pour lesquelles le site est signalé dans la base de données. Je ne vous ennuierai pas avec les détails, mais pour accéder à ces informations, vous devez prouver que vous êtes le propriétaire du site , pour ce faire, configurer un enregistrement DNS personnalisé ou télécharger des fichiers à la racine du domaine. Nous l'avons fait - et en 20 minutes, nous avons reçu un rapport sur notre site.
Le rapport ressemblait à ceci:
Ceci n'est ... pas particulièrement informatif
Le rapport contenait également un bouton Demander un examen sur lequel j'ai rapidement cliqué sans prendre aucune mesure sur le site, car il n'y avait aucune information sur le problème allégué. J'ai soumis une candidature avec la note que je n'avais pas d'URL malveillantes répertoriées, bien que la documentation indique que Google fournit toujours des exemples d'URL pour aider les webmasters à identifier les problèmes.
Bien! Une demande de vérification d'un rapport non valide peut ralentir encore davantage les vérifications futures.
Environ une heure plus tard, le site a été supprimé de la base de données GSB, nous n'avons même pas fini de retirer les clients de ce CDN. Environ deux heures plus tard, un e-mail automatique est arrivé confirmant que la vérification avait réussi. Aucune clarification quant à la cause du problème.
Que s'est-il passé ensuite
Au cours de la semaine qui a suivi l'incident, nous avons continué de recevoir des rapports périodiques sur les problèmes d'accès de la part des clients.
La navigation sécurisée Google fournit deux API différentes à utiliser dans des produits commerciaux et non commerciaux. Dans notre cas, le problème était reproductible chez au moins certains utilisateurs de Firefox, ainsi que certains antivirus et dispositifs de sécurité réseau. Ils ont étiqueté notre site et en ont bloqué l'accès plusieurs jours plus tard .
Nous avons continué à migrer tous les clients de l'ancien CDN vers le nouveau, et nous avons donc résolu le problème pour toujours. Nous n'avons jamais vraiment découvert la raison et l'avons imputée à une IA défoncée au siège de Google.
Comment empêcher la navigation sécurisée Google de baliser votre site
Si vous dirigez une entreprise SaaS et promettez à vos clients une disponibilité garantie, l'inscription dans la navigation sécurisée Google sans raison spécifique représente un risque commercial très réel.
Malheureusement, étant donné le mécanisme purement opaque de Google pour le marquage et l'affichage des sites, il est peu probable que cela soit évité. Mais vous pouvez certainement concevoir votre application et vos processus de manière à minimiser la probabilité que cela se produise, à réduire l'impact de la liste noire réelle et à minimiser le temps nécessaire pour résoudre le problème.
Voici les étapes que nous prenons nous-mêmes que je peux recommander:
- . , GSB . , . , company.om , app.company.net , eucdn.company.nt , useastcdn.company.nt . .
- . - , SaaS . , , . , , . , companyusercontent.cm .
- Google Search Console. , , . , , .
- Soyez prêt à changer de domaine si nécessaire . C'est la chose la plus difficile à faire, mais c'est le seul outil anti-liste noire efficace: concevoir des systèmes de sorte que les noms de domaine de service puissent être facilement modifiés (via des scripts ou des outils d'orchestration). Par exemple, supposons que eucdn.company2.net possède un enregistrement CNAME pour eucdn.company.net, et si l'ancien est bloqué, mettez à jour la configuration de l'application pour charger des ressources à partir d'un autre domaine.
Que faire si votre application SaaS ou votre site Web est mis sur liste noire par Google Safe Browsing
Voici ce que je recommanderais:
- Si vous pouvez facilement et rapidement basculer votre application vers un autre domaine, c'est le seul moyen de résoudre l'incident de manière fiable, rapide et supposée . Si vous le pouvez, faites-le. C'est tout.
- , , Google Search Console. , , .
- , (, ), . Safe Browsing , , .
- , , , . .
Quelques mois après le premier incident, nous avons reçu un e-mail de la Search Console nous informant que l'un de nos domaines était de nouveau sur liste noire. Quelques heures plus tard, en tant qu'administrateur de domaine G Suite, j'ai reçu un autre e-mail intéressant, que vous pouvez lire ci-dessous.
Le "sc" dans sc-noreply@google.com signifie Search Console.
Permettez-moi de vous expliquer en mes propres termes ce que c'est, car c'est tout simplement époustouflant. Il s'agit d'un e-mail d'avertissement de la Search Console concernant la mise sur liste noire. Ce deuxième e-mail indique que le filtre d'hameçonnage automatique de G Suite considère cet e-mail de Google Search Console comme un faux . Bien sûr que non.parce que notre domaine a effectivement été mis sur liste noire. Google ne peut donc même pas décider si ses propres alertes de phishing sont du phishing . (Lol?)
Quelques pensées désagréables sur l'avenir d'Internet
Pour quiconque dans l'industrie de la technologie, il est assez clair que les grands géants de la technologie sont à peu près les gardiens de l'Internet. Mais avant, je l'interprétais dans un sens libre et métaphorique. L'incident de navigation sécurisée décrit ici a montré très clairement que Google contrôle littéralement qui peut accéder à votre site, peu importe où et comment vous l'exploitez. Étant donné que Chrome détient environ 70% du marché et que Firefox et Safari utilisent dans une certaine mesure la base de données GSB, Google peut rendre n'importe quel site presque inaccessible sur Internet d'un simple coup de doigt.