Google marque les sites d’Immich comme dangereux

 (immich.app)
1 points par GN⁺ 2025-10-23 | 1 commentaires | Partager sur WhatsApp
  • Récemment, tous les sites liés à Immich ont reçu un avertissement de danger en raison du service Google Safe Browsing
  • L’ensemble du domaine immich.cloud a été touché, rendant l’accès pratiquement bloqué dans la plupart des navigateurs
  • La cause vient du fait que des URL de déploiement internes, notamment des environnements Preview, ont été automatiquement explorées puis traitées comme des faux positifs
  • Une contestation via Google Search Console a permis une restauration à court terme, mais le problème réapparaît à chaque création d’un nouveau Preview
  • En raison de la nature open source et auto-hébergée du service, il s’agit d’un problème structurel, et les environnements Preview seront à l’avenir séparés sur un domaine distinct

L’incident où Google a marqué les sites d’Immich comme dangereux

20 octobre 2025
Par Jason Rasmussen

Aperçu

  • Au début de ce mois, tous les sites web *.immich.cloud ont été classés comme dangereux, et les utilisateurs ont vu dans leur navigateur un avertissement de sécurité (le fameux "red-screen-of-death")
  • Personne dans l’équipe ne comprenait clairement le fonctionnement de cette fonctionnalité du navigateur, mais ce savoir fait désormais partie de la liste des "cursed knowledge"

Contexte

  • Google fournit gratuitement le service Safe Browsing, destiné à déterminer si un site contient des malwares, des logiciels indésirables ou des techniques d’ingénierie sociale
  • Les principaux navigateurs comme Chrome et Firefox intègrent ce service
  • La manière exacte dont le service décide qu’un site est dangereux reste floue
  • Lorsqu’un site est classé comme dangereux, la majorité des utilisateurs ne peuvent plus l’utiliser
  • Seule une infime minorité d’utilisateurs peut encore y accéder via les liens "En savoir plus" et "visiter ce site non sécurisé"

Prise de conscience du signalement

  • Au début du mois, de nombreux sites du domaine immich.cloud ont été marqués comme "dangereux", et des utilisateurs se sont plaints que leurs propres instances Immich auto-déployées avaient elles aussi été signalées
  • Tous les sites internes utilisés par l’équipe, y compris les environnements Preview, affichaient également cet avertissement
  • Il fallait à chaque fois passer par le processus "site sûr" pour y accéder, ce qui était très contraignant

Réponse via Google Search Console

  • Comme l’avertissement n’avait pas été levé après plusieurs jours, l’équipe a décidé d’utiliser la voie officielle de réponse : Google Search Console

  • Ce service impose de créer un compte Google, d’utiliser Search Console et de demander une revue pour les sites signalés

  • Search Console fournit quelques explications sur les raisons du classement comme dangereux

    • "Google a détecté du contenu nuisible sur certaines pages de votre site"
    • "Ces pages présentent des risques tels que l’incitation à installer des logiciels indésirables ou l’exposition de données personnelles"

  • En examinant la liste complète des URL pointées comme problématiques, il s’est avéré qu’il s’agissait uniquement d’URL liées aux environnements Preview

  • Le plus choquant a été de constater qu’un seul sous-domaine signalé suffisait à faire classer tout le domaine comme dangereux

Impact

  • Les environnements Preview et les services internes (zitadel, outline, grafana, victoria metrics, etc.) ont tous été affectés
  • Le tile server de production (tiles.immich.cloud) a également été concerné
  • Cependant, comme le tile server est appelé via JavaScript et ne dispose pas d’interface utilisateur directe, il a été confirmé qu’il continuait à fonctionner normalement

Tentative de "résolution" du problème

  • Dans Google Search Console, il faut utiliser la fonctionnalité Request Review pour contester la décision et expliquer la résolution
  • Si l’on demande simplement une revue sans avoir réellement résolu le problème, la durée d’examen s’allonge

