[lucideer]

> mitigating false positives

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.

I think there's likely a conversation to be had about messaging - Chrome's warning page seems a little scarier than it should be, Firefox's is more measured in its messaging. But in terms of the API service Google are providing here this is absolutely not a false positive.

The rest of your comment seems to be an analoy about people not being responsible for protecting their home or something, I'm not quite sure. If you leave your apartment unlocked when you go out & a thief steals your housemate's laptop, is your housemate required to exclusively focus on the thief or should they be permitted to request you to be more diligent about locking doors?

[Gormo]

> 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.

Where are you getting that from? I don't see any evidence that there actually was any malicious activity going on on the Immich domain.

> But in terms of the API service Google are providing here this is absolutely not a false positive.

Google is applying heuristics derived from statistical correlations to classify sites. When a statistical indicator is present, but its target variable is not present, that is the very definition of a false positive.

Just because their verbiage uses uncertainty qualifiers like "may" or "might" doesn't change the fact that they are materially interfering with a third party's activities based on presumptive inferences that have not been validated -- and in fact seem to be invalid -- in this particular case.

> If you leave your apartment unlocked when you go out & a thief steals your housemate's laptop, is your housemate required to exclusively focus on the thief or should they be permitted to request you to be more diligent about locking doors?

One has nothing to do with the other. The fact that you didn't lock your door does not legitimize the thief's behavior. Google's behavior is still improper here, even if website operators have the option of investing additional time, effort, or money to reduce the likelihood of being misclassified by Google.

[lucideer]

> its target variable is not present, that is the very definition of a false positive

The target variable is user hosted content on subdomains of a domain not listed in Mozilla's public suffix list. Firefox & Chrome apply a much stricter set of security settings for domains on that list, due to the inherent dangers of multiuser domains. That variable is present, Immich have acknowledged it & are migrating to a new domain (which they will hopefully add to Mozilla's list).

> The fact that you didn't lock your door does not legitimize the thief's behavior. Google's behavior is still improper here

I made no claims about legitimising the thief's behaviour - only that leaving your door unlocked was negligent from the perspective of your housemate. That doesn't absolve the thief. Just as any malicious actor trying to compromise Immich users would still be the primary offender here, but that doesn't absolve Immich of a responsibility to take application security seriously.

And I don't really understand where Google fits in your analogy? Is Google the thief? It seems like a confusing analogy.

[Gormo]

> The target variable is user hosted content on subdomains of a domain not listed in Mozilla's public suffix list.

No, that's the indicator. The target variable is "malicious website".

[CaptainOfCoit]

> 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 something malicious through that system, it seems Google did not have a legitimate reason for flagging it.

[bo0tzz]

> unless one of the developers in the team published something malicious through that system

If that happened we'd have much bigger problems than Google's flagging.

[lucideer]

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.

[bo0tzz]

As I've mentioned in several other comments in this thread by now: The whole preview functionality only works for internal PRs, untrusted ones would never even make it to deployment.

[krzyk]

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.

[bo0tzz]

> Google flagged this domain for legitimate reasons.

No they didn't.

[marcosdumay]

Do you know the legitimate reasons?

Because the article seems to only ever get an excuse from Google that is easy to dismiss because most sites do something similar.

[lucideer]

The legitimate reason is that the domain is correctly classified as having user generated active content, because the Immich GitHub repo allows anyone to submit arbitrary code via PR, and PRs can be autodeployed to this domain without passing review or approval.

Domains with user generated active content should typically by listed on Mozilla's Public Suffix list, which Firefox & Chrome both check & automatically apply stricter security settings to, to protect users.

[bo0tzz]

> correctly classified as having user generated active content

No it's not

> PRs can be autodeployed to this domain without passing review or approval.

No they can't

There is no untrusted/user content on these domains.

[MetaWhirledPeas]

> Google flagged this domain for legitimate reasons.

Why would it flag a domain rather than a subdomain?

[lucideer]

Which subdomain?

[krzyk]

The one that contained malicious code, if there was any.