Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google flags Immich sites as dangerous

immich.app

Post reply on HN
Print view View original

601–610 of 713 posts

Re: Google flags Immich sites as dangerous

#601

Post by inopinatus »

IshKebab wrote: post #582
inopinatus wrote: post #322

Earlier quoted context omitted.

Whois would be the choice. DNS’s less glamourous sibling, purpose built for delegated publication of accountability records

Whois isn't curated either.

Neither is nominating a third party for your parking fine.

The point is to get away from centralized gatekeepers, not establish more of them. A hierarchy of disavowal. It’s like cache invalidation for accountability.

If you don’t wanna be held responsible for something, you’d better be prepared to point the finger at someone whois.

Re: Google flags Immich sites as dangerous

#602

Post by akerl_ »

bo0tzz wrote: post #370
TheDong wrote: post #51

Earlier quoted context omitted.

It's open source, you can find this trivially yourself in less than a minute. https://github.com/immich-app/devtools/tree/a9257b33b5fb2d30...

If anyone's got questions about this setup I'd be happy to chat about it!

I’m curious about basically all of it. It seems like such a powerful tool.

I seem to have irritated the parallel commenters tremendously by asking, but it seemed implausible I’d understand the design considerations by just skimming the CI config.

Top of mind would be:

1. How do y'all think about mitigating the risk of somebody launching malicious or spammy PR sites? Is there a limiting factor on whose PRs trigger a launch?

2. Have you seen resource constraint issues or impact to how PRs are used by devs? It seems like Immich is popular enough that it could easily have a ton of inflight PR dev (and thus a ton of parallel PR instances eating resources)

3. Did you borrow this pattern from elsewhere / do you think the current implementation of CI hooks into k8s would be generalizable? I’ve seen this kind of PR preview functionality in other repos that build assets (like CLI tools) or static content (like docs sites), but I think this is the first time I’ve seen it for something that’s a networked service.

Re: Google flags Immich sites as dangerous

#603

Post by marcosdumay »

stonogo wrote: post #58
elphinstone wrote: post #45

Earlier quoted context omitted.

They are not the government and should not have this vast, unaccountable monopoly power with no accountability and no customer service.

the government probably shouldn't either?

The government tends to get out of their way to have accountability and customer service.

Re: Google flags Immich sites as dangerous

#604

Post by dpifke »

jdsully wrote: post #54

The one thing I never understood about these warnings is how they don't run afoul of libel laws. They are directly calling you a scammer and "attacker". The same for Microsoft with their unknown executables. They used to be more generic saying "We don't know if its safe" but now they are quite assertive at stating you are indeed an attacker.

Spamhaus has been sued—multiple times, I believe—for publishing DNS-based lists used to block email from known spammers.

For instance: https://reason.com/volokh/2020/07/27/injunction-in-libel-cas... (That was a default judgment, though, which means Spamhaus didn't show up, probably due to jurisdictional questions.)

The first step in filing a libel lawsuit is demanding a retraction from the publisher. I would imagine Google's lawyers respond pretty quickly to those, which is why SafeBrowsing hasn't been similarly challenged.

Re: Google flags Immich sites as dangerous

#605

Post by CaptainOfCoit »

no_wizard wrote: post #509
foobarian wrote: post #81

Earlier quoted context omitted.

First rule of the public suffix list...

I think what gets me more is I don't see an easy way to add suffixes to the list. I'm sure if I dig I can figure it out but you'd think given how its used they'd have an obvious step by step guide on the website

Last link the menu header: https://publicsuffix.org/submit/

Which then links to: https://github.com/publicsuffix/list/wiki/Guidelines#submitt...

Fairly obvious and typical webpage > documentation flow I think, doesn't seem too hard to find.

Re: Google flags Immich sites as dangerous

#606

Post by jkaplowitz »

snowwrestler wrote: post #571
jkaplowitz wrote: post #564

Earlier quoted context omitted.

In another comment in this thread, it was confirmed that these PR host names are only generated from branches internal to Immich or labels applied by maintainers, and that this does not automatically happen for arbitrary PRs submitted by external parties. So this isn’t the use case for the public suffix list - it is in no way public or externally user-generated. What would you recommend for this actual use case? Even…

If these are dev subdomains that are actually for internal use only, then a very reliable fix is to put basic auth on them, and give internal staff the user/password. It does not have to be strong, in fact it can be super simple. But it will reliably keep out crawlers, including Google.

They didn't say that these are actually for internal use only. They said that they are generated either from maintainers applying labels (as a manual human decision) or from internal PR branches, but they could easily be publicly facing code reviews of internally developed versions, or manually internally approved deployments of externally developed but internally reviewed code.

None of these are the kind of automatic user-generated content that the warning is attempting to detect, I think. And requiring basic auth for everything is quite awkward, especially if the deployment includes API server functionality with bearer token auth combined with unauthenticated endpoints for things like built-in documentation.

Re: Google flags Immich sites as dangerous

#607

Post by Gormo »

lucideer wrote: post #587
Gormo wrote: post #513

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

> 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 do…

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

Re: Google flags Immich sites as dangerous

#608

Post by 0xbadcafebee »

shadowgovt wrote: post #554
alias_neo wrote: post #277

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.

More accurate: a mom-n-pop grocery store has its listing on Google Maps changed to PERMANENTLY CLOSED DUE TO TOXIC HEALTH HAZARDS because the mom-n-pop grocery store didn't submit Form 26B/Z to Google. There was never any health hazard, but now everyone thinks there is, and nobody can/will go there. The fact that Form 26B/Z exists at all is problematic, but what makes it terrible is the way it's used to punish businesses for not filling out a form they didn't know existed.

Re: Google flags Immich sites as dangerous

#609

Post by shadowgovt »

0xbadcafebee wrote: post #608
shadowgovt wrote: post #554

Earlier quoted context omitted.

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.

More accurate: a mom-n-pop grocery store has its listing on Google Maps changed to PERMANENTLY CLOSED DUE TO TOXIC HEALTH HAZARDS because the mom-n-pop grocery store didn't submit Form 26B/Z to Google. There was never any health hazard, but now everyone thinks there is, and nobody can/will go there. The fact that Form 26B/Z exists at all is problematic, but what makes it terrible is the way it's used to punish busine…

This is an excellent analogy because it is incumbent upon businesses to follow all the laws, including the ones they don't know about. That's one of the reasons "lawyer" is a profession.

Google doesn't have the force of law (it's in this context acting more like a Yelp: "1 star review --- our secret shopper showed up and the manager didn't give the secret 'we are not criminals' hand sign"), but the basic idea is the same: there is a complex web of interactions that can impact your online presence and experts in the field you can choose to hire for consulting or not.

Didn't used to be that way, but the web used to be a community of 100,000 people, not 5.6 billion. Everything gets more complicated when you add more people.

Re: Google flags Immich sites as dangerous

#610

Post by 0xbadcafebee »

lukan wrote: post #71
0xbadcafebee wrote: post #65

Earlier quoted context omitted.

In the past, browsers used an algorithm which only denied setting wide-ranging cookies for top-level domains with no dots (e.g. com or org). However, this did not work for top-level domains where only third-level registrations are allowed (e.g. co.uk). In these cases, websites could set a cookie for .co.uk which would be passed onto every website registered under co.uk. Since there was and remains no algorithmic meth…

"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 invalid keys. The client can also sign the response. This solves many different security concerns, privacy concerns, and also eliminates the dependency on specific domain names.

I just came up with that in 2 minutes, so it might not be perfect, but you can see how with a little bit of work there's much better solutions than "I check for not-evil domain in list!"

Post reply on HN