I was also unable to find any Flatpak that has access to the home directory when installed, you may well be right but I couldn't find any. I used Flatseal to verify the permissions: https://flathub.org/en/apps/com.github.tchx84.Flatseal
I'm also of the opinion that we generally shouldn't use software that we don't absolutely trust. That has kept my .bashrc (and other files) safe so far.
To be fair it's possible the situation has changed since I last checked. But at least it used to be this way (https://flatkill.org/2020/). I'm glad the situation has improved in terms of security, but I'm still not a big fan of the flatpak design as a whole.
Yep, but pretty much every single piece of software you've installed on your system can read and write files to your home directory in a silent way without root, and that's where your most important files are on a desktop machine (API tokens, secrets, client projects, etc.).
I have my own opinionated Arch / niri set up and there's 1155 packages installed. That's 1155 opportunities for a package to be compromised. This is also why I try very hard to avoid the AUR and only use it as a last resort (I use 2 packages from it). It doesn't guarantee safety but the official Arch package repos do seem to have more checks and bounds vs the AUR.
Arch at least mandates author signed packages which is unfortunately rare these days, but keys do not need to be on smartcards, and code review is not enforced. You compromise the right arch maintainer and you could do some real damage.
Arch is second only to Guix in terms of supply chain security for desktop distributions, but both still have a threat model that cannot tolerate a single laptop compromise.
I do know some of the arch maintainers (e.g. dvzrv IIRC) are working on build infrastructure that would completely automate the build process and HSM signing to separate read-only images on build servers[0, 1, 2]. I haven't heard about updates to buildbtw in a while, but development seems still somewhat active and signstar is mentioned now and then at some conferences. It feels like it is not making any progress, but I don't pay any attention to the development, so it is likely just my perception of it just having been waiting on visible process to it and not seeing it.
I am aware of their work, and while this is better than the status quo, it does even come close to my threat model of "trust no single computer or machine" which is what I must support.
The freaking point is that basically anything worth running will have that amount of access, even Flatpaks. And you don't freaking know what's malicious before hand.
I think that depends on your point of view. I wouldn't run a program on my computer unless I were sure that it's not malicious. And if you mean that some program I already trust could be exploited, that's true even for the Linux kernel or any sandbox / security solution you would come up with. I'm not denying that there's always a risk, but there's nothing good in running arbitrary code that you can't trust.
I would suggest you have your physician submit a Expanded access request immediately, because the same page says that they will close this program after FDA approval as they transition to commercial use, but the timeline for that is unclear.
If the TPM signs the original image taken by the camera, then even the slightest image processing on another device would invalidate the signature. Routine changes like cropping, scaling, converting between image formats / quality levels, or applying image filters would invalidate the signature.
An adversary can manipulate the date/time settings on the camera and forge evidence to frame someone. "This cryptographically signed photo, with timestamp, proves that you were here at this time!"
And camera sensors can get damaged and need replacement. But if replacement of the TPM-and-sensor chip is allowed, then you can just as well replace it with a sensor from another camera. In which case a signature from a specific TPM+sensor doesn't prove that a specific camera took the photo, at best it might be evidence that a specific camera model took the photo.
If the manufacturer will happily ship a replacement TPM+sensor for a specific camera, someone can fraudulently claim that their sensor is broken and be given a new TPM+sensor for the same camera. And there will now be multiple TPM+sensors in existence that have the same key. Since this module can be switched between cameras, there could be multiple cameras that signed a given picture.
To ship (identical) replacement TPMs, the manufacturer would also need to know the private keys of all the cameras, so the manufacturer could forge arbitrary signatures at will.
Finally maybe the manufacturer doesn't want to deal with the above problems and decides that repairing the camera's TPM is not allowed after all, or that only the manufacturer is allowed to repair a camera, but then they may be in violation of right-to-repair laws in several jurisdictions.
I'm not a lawyer. But I think if your "binary patch" is a series of instructions to write specific code to specific locations in a binary file, and the patch itself doesn't include any of the code present in the original binary, making/distributing a binary patch can't possibly be copyright infringement.
It's normal in the videogame ROM hacking community to distribute this kind of binary patches (known as IPS patches) so as to avoid legal trouble, since the binary patch is useless if the user doesn't have access to the original videogame ROM. Distributing the ROM or even its patched version would be illegal, but a patch of the kind I mentioned is fine.
I'm curious whether OP could have achieved the same result without rooting the tablet, by running the following command in ADB shell, to remove the unwanted package:
The only difference to the command the agent executed as root is the additional "-k" flag, which instructs the package manager not to delete data/cache directories off the device (which may require root access). But the effect is the same in that the undesired package is uninstalled from the user's profile.
I'm sharing this because I've used this command to debloat Android devices I was unable to root, removing various "system packages" that would otherwise refuse uninstall attempts. It's worth a try when you don't otherwise have root access. At worst you should get an error message if it doesn't work.
The difference here is that the scientific papers he downloaded weren't freely available to the public, like those scraped webpages would be. Corporate scrapers have been sued[0] in the past for scraping pages from behind a login page / paywall.
reply