4 ms·

I'm fighting this right now on my own domain. Google marked my family Immich instance as dangerous, essentially blocking access from Chrome to all services host

I'm fighting this right now on my own domain. Google marked my family Immich instance as dangerous, essentially blocking access from Chrome to all services hosted on the same domain. I know that I can bypass the warning, but the photo album I sent to my mother-in-law is now effectively inaccessible.

david_van_loon 1y ago
Since other browsers, like Firefox, also use the Google Safe Browsing list, they are affected as well.
donmcronald 1y ago
Just in case you're not sure how to deal with it, you need to request a review via the Google Search Console. You'll need a Google account and you have to verify ownership of the domain via DNS (if you want to appeal the whole domain). After that, you can log into the Google Search Console and you can find "Security Issues" under the "Security & Manual Actions" section. That area will show you the exact URLs that got you put on the block list. You can request a review from there. They'll send you an email after they review the block. Hopefully that'll save you from trying to hunt down non-existent malware on a half dozen self-hosted services like I ended up doing.
- shaky-carrousel 1y ago
  It's a bit ironic that a user installing immich to escape Google's grip ends up having to create again a Google account to be able to remove their Google account.
  - david_van_loon 1y ago
    Indeed. Thankfully, this isn't the first time Google has caused an issue like this, so I'm familiar with the appeal process.
- account42 11mo ago
  Reviews view Google Search Console are pointless because they won't stop the same automated process from flagging the domain again. Save your time and get your lawyer to draft a friendly letter instead.
