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

631–640 of 713 posts

Re: Google flags Immich sites as dangerous

#631

Post by bo0tzz »

lucideer wrote: post #588
CaptainOfCoit wrote: post #541

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.

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.

Re: Google flags Immich sites as dangerous

#632

Post by bo0tzz »

lucideer wrote: post #589
marcosdumay wrote: post #568

Earlier quoted context omitted.

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.

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

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

Re: Google flags Immich sites as dangerous

#633

Post by bo0tzz »

lucideer wrote: post #591
bo0tzz wrote: post #367

Earlier quoted context omitted.

> what Immich is doing here is extremely dangerous You fully misunderstand what content is hosted on these sites. It's only builds from internal branches by the core team, there is no path for "external user" content to land on this domain.

It's builds from PRs that can be submitted by anyone with a GitHub account

Dude, I built it, surely I'd know how it works...

Re: Google flags Immich sites as dangerous

#634

Post by account42 »

Yes, this is not a new problem: Web browsers has taken on the role as internet police but they only care about their judgement and don't afford websites operators any due process or recourse. And by web browsers I mean Google because of course everyone just defers to them. "File a complaint with /dev/null" might be how Google operates their own properties but this should not be acceptable for the web as a whole. Google and those integrating their "solutions" need to be held accountable for the damage they cause.

Re: Google flags Immich sites as dangerous

#635

Post by bo0tzz »

akerl_ wrote: post #602
bo0tzz wrote: post #370

Earlier quoted context omitted.

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

1. It only works at all for internal PRs, not for forks. That is a limitation we'd like to lift if we could figure out a way to do it safely though.

2. It's running on a pretty big machine, so I haven't seen it approach any limits yet. We also only create an instance when requested (with a PR label).

3. I've of course been inspired by other examples, but I think the current pattern is mostly my own, if largely just one of the core uses of the flux-operator ResourceSet APIs [1]. It's absolutely generalizable - the main 'loop' [2] just templates whatever Kubernetes resources based on the existence of a PR, you could put absolutely anything in there.

[1]: https://fluxcd.control-plane.io/operator/resourcesets/github...

[2]: https://github.com/immich-app/devtools/blob/main/kubernetes/...

Re: Google flags Immich sites as dangerous

#636

Post by account42 »

asplake wrote: post #220
jadengeller wrote: post #154

Earlier quoted context omitted.

I'd probably say we ought to use DNS.

And while we’re at it, 1) mark domains as https-only, and 2) when root domains map to a subdomain (eg www).

I might amuse you to know hat we also already have a text file as a solution for https-only sites.

Re: Google flags Immich sites as dangerous

#637

Post by account42 »

com2kid wrote: post #137
gmueckl wrote: post #109

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.

Just because you can do something doesn't mean you should.

Your micro-controllers should use open standards for their debugging interface and not force people to use the vendor website.

Re: Google flags Immich sites as dangerous

#638

Post by account42 »

sofixa wrote: post #562
gmueckl wrote: post #540

Earlier quoted context omitted.

I'll flip that around on you: why oh why do we need to browsers to carry these security holes in them? The Stadia flasher is a good example: how do I know that a website doesn't contain a device flasher that will turn one of my connected devices into a malicious actor that will attempt to take over whatever machine it's plugged into?

You know because there is an explicit permission box that pops out and asks if you want to give this website access to a device, and asks you to select that device. Same as your camera/microphone/location.

And we all know that non-technical users never just click Yes to make the annoying popup go away.

Re: Google flags Immich sites as dangerous

#639

Post by account42 »

shadowgovt wrote: post #111
gmueckl wrote: post #109

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.

How else am I going to make a game in the browser that be controlled with a controller?

You don't, that's the point: not everything needs to be crammed into a browser.

Re: Google flags Immich sites as dangerous

#640

Post by account42 »

shadowgovt wrote: post #345
gmueckl wrote: post #216

Earlier quoted context omitted.

Every decent host OS already has a dedicated driver stack to provide game controller input to applications in a useful manner. Why the heck would you ship a reimplementation of that in JS in a website?

So that you can take input from countrollers that haven't been invented yet and won't fit the HID model.

If it hasn't been invented yet we don't know the implications of giving a website access to it either.

And that's before realizing it's already a bad idea with existing devices because they were never designed for giving untrusted actors direct access.

Post reply on HN