Worse. More like less than 0.0001% of the humans on the planet.

Samesies

These are all holes in the Swiss cheese model.

Just because you and I cannot immediately consider ways of exploiting these vulnerabilities doesn’t mean they don’t exist or are not already in use (Including other endpoints of vulnerabilities not listed)

This is one of the biggest mindset gaps that exist in technology, which tends to result in a whole internet filled with exploitable services and devices. Which are more often than not used as proxies for crime or traffic, and not directly exploited.

Meaning that unless you have incredibly robust network traffic analysis, you won’t notice a thing.

There are so many sonarr and similar instances out there with minor vulnerabilities being exploited in the wild because of the same"Well, what can someone do with these vulnerabilities anyways" mindset. Turns out all it takes is a common deployment misconfiguration in several seedbox providers to turn it into an RCE, which wouldn’t have been possible if the vulnerability was patched.

Which is just holes in the swiss cheese model lining up. Something as simple as allowing an admin user access to their own password when they are logged in enables an entirely separate class of attacks. Excused because “If they’re already logged in, they know the password”. Well, not of there’s another vulnerability with authentication…

See how that works?

Please to see: https://github.com/jellyfin/jellyfin/issues/5415

Someone doesn’t necessarily have to brute Force a login if they know about pre-existing vulnerabilities, that may be exploited in unexpected ways

Fail2ban isn’t going to help you when jellyfin has vulnerable endpoints that need no authentication at all.

Jellyfin has a whole host of unresolved and unmitigated security vulnerabilities that make exposing it to the internet. A pretty poor choice.

https://github.com/jellyfin/jellyfin/issues/5415

“It’s just a prank bro”

Yep, just like electron or Tauri. A web view wrapped in a native application.

These are very common these days, it’s the same use case and value proposition. Mainly because it’s just easier to develop UIs with web technologies that look the same everywhere, never without the app.

You do know that a pwa can be packaged up in an app container and you won’t even be able to tell the difference?

It doesn’t actually have to operate like a pwa, and require native pwa sport.

There are tons of apps that you use that are just well packaged PWAs, packaged as an app store app, and you don’t even know about it.

PWAs only suck on when they suck, just like everything else.

I got the feeling that these replies are written by ChatGPT?

It kind of is though?

Essentially no protections for operators from bots, which means no protection for communities from automated infiltration and astroturfing.

The only thing stopping it is that the cost/benefit isn’t there yet with how small Lemmy is. But that’s slowly changing.

Thank you for making no effort to engage in conversation and instead trying to shut it down because it doesn’t agree with you.

Insinuating that I’m repeating talking points as a way to dismiss my opinion is the kind of bad faith comments no one wants here.

I’m familiar with them.

These are projects sitting years, maybe even a decade, away from maturity. IF web standards and capabilities don’t change at all over the next 5-10 years.

Hopefully that puts this into perspective. These are really cool projects, but without a massive influx of engineering effort and organization, they will likely be perpetually, hopelessly, behind the standard rate of change required of browsers. Nevermind meeting the current standards of performance, security, observability, ecosystem, user and developer experience.

It’s always good to check in on these projects yearly, see how it’s going, see if they are accelerating or slowing down. Eventually one of them will take off, and potentially leech resources from other similar projects.

Though, the nature of FOSS is that 1000 people will work on 200 different projects all trying to do the same thing, instead of combining and organizing efforts to go after the same unified goal.

This isn’t really a statement of fault but rather a statement of reality. Without dedicated full-time organization, this is usually how scattered resources solve problems. Which is a core problem here in that dedicated organization to rapidly grow the engineering effort for a particular project usually requires funding and full-time employees. To both market it to engineers as an interesting project, mature documentation and DevX, mature the onboarding experience for devs, and to handle the organizational aspects of distributing said work.

Any fork will die a slow and painful death of it can’t get the necessary funding for project management and maintainer salaries.

It will also dwindle, hard, towards irrelevancy.

In world where the only viable browser is one owned and operated by Google.

CEO is paid for from the for profit. The majority of costs are engineering salaries for Firefox.

Wtf you on about?

The grand majority of all costs for Firefox are in engineering salaries. And there is no million dollar CEO relating to the nonprofit’s expenses, that CEO is paid for from funds from the for profit organization.

Browsers are CRAZY expensive to build and maintain. And teams of engineers are crazy expensive.

I use jellyfin, and jellyfin is not safe to expose to the internet.

They have a handful of vulnerability and security holes that have been open for like 5+ years now. And the old emby architecture is quite difficult to work with.

And your simple command that covers all the file types supported, on any platform, is… What?

If you’re gonna bitch, and say your alternative is better, you had better cough up the alternative or your just full of shit…

Naw, that’s what shitty AI is for