wiether 1y ago
No later than last weekend I was comtemplating migrating my family pictures to a self-hosted Immich instance... I guess a workaround Google's crap would be to put an htpasswd/basic auth in front of Immich, blocking Google to get to the content and flagging it.
- skatsubo 1y ago
  Add a custom "welcome message" in Server Settings (https://my.immich.app/admin/system-settings?isOpen=server https://my.immich.app/admin/system-settings?isOpen=server) to make your login page look different compared to all other default Immich login pages. This is probably the easiest non-intrusive tweak to work around the repeated flagging by Safe Browsing, still no 100% guarantee. I agree that strict access blocking (with extra auth or IP ACL) can work better. Though I've seen in this thread https://news.ycombinator.com/item?id=45676712 https://news.ycombinator.com/item?id=45676712 and over the Internet that purely internal/private domains get flagged too. Can it be some Chrome + G Safe Browsing integration, e.g. reporting hashes of visited pages? Btw, folks in the Jellyfin thread tried blocking specifically Google bot / IP ranges (ASNs?) https://github.com/jellyfin/jellyfin-web/issues/4076#issuecomment-1506148340 https://github.com/jellyfin/jellyfin-web/issues/4076#issueco... with varying success. And go through your domain registration/re-review in G Search Console of course.
  - david_van_loon 1y ago
    Thank you for the "welcome message" suggestion! I'll implement that in the hope it may help in the future.
- tbyehl 1y ago
  That probably wouldn't work, I get hit with Chrome's red screen of annoyance regularly with stuff only reachable on my LAN. I suspect the trigger is that the URLs are like [product name].home.[mydomain.com].
  - wiether 1y ago
    I'm actually already avoiding this issue but for another reason: hackers will scan subdomains matching known products with known vulnerabilities, so hosting a Wordpress behind "wordpress.domain.tld" will get you way more ill-intentioned requests than "tbyehl.domain.tld". Thus if I started hosting my Immich instance, I would probably put it behind "pxl.domain.tld" or something like that. Not a garantee to pass the Google purity test, but, according to some reports, it would avoid raising some redflags.
darkwater 1y ago
Out of curiosity, is your Immich instance published as https://immich.example.com https://immich.example.com ?
- david_van_loon 1y ago
  Yes, it's on the "immich" subdomain. This has crossed my mind as a potential triggering cause, as has the default login page.
lucideer 1y ago
Unless I missed something in the article this seems like a different issue. The article is specifically about the domain "immich.cloud". If you're using your own domain, I'd check to ensure it hasn't been actually compromised by a bonnet or similar in some way you haven't noticed. It may well be a false positive of Google's heuristics but home server security can be challenging - I would look at ruling out the possibility of it being real first. It certainly sounds like a separate root issue to this article, even if the end result looks the same.
- lucideer 1y ago
  *botnet
david_van_loon 1y ago
Update: my appeal of the false positive has been accepted by Google and my domain is now unblocked.

david_van_loon 1y ago

Since other browsers, like Firefox, also use the Google Safe Browsing list, they are affected as well.

donmcronald 1y ago

Just in case you're not sure how to deal with it, you need to request a review via the Google Search Console. You'll need a Google account and you have to verify ownership of the domain via DNS (if you want to appeal the whole domain). After that, you can log into the Google Search Console and you can find "Security Issues" under the "Security & Manual Actions" section. That area will show you the exact URLs that got you put on the block list. You can request a review from there. They'll send you an email after they review the block. Hopefully that'll save you from trying to hunt down non-existent malware on a half dozen self-hosted services like I ended up doing.

shaky-carrousel 1y ago
It's a bit ironic that a user installing immich to escape Google's grip ends up having to create again a Google account to be able to remove their Google account.
- david_van_loon 1y ago
  Indeed. Thankfully, this isn't the first time Google has caused an issue like this, so I'm familiar with the appeal process.
account42 11mo ago
Reviews view Google Search Console are pointless because they won't stop the same automated process from flagging the domain again. Save your time and get your lawyer to draft a friendly letter instead.

wiether 1y ago

No later than last weekend I was comtemplating migrating my family pictures to a self-hosted Immich instance... I guess a workaround Google's crap would be to put an htpasswd/basic auth in front of Immich, blocking Google to get to the content and flagging it.

skatsubo 1y ago
Add a custom "welcome message" in Server Settings (https://my.immich.app/admin/system-settings?isOpen=server https://my.immich.app/admin/system-settings?isOpen=server) to make your login page look different compared to all other default Immich login pages. This is probably the easiest non-intrusive tweak to work around the repeated flagging by Safe Browsing, still no 100% guarantee. I agree that strict access blocking (with extra auth or IP ACL) can work better. Though I've seen in this thread https://news.ycombinator.com/item?id=45676712 https://news.ycombinator.com/item?id=45676712 and over the Internet that purely internal/private domains get flagged too. Can it be some Chrome + G Safe Browsing integration, e.g. reporting hashes of visited pages? Btw, folks in the Jellyfin thread tried blocking specifically Google bot / IP ranges (ASNs?) https://github.com/jellyfin/jellyfin-web/issues/4076#issuecomment-1506148340 https://github.com/jellyfin/jellyfin-web/issues/4076#issueco... with varying success. And go through your domain registration/re-review in G Search Console of course.
- david_van_loon 1y ago
  Thank you for the "welcome message" suggestion! I'll implement that in the hope it may help in the future.
tbyehl 1y ago
That probably wouldn't work, I get hit with Chrome's red screen of annoyance regularly with stuff only reachable on my LAN. I suspect the trigger is that the URLs are like [product name].home.[mydomain.com].
- wiether 1y ago
  I'm actually already avoiding this issue but for another reason: hackers will scan subdomains matching known products with known vulnerabilities, so hosting a Wordpress behind "wordpress.domain.tld" will get you way more ill-intentioned requests than "tbyehl.domain.tld". Thus if I started hosting my Immich instance, I would probably put it behind "pxl.domain.tld" or something like that. Not a garantee to pass the Google purity test, but, according to some reports, it would avoid raising some redflags.

darkwater 1y ago

Out of curiosity, is your Immich instance published as https://immich.example.com https://immich.example.com ?

david_van_loon 1y ago
Yes, it's on the "immich" subdomain. This has crossed my mind as a potential triggering cause, as has the default login page.

lucideer 1y ago

Unless I missed something in the article this seems like a different issue. The article is specifically about the domain "immich.cloud". If you're using your own domain, I'd check to ensure it hasn't been actually compromised by a bonnet or similar in some way you haven't noticed. It may well be a false positive of Google's heuristics but home server security can be challenging - I would look at ruling out the possibility of it being real first. It certainly sounds like a separate root issue to this article, even if the end result looks the same.

lucideer 1y ago
*botnet

david_van_loon 1y ago

Update: my appeal of the false positive has been accepted by Google and my domain is now unblocked.