Live data from Hacker News

Google flags Immich sites as dangerous

immich.app

621–630 of 713 posts

Re: Google flags Immich sites as dangerous

#621

Earlier quoted context omitted.

> The problem is that the divide of alignment of interests there is between new, small companies and users. New companies want to put up a website without tripping over one of the thousand unwritten rules of "How to not look like a phishing site or malware depot" (many of which are unwritten because protecting users and exploiting users is a cat-and-mouse game)... And users don't want to get owned Some candidate lang…

> Monopolistic companies may not actively impose restrictions which harm others (includes businesses) That's not generally how monopoly is interpreted in the US (although jurisprudence on this may be shifting). In general, the litmus test is consumer harm. A company is allowed to control 99% of the market if they do it by providing a better experience to consumers than other companies can; that's just "being successf…

> Too broad. It harms me when Google blocks my malware distribution service because I'm interested in getting malware on your machine; I really want your Bitcoin wallet passwords, you see. ;)

That's okay, a random company failing to protect users from harm is still better than harming an innocent person by accident. They already fail in many cases, obviously we accept a failure rate above 0%. You also skipped over the rest of that paragraph.

> users like Chrome and are free to use it and tend to find site protection useful (or at least "not a burden to them")

That's okay, Google can abide by the proposal I set forth avoiding automated mistaken harms to people. If they want to build this system that can do great harms to people, they need to first and foremost build in safety nets to address those harms they cause, and only then focus on reducing false negatives.

Re: Google flags Immich sites as dangerous

#622

Earlier quoted context omitted.

> First & foremost I really need to emphasise that, despite the misleading article title, this was not a false positive. Google flagged this domain for legitimate reasons. Judging by what a person from the Immich team said, that does not seem to be true? > the whole system only works for PRs from internal branches - https://news.ycombinator.com/item?id=45681230 So unless one of the developers in the team published so…

Anyone can open a PR. Deploys are triggered by an Immich collaborator labelling the PR, but it doesn't require them to review or approve the code being deployed.

Yes, but unless that pr contain malicious code domain shouldn't be marked as such. You should assume good faith, not the other way around.

Re: Google flags Immich sites as dangerous

#624
post #531

Earlier quoted context omitted.

The reason Google doesn’t block Microsoft isn’t that they’re “looking out for Microsoft.” They’re looking out for themselves by being aware that blocking something that millions of people use would be bad for business.

So why isn't blocking something that is starred 82k times on GitHub bad for business.

I forget. How much do users pay per star again?

Re: Google flags Immich sites as dangerous

#625
post #177

Can I use this space to comment on how amazing Immich is? I self host lots of stuff, and there’s this one tier above everything else that’s currently, and exclusively, held by Home Assistant and Immich. It is actually _better_ than Google photos (if you keep your db and thumbs on ssd, and run the top model for image search). You give up nothing, and own all your data.

What model do you recommend for image search?

This is what I use:

ViT-SO400M-16-SigLIP2-384__webli

I think I found it because it was recommended by Immich as the best, but it still only took a day or two to run against my 5 thousand assets. I’ve tested it against whatever Google is using (I keep a part of my library on Google Photos), and it’s far better.

Re: Google flags Immich sites as dangerous

#626
post #71

Earlier quoted context omitted.

"The engineering equivalent of a car made of duct tape" Kind of. But do you have a better proposition?

Cookies shouldn't be tied to domains at all, it's a kludge. They should be tied to cryptographic keypairs (client + server). If the web server needs a cookie, it should request one (in its reply to the client's first request for a given url; the client can submit again to "reply" to this "request"). The client can decide whether it wants to hand over cookie data, and can withhold it from servers that use different or…

> They should be tied to cryptographic keypairs (client + server).

So now, if a website leaks its private key, attackers can exfiltrate cookies from all of its users just by making them open an attacker-controlled link, for as long as the cookie lives (and users don't visit the website to get the rotated key).

> If the web server needs a cookie, it should request one

This adds a round-trip, which slows down the website on slow connections.

> the client can submit again to "reply" to this "request"

This requires significantly overhauling HTTP and load-balancers. The public-suffix list exists because it's an easy workaround that didn't take a decade to specify and implement.

Re: Google flags Immich sites as dangerous

#627

Earlier quoted context omitted.

But do we need e.g serial port or raw USB access straight from a random website? Even WebRTC is a bit of a stretch. There is a lot of cruft in modern browsers that does little except increase attack surface. This all just drives a need to come up with ever more tacked-on protection schemes because browsers have big targets painted on them.

Itch.io games and controller support. You have sites now that let you debug microcontrollers on your browser, super cool. Same thing but with firmware updates in the browser. Cross platform, replaced a mess of ugly broken vendor tools.

While that's pretty convenient, I'm worried about what happens when the vendor shuts down the website. "Ugly broken vendor tools" can be run forever in a VM of an old system, but a website would be gone forever unless it's purely client-side and someone archived it.

Re: Google flags Immich sites as dangerous

#628

Earlier quoted context omitted.

> That good enough? Not really. Does the car still drive? That sounds like a software bug; hardly indicative that the entire car is held together with duct tape, but a pretty bad bug non the less.

So i can't remember the specifics or find any references, but many years ago i remember reading about a car (prius maybe?) that would shut off and lock the doors when pulling away from a stop. (Ex: stopped at a red light, when it turns green the car would go far enough to cut off in the middle of an intersection then trap everyone inside.) "This is Fine."

That's terrifying.

Re: Google flags Immich sites as dangerous

#629

Earlier quoted context omitted.

> That good enough? Not really. Does the car still drive? That sounds like a software bug; hardly indicative that the entire car is held together with duct tape, but a pretty bad bug non the less.

The browser still drives when Google throws up a safety warning. It's just harder to drive to one house, and the homeowner is justifiably irritated about this.

The other commenter's analogy of a small-business is better I think, the issue with the browser problem is that it doesn't hinder one person getting to one house, it hinders all persons getting to one place the owner _wants_ people to get to easily.

The browser issue can destroy a small business, one thing I think we can universally agree we don't want. If all of the people who come looking for it find it's being marked as malicious or just can't get there at all, they lose customers.

Worse yet, is that Google holds the keys because everyone uses Chrome, and you have to play their game by their rules just to keep breathing.

Re: Google flags Immich sites as dangerous

#630
A similar issue happened to us at APKMirror last week. https://x.com/ArtemR/status/1979428936267501626.

We still don't know what caused it because it happened to the Cloudflare R2 subdomain, and none of the Search Console verification methods work with R2. It also means it's impossible to request verification.

Post reply on HN