…saying what newsom or allred said.

I don’t know about allred, but if this is the Gavin Newsom statement you’re referring to:

I think it’s an issue of fairness, I completely agree with you on that. It is an issue of fairness — it’s deeply unfair…

Then I don’t understand how it goes from that to:

…cheering on as trans people are murdered in camps…

…that proved that the algorithms/protocols work.

You can use a perfect algorithm and still be insecure because the implementation was bad. You are trusting the SimpleX Chat devs to a degree.

I wouldn’t trust encryption made by anti-vaxer more than…

Important to note: SimpleX Chat has gone through two security audits.

The SimpleX Chat is AGPL. If the founder is problematic, one can fork it and avoid reinventing what has already been made.

It is forkable if necessary. I do think SimpleX is a great piece of software that shouldn’t be reinvented because of the founder.

There was this recent attack to XZ utils, which shows that more attention is needed on the code being merged and compiled.

XZ was made possible largely because there was unaudited binary data. One part as test data in the repo, and the other part within the pre-built releases. Bootstrapping everything from source would have required that these binaries had an auditable source, thus allowing public eyes to review the code and likely stopping the attack. Granted, reproducibility almost certainly would have too, unless the malware wasn’t directly present in the code.

Pulled from here:

Every unauditable binary also leaves us vulnerable to compiler backdoors as described by Ken Thompson in the 1984 paper Reflections on Trusting Trust and beautifully explained by Carl Dong in his Bitcoin Build System Security talk.

It is therefore equally important that we continue towards our final goal: A Full Source bootstrap; removing all unauditable binary seeds.

Sure you might have the code that was input into GCC to create the binary, and sure the code can be absolutely safe, and you can even compile it yourself to see that you arrive at the same bit-for-bit binary as the official release binary. But was GCC safe? Did some other compilation dependency infect the compiled binary? Bootstrapping from an auditable seed can answer this question.

Same could’ve once been said about a free OS like Linux. Now it is absolutely possible, with the downsides shrinking bit by bit.

The goal of 100% free is one I support. And these people are working to make it possible.

…thus denying the artists revenue.

This assumes they would otherwise pay for it, and that they measurably harmed the artist’s revenue. Those aren’t a given.

Until such a time as we come up with a new word…

Use of copyrighted material without permission and possible deprivation of revenue. It doesn’t need to be a single word.

In my experience, Yes. Websites tend to execute too much of their site in JavaScript. The paywall part is no exception.

Disable JavaScript to bypass.

Simple solution is to use cryptsetup to encrypt it, forget the key, and optionally overwrite the first megabyte or so of the disk (where the LUKS header is).

Sounds like flatpaks/appimages with extra steps.

I’m fairly sure the complexity of flatpak/appimage solutions are far more than the static linking of a binary (at least on non-glibc systems). Its often a single flag (Ex: -static) that builds the DLLs into the binary, not a whole container and namespace.

The question should by why you’d want to.

Because the application working is more important than the downsides in my case. Its quite useful for an application which hasn’t been updated in a long time, will never receive updates again, or doesn’t work in my nonstandard environment.

I have had older applications fail to function due to DLL hell.

From my experience a user account needs to be in the “wheel” group to elevate privileges through sudo. So try that.

Simply: Do the protections against someone taking your computer and installing a malicious program before/as your OS, or a program that has attained root on your machine and installs itself before/as your OS, matter enough to you to justify the increased risk of being locked out of your machine and the effort to set it up and understand it.

If you don’t understand and don’t want to put in the effort to, then my advice would be to leave it off. Its simple, and the likelihood it saves you is probably very miniscule.

A threat model in which you don’t trust the Linux Foundation and volunteers but do trust Microsoft.

Its all about what you want to protect. If a security breach is worse for you on Linux than it is on Windows because of which party has the data, then for you, Windows might be more secure.

Some people get confused because they think there is some objective measurable security rating one can apply to a system for every person. There isn’t. We may use the same systems but have different threat models and thus rate the security different.

Privilege escalations always have to be granted by an upper-privilege process to a lower-privilege process.

There is one general way this happens.

Ex: root opens up a line of communication between it and a user, the user sends input to root, root mishandles it, it causes undesired behavior within the root process and can lead to bad things happening.

All privilege escalation is two different privilege levels having some form of interaction. Crossing the security boundary. If you wish to limit this, you need to find the parts of the system that cross that boundary, like sudo[1], and remove those from your system.

[1]: sudo is an SUID binary. That means, when you run it, it runs as root. This is a problem, because you as a process have some influence on code that executes within the program (code running as root).

secureblue is about as secure as Linux can get…

Unless you have an unusual threat model, this statement is utter nonsense. I can run a kconfig stripped kernel with zero kernel modules and one userspace process that is completely audited and trusted, without the ability to spawn even other processes or talk to network (because the kernel lacks support for the IP stack).

Secureblue might offer something significant when compared to other popular and easily usable tools, but if you compare it to the theoretical limit of Linux security, its not even comparable.

I examined Secureblue’s kernel parameters and turned multiple of them off because some were mitigations for something that was unnecessary. IE: The kernel would make the analysis that your hardware is not affected by a vulnerability, and thus there is no need to enable a specific mitigation. But they would override this and force the mitigation, so you take a performance hit, for what I understand to be, no security gain. Not sure why they did that, a mistake? Or did they simply not trust the kernel’s analysis for some reason? Who knows.

Is desktop linux more insecure than Windows?

This is an impossible question to answer without more information. Depends on your threat model, how you use the computer, your distro, etc.

Security is much more effective and adopted when it is simple. My understanding is that SELinux is not.

This means not only will fewer people use it and more people turn it off if something doesn’t work, it means more people are at risk of misconfiguring their system to allow something they didn’t intend to.

This is somewhat mitigated from the fact that, from my experience, Linux Security Modules cant ever make you less secure than without it. But it still can provide a false sense of security if you misconfigure it.

Here is a good article showing what I am referring to, and providing a solid security tool: BSD pledge/unveil on Linux.