This is a secondary account that sees the most usage. My first account is listed below. The main will have a list of all the accounts that I use.

[email protected]

Garbage: Purple quickly jumps candle over whispering galaxy banana chair flute rocks.

  • 21 Posts
  • 261 Comments
Joined 2 years ago
cake
Cake day: July 4th, 2023

help-circle
















  • FUD. Apps cannot listen to the microphone without going through the OS first. I call FUD or share with me this magical OS-bypassing code. Compromising the OS at such a fundamental level on a recent Android version is almost certainly beyond their capabilities. I am more likely to believe the content that inspired this article is more aimed at investors and is blatantly making false claims, and that such claims from the privacy policy are generic disclaimers.

    Further, have you ever tried to get an app to consistently run in the background on purpose? It’s an enormous PITA when you actually want this to happen. Android apps do not typically run in the background at all unless they have again special permissions to bypass background restrictions. The OS strongly prefers to pause and eventually kill apps to save battery rather than permit background activities to occur unless they fall into specific categories and then only at specific times to optimize the battery usage.

    If an app asks to run in the background all the time, bypass battery restrictions, and you grant it microphone access explicitly, the problem is no longer Android. The problem is the user being stupid by granting access against their own interests. And even then, it’ll still trip the microphone indicator.



  • As long as the user owns the TPM and has full control over it, I don’t see a problem. I paid for that hardware. I want to use it. There are already tools that can talk to it. It’s just not fully implemented and integrated into the system in a secure fashion. Indirectly, you kind of point out why there hasn’t been as much motivation to provide these features because they’re associated with the user giving up control, but it doesn’t have to be this way. The hardware can work for me if the support were there.

    With the right support, it can even be combined with the password. This lets me enforce that the drive only unlocks in this machine, with this password, and only with the software that I set. That’s certainly more secure than how most distros do FDE today. It covers more use cases and enables a much stronger threat model.



  • One major obstacle is third party drivers, specifically Nvidia, that forces building and signing your own kernel modules. It can be done, but it’s certainly more complexity than distributing signed binary drivers from the distro. I think Ubuntu has preliminary support for TPM-backed FDE, but only if you aren’t using such drivers. It doesn’t work in combination.

    I don’t want to sign my own modules. I want them to shipped signed, so the key isn’t expected to be on my machine. If I were doing kernel development work, I’d have disabled secure boot entirely anyway.