Notices by GrapheneOS (grapheneos@grapheneos.social), page 3

@dalias @a1ba @NebulaTide We haven't focused much on improving those standalone apps since OS improvements make a much bigger difference for GrapheneOS users and it's hard to build any kind of community with the Play Store users to get anything back from it. Our Camera app did end up with >5m downloads with >1m active users but it hasn't resulted in any contributions to it. We're going to start much more active work on it soon but odd form of success it had on the Play Store isn't a factor.

@dalias @a1ba @NebulaTide There's a lot of pain releasing apps through the Play Store in general aside from this, but the same applies to most alternatives to it.

The delay for app review is at least generally down to around 1 day right now. There were times in the past where it took a week or more to get an update approved and there's no way to get it accelerated for a critical update.

There are some very painful policies and it can be very painful to get the allowed exceptions approved.

@dalias @a1ba @NebulaTide Google hasn't forced existing apps to move to Play Signing. They do require it for all new apps. We entirely split the 3 apps we release on the Play Store from the ones we include in GrapheneOS and our app repository. There's the GrapheneOS variant of the apps with the normal app id like app.grapheneos.camera signed with our keys and then the Play variant with a suffix like app.grapheneos.camera.play with Play Signing, and we encourage people to use our App Store.

@dalias @a1ba @NebulaTide They did provide a code transparency system to prove the generated APKs match the provided code but it does not cover all the relevant forms of resources, just all the code, so we don't think it provides what is needed even if it was widely adopted to verify what's generated.

Google essentially moved to the system used by the Apple App Store where developers upload bundles of signed code which are then turned into the actual signed packages by Apple and Google.

@dalias @NebulaTide Play Store used to be a way to obtain developer builds of apps signed by the developers but has moved away from it and the code transparency system they provide isn't a complete solution to verifying what they generate and sign from the app bundles uploaded by developers.

For our own app repository, we don't want to build thousands of open source apps largely not aligned with our approach, especially without doing a pass updating dependencies and adding basic hardening.

@Kulei @newhinton We recommend using Accrescent for the apps which are available through it. It's not specific to either open source apps or privacy focused apps but rather is meant to become a Play Store alternative.

Obtainium + App Verifier for getting apps directly from developers, although we'd prefer a leaner and more security focused approach than Obtainium.

@Kulei @newhinton

> Isn't Obtainium just worse than F-Droid?

No, since it avoids added another trusted party which has proven to be highly untrustworthy.

> antivirus scanning

It's performative.

> F-Droid still does better checks than something like Play Store, right?

F-Droid doesn't have a target API level standard or other basic standards that the Play Store and Accrescent enforce. They don't do any serious review, it's the same largely imaginary system as the Play Store in that regard.

Regularly not shipping critical Firefox security patches for months is the norm for the main F-Droid repository. Whether or not they sign the apps themselves as they do for the vast majority of apps, updates can be indefinitely delayed based on issues with their outdated infrastructure or their Debian-style downstream patches needing to be updated.

For the small subset signed by the app developers, many kinds of disagreements between F-Droid and developers will mean an end to receiving updates.

@sheogorath F-Droid is filled with insecure apps with unpatched vulnerabilities in libraries, etc. Many of the apps are unmaintained without updates. Many apps which are maintained don't get properly updated by F-Droid. There are often substantial delays for updates. F-Droid has consistently introduced security vulnerabilities and rolled back security features with how they do their builds, patching, etc. Not really a curated app store. It's a poorly maintained repo of some open source apps.

@sheogorath F-Droid has repeatedly gone months without shipping privacy/security patches for Firefox and other apps. Someone not getting browser security patches for their main browser for months is quite a serious problem.

@sheogorath It's curated in the sense that they only have open source apps in it. They don't have any real standards beyond stuff being fully open source. The selection of apps is very arbitrary and tons of high quality modern apps are not included in it while tons of obsolete and insecure apps are included. Some apps which would be fine to use are not because they end up doing weird things like downgrading the dependencies

F-Droid has absolutely had fake/scam apps including of one of ours.

@dalias @NebulaTide Our current general recommendation is obtaining apps directly from open source developers. Obtainium and App Verifier are useful tools for that, but Obtainium doesn't do things in a way that we can wholeheartedly recommend it or package it in our app repository. We could make our own tool for downloading app builds with pinned keys from where developers publish them without involving third parties. Could support a reproducible build verification system via third parties too.

F-Droid has incredibly poor security practices and a strong anti-security attitude held by most of the people involved. They've consistently engaged in coverups of vulnerabilities and targeting multiple security researchers with libel and harassment.

It's a massive single point of failure and not worthy of the trust many people are placing in it. It's adding another trusted party compared to using the apps built and signed by the developers. It is not avoiding trust in the developers of apps.

For the vast majority of apps they package, F-Droid downloads and builds whatever developers publish, then sign it with their own keys and release it. They aren't doing any real review as people believe. What they really do is run things through basic scans looking for libraries they've disallowed, primitive antivirus checks for common Android malware as if that's what malicious code in an open source project would be, etc. It took them that long just to realize an app openly took over updates.

A post from the developer of WireGuard on the severe security flaws and lack of trustworthiness of F-Droid:

https://gitlab.com/fdroid/fdroiddata/-/issues/3110#note_1613430404

This led to them including a self-update system which was openly implemented and documented. F-Droid was unaware they'd shipped it for half a year, and by then WireGuard had essentially escaped from in their words being held hostage by F-Droid.

This was a rare case where an app used developer signing keys via their flawed reproducible builds system. Most don't.

Android's Private DNS feature originally used DNS-over-TLS (DoT) before Google decided to focus on DNS-over-HTTPS (DoH) over DoT or the newer DNS-over-QUIC (DoQ).

They're migrating Android to always using DoH when available. They started by always using it when the network or user configures Cloudflare or Google DNS for initial testing. Using it for everything else is behind multiple feature flags enabling newer asynchronous DNS resolution code and automatic detection of DNS-over-HTTPS support.

DoT and DoQ are leaner than doing DNS via HTTP using TLS or QUIC. The only reason DoH is winning out is because reusing HTTPS means the standard port is TCP/UDP 443 so it bypasses misguided filtering.

It's entirely possible to host DoT/DoQ on port 443 and it looks the same as HTTPS since it's TLS or QUIC either way. It's just not the standard port so they lost for client side usage despite being superior protocols. DoQ will very likely win for usage on authoritative DNS servers though.

We could enable support for automatically detecting DoH support early but it would be risky. We're planning on following along with Android's schedule for enabling these and nearly all other features. DoT does usually work perfectly fine.

Android's DoH implementation is newer than DoT so they wrote it with fancy async Rust. Rust has become the preferred language for new low-level code in Android. DoT would have been Rust if it was added today. DoT/DoQ are just losing to DoH due to the port.

Worth noting encrypted DNS doesn't hide much from networks since they can still see the IPs. Host names are also in plain text for TLS without the barely deployed ECH. If you use a VPN to have a shared IP for privacy, using a different DNS resolver makes you stand out from other users of the VPN.

DoQ will likely be the winner for server-side usage on authoritative DNS servers where the clients are DNS resolver servers rather than end users. DoT/DoQ are generally preferred by server/network engineers and DoH by browser/OS engineers.