[Privacy] Preventing Android App Support from importing personal data like contacts

General
#1

EDIT: Unfortunately, I rebooted and saw all my contacts in Android again. So, at the moment, the following trick seems not to survive reboot or not to work at all as I perhaps had a false positive.

I started using Android App Support (AAS, Alien Dalvik) a bit more recently.
Android apps seem greedy of personal data.
In case an app refuses to work if one doesn’t accept to share e.g. contacts, then the address book privacy is lost.
It is not possible in the settings to disable synchronization between the SFOS address book and Android’s one.
This didn’t suit me, so, here is the way I found to prevent this situation.
Please be tolerant and provide remarks/improvements as I have zero knowledge in databases not in Android App Support mechanics.
Try at your own risks.

On SFOS, contacts are stored in a database which is /home/defaultuser/.local/share/system/privileged/Contacts/qtcontacts-sqlite/contacts.db and in temp files along this db in the same directory.

On the Android side, contacts are stored in /home/.android/data/data/com.android.providers.contacts/databases/contacts2.db

It seems that the contacts are copied from SFOS db to AAS db during AAS startup.

Nulling the SFOS db file rights at the beginning of AAS startup and set these rights back at the end of the startup seems to correctly prevent the contacts from being imported.
(Changing the ownership to root doesn’t seem to work anymore.)

Here is how I do:

  • Stop Android App Support.

  • Edit /usr/libexec/appsupport/start-aliendalvik.sh (previously /usr/sbin/start-aliendalvik.sh)

After:

# License: Jolla Proprietary

Insert this line:

chmod 000 /home/defaultuser/.local/share/system/privileged/Contacts/qtcontacts-sqlite/contacts.db*

  • Edit /usr/libexec/appsupport/alien-post-startup.sh

At the same place like above, insert:

chmod 644 /home/defaultuser/.local/share/system/privileged/Contacts/qtcontacts-sqlite/contacts.db*

  • Delete the Android address book /home/.android/data/data/com.android.providers.contacts/databases/contacts2.db

  • Start Android App Support and verify that the address book is empty.

4 Likes
#2

also should redo it after every update / alien reinstall

1 Like
#3

I seem to remember this used to be configurable before Android starts (i.e. permissions for appsupport). Huh. I might remember wrong.

Anyhow, I just linked that contacts.db2 to /dev/null:

$> devel-su
#> cd /home/.android/data/data/com.android.providers.contacts/databases
#> mv contacts2.db nosuchthing
#> ln -s /dev/null contacts2.db

On Signal this seems to have the desired effect without disturbing functionality.

Survives Appsupport restart & reboot.

4 Likes
#4

You don’t. There used to be a setting for it in older iterations of AD.

6 Likes
#5

Oh, yes also a good way, thanks.
Only downside is that one cannot save contacts anymore from within Android.
Out of that, it is probably the safest way regarding privacy.

#6

But there must be a way to jump over the contacts export step.
I know the existance of strace or lsof…
Are there more appropriate tools I could play with, to try understanding the AAS start process?

#7

Unfortunately, I rebooted and saw all my contacts in Android again. So, at the moment, the trick from first post seems not to survive reboot, hence is not useable.

#8

I’m very sorry and disappointed, having to say this also is unperfect. When I link this file to /dev/null, some Android apps fail to start and crash. I tried ‘Contacts’ and ‘Telegram FOSS’ from f-droid.

#9

I might have completely misunderstood this whole thread, but I don’t understand how you guys manage to get your contact data automatically imported to the android side. Because I don’t. My /home/.android/data folder is totally empty!
On the other hand, I do not use to many android apps (mostly banking apps) and I use android settings to deny access for unwanted apps.
Is there any reason you can’t do the same?
As I said, I might have misunderstood the whole thing.

#10

Try again with root permissions

1 Like
#11

@eson are you sure that’s /home/.android and not /home/defaultuser/android_storage? And whatever tool you used, does it have permission to look at /home/.android?

I think it’s mostly the scripts in /usr/libexec/appsupport/. Some of them generate other ad-hoc scripts, iirc. Sometimes they call each other.
The created config is mostly in /tmp/aliendalvik/appsupport iirc.

But a quick grep for “contact” or “database” shows up nothing.

One would have to go through all of them to figure out where they gather configuration and instructions from.

There are also appsupport-* utilities.

BTW there’s a possibility to fill in some extra config without editing the system files: create /usr/libexec/appsupport/alien-generate-extra-config.sh and put what you want done in it. See here.

2 Likes
#12

Thanks! And there they are…

1 Like
#13

I’ve been thinking about it one more round, and I must say I wasn’t aware that those files was not just hidden, but hidden hidden.
Still learning, apparently…

#14

Yes, you are right. Normally, avoiding contacts access in AAS Settings should suffice.
But I seem to remember that some apps refused to work without contacts access.
Anyhow, it’s more for me a matter of principle and prudence (well, strong word, my db is not so sensible).
As there are regularly small scandals comming out about privacy abuses from the giants,
As my knowledge in a reliable way to veryfy those things is limited,
As Microg pretends some apps can missbehave without contact access (‘find accounts on the device’),
I concluded it would be simpler just not to export contacts from SFOS to AAS and in paralell allow contacts access where needed on the Android side.

By the way, happy new year, health and love in 2024 to all members and their families!j

1 Like
#15

Many thanks for having elaborated,
Indeed, I had a look into some of these scripts and grepped all of them for ‘contacts’, ‘address’… too, but unfortunately found nothing.
I concluded that the impirtation was perhaps made by a binary that we cannot read.

Do you know of an utility that could monitor a file acesses? That way, it’d be possible to see who is accessing the contacts db…

#16

strace -e file <command> will list file-related syscalls.

inotify-watch can wait for open/close/… and do something when detected.

Not sure how well they work with lxc and different namespaces though.

fanotify looks useful as well, and can be compliled easily on-device. From my brief test with this tool, it’s apkd-bridge who reads the contacts db.

(Note that I’m looking at AAS on a 4.4 system, things may be different on 4.5).

Now, apkd-bridge is run from a service, so maybe systemd sandboxing can be used to restrict file access to the contacts db. E.g. by using TemporaryFileSystem for the location of the contacts db so it is hidden by a tmpfs mount.

2 Likes
#17

Tried both InaccessiblePaths and TemporaryFileSystem for the apkd-bridge service, didn’t work. Maybe because they are user services?

What does work is masking the service.
AAS will start, and the contacts db on the aas side will still be created.
But no contact info is in the new database.
(what is there is e.g. account info, and some entries regarding contact thumbnails. I suopose those are added by something else. )

No idea what will break by masking this, didn’t test thoroughly.

2 Likes
#18

Have you tried simply stopping & disabling it?
I did now, will see how it goes.

FWIW,these are the commands:

systemctl --user stop apkd-bridge
systemctl --user disable apkd-bridge
# or
systemctl --user mask apkd-bridge
# check status
systemctl --user status apkd-bridge
1 Like
#19

I wouldn’t downplay it. The fact that on Android many apps (and Google itself) have complete access to all my Contacts has always horrified me and is the single biggest reason I never used Whatsapp etc. on my daily driver. I mean this is real life data of the deepest kind both personal and professional. It’s nobody’s business xcept my own.

3 Likes
#20

That’s lovely @nephros, many thanks for having been searching, trying and explaining.
It’s progressing, even perhaps solved.
I’m going to try simply disabling the service too, and report how it goes.