Hacker Newsnew | past | comments | ask | show | jobs | submit | fsflover's commentslogin

Qubes OS is a niche security-oriented operating system that runs everything in VMs with about 70k users [0]. Even less users contribute with amazing things like running in RAM [1] or using very minimal VMs with Debian and Fedora [3] to minimize the attack surface and bloat.

[0] https://doc.qubes-os.org/en/latest/introduction/statistics.h...

[1] https://forum.qubes-os.org/t/qubes-os-live-mode-dom0-in-ram-...

[2] https://forum.qubes-os.org/t/how-i-learned-to-love-liteqube-...


The solution is to use AGPLv3.

I’m maybe daft but AGPLv3 doesnt prevent $Evilcorp from using it, they just need to share any modifications or forks they made?

And at this point, it appears running code through an LLM to translate it eliminates copyright (and thus the licence), so $Anycorp can use it.

Our stuff is AGPL3 licenced and if this present trend continues we might just switch to MIT so at least the little guys can take advantage of it the way the big guys can.


Only if they provide the software or software as a service. Then I suspect it's good enough if the modifications or forks made are shared internally if software is used only internally, but on the other hand I'm not a lawyer.

> if software is used only internally

Internal users are still users tho. They are entitled to see source code and license allows them to share it with the rest if of the world.


Employers might argue that such internal use and distribution would fall under the “exclusively under your behalf” clause in the GPLv3, which is inherited by the AGPLv3.

Oh, I guess it would. Ignore me.

This is the point. They can use and modify it, but they also have to share their modifications, i.e., help its development. Yet most megacorps never even touch this license.

What else is this about? Debian repositories still contain no malware and if you install software exclusively from them, you'll be safe.

Run OpenSnitch for a while and you'll quickly realize how much of your system does phone home. Off the top of my head:

- GNOME Shell (extension updates without a way to disable this, weather),

- GNOME Calculator (currency exchange rates),

- NetworkManager (periodic hotspot portal checks in most configurations),

- GDB (debuginfod enabled by default),

- Firefox (extension updates, push notifications, feature flags, telemetry, ..., some parts cannot be disabled),

- VSCodium (Open VSX callbacks even when installing extensions from disk with updates disabled, JSON schema auto-downloads, extensions making their own unsolicited requests, ...),

- Electron (dictionary updates from Google servers, no way of disabling; includes any application running on top of upstream Electron, such as Signal, Discord, etc.),

- GoldenDict (audio samples fetched from the Internet on word look-up, no way to disable)

Of course, this is nothing compared to Windows [0] and macOS [1], but the malpractice of making Internet connections without asking, by default, has unfortunately been finding its way everywhere since modems stopped making audible sounds.

Having read about PRISM and seen the leaked dashboards of Paragon Graphite (said to be used by ICE), and with LLMs bridging the gap between mass and targeted surveillance, I don't want any of this.

[0] https://github.com/microsoft/calculator/blob/ffd0519676019a0...

[1] https://sneak.berlin/20201112/your-computer-isnt-yours/


> GNOME Calculator (currency exchange rates),

Which would crash (technically hang) if you blocked it. [0]

[0] https://forums.debian.net/viewtopic.php?p=818264


People still care about these things on Debian. But as is said 20 years ago there was no need, because the default was to be sane.

Are these malware ?

Per se? No, maybe with the exception of GNOME Shell which literally runs code from the Internet unsandboxed. Can the traffic they silently generate be used for malicious purposes? Absolutely.

Wasn’t it KDE that had malware in its theme store not too long ago? Let that sink in for a bit. You changed around some icon themes and it executed arbitrary code.

And let’s not pretend that kde wouldn’t have an extension system if it could - but it’ll never have one because implanting one in that c++ spaghetti nightmare will never happen.


I think you meant to reply to this: https://news.ycombinator.com/item?id=47702680

But if not, I'm not criticizing GNOME in isolation here. It's just what I use and what I'm most familiar with. KDE has the same issues and it does have an extension system too. It's called KNewStuff.


you could always run kwin_wayland and prevent all that phoning home...

Problem with updates is that without automatic ones, users could stay on outdated systems and possibly get hacked through some vulnerability(of which there are many). While on the other hand, having explicit confirmations for each network request would be crazy annoying.

Maybe some middleground of having the tool OP sent built-in would be a good option.


I run all my systems with all outgoing connections blocked by default, and yes, it is annoying.

But it wasn't always this way, and so, I don't think it has to be. People just need to start paying attention to this.

The impact of a lot of those vulnerabilities would be mitigated if the affected programs didn't connect to the network in the first place.

As for updates in general, I really like the model adopted by Linux update managers and BSD port systems. The entire repository metadata is downloaded from a mirror and cached locally, so the search terms never leave your machine. Downloads happen from the nearest mirrors, there's no "standard" mirror software (unless rsync and Apache count?) so they don't report what was downloaded by whom back to any central system and you can always host your own. Everything is verified via GPG. And most importantly, nothing happens on its own; you're expected to run `apt/dnf update` yourself. It won't randomly eat your bandwidth on a metered connection or reveal your OS details to a public hotspot.

