Google flags Immich sites as dangerous

Reports of False Positives and Real-World Impact

• Multiple people report Google Safe Browsing falsely flagging:
  • Self‑hosted Immich instances (often on immich.example.com).
  • Other self‑hosted apps: Jellyfin, Nextcloud, Home Assistant, Umami, Gitea, Portainer.
  • Business documentation sites, WordPress installs, webmail, even internal-only or LAN-only services.
• Effects include Chrome’s red “dangerous site” interstitial, Firefox/Brave/DNS resolvers blocking via the same list, and in some cases long‑term damage to domain reputation and email deliverability.
• Appeals through Google Search Console sometimes work, but flags often reappear; process is opaque and slow, with boilerplate responses.

How Sites Seem to Get Flagged

• Heuristics mentioned in the thread:
  • Generic login pages that look like other self‑hosted products or cloud services (Immich, Jellyfin, Nextcloud, Home Assistant, “gmail.”, “plex.”).
  • Multi‑tenant domains where different subdomains host different content (including Immich’s PR preview subdomains).
  • Chrome’s Safe Browsing pipeline (hashing “page color profiles” / layout similarity, plus many other unspecified signals).
  • Discovery of URLs via:
    • Gmail scanning (disputed; others argue Chrome’s “enhanced protection” URL uploads explain it).
    • Certificate Transparency logs listing new hostnames.
• Some claim even non‑public or robots.txt‑blocked sites and purely internal domains have been flagged.

Immich Preview Architecture and Risk

• Immich ran PR preview environments under *.preview.internal.immich.cloud.
• Concern: anyone submitting a PR could, via maintainer labeling, get arbitrary code deployed on a first‑party domain, enabling phishing or abuse.
• Maintainer clarifies:
  • Only internal branches and maintainer‑applied labels can trigger previews; forks cannot.
  • Nonetheless, contributors’ code is being hosted on the same second‑level domain as production resources, which Safe Browsing treats as high‑risk.
• Immich is moving previews to a separate domain (immich.build), but that alone doesn’t fully solve Safe Browsing behavior.

Public Suffix List and Multi‑Tenant Domains

• Several comments note: if you host user (or contributor) content on subdomains, your base domain should be listed on the Public Suffix List (PSL) so:
  • Browsers treat each subdomain as a separate “site” for cookies and, possibly, Safe Browsing blast radius.
• Many developers admit they had never heard of the PSL; others say it’s “tribal knowledge” for hosting user content.
• Tradeoff: PSL makes cross‑subdomain auth harder, but improves isolation.

Power, Due Process, and Responsibility

• Strong criticism of Google’s effective gatekeeping:
  • One company’s opaque, automated system can render a domain “dangerous” to most users, with no clear standards, timeline, or human contact.
  • Fears of anticompetitive use (Immich competes with Google Photos), and of the mechanism being weaponizable against self‑hosting.
  • Discussion of libel, tortious interference, small‑claims suits, and antitrust; some suggest coordinated legal action.
• Others push back:
  • Any effective malware/phishing filter must have some false positives.
  • Given Immich’s architecture (PR previews on a first‑party domain without PSL separation), Google’s classification is technically understandable even if painful.
• Overall tension: user safety vs. the right of small operators to deploy and self‑host without being silently penalized by a de facto monopoly list.