Switching from iOS, confused about App Stores and Profiles

coffeefun

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!

matchboxbananasynergy

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.

coffeefun

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!

Lusca

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!

tango

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?

coffeefun

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!

matchboxbananasynergy

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.

tango

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

ve3jlg

matchboxbananasynergy 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.

If one decides to switch apk sources, will uninstalling the app clear signatures and reset TOFU?

I realize that user data will be lost.

matchboxbananasynergy

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.

tango

matchboxbananasynergy

Thats great thanks for clearing that up, your knowledge on here is invaluable and greatly appreciated!

MrStreisand

matchboxbananasynergy

hey again!

Wanted to double check if i understand correctly - if i use Obtainium on a single profile device - as long as i check the web site for the app and expect the dev to be responsible about their keys (eg proton, signal, nextcloud) I have no reason to worry about the updates coming through obtanium?
and another thing - if i'd use single profile with obtanium, any options of getting a tesla app and google camera, without using gPlay & aurora store? (i know the question is a bit dumb, i just wanted to make sure)
Cheers

matchboxbananasynergy

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!

MrStreisand

coffeefun
Hey there, it's been almost a year since you started on the journey, could you help - share what set up you have arrived at so far and how is it serving you?
Cheers

coffeefun

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?

matchboxbananasynergy

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.

evalda

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.

coffeefun

evalda

Thanks for including this possibility in the discussion. It's helpful for someone like me, not very tech savvy, to at least be aware of these issues, even if my personal threat model is vanilla. It's important to be aware of the potential consequences when agreeing to use features, and then let the user decide if that is a likely scenario. Thanks for your help!

ve3jlg

matchboxbananasynergy Anything that Play Store can see, other apps can too.

Irrelevant.

It's Google's core business model to fingerprint every person and combine as much data as possible about each together to build a detailed personal profile about them - not so of almost all other apps. They aren't doing this and do not have the extremely broad reach across the internet and devices which Google does, so can only be much less invasive.

Furthermore, for the many users who do not live on the U.S., they do not expose themselves to NSA wiretaps to nearly the same risk if they do not use American-based services like Google's infrastructure.

matchboxbananasynergy

ve3jlg GrapheneOS does not bundle any type of Google service or app in it. If someone is not okay with using Sandboxed Google Play after fully understanding how it works and that it is fundamentally different compared to privileged play services that you would find on the Stock OS, they can simply choose to not use it.

Not everyone's threat model, needs, or expectations are the same. People need the apps they depend on to work. The best way for them to do that is to use Sandboxed Google Play. It is better than using Stock OS with privileged play services, and it is much better, and much more secure than other approaches trying to do the same thing.

If you can use all the apps you need without Sandboxed Google Play, you're free to not use it; in fact, that would be ideal, but people's journey into privacy doesn't happen instantly, and the more you try to change at once, the more likely you are to completely give up and go back to something objectively worse.

People who use Sandboxed Google Play on GrapheneOS are already miles ahead of most people when it comes to their phones.

matchboxbananasynergy

ve3jlg If one decides to switch apk sources, will uninstalling the app clear signatures and reset TOFU?

Yes. Once an app is uninstalled from all user profiles on the device, then installing an app with the same app ID again can have any signature it wants.

If that wasn't the case, you could move between F-Droid builds (signed by F-Droid) and developer builds (signed by the developer), for example.

The point about it being in all profiles is important because that thing is universal. If you have a variant of an app of an app in one profile and try to install an app with same app id but a different signature in another profile, Android will stop you, as it detects that you already have it installed with another key.

Same thing applies to trying to install a version than the currently installed version in another profile.

MrStreisand

matchboxbananasynergy

Hey there!
Switching from ios myself and the way you and others have explained couple of questions in this thread is invaluable, if i can suggest to pin this particular thread somewhere easier to find for the newcomers, this here is pure gold!
Cheers

« Previous Page Next Page »