• General
  • Switching from iOS, confused about App Stores and Profiles

coffeefun

No problem. With Signal if you go into the app info, then go to "app battery usage" and click on "unrestricted", then give app permission to install apps. This should get Signal running properly for you . As for other apks that self update im not sure as I dont use many apps. It really is up to the individual regarding how to install apps. Some on here like sandboxed google play and some dont. The icing on the cake would obviously be a GOS store of apps which may or may not happen in future, but for now im just very grateful that the developer makes this fine OS available to us.

BluishHumility Google collects a lot of information every time you take an action on the Play Store, such as installing or uninstalling an app. For example:

On GrapheneOS, Play Store has the same exact access that all other apps would. Anything that Play Store can see, other apps can too.

Available sensors (including significant_motion, wake_gesture, glance_gesture, and stationary_detect sensors; typically for pedometer utilities, navigation apps, etc.)

It is important to note that you can revoke the sensors permission on GrapheneOS, including for Play Services / Play Store.

BluishHumility The best FOSS apps are in F-Droid. Some of the app versions in F-Droid are explicitly more functional than their Play Store counterparts--for example, have you ever tried running the Play Store version of Termux? It is essentially useless.

This is not (always) on Google. Developers deciding to paywall the full apps on the Play Store, or deciding to omit some feature is their choice, and provided that it doesn't violate the Play Store's policy, they could include it in the Play Store variant just as well.

The reason that Termux is not great when obtained from the Play Store is because Termux themselves have obsoleted it:

https://github.com/termux/termux-app#google-play-store-deprecated

The reason for that is because they no longer meet the requirements to keep being published there. There are issues with the app that they're not able/willing to solve and as a result cannot bump up their targetSdk above 28 (we're currently at 33). That is a security issue, and one of my many gripes with F-Droid. Sure, in this case, F-Droid provides a home for an app that is no longer "allowed" on the Play Store. That said, you should consider whether Play Store's request is unreasonable, and whether obtaining apps from a repository that doesn't check for these things is wise.

BluishHumility Having a phone in the first place isn't secure.