Demande de restauration d’un site dangereux

  • Comme l’équipe estimait qu’il n’y avait en réalité aucun problème, elle a transmis l’explication suivante

    • Immich est une application auto-hébergée, et l’équipe Immich (https://immich.app/) administre et exploite directement l’ensemble de ce domaine
    • Tous les sites signalés ne sont que des environnements auto-déployés officiels et n’usurpent l’identité de personne

  • En 1 à 2 jours, le domaine a retrouvé un statut normal et l’accès a été rétabli

Efforts pour limiter le problème

  • Lorsqu’un label preview est ajouté à une Pull Request GitHub, un environnement Preview Immich est créé automatiquement, et une URL de Preview est générée immédiatement avec un commentaire de vérification

    https://pr-<num>.preview.internal.immich.cloud/

  • Chaque fois qu’un nouvel environnement Preview est créé, le domaine immich.cloud est de nouveau classé comme dangereux

  • L’hypothèse est que Google explore GitHub, découvre les nouvelles URL, les visite, puis les classe comme dangereuses

  • La contre-mesure actuellement prévue consiste à isoler les environnements Preview sur un domaine distinct dédié (immich.build)

Un problème plus large

  • Le système Google Safe Browsing semble avoir été conçu sans tenir compte des spécificités des logiciels open source et auto-hébergés
  • Outre Immich, plusieurs autres projets populaires ont connu des problèmes similaires
  • Google peut bloquer arbitrairement n’importe quel domaine, et en pratique il n’existe guère d’autre recours que de continuer à demander des revues à Google

Cheers,
L’équipe Immich

À lire aussi

1 commentaires

 
GN⁺ 2025-10-23
Commentaires sur Hacker News

  • Si vous prévoyez d’héberger du contenu utilisateur sur des sous-domaines, vous devez enregistrer le site dans la Public Suffix List https://publicsuffix.org/list/
    Ainsi, un sous-domaine contaminé n’affectera pas l’ensemble du site

    • Quand on héberge du contenu généré par les utilisateurs, faire figurer son domaine dans la PSL est une sorte de connaissance implicite parmi les développeurs web
      C’est difficile de connaître ce genre de chose sans y avoir déjà été confronté, comme dans le cas d’Immich, donc la plupart des gens l’ignorent avant de le vivre eux-mêmes

    • Par le passé, les navigateurs utilisaient un algorithme qui ne bloquait la définition large des cookies que lorsqu’un domaine n’avait pas de point (par ex. .com, .org)
      Mais cela créait un problème sur des domaines de niveau inférieur comme .co.uk, où les cookies pouvaient fuiter vers tous les sous-domaines enregistrés en dessous
      Comme les politiques d’enregistrement diffèrent selon chaque TLD, il n’y avait pas de solution purement technique côté développement, d’où l’apparition d’une liste maintenue manuellement comme la Public Suffix List
      Quand on voit que le navigateur a ce type de limite dès sa conception, le web donne un peu l’impression d’une voiture assemblée au ruban adhésif https://publicsuffix.org/learn/

    • En regardant plusieurs liens dans ce fil, il y a en réalité deux problèmes

  1. Le fait d’enregistrer son domaine dans la Public Suffix List quand on héberge du contenu utilisateur sur son propre domaine, comme Immich
  2. Le fait que, lorsque des utilisateurs hébergent eux-mêmes des projets open source comme immich ou jellyfin sur leur propre domaine, cela puisse être pris à tort pour du phishing
    Le premier est relativement simple si l’on connaît la PSL, mais le second est plus gênant, surtout lorsque le nom de domaine contient le nom du logiciel

  • Le problème n’est pas le contenu utilisateur en lui-même, c’est que j’ai déployé directement le build de release d’Immich sur mon propre serveur et Google a bloqué tout mon domaine

  • Ce n’est pas parce qu’Immich hébergeait réellement du contenu utilisateur, mais parce que le problème s’est produit sur un sous-domaine utilisé pour les aperçus de PR
    À mon avis, c’est clairement un bug du côté du code de Google

  • Je recommande de parcourir toute la liste « Cursed Knowledge » de l’équipe Immich https://immich.app/cursed-knowledge

    • Certains éléments de cette liste ressemblent plutôt à une conception de sécurité normale
      Par exemple, « certains téléphones suppriment automatiquement les informations GPS lorsqu’une application sans autorisation de localisation lit une image »
      Cela semble au contraire être un comportement naturel et souhaitable

    • Ce serait bien de pouvoir partager ce type de savoir-faire dans un fichier standard comme CURSED.md pour chaque projet
      Tout le monde pourrait ainsi apprendre de ces connaissances acquises sur le terrain

    • « Les paramètres de requête Postgres sont limités à 65 000 »
      Ce qui est amusant, c’est qu’un tel nombre puisse encore ne pas suffire

  • Il y a toujours une chose que je me demande avec ce genre d’avertissements
    Ils collent très directement les étiquettes « escroc » ou « attaquant » ; est-ce que cela ne relève pas de la diffamation ?
    C’est pareil avec les avertissements de Microsoft sur les exécutables non vérifiés
    Avant, ils disaient plutôt « nous ne savons pas si c’est sûr », alors qu’aujourd’hui ils affichent quelque chose de plus affirmatif, du style « vous êtes un attaquant »

    • Le mot « escroc » n’apparaît pas dans l’avertissement réel ; la formulation est plutôt « des attaquants peuvent être présents sur le site », « might », etc.
      Cela inclut aussi les cas où un tiers malveillant a compromis le site
      Le propriétaire du site n’est pas désigné comme attaquant
      Le service juridique a probablement examiné ce texte avec beaucoup de soin

    • Je ne suis pas avocat, mais je ne crois pas qu’il y ait déjà eu d’affaire portée devant les tribunaux à propos de ce type d’avertissement
      Cela pourrait peut-être relever de la diffamation

  • Ce n’est peut-être pas un problème énorme, mais je me demande si, pour un site comme Immich, n’importe qui peut soumettre une PR, lui faire ajouter le tag preview, et voir automatiquement son contenu hébergé sur https://pr-<num>.preview.internal.immich.cloud
    Au fond, cela ne veut-il pas dire que n’importe qui peut y publier librement n’importe quoi ?

    • Sur GitHub, les personnes pouvant ajouter des labels sont limitées aux collaborateurs, donc ce n’est pas complètement ouvert
      Cela dit, s’il est possible pour un collaborateur de soumettre d’abord une PR légitime, d’obtenir le label, puis de publier ensuite n’importe quoi, il reste un risque

    • On dirait une idée de phishing qui ne coûte vraiment rien

  • Il est difficile à croire qu’une seule entreprise puisse décider jusqu’aux sites auxquels on peut accéder
    Comme si le fait de limiter l’exécution des applications ne suffisait pas, on en est maintenant là

    • C’est l’une des nombreuses conséquences d’un Congrès américain longtemps inefficace

    • Ce qui m’étonne, c’est la façon dont ils ont réussi à faire croire même à des utilisateurs qui détestent la publicité que ces grands groupes sont « cool »
      Personne ne veut de publicité, mais pour l’entreprise c’est un moyen de gagner de l’argent
      Je ne comprends pas comment Google parvient à emballer une image d’entreprise aussi peu éthique comme quelque chose de « stylé »

  • J’ai l’impression que l’Internet ouvert est terminé
    Désormais, tout est contrôlé par des monopoles
    J’ai gardé une application iOS sur l’App Store pendant trois ans, puis soudain Apple a exigé une nouvelle licence qui n’existait même pas, en menaçant de retirer l’application si je ne la fournissais pas
    Rien n’avait changé depuis trois ans, et pourtant voilà où on en est
    Je suis de plus en plus lassé du fait qu’on ne puisse même plus vraiment faire de l’auto-hébergement librement

    • Si vous pouviez expliquer plus en détail le problème avec l’application iOS et les exigences d’Apple, ce serait vraiment utile

  • Un de mes amis et client utilisait un hébergement de type WordPress avec une simple redirection
    Son hébergeur s’est retrouvé un jour sur la liste noire des « sites dangereux »
    Même après avoir supprimé la redirection, son propre domaine restait contaminé, et à cause de cela Google n’acceptait plus du tout les e-mails provenant de ce domaine
    Il a bien réussi à faire retirer son domaine de la liste noire après une demande de réexamen, mais le blocage des e-mails est resté permanent
    Au final, il a dû enregistrer un nouveau domaine, et ce comportement de Google ne fait qu’inciter à créer sans cesse des comptes jetables

    • Rien que d’entendre ce genre d’histoire, ça fait peur
      Imaginer que mon domaine, que j’utilise sans problème depuis 25 ans, soit blacklisté par erreur et que mes e-mails soient bloqués, c’est terrifiant

  • Ma conclusion, c’est qu’il vaut mieux séparer les domaines selon les usages
    Il y a certes l’inconvénient, à l’échelle mondiale, que plusieurs TLD puissent paraître plus officiels, mais ce cas me conforte encore davantage dans cette idée
    Par exemple
    www.contoso.com (public)
    www.contoso.blog (public, avec commentaires utilisateurs)
    contoso.net (interne)
    staging.contoso.dev (développement / endpoint zero trust)
    raging-lemur-a012afb4.contoso.build (snapshots)

    • Mais si l’on sépare ainsi les domaines, le risque que cela paraisse être du phishing est beaucoup plus élevé pour les utilisateurs
      J’ai déjà reçu un e-mail de githubnext.com ; comme pour moi GitHub = github.com, j’ai naturellement pensé à du phishing ou du spam
      En fait, c’était bien un vrai service

    • Bonne approche

  • Je rencontre actuellement exactement le même problème avec mon propre domaine
    Google a classé notre instance familiale d’Immich comme site dangereux, ce qui a rendu tous les autres services servis depuis ce même domaine inaccessibles dans Chrome
    On peut certes contourner l’avertissement, mais l’album photo que j’avais envoyé à ma belle-mère est devenu inutilisable

  • J’ai eu exactement la même expérience au début de l’année en auto-hébergeant Umami Analytics
    https://news.ycombinator.com/item?id=42779544#42783321
    Ce n’est qu’après avoir mentionné une « action en justice » dans ma contestation via Google Search Console que le signalement a été levé