It is really a shame that there are no steps taken to better protect contacts against fraudulent apps like from Meta. Is there really no will to make the contact handling at least as protected as in IOS18 ?
I want to point out that there already is labels in contacts. So it should be easy to use these labels for app-local contact lists, meaning a way of defining which app can access which contact label(s).
I see no privacy protection going on in this case.
Indeed, I also found a solution by rooting, installing XPrivacy Lua (together with the Pro Companion App) and slightly adapting an existing XPrivacy rule. However, I am aware that this might not be for everyone…
Unfortunately, I am not aware of any (other) projects or Android custom ROMs where the access to the saved contacts can be limited to a certain sub-set for every app. The current Android approach is “all or nothing” (where “nothing” may work reasonably well even for WhatsApp, but still…)
As a workaround, there are apps like Launch Chat where e.g. a WhatsApp chat for a contact can be launched even if WhatsApp does not have access to the system contacts.
There has been some discussion on this forum about work profiles with a separate set of contacts so that an app in a work profile does not see the personal contacts.
Moreover, there are apps like Fossify Contacts where contacts can be saved only in the storage of the app, but not the Android contact provider. Hence, these contacts are only visible in the Fossify Contacts app, but cannot be accessed by e.g. WhatsApp.
Personally, the option to limit the contacts an app can see would be more than welcome!
Ok, lets try to make my point clearer. It does not really matter if I can find some odd solution for this problem. My writing is more about joe-average-user. And it is quite clear that he will never ever root his phone nor make profiles (which is why my personal joe-average-user wants to drop graphene - it is overly complex in this respect and hard to handle by normal users). The label approach would be straight forward and easy to understand and configure (during contacts right approval a selector is needed for the label, or none which is the current standard).
My personal e/os is completely stripped from Google and equivalent patches and apps I use work nevertheless - even my banking app (with a minor flaw). So generally e/os would be a good choice, but unfortunately joe-average-user installs whatsapp (instead of an XMPP messenger).
So security is way behind IOS now…
I absolutely agree regarding your “joe-average-user”, such a solution would be nice! But as I have pointed out,
So the /e/OS team would have to implement it by itself. As your idea is a good one IMHO, it should be proposed. Unfortunately, the /e/OS developers seldom consult the forums for suggestions etc. so that the proposal should be posted on the /e/OS GitLab. As the registration for the GitLab currently does not work as desired because of the outage, I (or another user?) may post the suggestion there.
To be nitpicky, you mention “security”, but I think you mean “privacy”
such a feature will rather arrive through Google implementing it, not downstream in Lineage or /e/OS - it’s just too fundamental. There are workarounds as described in your previous thread on this - but not equivalent as of now. I’d watch
Depends on the point of view. From the user perspective it is probably a bit more privacy related. But from the contacts point of view you may well argue it to be a security hole if your personal contact data gets stolen. The contact may have lots of fields filled amongst which can be the complete address (and maybe more).
PS: I have no idea how to mark this a feature request …
All in all rooting is super simple, even for Joe Avarage. If you can install /e/OS, you can root. You only need to flash one simple file as an IMG in recovery and install the same file as an APK in Android. That’s it. You’re rooted!
Of course, after that there is some work to do, but don’t tell rooting is difficult. It is not.
Not sure about the english terms and actual selection to choose from but it should be possible to edit additional “optional keywords” under the header of the thread and add “feature proposal” or “feature request” or “request a feature” (on top of already chosen “contacts” and “applications”) besides the main category “using /e/OS”
I must confess that I was wrong and that GrapepheneOS already has a functionality like you have suggested, @skraw ; see Grapheneos - Usage Guide - Contact Scopes. Maybe this should be mentioned in a GitLab issue as an additional reference.
Thank you for your work. The feature request is really describing the problem very well and pointing to various solutions (like IOS and Graphene). Thanks a lot!
I hope someone reads it and really understands the problem. Because it is a big one…