I would argue that our phones are probably among the most secure electronics devices that we own. Unless of course you mean "nothing is ever secure, everything can be compromised, we're all going to die", in which case, fair enough.

    matchboxbananasynergy Unless of course you mean "nothing is ever secure, everything can be compromised, we're all going to die", in which case, fair enough.

    Haha! I meant more that having a phone in any capacity is less secure than not having one...but yes: by extension, this. XP

    Again learning from questions & answers by others, periodically I feel like don't want to bother because it, must has been asked before and I try to find the answers. However I can ask it here maybe by keep on topic, coming from IOS with the same goal.

    I was have a owner profile, did dowload the apps I needed directly from Github and use RSS reader "Readyou" where I can see in one list if there is an update for any of those apps.

    Side of Buritos is a great add-on "info & how to" for anything GrapheneOS related after the original page, this forum, and the Matrix room ofcourse, https://www.youtube.com/watch?v=FFz57zNR_M0

    Then now I was confused a couple days ago by some discussions about notifications that need Google, be aware that English isn't the best part of me, so I blame only myself for it. I did (not want..) download the Google stuff that comes with GrapheneOS for thinking it has to for 100% notifications to work. Now I understand an app like Signal not need that, Proton do, but I use Proton without notifications for a more secure feeling in my head when carry my mail with me by every time I need to sign in name + password and log-out after read or send.

    Hope you guys (are there realy no girls here?) still with me and can follow it so far and my question is,

    How I know, how can I see if a app need Google or can do it by itself like Signal, where to look for?

    coffeefun For a follow-up question, I am curious what is the best way to install Protonmail (and their other apps) and keep them updated with the latest versions

    Wow, I've read the great discussion that happened in that thread. I think other people already answered many questions and made very good points. I will try to answer your specific question here.

    I think the first decision you need to make is if you're going to use Sandboxed Google Play Services or not. This affects not only ProtonMail but all other apps you're going to use.

    If you decide to use Sandboxed Play Services, I suggest using Play Store (with a separate Google account created specifically for that purpose) and install all apps from Play Store. Using Play Services, you'll get notifications from ProtonMail when new email arrives. It also means notifications for all other apps will work seamlessly out of the box.

    If you decide not to use Sandboxed Play Services, you can download ProtonMail apk directly from their website. I don't know if ProtonMail app can auto-update itself, if anyone knows please let us know. If it doesn't auto-update, you can sign up to RSS feed of their releases https://github.com/ProtonMail/proton-mail-android/releases using your favorite RSS feed reader and you'll be notification when a new version of the app is available, then download the new release and install it.

      As I said, my English is poor, but I did leave Reddit to answer the request from GrapheneOS to join this forum or Matrix and stay away from the haters + propaganda against GrapheneOS.

      But I never saw on Reddit someone just copy-paste an on already given comment then (translate?) excactly my post like it was that **** to understand (even giving the link) my words. Many people liked Reddit because the feeling be a noob was or is more less. Quess what?

      But you right, I did ask for it...

      matchboxbananasynergy

      Thank you for this excellent explanation of some differences between Play Store and Aurora Store. My goal is privacy, but I value security more than privacy because I don't think you can have real privacy without security, especially for non-tech people like myself. So, based on that, I will choose Play Store with a sole-purpose account if I need apps from that store.

      Most of the apps I already use are available as APK downloads (e.g., Signal, Protonmail, Standard Notes), and I would prefer to switch to other FOSS apps for things like weather and maps. So, for most of my usage, I don't actually need Play Store (I can forgo notifications). If I really wanted to avoid Google, it sounds like using RSS for APKs offers more privacy than Play Store while having an equal level of security. Is that correct?

      A wrinkle in all this seems to be my attachment to Spotify. I have searched, and it seems like it is only available through the Play Store, not direct APK download. If that is correct, and I want to keep my owner profile FOSS-only with no Google Play, would I be able to create a "Music" profile to install Google Play and Spotify, and continue to stream music from the Music profile while using my owner profile? And, perhaps more importantly, does this strategy provide real benefit from a privacy perspective? And, does running two profiles impact battery life?

      Thanks for your help! The dialogue in this community is very constructive!

        evalda

        Thanks for helping me clarify the pros and cons of using Google Play on GrapheneOS! With respect to the RSS method for downloading APKs from GitHub, I have read (or maybe seen videos, I can't recall) that it's important to check the security code of each version. This is the part that is confusing for me. I don't plan to use many apps, and the ones I do use, I dare say, are fairly "mainstream" like Signal, Protonmail, Standard Notes, Bitwarden, and so on. For these "mainstream" APKs, is it still a recommended practice to be checking these key signatures? Apologies if that isn't the correct term, I'm still learning about this approach. Thanks for your help!

          coffeefun
          Hey coffeefun

          First of all I believe that all the apps you have listed so far will work fine (not notifications on Protonmail) without Sandboxed Google Play installed. (I believe Spotify works without it but someone needs to test it out)

          If you get the app from a reputable source the first time i.e Official Website, Playstore, Github release page etc Android will automatically verify each updare for you without you having to check. It uses a TOFU (Trust On First Use) model.

          A lot of the things mentioned in this discussion can quickly lead you down a rabbit hole. I would say to just install GrapheneOS and use one profile without Google Play installed.

          • Get Signal apk from their website
          • Get Protonmail apk from their website
          • Get Spotify from Aurora Store OR use Google Play to get it
          • Use Aurora or Google Play to keep your apps up to date

          If you have anymore questions or follow up questions let us know!

          coffeefun Most of the apps I already use are available as APK downloads (e.g., Signal, Protonmail, Standard Notes), and I would prefer to switch to other FOSS apps for things like weather and maps. So, for most of my usage, I don't actually need Play Store (I can forgo notifications). If I really wanted to avoid Google, it sounds like using RSS for APKs offers more privacy than Play Store while having an equal level of security. Is that correct?

          Not necessarily. Getting your apps through APK downloads, no matter which way you use to track updates for them puts the onus on you to ensure that the APKs you're downloading are legitimate, and that you're updating on time.

          For example, you will need to ensure that the first download is legitimate by verifying its signature with a tool like apksigner. Furthermore, to use the example of Termux that someone mentioned above, their GitHub Release (which is likely what you'd use when going for the "RSS method") is signed with a test key that many people in their community have access to. That makes it trivial for someone to create and sign a release with the same key that you think is legitimate and trick you into downloading malware.

          On Android, when you download an app, you can only update it if the signature of the initial install matches. If the signature is leaked (intentionally or not) and used by others, or if the initial download is not the legitimate one, this protection isn't worth much.

          These are the kinds of things you won't have to worry about with Play Store since you obtain Play Store itself from "Apps" which provides a very high guarantee that you're getting the legitimate app, and then of course apps you download from the Play Store also have guarantees that they're legit, unless you unintentionally download a copycat (they exist).

          coffeefun would I be able to create a "Music" profile to install Google Play and Spotify, and continue to stream music from the Music profile while using my owner profile? And, perhaps more importantly, does this strategy provide real benefit from a privacy perspective? And, does running two profiles impact battery life?

          You can't realistically do that with user profiles. When you switch to another user profile, your music will stop playing. The benefit there is also dubious. Spotify wouldn't be able to see or communicate with the apps on your owner profile, but are you assuming that it tries to do so anyway?

          And, does running two profiles impact battery life?

          In some capacity, I'm sure.

            matchboxbananasynergy

            Just out of interest and without sounding patronizing, with regards to verifying an apk do you know of anyone who for example has installed the Signal apk direct from their website and it has turned out not to be 100% official?

              tango No, but that doesn't mean you shouldn't be concerned about it.

              To be clear, for that to be the case, Signal's website would need to be compromised.

              Ideally, you should get the APK from one site, and their hash from another site. That's because if the website is compromised, you can substitute both the APK file and the hash with the malicious one.

              As an example, this is how Accrescent recommends verifying it:

              https://accrescent.app/faq#verifying

              Accrescent's signing certificate hash can be verified by using apksigner with the --print-certs option. Certificate hashes are published here, on GitHub, and on Twitter.

              You should check the certificate hash from a different source than you got the app from. For example, if you download Accrescent from GitHub, you should verify the certificate hash from Twitter or this website to distrust the server.

              Again, this is something that only has to be done for the first install. Subsequent updates are fine, because your device will check that the signing keys match and won't update if they don't.

                matchboxbananasynergy

                Ok thanks for that detailed reply. Just to confirm does that mean if the apk installed initially was corrupt then one would not be able to successfully update it or if it has been installed and then updated once or twice by overwriting the initial install from the official website does it still need to be verified? Thanks

                  tango I think breaking it down with an example will help.

                  Every app has an app ID. Let's assume the app ID in this case is com.example.app. This app has been signed by me, using my signing key.

                  If you install that app, and then someone tries to get you install an update to that app with the same com.example.app app ID but signed with their key, the update won't work, and Android will stop you.

                  That is because Android knows that com.example.app is signed with a specific key. An app with the same app ID but another signing key is seen as malicious.

                  If you uninstall the app that I'd signed, and install the malicious app, Android will let you do it. However, as long as the app you installed initially is the legitimate one, all updates to that app will also have to be signed with the same key. The only reason for an app update to be malicious in that case is if the developer or whoever is signing that app to have their key compromised, which would allow malicious actors to sign their malicious app with the "legitimate" key.

                  All in all, this is why it's only necessary to verify the installation on the first install. Android will take care of it from there by not allowing you to update an app with the same app id but different signing key.

                  I hope that clears up any confusion.

                    matchboxbananasynergy

                    Thank you for your help, and the help from others! I truly appreciate this community, how people are willing to share their time and expertise in helping people achieve their privacy and security goals. I would like to contribute by summarizing what I have learned so far.

                    These conclusions are in the context of my personal threat model, which is pretty vanilla. I want to avoid surveillance capitalism. I'm coming from iOS, having never used an Android, and I already use (mostly) FOSS and/or privacy-respecting apps, and very few apps in general. Spotify is my main weakness in terms of privacy, but I truly value the music discovery I get from their collecting my listening data, so it’s a known and accepted weakness in my threat model.

                    On GrapheneOS, there are many ways to install apps: sandboxed Google Play, Aurora Store, F-Droid, RSS and GitHub, and others. I will focus on these specified four from the thread discussion.

                    Sandboxed Google Play is a secure method for installing and updating apps, with some minor (in my threat model) privacy compromises (see notes below). I will use this option (for now) for installing apps. I will use a single-purpose Google account to log in to Google Play. I will install it in my owner profile to be able to use Spotify. If I didn’t use Spotify, then I would likely avoid Google Play and skip down the list to using RSS and GitHub to install apps (and forgo notifications in Protonmail as a result).

                    Aurora Store uses shared Google accounts to access Play Store anonymously. Great for privacy, but this comes with some security risks (e.g., the shared account might have opted into beta versions of apps). Aurora Store itself has security risks (see link below). I prioritize security before privacy in my threat model, so I won’t use Aurora Store to install apps.

                    F-Droid has security concerns, and since I believe security is a necessary condition for privacy, I won’t use F-Droid to install apps. Their website is still a great method for FOSS app discovery. I hope the security flaws are fixed, because I would truly love to default to this store with its combined ease of use and focus on FOSS apps.

                    Security risks of using Aurora Store and F-Droid are explained in more detail in this link that was shared earlier:
                    https://privsec.dev/posts/android/f-droid-security-issues/

                    RSS and GitHub is a secure, but more complicated, approach to installing apps, and has privacy benefits over using Google Play for apps. This approach requires some skill and places a lot of the security responsibility on the user: (a) downloading the app from a reputable source; (b) verifying its signature; and (c) keeping it updated in a timely manner. It seems like the most complicated part is how the key signature is distributed to users, especially with respect to security. With TOFU (Trust On First Use), signature verification is luckily a one-time chore per app. Keeping it updated might be more tedious than Google Play, in exchange for being (more) free from Google. If I didn’t use Spotify, I would use this method instead of Play Store.

                    As a result of choosing sandboxed Google Play to install apps, I will face these potential privacy cons:

                    • Con: Google Play can collect data about notifications (but not the content if encrypted, like Signal messenger), and probably app metadata. Solution: n/a

                    • Con: Google Play can see a list of installed apps on that profile. But, so can all other apps in that profile. Solution: Install Google Play on secondary profile(s), if that provides other actual benefits (e.g., having two sets of contacts).

                    • Con: Google Play can access some user settings like timezone and language. Solution: n/a

                    • Con: Google Play increases attack surface, and creates an extra attack channel via notifications. Solution: n/a

                    • Con: Google Play can communicate with other apps via mutual consent, and those apps can leak data to Google that way. Solution: 1) Install Google Play on secondary profile(s) away from sensitive apps; 2) In profile with Google Play, choose apps that are unlikely to willfully sharing data with Google (i.e., FOSS apps, privacy-friendly apps).

                    For future actions, I will continue to educate myself about the RSS installation method, and I will keep an eye on Accrescent and consider it when it transitions out of alpha-beta phases.

                    Thank you again to everyone for your help!

                      coffeefun I'm glad we could help!

                      I have a couple of questions about your conclusions:

                      coffeefun Con: Google Play increases attack surface, and creates an extra attack channel via notifications. Solution: n/a

                      How do we arrive to this conclusion? What attack are you referring to here?

                      coffeefun Con: Google Play can see a list of installed apps on that profile. But, so can all other apps in that profile. Solution: Install Google Play on secondary profile(s), if that provides other actual benefits (e.g., having two sets of contacts).

                      Keep in mind that GrapheneOS has been implementing features that make it easier for you to provide more granular control of your data to apps even without needing profiles. An excellent example of this is Storage Scopes. GrapheneOS also plans to have Contact Scopes as well in order to limit what contacts an app will have access to. I thought I'd mention that since you specifically brought up contacts etc. :)

                      coffeefun Con: Google Play can communicate with other apps via mutual consent, and those apps can leak data to Google that way. Solution: 1) Install Google Play on secondary profile(s) away from sensitive apps; 2) In profile with Google Play, choose apps that are unlikely to willfully sharing data with Google (i.e., FOSS apps, privacy-friendly apps).

                      I just want to make it clear (I think you understand this, but I want to make sure) that this mutual communication is not in any way limited to Play Services etc. It's something that all apps are fundamentally capable of doing. If you think that one of your apps that houses sensitive data might be abusing this communication channel to pass on private data that you've trusted it with, perhaps the bigger issue isn't Sandboxed Google Play, but the app you're trusting with your data in the first place. Just some food for thought!

                        matchboxbananasynergy

                        Well, it serves me right to have it be my turn to answer questions!

                        matchboxbananasynergy How do we arrive to this conclusion? What attack are you referring to here?

                        This was mentioned in a post above. I hope I didn't miscommunicate. Let me try quoting it here; I hope I do it right!

                        evalda Extra software increases attack surface. Also, given Play Services can receive notifications it creates an extra attack channel

                        matchboxbananasynergy GrapheneOS also plans to have Contact Scopes as well in order to limit what contacts an app will have access to.

                        This would be great! I abandoned WhatsApp, for example, on iOS because of this very issue. I have many friends and colleagues that still use it as their primary messenger, so it's complicated for me to abandon it. I've only managed to convert a subset of my contacts to Signal over the years.

                        matchboxbananasynergy I just want to make it clear (I think you understand this, but I want to make sure) that this mutual communication is not in any way limited to Play Services etc. It's something that all apps are fundamentally capable of doing. If you think that one of your apps that houses sensitive data might be abusing this communication channel to pass on private data that you've trusted it with, perhaps the bigger issue isn't Sandboxed Google Play, but the app you're trusting with your data in the first place. Just some food for thought!

                        Yes, thank you for confirming, this was my understanding that all apps within a profile can do this. Other than Spotify, the apps in my owner profile are ones that come recommended by the privacy community (e.g., Signal, Protonmail, Standard Notes, Bitwarden, etc.). Am I correct in assuming that using this category of apps limits, or even negates, the privacy risks of this potential communication channel? Since it requires mutual consent between apps, I assume that even if Spotify wanted to secretly communicate with Signal, for example, that Signal would brush off those attempts, breaking the mutuality of that channel?

                          coffeefun This was mentioned in a post above. I hope I didn't miscommunicate. Let me try quoting it here; I hope I do it right!

                          I see, I must've missed that! I think that "attack channel" is very strong and scary wording. I'm assuming that what @evalda means here is that if an app is not properly using FCM for notifications with Play Services (Signal is an example of an app that does this properly), you could be leaking your notifications to Play Services. It all goes back to trusting the developers of your apps to be doing things properly in the first place.

                          coffeefun This would be great! I abandoned WhatsApp, for example, on iOS because of this very issue. I have many friends and colleagues that still use it as their primary messenger, so it's complicated for me to abandon it. I've only managed to convert a subset of my contacts to Signal over the years.

                          Absolutely, you shouldn't have to stop using an app just because it insists on using an invasive permission (apps are fully capable of implementing a contact picker that allow you to choose specific contacts as far as I understand, but it's one of those things that we've never even seen, because no apps seem interested in using it). Storage Scopes were huge, and in my opinion is one of the greatest features that are unique to GrapheneOS. Contact Scopes will only make things better. :)

                          coffeefun Since it requires mutual consent between apps, I assume that even if Spotify wanted to secretly communicate with Signal, for example, that Signal would brush off those attempts, breaking the mutuality of that channel?

                          Correct, both apps would have to agree and explicitly define that they're open to communicating with one another.

                            matchboxbananasynergy I think that "attack channel" is very strong and scary wording. I'm assuming that what @evalda means here is that if an app is not properly using FCM for notifications with Play Services (Signal is an example of an app that does this properly), you could be leaking your notifications to Play Services.

                            I am sorry if it sounded scarier than it should be :) Scenario you describe is one possibility, but I was referring to the fact that any inbound communication channel (push notifications in this case) create a new way how your device can be targeted and potentially compromised.

                            I don't think it adds a lot of risk, especially for an average user. Nevertheless, it's still an extra communication channel which may have bugs in its implementation which can be discovered and potentially exploited. The less ways there are to receive network packets from the outside world, the better. But again, I don't think it adds significant risk.