GrapheneOS App Store now includes a mirror of Accrescent, which is a privacy and security focused alternative to the Play Store distributing developer builds of apps:
Accrescent comes from within the GrapheneOS community and we're collaborating together.
Accrescent is in alpha and isn't yet open to any developers uploading their apps. It will have a lot more apps available in the future. It will become a full alternative to Play Store permitting closed source apps too, but you'll be able to filter to show only open source apps.
Lead dev of Accrescent is a GrapheneOS user and contributor. It'll be a good place to publish apps for GrapheneOS users. AppVerifier, BeauTyXT and Transcribro are from the same person who wrote our Info app. Molly is a security-focused fork of Signal from another GrapheneOS user.
AppVerifier was based on a planned GrapheneOS feature for users to verify APK files based on their key fingerprint. The feature is currently stalled since relying on the clipboard isn't ideal. For now, users can use AppVerifier from Accrescent until we ship a built-in approach.
We'll be delegating distributing developer builds of apps signed by the developers to Accrescent rather than doing it in ourselves. Our App Store will be focused on our own apps and eventually hardened, rebranded builds of important third party apps widely used by our community.
@GrapheneOS@grapheneos.social I have used it for a while, doesn't seems there's many apps there yet (the only one I use is Molly, the Signal 3rd party client)
@Orca There will be a lot more apps there in the future. We're doing our part to make it available to GrapheneOS users securely and to promote it now.
@GrapheneOS
I wonder if it is possible to add F-Droid too, as it is the biggest store for privacy friendly apps.
@jak2k We can't recommend using F-Droid due to extremely poor security practices throughout their client, repository design and infrastructure. The developers have an anti-security attitude and have demonstrated thoroughly untrustworthy behavior.
We're going to be supporting Accrescent and helping them get what they need to reach a stable release and provide a huge number of apps with the support of the app developers.
People are free to use F-Droid on GrapheneOS but we won't promote it.
@GrapheneOS Usually you recommend staying with the original app, especially when it itself is security focused such as Signal. I've personally not looked into Molly much or how trustworthy they are and how quickly they ship updates, but is there any documented reason why you give a shout out to Molly in particular or why they are trustworthy?
@ljrk Molly is a reputable project and we know them well. They're doing good work and are trying to get some of the improvements into Signal but Signal isn't very receptive to it.
@GrapheneOS For the application, do you still check that there are no problems in the application?
@GrapheneOS The latter is definitely also my impression, unfortunately. I just was hesitant of trusting Molly because there've been a lot of people trying to shit on Signal while producing something way worse :'-)
@ljrk Molly is a fork of Signal that's compatible with it. It closely follows the Signal releases.
@ljrk @GrapheneOS
I can only say that Molly works well on iodéOS and gets regular updates. Can’t check security/privacy.
@GrapheneOS@grapheneos.social unrelated to this post, but I always wanted to ask about TTS since it's absent in GOS, it's an amazing feature not just for accessibility but for convenience as well.. there are lots of Ai models that offer human-ish voices and run locally now, and I was wondering if you're planning to take advantage of them to implement such feature ?
@levi Android allows user installed apps to provide a text-to-speech implementation for the OS and other apps. You simply have to install one, set it up and enable it in the OS settings. We don't bundle one due to problems with their licensing and security.
@GrapheneOS
Hmm, how can the repository design be insecure? Everything is loaded over https and APKs are signed. Isn't that already secure? A growing number of apps are now also build reproducable.
Are there more information somewhere about this?
They still build and sign nearly all the apps themselves, and are not migrating towards using that approach. Regardless of whether it's their own builds with their own signatures, F-Droid is still responsible for securing the initial download. It has poor security throughout the design and implementation.
You can read https://privsec.dev/posts/android/f-droid-security-issues/ as a starting point but it doesn't cover most of our technical concerns with F-Droid. We also have major concerns about the people in charge of it.
@jak2k
Accrescent also signes the repository so their servers are untrusted.
https://accrescent.app/features
@GrapheneOS
F-Droid attempts to do repository metadata signing but both the approach they take and implementation is quite flawed.
Transport security via HTTPS using WebPKI doesn't only trust their server. It also trusts every CA and sub-CA without a way to monitor abuse since unlike a browser there isn't enforced Certificate Transparency. We pin root keys and backup keys for our services in our apps but of course it's not what's relied on for verifying App Store repository metadata.
@GrapheneOS
Better than default Android and runs on my phone, while GrapheneOS does not.
@ljrk
@fiee Tbf, that's not much of a
@GrapheneOS problem, it's impossible to build certain features if the hardware doesn't support them and it would be irresponsible to build it without those features because people would believe the phone would be as secure and thus trust/rely on this.
Arguably, many custom roms are less secure against a multitude of attacks than stock even (at least if stock android is more or less up to date). It sucks, but that's on the vendor.
(All this is something Mike Kuketz has been pushing recently too, much to the chagrin of his followership who mostly equate not-Google = secure and private which is terribly wrong, but he has certain blame to take for spreading that misinfo. Now he's more openly spoken out against that but his previous texts are now biting him :'-D)
@ljrk @fiee If the stock OS isn't up-to-date, where would the alternate OS be getting firmware updates? Many of these operating systems don't even ship the firmware, driver, HAL and other updates that are available because they simply leave the firmware and OS vendor images which were present when they were installed. A proper production OS needs to ship all this and build the vendor images itself even if a lot of what's in there are just prebuilt code from the stock OS for the firmware, etc.
The GOS community seems to think so but I've never understood why.
*Or at least, they were planning on doing that a while ago. Have they gone ahead with it?
The reason we're including Accrescent in our App Store is to provide a secure way to obtain it, since our App Store has signed metadata with downgrade protection and the App Store client doesn't trust the server. The same thing applies to Accrescent. It provides a secure method to initially obtain the application before it's secured by the developer's signing keys. It is verified based on the hash in the metadata in addition to the developer's signing key too.
It does protect against an attacker who has compromised both the server for the app store and has obtained the developer's signing key. They would need to put a backdoor into a release, which they could do whether or not it's open source software and whether or not it's built by the app store. F-Droid pretends building apps offers protection against this but the reality is that they blindly build the code and there is no way to auto-detect backdoors being added.
- replies
- 1
- announces
- 0
- likes
- 0
The app's signing key is how the OS package manager verifies the app, but both our App Store and Accrescent also verify each downloaded APK based on the repository metadata. We were explaining that having control of the app repository and the developer's signing key isn't enough because the repository metadata is signed offline. That's why we said they'd need to actually put a backdoor into either the app's source code or the latest official build of the app.
Reproducible build verification can't actually prevent this. It only prevents them putting it into the build without also putting it into the source code. It's clearly possible to put a backdoor into the source code without it being detected as shown by the multiple times it has been caught happening after the fact in widely used projects. The most well known recent example was the xz ssh backdoor, but that's not the only one, and there may be important missed cases.