I don't know about privacy but Android's security is good enough. If really care about privacy anyway, you should be using microG or GrapheneOS where Google's spying is limited on the device.
hottari
joined 3 years ago
Irrelevant. Some systems may be hard to compromise but most humans are not.
Yeah. Came across it when it was released. It's still considered experimental.
And am sure NixOS is great but it definitely is a weird operating system.
My (maybe flawed?) thoughts: Why bother with full disk encryption if one could just boot the notebook to undo the encryption?
If it were that easy to do, we wouldn't have even bothered with doing disk encryption in the first place. And it's not like cracking TPMs is a walk in the park.
Using my yubico fido 2 key in combination with a small PIN I can easily decrypt my LUKS drive and know nobody else can decrypt it as long as I have my yubico with me.
This definitely could help in a scenario where an attacker has only your notebook but for it to make a difference your attacker must not be able to access your Yubikey and/or compel you to hand it over.
As long as your LUKS drive is encrypted (TPM or not, Yubikey or not), you are relatively safe from an unauthorized party trying to access your data. Either of these attestation tools add a layer of defense for your encrypted drive.
Tried switching some time back, didn't take long to go back to docker. Podman does not have the polish that docker has taken years to perfect and as much as I love systemd, managing containers in docker is 10x better.
Would love to get systemd-boot entries for BTRFS snapshots (openSUSE is currently working on an implementation of this). But my current strategy is arch-chroot when things go haywire (recently broke sudo). And local + cloud backups of my home folder should the situation demand it.
Pfftt. This sub is regarded.
Arch. Some of its users take this distro for granted a lot of times but it only goes downhill from here once you start looking at other distros.
Tumbleweed. Solid, Automated QA testing.
Chimera Linux. Security-related compilation flags go brrr. No systemd.
Maybe we'll see SerpentOS sometime before this decade ends but who knows.
On a side note. Aeon 1.0 if/when released, can't wait to see how it all turns out. Especially if they manage to integrate BTRFS snapshots with systemd-boot entries.
Am already sold on immutable distros as the future of desktop Linux. 8/10 applications that I use today are flatpaks or dockers. That remaining 20% of the work to be done on immutable is what am anxious about.
This summary should cover my main concerns with current secure boot implementations on the major distros. Ignore everything else other the linked part. I also would not want to be forced to use grub as the bootloader.
Curious. What did you not like about using TPM to store keys in your setup? I use TPM for secure state validation & automatic decryption of my LUKS drive, it's great and also acts as a tripwire for secureboot state.
I could build a custom version of Silverblue (u-Blue) to replicate what I already have setup, but none of this would be supported configuration. All this is not entirely to blame on on immutable distros (traditional distros don't give a damn about secure boot either way), just that to mess around within /etc is a no-no in such a model so to get multiple pre-configured options for secureboot configs/keys that work seamlessly would be a great experience for me.
RedHat & Debian family desktop distros use a key that is signed by Microsoft for supporting secure boot. For compatibility reasons mostly as some hardware will brick when the MS signed keys are not found. But I prefer to sign my own keys and enroll them as I currently do with sbctl. I have no need for extra kernel modules/drivers as Nvidia users would (seems like a hacky workaround if the kernel can't ship the drivers and signing your own kernel makes the situation even more complicated).
However I have been meaning to try Distrobox, if I get around to trying out immutable I will give it a good run.
MicroG & GrapheneOS projects specialize in blocking non-essential tracking related connections to Google. They are effective at that too.
Doesn't sound like an Android problem as any device with a speaker can be abused if I understand what you are saying.
Can't speak for compass & accelerometer permissions but how do you expect auto-rotation to work in apps?
Do you really expect people to push a consent toggle every time they visit pornhub.com. Be serious.
I think you are overthinking this. The concern here should be can Google or any other party exfiltrate this offline data and if so, what can you do to stop it?
Popping up a Wireshark equivalent and monitoring the chatter on your device is a good place to start. Otherwise you would be making cases for where there is no argument to be made.