I hate this take. That is not how security should look on consumer devices at all and it’s one of the ways the security industry is being co-opted to ruin consumer devices. The user is not the attacker on a consumer device. Consumer devices should provide tools to enable strict protections and allow the user to choose. It should be easy to put the device into the fully locked down state at instal/initial provisioning, likely even the default, but it should also be easy to deviate from that during provisioning. After provisioning it should, of course, be incredibly hard or impossible to go from the locked-down state to the nonlocked-down state without wiping data.

deleted by creator

Does macOS have namespaces? Can you modify the kernel? An equivalent to Linux Security Modules? ConfigFS? FunctionFS? I haven’t used it in decades so genuinely asking.

If I remember correctly you have to do some funny business to change things in the root directory too?

They’re completely different operating systems, there will of course be differences. In my experience Linux definitely gave more freedom to do whatever you wanted though. It’d be a bit disingenuous to argue otherwise. They serve different purposes, and that’s ok.

But oof repairing things on those logic boards… Everything soldered on makes the hardware a nightmare. I swore off Mac after trying to get one repaired. Had to trash the whole logic board and lose everything. I think that design is almost criminal tbh.

As long as it’s installed on a device you control it’s pretty easy to sniff TLS traffic from an Android application, even if they’re pinning certs. I do this all the time for work. Frida makes it extremely easy, even giving you the ability to edit boringssl if something important is happening in native code. I’ve had to do this a couple times.

If you don’t have root you’ll have to recompile the application though which could matter if you need the signature to not change, but that isn’t a common requirement.

It’d be nice to have a better way to test though; I’ve wanted to check out Waydroid. Some coworkers just use an emulator which works great if it doesn’t need specific hardware.

This doesn’t seem to be a Rust problem, but a modern development trend appearing in a Rust tool shipped with Cargo. The issue appears to be the way things are versioned and (reading between the lines maybe?) vendoring and/or lockfiles. Lockfiles exist in a lot of modern languages and package managers: Go has go.sum, Rust has Cargo which has Cargo.lock, Python has pip which gives a few different ways to pin versions, JavaScript has npm and yarn with lock files. I’m sure there are tons of others. I’m actually surprised this doesn’t happen all the time with newer projects. Maybe it does actually and this instance just gains traction because people get to say “look Rust bad Debian doesn’t like it”.

This seems like a big issue if you want your code to be packaged by Debian, and it doesn’t seem easy to resolve if you also want to use the modern packaging tools. I’m not actually sure how they resolve this? There are real benefits to pinning versions, but there are also real benefits to Debian’s model (of controlling all the dependencies themselves, to some extent Debian is a lockfile implemented on the OS level). Seems like a tough problem and seems like it’ll end up with a lot of newer tools just not being available in Debian (by that I mean just not packaged by Debian, they’ll likely all run fine on Debian).

No intention of validating that behavior, it’s uncalled for and childish, but I think there is another bit of “nontechnical nonsense” on the opposite side of this silly religious war: the RIIR crowd. Longstanding C projects (sometimes even projects written in dynamic languages…?) get people that know very little about the project, or at least have never contributed, asking for it to be rewritten or refactored in Rust, and that’s likely just as tiring as the defensive C people when you want to include Rust in the kernel.

People need to chill out on both sides of this weird religious war. A programming language is just a tool: its merits in a given situation should be discussed logically.

I’m relatively qualified. Studied physics all through college and spent a couple years working in quantum computing. I’ll chime in here because Schrodinger’s cat jokes are a pet peeve.

You are correct that, as far as we understand, it is literally impossible. There has been a competing theory for decades, but I’m not really up on the specifics https://en.wikipedia.org/wiki/De_Broglie–Bohm_theory. The reason it is generally rejected is that it appears to violate relativity.

Anyway… the cat thought experiment is such a fun thought experiment to me because it specifically makes us think about a very practical issue with respect to quantum computing: decoherence. If you take his thought experiment to an extreme, it actually should be theoretically possible to create a state in which a macroscopic object (the cat) and a quantum object (the radioactive source) are indeed entangled. But that is absurd according to everything we’ve ever seen. So what’s up? The missing concept here is decoherence – while this state may theoretically exist, it’d decohere on timescales so small we can’t even imagine. The fun connection here is that decoherence is the exact thing we’re trying to fight in quantum computing. Essentially we’re trying to make this thought experiment a reality for a much less complex system.

Some more on decoherence: https://en.wikipedia.org/wiki/Quantum_decoherence