@orclev Standard operating procedure is increasingly to extract data with standard forensics software. If it doesn't go smoothly then they'll likely detain people and get experts to deal with it.
GrapheneOS
joined 3 years ago
@modem_down @beep @Semi_Hemi_Demigod It would be trivially detected by widely distributed standard forensic software including the non-Premium variant of Cellebrite able to run on a laptop.
@jcs The definition of openness used by Librem 5 is that a fully closed source device with closed source firmware and software would be open and freedom respecting as long as none of the firmware/software can be updated.
Purism prevents updating firmware for the SoC and calls it open even though the SoC is fully closed source hardware and does have closed source firmware, which just can't be updated. They don't count secondary components like radios. 99.999% closed source hardware isn't open.
@jcs Librem 5 has atrocious privacy and security due to using a bunch of low security and outdated components, which are not open and do not have open firmware. Many components including the radios lack proper security updates. Purism does not provide the firmware updates through their OS and has set up a bunch of it in a way where it can't be updated. They even went out of the way to move things to a locked down secondary processor to block updates. They claim if you can't update it, it's open.
@jcs Librem 5 has a fully closed source SoC, which means System on a Chip as opposed to a traditional desktop where the components would be part of a motherboard. The board schematics are for a basic PCB. It's a nearly entirely closed source device in terms of where the actual complexity is. The SoC is the core component providing nearly all the base functionality. The SSD, memory, touchscreen, battery, Wi-Fi, Bluetooth, cellular, etc. are all closed source, as are various other chips, etc.
@informapirata @informatica It would not be the end of F-Droid, it would only require them to stop incorrectly using package names (application ids) not belonging to them. F-Droid doing that already causes issues and we've reported it as an issue many times for several years. Simply doing domain-based verification without ID verification similar to Let's Encrypt would have caused problems for them too unless developers authorized the usage explicitly.
See our post at https://discuss.grapheneos.org/d/26966-f-droids-delevoper-statements-about-googles-registration/3.
@andreabont @informapirata @morrolinux @gnulinuxitalia We only recommend that apps already using the Play Integrity API and unwilling to remove it move to using this instead. This enables them to support arbitrary other devices and operating systems. Other attestation roots can be supported along with arbitrary alternate operating systems via allowing their verified boot keys. That's much better than the Play Integrity API. We'd prefer if apps didn't check the device/OS but they insist on it.
@shiva @informatica @informapirata We don't think these are good recommendations for users who care about privacy and security. There's a lot more to privacy than simply avoiding Google apps/services.
We recommend https://eylenburg.github.io/android/_comparison.htm for a high quality comparison between Android-based operating systems. The other OSes listed there do not keep up with privacy/security patches which is the bare minimum. CalyxOS updates have also recently been discontinued as a whole (https://calyxos.org/news/2025/08/01/a-letter-to-our-community/).
@lka1988 We focus our effort on the base OS and areas which are not already covered by high quality open source apps. We don't need to build our own domain-based filtering and blocklists for it because they already exist.
We have built-in content filtering in Vanadium based on EasyList + EasyPrivacy. That's more usable (per-site toggle) and much less limited than what domain-based filtering can do but it's still limited by needing to permit dual use functionality and is still easily bypassed.
> Plus, in the first comment, you suggested “RethinkDNS”, which depends on their own DNS servers.
You do not need to use their DNS servers. You can use local filtering and your choice of DNS servers including the network provided ones.
> I wouldn’t think a security and privacy-focused ROM should be recommending anything but a locally hosted option.
We're recommending using local filtering via RethinkDNS, not the RethinkDNS servers. They allow downloading the blocklists locally.
You can see from https://eylenburg.github.io/android/_comparison.htm that we have no limitations on call recording while others do. The fact that it's manual means users are taking responsibility for it each time. It's little different than recording a call with a tape recorder on speaker phone. If we did it automatically, then users would not be making a conscious decision to enable it case-by-case. That would be a problem, and not an acceptable way to do it without an extra explicit opt-in.
view more: next ›
@modem_down @beep @Semi_Hemi_Demigod The software walks the person using it through enabling Android Debug Bridge and extracting data with it. It's either not going to work or will be able to see many signs of what happened. GrapheneOS is well known to the forensic data companies and they make a point of trying to support it. They haven't had much success with locked GrapheneOS devices but they can certainly handle detecting it and detecting if a feature like this was used via ADB.