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

681–690 of 713 posts

Re: Google flags Immich sites as dangerous

#681

Post by udev4096 »

immibis wrote: post #619
udev4096 wrote: post #302

Earlier quoted context omitted.

You should not be downvoted. Either HN has had an influx of ignorant normies or it's google bots attacking any negative comments

HN is extremely tone-policed. Lines like "holy shit look in a mirror" are likely to attract downvotes because of their form, with no other factors being considered.

It's full of people described in this blog post [1]. As it concludes, GTFO! Flagging is the IRL equivalent of crying to your superior instead of actually having an argument which is pathetic

[1] - https://geohot.github.io/blog/jekyll/update/2025/10/15/pathe...

Re: Google flags Immich sites as dangerous

#682

Post by udev4096 »

tjpnz wrote: post #391
udev4096 wrote: post #302

Earlier quoted context omitted.

You should not be downvoted. Either HN has had an influx of ignorant normies or it's google bots attacking any negative comments

People working for famous adtech companies don't like it when people like op burst their bubble. I myself don't like it one bit - keep on changing the world you beautiful geniuses!

Exactly! Most of HN users work for "big tech" and are complete sell outs to their corporate overlords. Majority of them are to blame for the current bloated state of the web along with excessive mass surveillance and anti-privacy state we are in

Re: Google flags Immich sites as dangerous

#683

Post by shadowgovt »

bigbadfeline wrote: post #570
shadowgovt wrote: post #102

Earlier quoted context omitted.

Sympathy for the devil, people keep using Google's browser because the safe search guards catch more bad actors than they false positive good actors.

> the safe search guards catch more bad actors than they false positive good actors. Well, if the legal system used the same "Guilty until proven innocent" model, we would definitely "catch more bad actors than false positive good actors". That's a tricky one, isn't it.

You do not want malware protection to be running at the speed of the legal system.

A better analogy, unfortunately for all the reasons it's unfortunate, is police: acting on the partial knowledge in the field to try to make the not-worst decision.

Re: Google flags Immich sites as dangerous

#684

Post by shadowgovt »

account42 wrote: post #644
shadowgovt wrote: post #102

Earlier quoted context omitted.

Sympathy for the devil, people keep using Google's browser because the safe search guards catch more bad actors than they false positive good actors.

This is not an honest argument. Most people don't even know this web censorship mechanism exists until they see something (usually legit) blocked.

Do they then switch browsers in response?

Re: Google flags Immich sites as dangerous

#685

Post by shadowgovt »

hulitu wrote: post #160
shadowgovt wrote: post #102

Earlier quoted context omitted.

Sympathy for the devil, people keep using Google's browser because the safe search guards catch more bad actors than they false positive good actors.

> people keep using Google's browser because the safe search guards catch more bad actors than they false positive good actors. This is the first thing i disable in Chrome, Firefox and Edge. The only safe thing they do is safely sending all my browsing history to Google or Microsoft.

That's a reasonable thing for you to do (especially if you have some other signal source you use for malware protection), but HN readers are rarely representative of average users.

This feature is there for my mother-in-law, who never saw a popup ad she didn't like. You might think I'm kidding; I am not. I periodically had to go into her Android device and dump twenty apps she had manually installed from the Play Store because they were in a ring of promoting each other.

Re: Google flags Immich sites as dangerous

#686

Post by Groxx »

Groxx wrote: post #426
lukan wrote: 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?

I'm under the impression that CORS largely solves it? which is still much too new to be able to shut down the PSL of course. but maybe in 2050.

Since this is being downvoted: no, I'm quite serious.

CORS lets sites define their own security boundaries between subdomains, with mutual validation. If you're hosting user content in a subdomain, just don't allow-origin it: that is a clear statement that it's not "the same site". PSL plays absolutely no part in that logic, it seems clear to me that it's at least in part intended to replace the PSL.

