Join us 2026-09-25T21:00:00Z for This Week in Privacy #72, to catch up on the latest Privacy Guides updates and to discuss trending news in the privacy space.
During the livesteam we’ll answer viewer questions. If you have a question for us, please leave a comment in this forum thread or the YouTube chat.
Members please leave your questions for us and we will try to get them answered first during the livestream
Please be aware that by posting here your post will be displayed on the YouTube stream.
Streaming Platforms
You can join the link above when the stream starts to watch and chat in the livestream without an account.
We will also be streaming from the following platforms:
Took them that long. I already migrated to droid-ify because f-droid is that buggy. Download would often fail midway, and constantly freeze every few seconds.
I used f-droid basic with beta updates enabled for months and never really had issues, great overhaul!
I would highly encourage
GrapheneOS to include “f-droid basic” in their appstore. It is an objective benefit for security as the TOFU (trust on first use) for this extremely critical component is eliminated through verification from the root of trust. It is silly to just include Accrescent (more on that later)
it actually contains most FOSS apps out there, unlike Google Play or Accrescent. I currently have access to 5855 apps that I can browse offline, from F-Droid and Izzy alone! Search is really fast too and includes source code links.
many devs make blobfree builds specifically for F-Droid. Their importance should not be underestimated, if nobody enforced blobfree builds, they wouldn’t exist!
they are an independent and open source build system building apps from source. I.e. they do not use Android studio on some outdated Windows full of malware! It is a transparent build system, which is worlds better than having “apps straight from their developers” but no idea how they were built.
updates with f-droid run in the background and are efficient. Obtainium somehow supports background updates but not reliably, and it is extremely inefficient!
F-Droid is big and significant, unlike Obtainium or Accrescent. It is a community of people and they play a big role in the FOSS Android space. They actually care about open source and transparency, unlike any of these other sources. Accrescent contains a random selection of apps, some of which (like QLango) are proprietary and not privacy friendly. Google Play often has the “play” builds of FOSS apps, including proprietary libraries by Google that can spy on you, even without any privileged play services installed
F-Droid contains a ton of apps that are built reproducibly, which is required to be able to verify that an APK actually came from the code that it says it uses. No other project does that. You can check that using verified-apps, if an App has matches from F-Droid and Direct APK Link
I currently use F-Droid+Izzy with a few external repos like Ironfox, FUTO, Briar, Collabora, Twinhelix Signal-FOSS or Molly, Newpipe, Brave, WG Tunnel
Updates work really well and are efficient, and I supplement missing apps with Obtainium.
F-droid apps are also NOT all signed with the same key. I dont know how they do it but I actually struggle to find any apps with matching signatures.
Also I dont know if F-Droid Basic is still the only app targetting recent Android versions. F-droid does have a focus on legacy compatibility, but not that much?
I use Obtainium for a few projects I can actually trust, even though there might not be transparency into their build system.
The Effect On UX in GrapheneOS
The bias against F-Droid (or the blocking against copyleft apps that also prohibit Tivoization (like the GPLv3) really hurts the UX of GrapheneOS.
Side tangent: The fact that Linux uses the GPLv2 is the sole reason that GrapheneOS gets access to the Android sources at all. And that no part is GPLv3 means they are just lucky that Google allows installing another OS on their phones. But they want a potential future partner OEM to be able to take that right from users, how ironic is that? Even without the fact that A they had the entire CopperheadOS debacle before and B that means they can’t preinstall a ton of the most reputable FOSS apps including OpenEUICC or Fossify
The effect is minor, but so is the benefit of including the “promising Accrescent” in their Appstore. It would be a net positive to not direct people to the Playstore or Accrescent (a nearly useless, intransparent store with unreliable updates and no metadata).
As said, the playstore will provide builds of FOSS apps that actively include proprietary blobs. Not to mention that some use Google Play Signing which means Google is in control of the signing key and could do whatever they want with the app before signing it!
It is less secure to need to go on the internet (likely without a VPN or secure DNS like Quad9 installed and hope that DuckDuckGo will direct you to the correct F-Droid store.
Also, after arriving there, you need to ignore the big blue download button, search for “F-Droid Basic”, hope that the search finds it (the dash is an issue here), scroll down and ignore a warning to install the latest APK manually, then trust a browser to install an app (which is bad) and hopefully remove that allowance directly afterwards.
How bad is that lol?
Panic Button/Trigger
This is a really interesting concept that exists since quite a while. A few apps respond to it but not many. Apps with device owner or profile owner access like Hail can use different methods to hide apps from the system which will make them disappear for other apps. This could be used and would be cool, but I wouldnt want an internet facing appstore to do it.
We have seen what usage of a duress Pin can lead to, so alternative less invasive solutions are really welcome. Hiding actions is a cat and mouse game, but it is kinda typical for GrapheneOS to block off any ideas there. One could only delete secondary profiles, or wipe certain directories and write and delete a bunch of “cache” files for example.
Open AI models
That one is kinda funny.
All current models infringe copyright massively. They are all f-ing illegal and nobody does anything. Meanwhile people who want to watch and listen to media privately, while owning, preserving and sharing it, need to fear huge fines
Many models are open-washed and somehow even the open source community doesnt do much against that. Now that actual open models exist, this should change?
It’s a good thing Accrecent will allow closed source apps. They need to add metadata but A crescent itself is private so you don’t loose privacy by using Accrecent unled you install apps that are invasive. The alternative to get the apps people need is play store or aurora store which are much less private ways to install apps.
Yes of course. Point is, Accrescent doesnt even try to work in the role of F-Droid
And technically a 3rd party f-droid repo could do the same (apart from the pinning stuff they do idk how, and signed metadata (which accrescent kinda doesnt use either, yet))
Like idk what minimum version pinning is supposed to do, a repo will simply have a limited amount of APKs
The one thing they don’t want in the base OS is GPLv3, not copyleft licenses as a whole. Vanadium is licensed under GPLv2.
Their reasons for avoiding it are very valid in my opinion:
They want GrapheneOS to be a drop-in replacement for AOSP that can be used anywhere AOSP is used, including for devices with an immutable root of trust.
While I personally believe general-purpose computing devices should always allow users to install another OS (and that OS should be able to take advantage of all hardware features), I can imagine there are some specialized use cases where an immutable root of trust can make sense. Also, if a company is gonna make a tivoized device, I’d much rather it runs a more private and secure OS than some half-baked GMS Android.
A lot of companies avoid GPLv3 like the plague, so this could limit their ability to find hardware partners.
It’s very important that GOS is able to partner with hardware manufacturers, since as you correctly pointed out, they’re currently dependent on Google’s (dwindling) good will for devices. Hardware partnerships could also lead to more secure and more open devices down the road.
The Motorola partnership may not have been a thing had GOS made use of GPLv3 code.
It’s the reason they can get the kernel drivers for Pixels, yes, but not the whole Android sources. AOSP is not open source due to Linux’s GPLv2 (otherwise the userspace would be GPLv2 too, not Apache 2.0), it was a business decision from Google. Userspace is not subject to the kernel’s GPLv2 requirements, as made explicit by the Linux-syscall-note.
GPLv2 doesn’t even get them full driver sources, since there often is proprietary userspace driver code.
They wouldn’t include it anyway due to the large amount of memory unsafe code.
They’re overhauling the default AOSP apps themselves.
Well, duress pin is a nuclear solution, it should only be used when the situation really calls for it.
Secondary profiles can’t be wiped with plausible deniability. It would give people a false sense of security. It won’t stand up to forensic analysis and it’s only gonna get worse as awareness of the feature spreads.
Sure, the project attempting to build a private alternative to the Play Store for general Android app distribution is useless. Making a platform for developers to publish their builds without a third party signing them and introducing delays in updates is useless. And doing so with great care for security is useless.
Development is very transparent.
This was fixed during the client rewrite.
This is coming once the work on core stuff is finished.
As a FOSS enthusiast myself, I very much welcome stores dedicated to open source apps that ensure completely blob-free builds. While it’s great that Accrescent allows proprietary apps since in practice people will want/have to use them, I’m glad if FOSS stores exist alongside it. I just don’t want them to add another trusted party, since you will have to trust the developer either way, and they should take security seriously.
I’m making an app and I would love to have it on Accrescent. I will likely release it on F-droid or my on F-droid repo (I haven’t looked into it), just so as many people as possible can enjoy it, but as a user I’d much prefer to get all my apps from Accrescent. It’s a smooth experience I can trust. F-droid just does not inspire confidence with their security (and therefore privacy).
I recommend making it build reproducibly before submitting it to F-Droid, as the key would change otherwise and users would need to reinstall. You can put a comment about this into the app description.
Plus maybe faster releases on your code repo and and a separate f-droid repo if you like.
Funny how you cut my quote there. I changed it to make it clearer
I agree with your other points and the nuance of specialized devices. A small(ish) player needs to focus on adoption and compatibility, only bigger players are able to make demands.
That said, GrapheneOS is funded by donations and I would like them to defend the freedom of their users through such a license change. Their employee count and funding structure is pretty intransparent, so I don’t know if company donations play a significant role there.
GPLv3 code could also simply be left out if an OEM wants to ship a tivoization-allowed GrapheneOS build. This would be 3rd party apps and components, like their choice to allow using Googles proprietary SIM Card component instead of also allowing users to choose OpenEUICC (There are other factors there, like “unsafe C code” or lower compatibility. Still sad).
Motorola doesn’t ship GrapheneOS themselves and as part of their deal they do not permalock their bootloaders, and it doesnt look like they would? So idk. But still, this was only a side note, there are facettes about this.
Understandably, they mentioned they would work on something but that doesn’t seem to exist yet after multiple years. There is also memory tagging which afaik can protect against a lot of memory related vulnerabilities.
They use ReFra and plan to use FlorisBoard so I think it is clear that they are not able to just rewrite the world to get what they want. Also, their apps might work but still have way less features. Compare MJ PDF to their PDF reader etc.
In the end, you can replace nearly all of the apps, so including a useful appstore in apps and giving users a quick start would be enough.
I like the “wipe after x failed attempts” solution which existed in iOS 8 (recent PG video) and doesn’t seem to exist in Android.
Yes but there are more arguments here
not every analysis uses the best tools, which are expensive and proprietary
it could be a legal difference to protect some data while offering access to the rest. There might be nuances here, although not many
you shouldn’t give cops access anyways and don’t have to in most countries. Pixels especially with USB-port lock are not crackable, this would simply be an extra protection. Arguable if a pin would be the best solution there.
There are valid arguments against wiping your device at all. In many countries “destruction of evidence” is clearly regulated so you shouldn’t even think about it.
Auto-reboot, usb-port-lock and the regular Android “Lock” (prohibiting fingerprint use) are already fantastic, no contradiction here.
In the current state, yes kinda. The idea is good, for proprietary apps. But as said, the benefit of including the nearly useless store in GrapheneOS is smaller than the drawback of needing to insecurely obtain a more full-featured FOSS appstore like F-Droid.
I mean, they could include Obtainium and Verified-Apps in their store too, why not? It is not the same as preinstalling an app, they could remove apps later without issues.
Who adds whom? Reproducible builds on F-Droid are built by the dev but checked by F-Droid, the only issue is speed and reliability of delivery.
I agree that a store for proprietary apps is needed. I hope that it will thrive. But focusing on that while ignoring the world of alternatives is not smart.
On the wired headphones, just for putting into contrast, it appears bluetooth can not only be hacked but the connection (doesnt need to be an initial key exchange) can be used to control the “active” device like your phone
This doesnt seem to require specialized hardware at all, similar to Wifi attacks, just a less protected bluetooth device, maybe with root access.
So wired headphones are still WORLDS more secure! I recommend to check out the talk and try it on your own headphones! As far as I know there was no response by manufacturers, my Sennheiser headphones have had updates with absolutely no comment on security fixes.
I think the main point here is that GPLv3 will straight up scare some companies away, regardless of the actual details of how it’s used. See Google’s AGPL Policy for example. It’s about AGPLv3, not GPLv3, but it shows how cautious companies can get regarding viral licensing restrictions. And if companies have to make some effort to remove the GPLv3 parts, it’s no longer a “drop-in replacement”.
Regarding the Motorola partnership, there might be some devices sold with GrapheneOS preinstalled, I think the details are still not worked out yet. But yeah, you must have an unlockable bootloader for a GOS partnership, even if you’d only want to make devices with it preinstalled, since “Support for using alternate operating systems including full hardware security functionality” is part of their hardware requirements. They want their licensing to allow people to use their code to make devices with an immutable root of trust, but they’re not going to port the official project to such a device, at least according to their current requirements.
They don’t want to use something that is less secure than what’s used on the stock OS and what they have currently. Sure, GOS has strong exploit protections, but the goal is to decrease the amount of memory unsafe code in the OS, not increase it. The Google app integration doesn’t share any data, but even if you consider OpenEUICC to be better than the current approach, it would be a waste of time to work on integrating it if they still have to replace it later by their own app because it’s not satisfactory.
They have a lot to work on and many higher priority things.
Interestingly, one of their devs was working on an eSIM app recently, but I assume it’s just a proof of concept at this point. They did start a serious effort to improve the default OS experience this year and hired an app team, so we might see progress on eSIMs too in the not too far future.
Well, if there are projects that meet their requirements it’s better than starting from the legacy AOSP apps or from scratch. But they did rewrite the AOSP Messaging app and are doing the same for the Contacts app (and will be doing it for the Phone/Dialer app, and potentially Clock and Calculator).
Oh, I agree there, but they will get better over time. Their PDF Viewer still lacks a lot of important features, but the recent update was already a nice improvement, having to use the menu arrows to change pages was rough. But it’s precisely because they made it themselves with a unique approach (WebView, CSP) that their PDF Viewer is particularly secure, you wouldn’t have gotten that had they just integrated another app.
True, that’s why I said it should only be used if the situation really calls for it, if the benefits of using it outweigh the consequences.
Fully agree with this, this probably would have been the best course of action in the recent case.
Yes, but the point is, it’s a feature with no guarantee it will fulfill its intended purpose. People might wrongly believe it does and put themselves at risk because of that. And in general, if a feature can be defeated, you can’t and shouldn’t rely on it as part of your threat model, especially in high-stakes situations like that. Even if you want to believe it will be fine and useful in a lot of cases, awareness of it will spread over time and adversaries will adapt to deal with it systematically, and the feature will end up as nothing more than a misleading hazard.
Ok, saying the project is “useless in its current state” is different from simply saying it’s “useless”. I still don’t agree, because it’s a nice way to get the few apps that are on there. Besides that, I think the reason GOS decided to include it in their App Store so early is to put the project in the spotlight and encourage people to use it. Ultimately though, Accrescent is still alpha software and lberrymage is working on it alone for now, so of course it takes time for it to reach maturity.
They plan to have an open source tag, so it will be nice for FOSS apps too. I do hope they strictly enforce builds being completely blob-free for this, otherwise I think it would be misleading to users and would make it hard to establish a clear and unambiguous criteria for what counts as open source.
While they do mention using Obtainium + AppVerifier, since currently it can be the best way to get apps in a lot of cases, I think this is not something they consider satisfactory and want to really encourage, especially since it’s a convoluted approach that people lacking the required tech literacy can’t be expected to use.
Once people end up depending on them being available in the App Store as part of their setup, it’s hard to walk that back.
No objection that reproducible builds solve the trusted party problem. I don’t know what the current percentage is, but I think this is still far from the majority of apps.
At the end of the day, F-Droid doesn’t meet their security standards, so they won’t include it, it’s that simple. I personally appreciate GrapheneOS having high standards and sticking to them. As a user I know I can trust things to be solid, and it helps raise the bar in the privacy community as a whole. As a result of them having strict standards, we now have an OEM improving some of their devices to meet them.
