No, firefox doesn't implement the webusb standard which they probably want.
https://developer.mozilla.org/en-US/docs/Web/API/WebUSB_API
The problem here is not browser support, but them not shipping a native application or library (which I would want to be open source).
Absolutely, this is an admirable project.
But the first thing you should know is that QubeOS is not based on Linux, but is actually a different kernel, Xen. The Xen kernel virtualizes Linux, and all Linux runs under it.
Networking and hardware access is done by certain VM's having devices (like the ethernet card or monitor/keyboard) passed through them, where Linux then handles the hardware access with it's drivers.
This is important to understand that, because QubeOS is not a Linux distro. Really, it's just that they selected Linux (it was either Debian or Fedora IIRC) as their management VMs.
But once you understand that it's absolutely feasible to adjust the VM's. It's probably easier to modify a LInux distro (or create your own) and use that for all the VM's, and then to reuse Qube's management related software. That way you could do something like ship a version of debian that disables non-free software and firmware in the debian repos. Doing that is probably easier than creating your own distro entirely from scratch.
Another interesting thing about Qubes is that you are not limited to Linux. Of course, using Linux will be easiest. But the management VM's can technically be any OS that supports it.
The reality is that security is not just technical implementation, but also actually getting people to use the solutions. "Stop disabling SELinux" is not a real answer to when people disable it, like we have one person in this thread.
Another problem with complex security solutions is they are hard to get right. Even if you enable them and configure them, without being an expert, it's possible you left a gap here or there, and holes and gaps in these solutions.*
There is a good, but bit dated writeup here about the problems with Linux security, from an architecturual perspective: https://madaidans-insecurities.github.io/linux.html . But, the short version is that the Linux kernel is large and complex, and has a lot of attack surface. And it's a frequent source of vulnerabilities because attackers can hit it as long as they access to the kernel, even if they are in a container/sandbox. Like, copyfail and dirtyfrag would punch through containers, but also punch through SELinux.
For example, just earlier on lemmy someone dropped a zero day that punches through SELinux: https://programming.dev/post/51103657
Now, SELinux can be used to restrict what a root shell could do after escalating... but that's further complexity you have to learn to configure, and configure it correctly as well.
Ultimately, none of the Linux security solutions come anywhere near the isolation of simply running something in a virtual machine. Which, also happens to be a lot simpler and actually possible to get people to use.
*(putting this at the bottom because it veers off topic) I have a greater argument and problem with mentalities like this. I have noticed a pattern, where many of the more effortfull and toil intensive security solutions are recommended by people who have the time, energy, and skills to execute them. They have a bias/blindspot to the realities, which is that not everyone is in the same situation as them.
For example, updating/patching software. Linux distros like RHEL or Debian, have a policy where they only do security updates, and don't do feature updates or bugfixes. This enables them to ship automatic updates, so that security issues are automatically handled.
On the other hand software like Windows, likes to bundle in breaking changes along with security updates. So automatic updates get disabled because "They might break something". And then, people don't update them, and environments get horrifically out of date, because not enough money/time/people is put into regular IT people who are in charge of maintaining them.
But some environments, have heroes, people who go around patching everything and keeping everything up to date and secure. And when they see these environments that don't have everything patched, they usually give the advice of "You should patch everything" (while simultaneously advising against auto updates), not understanding that these environments are lacking a key ingredient: Themselves.
Sure, I could be a hero. I could "patch" everything manually. I could deploy SELinux. But that would only last until I get burnt out, or leave. Once I'm gone, SELinux, the patches, any similar security solutions are gone. I've met so many people, even in cybersecurity, that are apathetic about security, even though they might have cared once upon a time.
Proxmox is also making their own: https://www.proxmox.com/en/products/proxmox-datacenter-manager/overview
source code: https://github.com/proxmox/proxmox-datacenter-manager
Two more that I have found:
a grand scale with the XZ backdoor
The XZ backdoor, affected a lot less machines than you think. It did not affect:
The malicious code never made it into RHEL or Debian. Both of those distros have a model of freezing packages at a specific version. They then only push manually reviewed security updates, ignoring feature updates or bugfixes to the programs they are packaging. This ensures maximum stability for enterprise usecases, but the way that the changes are small and reviawable also causes them to dodge supply chain attacks like xz (it also enables these distros to have stable auto update features, which I will mention later). But those distros make up a HUGE family of enterprise Linux machines, that were simply untouched by this supply chain attack.
As for linux distros that don't integrate ssh with systemd or non systemd distros being affected, that was because the malware was inactive in those scenarios. Malicious code did make it there, but it didn't activate. I wonder if that was sloppiness on the part of the maker of the malware, or intentional, having it activate less frequently as a way of avoiding detection?
Regardless, comparing the XZ backdoor to the recent NPM and other programming language specific package manager supply chain attacks is a huge false analogy. They aren't comparable at all. Enterprise Linux distros have excellent supply chain security, whereas programming language package managers have basically none. To copy from another comment of mine about them:
Debian Linux, and many other Linux distros, have extensive measures to protect their supply chain. Packages are signed and verified, by multiple developers, before being built reproducibly (I can build and verify and identical binary/package). The build system has layers, such that if only a single layer is compromised, nothing happens and nobody flinches.
Programming langauge specific package repos, have no such protections. A single developer has their key/token/account, and then they can push packages, which are often built on their own devices. There are no reproducible build to ensure the binaries are from the same source code, and no multi-party signing to ensure that multiple devs would need to be compromised in order to compromise the package.
So what happened, probably, is some developer got phished or hacked, and gave up their API key. And the package they made was popular, and frequently ran unsandboxed on devs personal devices, so when other developers downloaded the latest version of that package, they got hacked too. The attackers then used their devices to push more malicious packages to the repo, and the cycle repeats.
And that’s why supply chain attacks are now a daily occurrence.
And then this:
You should probably turn off Dependabot. In my experience, we get more problems from automatic updates than we would by staying on the old versions until needed.
Also drives me insane as well. It's a form of survivorship bias, where people only notice when automatic upgrades cause problems, but they completely ignore the way that automatic security upgrades prevent many issues. Nobody cares about some organization NOT getting ransomwared because their webserver was automatically patched. That doesn't make the news the way that auto upgrades breaking things does. To copy from yet another comment of mine
If your software updates between stable releases break, the root cause is the vendor, rather than auto updating. There exist many projects that manage to auto update without causing problems. For example, Debian doesn't even do features or bugfixes, but only updates apps with security patches for maximum compatibility.
Crowdstrike auto updating also had issues on Linux, even before the big windows bsod incident.
https://www.neowin.net/news/crowdstrike-broke-debian-and-rocky-linux-months-ago-but-no-one-noticed/
It's not the fault of the auto update process, but instead the lack of QA at crowdstrike. And it's the responsibility of the system administrators to vet their software vendors and ensure the models in use don't cause issues like this. Thousands of orgs were happily using Debian/Rocky/RHEL with autoupdates, because those distros have a model of minimal feature/bugfixes and only security patches, ensuring no fuss security auto updates for around a decade for each stable release that had already had it's software extensively tested. Stories of those breaking are few and far between.
I would rather pay attention to the success stories, than the failures. Because in a world without automatic security updates, millions of lazy organizations would be running vulnerable software unknowingly. This already happens, because not all software auto updates. But some is better than none and for all software to be vulnerable by default until a human manually touches it to update it is simply a nightmare to me.
Debian Linux, and many other Linux distros, have extensive measures to protect their supply chain. Packages are signed and verified, by multiple developers, before being built reproducibly (I can build and verify and identical binary/package). The build system has layers, such that if only a single layer is compromised, nothing happens and nobody flinches.
Programming langauge specific package repos, have no such protections. A single developer has their key/token/account, and then they can push packages, which are often built on their own devices. There are no reproducible build to ensure the binaries are from the same source code, and no multi-party signing to ensure that multiple devs would need to be compromised in order to compromise the package.
So what happened, probably, is some developer got phished or hacked, and gave up their API key. And the package they made was popular, and frequently ran unsandboxed on devs personal devices, so when other developers downloaded the latest version of that package, they got hacked too. The attackers then used their devices to push more malicious packages to the repo, and the cycle repeats.
And that's why supply chain attacks are now a daily occurrence.
They do it though. People all of a sudden are motivated and able to enable bitlocker and secure boot and update their bios when they need it to play le funni video game.
No, because proton is not Windows. Wine only works on Linux, so it's actually a Linux platform. I consider every developer/publisher who targets proton to actually be targeting Linux, rather than windows. Every single time a windows update breaks something that continues to work on proton I laugh
See also: https://steamcommunity.com/app/221410/discussions/8/1734336452576620754/?l=czech
FreeBSD, OpenBSD and NetBSD are behind Linux.
Look, I dislike permissive licenses too, but you need a source to back this claim up.
Right now, each BSD does something special, that Linux (distro's) can't trivially replace, even if the usecase is more niche. NetBSD Dev's make efforts to get it running on many devices as they can. OpenBSD (and it's subprojects) are highly secure, moreso than Linux. Who do you think makes our beloved OpenSSH? OpenSSH noted for having very few vulnerabilities over it's two decade long existence, and OpenBSD itself is similar, which is insane because there are products with multiple bad vulnerabilities every year (Linux being one of them...). This is due to a highly security minded architecture - one that Linux lacks.
FreeBSD is like Linux before systemd. I like systemd, but systemd is really trying to be kubernetes on a single node. I like systemd because I like kubernetes, but I understand why someone wouldn't like it, and I question if "single node k8s" is the best architecture for a single server or personal desktop. The ports system results in freebsd packaging many server services that aren't packaged on Linux. Being able to manage those through the system package manager, and the conviniences that provides, is nice.
Different, and not popular don't mean bad.
There are exactly 3 types of phoronix commenters:
Source: https://0x2121.com/7/Lost_in_Translation/
Alt Text: (For searchability): 3 part comic, drawn in a simple style. The first, leftmost panel has one character yelling at another: "@+_$^P&%!. The second comic has them continue yelling, with their hands in an exasperated position: "$#*@F% $$#!". In the third comic, the character who was previously yelling has their hands on their head in frustration, to which the previously silent character responds: "Sorry, I don't speak Perl".
Also relevant: 93% of paint splatters are valid perl programs
Mongodb is proprietary.
Postgres is open source, and then there is documentdb which adds a mongodb compatible layer on top.
But it would probably be better just to use postgres + jsonb directly for that case.