Do other sites (like google's safety checks) use CORS for this purpose? Dunno. Seems like they could though? Or am I missing something?

Re: Google flags Immich sites as dangerous

#687

Post by immibis »

udev4096 wrote: post #681
immibis wrote: post #619

Earlier quoted context omitted.

HN is extremely tone-policed. Lines like "holy shit look in a mirror" are likely to attract downvotes because of their form, with no other factors being considered.

It's full of people described in this blog post [1]. As it concludes, GTFO! Flagging is the IRL equivalent of crying to your superior instead of actually having an argument which is pathetic [1] - https://geohot.github.io/blog/jekyll/update/2025/10/15/pathe...

HN flagging is just shadow moderation.

I asked dang if I was shadowbanned from flagging. He said yes, if I flag something then it doesn't count because I flagged the wrong things in the past.

The conclusion is that flagging isn't really up to user choice, but is up to dang who decides which things should be flagged and which shouldn't. It's a bit like how on Reddit, the only comments you can see are the ones that agree with the moderators of that subreddit.

Re: Google flags Immich sites as dangerous

#688

Post by 0xbadcafebee »

progval wrote: post #626
0xbadcafebee wrote: post #610

Earlier quoted context omitted.

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

> 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

This attack already exists in several forms (leaking a TLS private key, DNS hijack, CA validation attack, etc). You could tack a DNS name onto the crypto-cookies if you wanted to, but DNS is trivial to attack.

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

Requests are already slowed down by the gigantic amount of cookies constantly being pushed by default. The server can send a reply-header once which will tell the client which URLs need cookies perpetually, and the client can store that and choose whether it sends the cookies repeatedly or just when requested. This gives the client much more control over when it leaks users' data.

> This requires significantly overhauling HTTP and load-balancers

No change is needed. Web applications already do all of this all the time. (example: the Location: header is frequently sent by web apps in response to specific requests, to say nothing of REST and its many different request and return methods/statuses/headers).

> The public-suffix list exists because it's an easy workaround

So the engine of modern commerce is just a collection of easy hacks. Fantastic.

Re: Google flags Immich sites as dangerous

#689

Post by IanCal »

ramses0 wrote: post #385
IanCal wrote: post #305

Earlier quoted context omitted.

> any platform that needs this functionality but would prefer not to leak any details publicly. I’m not sure how you’d have this - it’s for the public facing side of user hosted content, surely that must be public? > We already have the concept of a .well-known directory that you can use, when talking to a specific site. But the point is to help identify dangerous sites, by definition you can’t just let the sites mar…

It's actually exactly the same concept that come to mind for me. `SomeUser.geocities.com` is "tainted", along with `*.geocities.com`, so `geocities.com/.wellknown/i-am-tainted` is actually reasonable. Although technically it might be better as `.wellknown/taint-regex` (now we have three problems), like `TAINT "*.sites.myhost.com" ; "myhost.com/uploads/*" ; ...`

I think we disagree on the problem.

The thing you want to avoid is this:

a.scamsite.com gets blocked so they just put their phishing pages on b.scamsite.com

The psl or your solution isn’t a “don’t trust subdomains” notification it’s “if one subdomain is bad, you should still trust the others” and the problem there is you can’t trust them.

You could combine the two, but you still need the suffix list or similar curation.

Re: Google flags Immich sites as dangerous

#690

Post by fc417fc802 »

arccy wrote: post #330
fc417fc802 wrote: post #261

Earlier quoted context omitted.

How does the PSL make any sense? What stops an attacker from offering free static hosting and then making use of their own service? I appreciate the issue it tries to solve but it doesn't seem like a sane solution to me.

PSL isn't a list of dangerous sites per-se. Browsers already do various levels of isolation based on domain / subdomains (e.g. cookies). PSL tells them to treat each subdomain as if it were a top level domain because they are operated (leased out to) different individuals / entities. WRT to blocking, it just means that if one subdomain is marked bad, it's less likely to contaminate the rest of the domain since they k…

Marking for cookie isolation makes sense, but could be done more effectively via standardized metadata sent by the first party themselves rather than a centralized list maintained by a third party.

Informing decisions about blocking doesn't make much sense (IMO) because it's little more than a speed bump for an attacker. Certainly every little bit can potentially help but it also introduces a new central authority, presents an additional hurdle for legitimate operators, introduces a number of new failure modes, and in this case seems relatively trivial for a determined attacker to overcome.

Post reply on HN