Neptr

Beans are far more versatile imo. Soy alone is sooo useful to me as a vegetarian.

Now if instead it was nightshades vs legumes, I would have a hard time picking because tomatoes are the best, and so are potatoes. And what would I even do without peppers and spicy food.

But legumes have so many amazing plants like soy/black/chili/garbanzo beans and peas. TVP is made usually from soy or pea protein and is a super useful source of protein. Legumes are also "nitrogen fixers", meaning they produce bioavailabile nitrogen rich soil.

I think I would have to give the win to legumes because I can survive on a diet predominantly filled with legumes but not really just potatoes/tomatoes/peppers/eggplants. I need protein.

Zen is basically Firefox with different UI. It is a security/privacy downgrade from Librewolf. You can configure Zen to have the same security/privacy settings by putting about:config in the URL bar change some of the toggles.

Use either the Arkenfox (also available in the interactive live viewer online) or Phoenix user.js as a template. Basically: disable WebGL, set WebRTC to disable nonproxied udp, disable JavaScript JIT, enable privacy.resistFingerprinting (optionally enable privacy.resistFingerprinting.letterboxing for screen fingerprint protection) and some other things.

Phoenix has some configs for Zen iirc which you can just patch. It is less strict than Librewolf when it comes to fingerprint protections (softening some of RFP's protections).

If you want to test that the fingerprint protections are working, use this test site by Arkenfox called TorZillaPrint.

There are gaps in between the rain drops which means we see other parts of the cone. Maybe?

Also charlie kirk /s

But legit, what kind of suffering could ever equal the pain he caused?

Windows has plenty of things to complain about. This type of feature is not one of them.

I recommend reading/listening to the book "Debt: The First 5000 Years" by David Graeber. It is a great book and talks about much more than just the myth of barter. The tl;dr is barter only happens between "strangers that you cant/wont enter into trade relationship with" or enemies. There is much more nuance in the book and many examples of indigenous peoples and their practices around debt (obviously) and barter.

Example: https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet

Also, in this article some explanation of why nothing should be in pid1 other than what is truly necessary, and any example pid1 program written in C under the heading "So how should init be done right?"

Are these "other features" hard dependent on systemd? If yes, how are they modular (or portable)? "My program can be used on any system with a couple of small dependencies: Linux kernel, glibc, and the systemd Kernel" /j

There are some attempts to use systemd tools independent for it, like elogind and eudev, but see what I mean. Hard forks (with major rewrites) are required because these tools heavily depend on systemd, which fine I understand having dependency, but you cant just use part of systemd since it is to tangled together. It would be nice if mire of systemd code was available as separate libraries so you could further reduce attack surface by building a significantly slimmed version of systemd+feature. I am unsure if you meant modular as in "you can choose to enable them" or as in "you can build without them" or both.

Also, I never claimed systemd ran everything under pid1, just plenty more then the should be, like init plus service manager (and more), not every single systemd tool because that would be beyond stupid and systemd isnt made by idiots.

Compromising/crashing pid1 (which becomes increasing likely when the program is massive) takes down the entire system. pid1 should only be the initial init (which should be as small as possible, basically a stub) and start the service manager as a separate pid. This allows the system to gracefully recover by restarting other processes without fully locking-up/crashing. It is a bad practice.

Disclaimer: I use systemd distros. I dont hate systemd, I just like the ability for alternatives to flourish without fighting an uphill battle.

It has major project scope creep (does too many things that arent init or service management), isn't modular or portable, only just gained support for muslc, it runs most of its init and management things in pid1 (which is a security and stability issue), it is a massive C program (large attack surface), it isnt very fast when compared to any other init (especially s6 or dinit which boot in under 4 seconds), it implements non-standard interfaces which just encourages further dependency, etc.

Systemd is like the Walmart of Linux OS tools. It replaces many other options and does things good enough (not the best, good enough) to make it worth it to use them and their ecosystem, and they make things simple to use. But just like Walmart, they undercut other options, stifle adoption, until they are the only shop in town.

Dinit does everything I need out of service manager, has similar command utilities and syntax to systemd, is much faster, simpler and cleaner code, avoids many of the pitfalls of systemd, supports user services. s6 is pretty good to but kinda terrible UX.

The simplest answer to why I dislike systemd is that with all the major distros using systemd, it will become harder and harder to use most Linux software without systemd and its growing set of utilities. If systemd made an effort to work with the community to implement standard interfaces then alternatives could flourish without requiring large on-going patches to much of the Linux software ecosystem. It will only get worse from here. Systemd is (basically) the init of Linux and I think that is sad.

The other problem with Matrix for me is that Element call (the protocol) is not present in most public instances and isn't very straightforward to selfhost. The default is jitsi which is not E2EE. Pretty major IMO because if Matrix is supposed to be a Discord alternative and supposedly E2EE but VC isnt encrypted, pretty yikes.

Also they have claimed for years that they have forward secrecy. Has something actually changed recently?

I misread that at first lol. Tats = tattoos, my brain didn't see that 'a'

Where did you read that Signal uses MLS? I could not find any claims of using MLS on Signal's specs page or their GitHub repo. Also MLS doesn't mean anything on its own, see Soatok's blog on MLS.

Soatok is currently in the process of writing a blog post about another vulneribilty they found in Matrix's encryption, and with Matrix's history of numerous vulnerabilities, I would stay away from that shit. No matter how "good" the algorithm is in theory, it is all about implementation. Matrix also has very brittle encryption, often times many messages will become unrecoverable, which is terrible UX.

You'd be better off just selfhosting XMPP+OMEMO, with the caveat that it is also flawed and leaks plenty of metadata.

The best alternatives to Signal (but not Discord) are SimpleX and Briar. Both are significantly better than XMPP/Matrix for privacy and security.

It was her estranged spouse though. The astronaut didn't commit the crime. I get that you are joking.

To preface: I don't hate (desktop) Linux, in fact I love it. It is all I use an all I will probably ever use (unless somehow RedoxOS becomes usable lol but even then probably not). Linux is great and I spend most of my time (in no particular order) using it while tinkering, browsing, gaming, doing work, and just having fun. It is precisely because I love Linux that it pains me that people shutdown immediately when they hear any criticism of Linux (and by extension any other of their fav open source projects). It is fine to critique projects, especially when they claim to be "privacy/security focused". That phrase is so broad and heavily diluted by over use. What does it mean to be security focused?

(My response uses somewhat technical language. I am not a troll and I am not trying to be mean. I am sorry if I come across as arogant)

The Linux kernel has so, so, so many (security) features, such as namespaces, landlock, SELinux/AppArmor, chroot, seccomp, ptrace, encryption, KVM, etc. Then there is libc, malloc, firewalls, Wayland, init system, so many different components. But how much of that is being configured/used in everyday Desktop distros to improve security?

What is actually wrong about the Linux hardening guide? Linux Desktop lacks a real threat model and it is trivial for any run app/script/binary executable to establish persistence, steal passwords, exfiltrate data, preload malicious binaries, escalate privileges, etc etc etc. Desktop Linux is insecure, period. The fact that Linux gives running apps so much information/access makes attacking it very easy.

For example, I could make a simple script that when run:

Installs itself at $HOME/.local/bin/sudo
Changes the $PATH (for example in ~/.bashrc ~/.profile) to prefer binaries in $HOME/.local/bin
Wait till the user runs a command as sudo (which runs the malicious script), stealing the password and passing the command to the legitimate 'sudo' (/usr/bin/sudo).
After this happens remove the evidence and create a systemd service file with a generic name (as to blend in with the hundred real services) that allows me to remotely control the system whenever.

"But if it is just a script, cant I check it before running?" Could be an obfuscated binary. "What if I check ~/.local/bin?" Could just as easily be /tmp or buried in ~/.cache somewhere. "What if I check the $PATH variable?" I could use an LD_PRELOAD attack instead. "What if I just only run trusted apps?" Are you sure you can trust everything you run? Is everything you run OSS? Does your developer sign updates (most use GPG, see https://gpg.fail/ for why this is bad) and have reproducible builds? What if they are hacked? What if a dependency they use is hacked?

One of the easiest examples of an untrusted app that people run all the time is video games. They are often proprietary, humongous, and require device/hardware access. Effectively impossible to audit.

And that is just a simple and straight forward privilege escalation attack to establish persistence. Instead of doing anything suspicious, the script could just exfiltrate data, such as app data, or system info (like package/kernel versions, OS name/version) to make a targeted attack easily. The malicious program could just create a systemd user service, which doesnt require root, and runs at boot with target network to establish persistence.

The only coherent threat model is to treat all apps as if they are malicious, which is what browsers (and to a weaker degree what Android/iOS) do. Websites are effectively untrusted apps, and browsers are designed to run untrusted code.

And that isn't even getting into all of the information obtainable from from the /proc, /sys, and /dev filesystems.

Flatpak and Snap are cool because they provide basic application sandboxing, but they aren't designed to run untrusted applications (not their threat model scope). Flatpaks/Snaps declare their own permissions (with few exceptions), so a malicious app could just have a different manifest. Kernel vulnerabilities are still a problem because sandboxed apps share the same kernel. Permissions for these apps arent granular and many often requested permissions severely weaken the sandbox (eg. Lutris Flatpak needs device=all for gamepads to work, and also has full filesystem read/write access). Ideally, dangerous permissions are designed to limit the impact/likelyhood of a sandbox break. People hate Snapd (and for good reason), but it has a much better permission systems (way more targeted and specific permissions minimizing the scope for specific use-cases) and can request the user to allow dangerous permissions at runtime (eg. Zoom wants access to Microphone shows an on-screen pop-up). There is also the problem that these sandboxes are written in memory unsafe languages and don't use hardened memory allocators (eg. mimalloc-secure, hardened-malloc, malloc-ng) though to be "fair" neither do practically any Linux distros.

Check out Kicksecure/Whonix and Secureblue for some of the hardening they do, but keep in mind none of them have or can fix the structural/cultural issues that continue to keep Linux behind curve when it comes to OS security. Any examples I have gave has a dozen others that will go unspoken. Check out Syd for information a real-world Linux sandboxing and exploit protection.

OS security is complicated. But ignoring the facts, burying your head in the sand, does nothing but stop you from expanding your knowledge and educating others. If we dont address these problems know, before the inevitable death of Windows, Linux Desktop adoption will be painful and malware will be plentiful.

It is also proprietary.

Maybe the got their shit together since I last checked, but hqving that history and being at the very least 1 month (usually more) behind for years is a very bad look for a ROM that bills itself as private and secure.

According to this well known comparison table they still havent changed: https://eylenburg.github.io/android_comparison.htm

They also leave plenty of proprietary binary blobs in the ROM.

/e/OS does not take security seriously. They are often 1-2+ months behind on Android security patches, leaving you vulnerable to literal dozens of high severity vulnerabilities. You would probably be better off with LineageOS.

It still isnt great. Better than DeltaChat/Matrix but decently worse than Signal's security.

N.E.P.T.R

@ Neptr @lemmy.blahaj.zone

Posts

8
Comments

513
Joined

1 yr. ago

I'm the Never Ending Pie Throwing Robot, aka NEPTR.
Linux enthusiast, programmer, and privacy advocate. I'm nearly done with an IT Security degree.
TL;DR I am a nerd.

N.E.P.T.R

Potato, better than beans, better than corn rule

What are your takes on the Zen browser?

we're all a little gay inside

i believe this is a form of sadism

Idea Raised For Nicer DRM Panic Screen Integration On Fedora Linux

Cash Rule(s) Everything Around Me

KaOS Linux Drops KDE Plasma After 12 Years for Niri/Noctalia to Escape systemd

KaOS Linux Drops KDE Plasma After 12 Years for Niri/Noctalia to Escape systemd

KaOS Linux Drops KDE Plasma After 12 Years for Niri/Noctalia to Escape systemd

KaOS Linux Drops KDE Plasma After 12 Years for Niri/Noctalia to Escape systemd

big list of selfhosted chat apps to meet all your friends on a real "server"

Ready for my morning run 🏃🏽‍♀️‍➡️

big list of selfhosted chat apps to meet all your friends on a real "server"

Woman sentenced for accusing her estranged spouse of illegally accessing bank account from outer space

deleted

ive learned alot past year :D

ive learned alot past year :D

ive learned alot past year :D

big list of selfhosted chat apps to meet all your friends on a real "server"

big list of selfhosted chat apps to meet all your friends on a real "server"

Jeff the kicker rule

Beatles rule

HD2 Rule

What is the URL for AudioBookBay?

does not rule (also fuck the police and corporate news)

#1 Rule of USA Healthcare: discriminate against poor people.

The GOAT (rule)

mr(ule) boner