On the GrapheneOS forum you will see a lot of bad opinions about F-Droid, for example this:
> It doesn't matter that the app is trustworthy, because F-Droid are extremely incompetent with security and the apps you install from F-Droid are signed by F-Droid rather than the developer.
> If the app is only available on F-Droid / third party F-Droid repo, use F-Droid Basic and use the third party repo rather than the main repo if available.
>
> If the app is available on Github then install the APK first from Github then auto-update it using Obtanium. Be sure to check the hash using AppVerifier which can be installed from Accrescent (available on the GrapheneOS app store).
By the way, while GrapheneOS recommends Accrescent, I don't use it anymore because they can't even add apps like CoMaps, while some of the apps they actually added are proprietary.
>the apps you install from F-Droid are signed by F-Droid rather than the developer.
That doesn't seem like a con if you take into account the context: F-droid is not shipping pre-build binaries from the developper, it asks for a buildable project from the developper.
If the source repo of the upstream dev are compromised, so will be hid own binaries anyway.
> [A]pps you install from F-Droid are signed by F-Droid rather than the developer.
Having recently gone through the F-Droid release process, I learned that this is not necessarily the case anymore.
F-Droid implements the reproducible builds concept. They re-build the developer's app, compare the resulting binary sans signature block, and if it matches they distribute the developer-signed binary instead of their re-built binary.
This is opt-in for developers so not all apps do it this way. I'd sure like to know how common this is, I wonder if there are any statistics.
F-Droid only uses reproducible builds for a tiny portion of apps, and there are still significant disadvantages. It depends on the app developers always complying with F-Droid's rules otherwise users are left without updates. F-Droid only checks that the build matches, they do not review/audit the apps and will not catch hidden malicious behavior or simply non-compliance with their rules. WireGuard's app deliberately broke F-Droid's rules by including a self-updater which was not noticed by F-Droid and shipped by F-Droid. WireGuard used this to start taking over updates for itself to migrate their users away from F-Droid. F-Droid eventually found out when the WireGuard developer brought it up many months later and couldn't do anything beyond dropping the app. It had taken over updates for itself already and F-Droid wasn't in the picture anymore.
The process adds a significant delay for updates but it does not actually protect users from developers in any meaningful way. This real world example with WireGuard demonstrates that.
> Work profiles are inferior to separate user profiles, which are built-in to GrapheneOS.
Different use cases. User profiles are only active when you manually switch to them, while work profiles are active _alongside_ your main profile.
So for untrusted apps that you only use occasionally and on-demand (like the myriads of travel / shopping / random services apps), user profiles are great. For apps that you want to keep in the background, such as the proprietary messaging apps that all your friends use, a work profile is much nicer.
Private Space is very similar to a user profile but nested inside of another user. GrapheneOS adds shared clipboard control for Private Space which was the main disadvantage compared to a secondary user.
GrapheneOS supports having a Private Space in secondary users instead of only a single one in Owner. Supporting multiple Private Spaces per user is a planned feature at which point work profiles will be fully obsolete. The remaining use case for work profiles is to have both a Private Space and work profile in the Owner user.
Don't you have user profiles in Pixels? I can create another user an switch. Just not super convient.
Work profiles are actually pretty good good... For work.
Just to add to that: Even some proprietary applications let you download their APK right from the website. WhatsApp is one such example (I don't recommend that you use it, Signal is much better, but if you require it, you don't have to use the Play Store).
Private space is identical to work profile. In the past, private space didn't exist and people used work profile instead as a workaround, but now that's not needed.
Private Space has a superior approach to isolation and encryption matching user profiles. Work profiles have some compromises for historical reasons. Private Space should be preferred over a work profile and the only reason to use a work profile for your own local usage is to use both a work profile and Private Space at the same time. Once GrapheneOS has support for multiple Private Spaces within a user, the use case for work profiles will be limited to the intended Bring Your Own Device enterprise deployment purpose. The intended purpose of work profiles is companies not having to give their employees work phones but rather owning/controlling a specific profile on their device with some influence over the overall device via rules for lock method, etc.
It doesn't work for everything; one of the banks I'm forced to use checks for how it was installed, and Android for some incomprehensible reason is happy to report that to any application that asks (along with lots of other information like bootloader status and developer mode — you really have fewer rights to 'your' device than random applications).
After opening the application, it complains about being installed through an "insecure method", and bails. Reinstalling through Google Play magically fixes that.
These "security checks" are spreading like measles, so expect to see this sooner or later.
> one of the banks I'm forced to use checks for how it was installed, and Android for some incomprehensible reason is happy to report that to any application that asks
That's because apps that aren't published just on the Play Store but also on other stores or for direct sideloads (for users running Huawei for example which doesn't have Play Store) need to be able to detect the installation method to do updates on their own if there is no backing store.
The use case makes some amount of sense, but I think once an API becomes predominantly used for fingerprinting and the real use case becomes a side effect you should just nuke the API.
It's the responsible thing to do. Apple has done it a few times.
GrapheneOS managed to make Google play services into normal android services, without higher privileges that they have on other android systems.
I am personally more than okay with using the official, proprietary GP services from time to time if they abide by the same rules, especially that I can make these rules as strict as I want.
And even if you install Google play on your graphene phone, it is still more isolated by default. Add that to the concept of storage scopes and more permissions control (apps have to ask for access to the network) and you have a more secure platform.
Many apps claim to require Play Services, but all my (several) bank apps work perfectly on GrapheneOS. No notifications because they rely on Google, but that is more feature than bug in my books.
Signal brings its own notifications, so they work perfectly.
The only app which was broken to the point of unusability was Too Good To Go, which demands that you pick locations on a map which relies on Play Services; the manual city entry is broken.
I use Google Maps only in Firefox Focus, but I've heard that builds of Google Maps up to about a year or so ago didn't rely on Play Services, and with Aurora Store you can manually enter a build number to install.
Need the Maps data, the satellite picture, or StreetView? All these past years this WebView wrapper have been working like a charm https://f-droid.org/packages/us.spotco.maps
Uh GF uses TooGoodToGo, I might try if it works with MicroG and the companion app which appears at FDroid (can't recall now the name, but it appeared with Droidify and some repos). It must be a Play Services API placeholder out there too.
Install Droidify, enable the repos, and install "microG Services" and "microG Companion".
