Earlier quoted context omitted.
[flagged]
[flagged]
> Imagine defending the most evil, trillion dollar corp
Hyperbole much?
Google flags Immich sites as dangerous
201–210 of 713 posts
Re: Google flags Immich sites as dangerous
#202Re: Google flags Immich sites as dangerous
#203A good takeaway is to separate different domains for different purposes. I had prior been tossing up the pros/cons of this (such as teaching the user to accept millions of arbitrary TLDs as official), but I think this article (and other considerations) have solidified it for me. For example www.contoso.com (public) www.contoso.blog (public with user comments) contoso.net (internal) staging.contoso.dev (dev/zero trust…
The biggest con of this is that to a user it will seem much more like phishing. It happened to me a while ago that I suddenly got emails from "githubnext.com". Well, I know Github and I know that it's hosted at "github.com". So, to me, that was quite obviously phishing/spam. Turns out it was real...
This is such a difficult problem. You should be able to buy a “season pass” for $500/year or something that stops anyone from registering adjacent TLDs.
And new TLDs are coming out every day which means that I could probably go buy microsoft.anime if I wanted it.
This is what trademarks are supposed to do, but it’s reactive and not proactive.
Re: Google flags Immich sites as dangerous
#204Earlier quoted context omitted.
sites.google.com
The same outfit is runimg a domain called blogger. Reminds me of MS blocking a website of mine for dangerous script . The offending thing i did was use document.write to put copyright 2025 (with the current year) at the end of static pages.
My work's email filter regularly flags links to JIRA and github as dangerous. It stopped being even ironically amusing after a while.
Re: Google flags Immich sites as dangerous
#205Earlier quoted context omitted.
Right, for postgres I would use unnest for inserting a non-static amount of rows.
In the past I've used batches of data, inserted into a separate table with all the constraints turned off and using UNNEST, and then inserted into the final table once it was done. We ended up both batching the data and using UNNEST because it was faster but it still let us resume midway through. We probably should have been partitioning the data instead of inserting it twice, but I never got around to fixing that. C…
Was MERGE too slow/expensive? We tend to MERGE from staging or temporary tables when we sync big data sets. If we were on postgres I think we'd use ... ON CONFLICT, but MERGE does work.
Re: Google flags Immich sites as dangerous
#206This may not be a huge issue depending on mitigating controls but are they saying that anyone can submit a PR (containing anything) to Immich, tag the pr with `preview` and have the contents of that PR hosted on https://pr- .preview.internal.immich.cloud? Doesn't that effectively let anyone host anything there?
So basically like https://docs.google.com/ ?
Yes, except on Google Docs you can't make the document steal credentials or download malware by simply clicking on the link.
It's more like sites.google.com.
Re: Google flags Immich sites as dangerous
#207I tried to submit this, but the direct link here is probably better than the Reddit thread I linked to: https://old.reddit.com/r/immich/comments/1oby8fq/immich_is_a... I had my personal domain I use for self-hosting flagged. I've had the domain for 25 years and it's never had a hint of spam, phishing, or even unintentional issues like compromised sites / services. It's impossible to know what Google's black box is do…
> I suspect my flagging was the result of failing to use a large email provider. This seems like the flagging was a result of the same login page detection that the Immich blog post is referencing? What makes you think it's tied to self-hosted email?
I'm not using self hosted email. My theory is that Google treats smaller mail providers as less trustworthy and that increases the odds of having messages flagged for phishing.
In my case, the Google Search Console explicitly listed the exact URL for a newly created shared album as the cause.
https://photos.example.com/albums/xxxxxxxx-xxxx-xxxx-xxxx-xx...
I wish I would have taken a screenshot. That URL is not going to be guessed randomly and the URL was only transmitted once to one person via e-mail. The sending was done via MXRoute and the recipient was using GMail (legacy Workspace).
The only possible way for Google to have gotten that URL to start the process would have been by scanning the recipient's e-mail. What I was trying to say is that the only way it makes sense to me is if Google via GMail categorized that email as phishing and that kicked off the process to add my domain to the block list.
So, if email categorization / filtering is being used as a heuristic for discovering URLs for the block list, it's possible Google's discriminating against domains that use smaller email hosts that Google doesn't trust as much as themselves, Microsoft, etc..
All around it sucks and Google shouldn't be allowed to use non-deterministic guesswork to put domains on a block list that has a significant negative impact. If they want to operate a clown show like that, they should at least be liable for the outcomes IMO.
Re: Google flags Immich sites as dangerous
#208Earlier quoted context omitted.
I'm in a similar boat. Google's false flag is causing issues for my family members who use Chrome, even for internal services that aren't publicly exposed, just because they're on related subdomains. It's scary how much control Google has over which content people can access on the web - or even on their local network!
It's a good opportunity to recommend Firefox when you can show a clear abuse of position
Firefox uses the same list.
Re: Google flags Immich sites as dangerous
#209Earlier quoted context omitted.
Some of these seem less cursed, and more just security design? > Some phones will silently strip GPS data from images when apps without location permission try to access them. That strikes me as the right thing to do?
Huh. Maybe? I don't want that information available to apps to spy on me. But I do want full file contents available to some of them. And wait. Uh oh. Does this mean my Syncthing-Fork app (which itself would never strike me as needing location services) might have my phone's images' location be stripped before making their way to my backup system? EDIT: To answer my last question: My images transferred via Syncthing-…
With the Nextcloud app I remember having to enable full file permissions to preserve the GPS data of auto-uploaded photos a couple of years ago. Which I only discovered some months after these security changes went into effect on my phone. That was fun. I think Android 10 or 11 introduced it.
Looking now I can't even find that setting anymore on my current phone. But the photos still does have the GPS data intact.
Re: Google flags Immich sites as dangerous
#210[flagged]
I heard the CEO has a Hitler bedspread and Mussolini tattoo on the far-right of his right buttock.