Simple, non-invasive, transparent, (almost) all-encompassing, and centrally configurable.


Does it contain Firefox? How about Chrome?

Quote from LittleSnitch:

> Little Snitch for Linux is built for privacy, not security

What's your definion of malware in this context?


It contains Firefox and Chromium. You are right that they may call home, but at least it's very limited and easily configurable. Could be too much for you but fine with me. Also Debian does change their config by default to minimize privacy issues: https://news.ycombinator.com/item?id=32582260

It's far from easy in the case of Firefox [0], and the last time I tried, some .mozilla.com domains would still get pinged. Chromium doesn't even have an official guide. The only options I found to be reliable are source-level patches, i.e. ungoogled-chromium and LibreWolf.

Note that LibreWolf still leaves some of the stuff on for you to manually disable (dom.push.connection.enabled, extension updates).

[0] https://support.mozilla.org/en-US/kb/how-stop-firefox-making...


In firefox, goto about:config and search for url.

You're welcome.


Ads, trackers, general boost to privacy. Not every protection tool is just about malware.

Yeah I will also be safe if I never turn on the PC, but some of us use computers to do actual work.

There are still phones not obeying the megacorps. Sent from my Librem 5.

Does your Librem 5 run banking apps, though?

Waydroid allows to run Android apps that don't require SafetyNet. If your bank forces you into the duopoly with no workaround, it's a good reason to switch.

And you only have that option as long as people oppose that secure boot enabled dystopia.

Instead of proprietary SecureBoot controlled by megacorps, you can use TPM with Heads based entirely on FLOSS with a hardware key like Librem Key. Works for me and protects from the Evil Maid attack.

You can also use SB with your own keys (or even just hashes)...just because Microsoft is the default included with most commercially sold PCs—since most people use Windows on their PCs—doesn't mean SB is controlled by them. You can remove their signing cert entirely if you want. I have done this and used my own.

Plus they signed the shim loader for Linux anyways so they almost immediately gave up any "control" they might have had through SB.


If arbitrary app stores are allowed without restrictions, isn't that equivalent to allowing installation of any apps?

That's the idea! "Allow" the user to install any apps they choose. (I put "allow" in quotes, to emphasize how bizarre it is that a few platform vendors get to decide what all of humanity is "allowed" to do with their computing.)

GP here. I agree in spirit but there’s a technical difference between ”approved to distribute” and ”approved in an App Store”. Specifically, you can distribute software for Windows and Mac outside of their stores, but you still need to have a code cert which means you’re under their mercy. This is the model Google wanted to transition Android to recently: keeping the APK path (no App Store) but gatekeep developers through signature enforcement etc.

So why don't you stop using the OS that has a completely different approach to computing?

Qubes OS is such OS: it runs everything in VMs with strong hardware isolation. My daily driver, can't recommend it enough.

The problem with this is, you spend a lot of effort for low benefit. You should spend it on actual security instead.

Changing a port and enabling aslr are not "a lot of effort".

Changing the port is not the kind of security measure that will consume a lot of the attacker resources

Sure, it'll do nothing to stop a determined attacker, but it does wonders to stop the noise from passive scanners.

Are you familiar with the Swiss cheese model of risk management[0]? Obscurity is just another slice of Swiss cheese. It's not your only security measure. You still use all the other measures.

[0] https://en.wikipedia.org/wiki/Swiss_cheese_model


It will conserve a lot of defender resources, it will completely bypass all mass scans, and it will make "determined attackers" much more visible as they will have to find the port first which will show up in logs and potentially land them in a tarpit.

What would be "actual security" in this context?

This isn't about security of the same kind as authentication/encryption etc where security by obscurity is a bad idea. This is an effort where obscurity is almost the only idea there is, and where even a marginal increase in difficulty for tampering/inspecting/exploiting is well worth it.


The one not described as "security through obscurity".

My point is: the "security through obscurity is bad" and "security through obscurity isn't real security" are both incorrect.

They apply to different threats and different contexts. When you have code running in the attackers' system, in normal privilege so they can pick it apart, then obscurity is basically all you have. So the only question to answer is: do you want a quick form of security through obscurity, or do you not? If it delivers tangible benefits that outweigh the costs, then why would you not?

What one is aiming for here is just slowing an annoying down an attacker. Because it's the best you can do.


Somehow your approach was not chosen by Intel ME or AMD PSP, and they remain unbreakable.

That's orthogonal to this. That requires special hardware and using those doesn't really rule this out as an additional measure.

> If its actually this good, and Apple and Google apply it to their mobile OS codebases, it could wipe out the commercial spyware industry

If Apple and Google actually cared about security of their users, they would remove a ton of obvious malware from their app stores. Instead, they tighten their walled garden pretending that it's for your security.



You're being downvoted because you posted a non sequitur, not because people don't believe you. Vulnerabilities in the OS are not the same thing as apps using the provided APIs, even if they are predatory apps which suck.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: