From Newsgroup: comp.mobile.android
Maria Sophia wrote:
Here's that flow in itemized format:
1. Export system contacts to VCF (preferably to external sd card)
2. Import VCF into DOpen Contacts (preferably from external sd card)
3. Verify contacts inside DOpen Contacts
4. Copy to safe non-phone storage (e.g., your home personal PC).
If desired, use Veracrypt to encrypt the contacts database.
4. Delete system contacts (optional)
5. Disable Google sync (optional)
If contacts change frequently, then back up DOpen Contacts' VCF regularly.
To add further technical value to this concept of setting up Android for contact management outside of what Google marketing wants us to do, below
is a verbatim copy of a post I just wrote up for Carlos & Frank just now.
Carlos E.R. wrote:
On 2026-02-06 11:55, Frank Slootweg wrote:
Carlos E.R. <robin_listas@es.invalid> wrote:
On 2026-02-05 22:32, Maria Sophia wrote:
Carlos E.R. wrote:
On 2026-02-05 19:47, Maria Sophia wrote:
Privacy is a million things where most people only know four or five >>>>>> of those million things, and just one of those million things that >>>>>> most people don't know is to keep their contacts sqlite database
completely empty on Android.
We do know. We choose to disregard.
But then you must ask for permission from each contact for you to store >>>> their private information on the cloud, which is a lot of work, is it not? >>>
No, I don't have to. Not in Europe.
If we had to, lawyers would have jumped lot long ago at the yugular of Google. And the regulatory bodies of several European countries. Right
now, France is suing some huge USA corporations for I don't remember
what exactly, related to privacy concerns.
And in the USA Google is also being sued for something big, too.
Not only that, but the contact information isn't stored "on the cloud"
in the first place. But "on the cloud" sounds so conveniently scary, so
why say where it's actually stored, when you can lie about it being "on
the cloud"?
Google would have to state in their conditions that they are going to
make use of the contact list for something akin to publishing it.
BTW, "*on* the cloud" isn't that bad anyway, but I digress ...
As to the original 'Subject:': What happened to Wi-Fi?
Hi Carlos (and Frank),
I read EVERYTHING you both write, always, so I appreciate what you said.
Carlos & Frank bring up excellent points that just having contacts in the sqlite location on Android (or in iOS) isn't a privacy hole by itself.
Since I put together systems for a living, and since I used to have an engineering-level TSSI special access designation, I'm likely more tuned to privacy holes than most people, as I've seen "how they work out there".
Most people, I'd wager, would be shocked at how much is hoovered about us.
With that in mind, I will address Carlos' & Frank's stated concerns above.
This is a technical summary of what actually happens with contacts on
Android and why the privacy risks are not about the SQLite file itself
but about the data flows around it.
1. What is Android's local-storage model for contacts anyway?
A. Android stores contacts in a local SQLite database accessed through
the ContactsContract provider.
B. The file is on the device, not on a remote server, so in that narrow
sense it is not "on the cloud" as Frank had astutely mentioned.
C. The real issue is not the file location but which processes can read
it and where they send the data. That locale could be "on the cloud".
2. What about the pernicious sync adapters from the hoovering outfits?
A. Google, Samsung and other account providers register sync adapters
that copy the local contacts to their servers.
B. This includes backup, deduplication, and "smart" features that
require server side processing.
C. Once synced, the data is stored, replicated, and retained under the
provider's policies. Do you trust them? I don't. Not inherently.
3. What about third-party app access to your contacts list?
A. Any app granted READ_CONTACTS can query the entire address book.
B. Many apps upload the data to their own servers for contact
discovery, spam detection, or analytics.
C. This creates shadow profiles of people who never installed the app
and never consented to any processing. IMHO, that's rude.
4. I think it was Carlos who brought up the EU rules on privacy...
A. Under GDPR the people in our address book are data subjects and we
and the service providers are controllers or joint controllers.
B. Storing a friend's number so we can call them is usually covered by
legitimate interest.
C. Uploading their data to multiple foreign companies for profiling is
a different matter and often outside reasonable expectations.
D. Purpose limitation and data minimization apply even if the user
interface makes the upload look routine.
5. Well then, what are the actual concrete technical risks?
A. Social graph reconstruction for one, in that a full address
book reveals who knows whom and which clusters exist.
B. Metadata enrichment for another, in that phone numbers and emails
can be cross referenced with breach corpora & data broker datasets.
C. Hashing does not really protect phone numbers because the space
is small and predictable so brute forcing is considered trivial.
D. Breach amplification is another domino effect where one compromised
app leaks data about everyone in the user's address book.
E. Centralized storage increases the impact of legal compulsion,
insider access, and mass breaches.
6. However, I openly admit an empty SQLite db is an extreme position.
A. It is true that an empty db cannot be synced or exfiltrated.
B. It is also true that most people want caller ID, messaging, and
search, so they accept some risk.
C. More practical controls include denying READ_CONTACTS to most apps,
disabling cloud sync, or using separate profiles for sensitive work.
7. What about using a private contacts app instead of the system database?
A. Apps like DOpen Contacts store entries in their own private
database, not in the system SQLite contacts provider.
B. This means no third-party app with READ_CONTACTS can see or copy
those entries because the private database is sandboxed.
C. Despite being private, the app still provides full functionality
for calling and texting because Android allows a dialer app to
initiate calls and send SMS without exposing its internal contact
store.
D. The app also maintains its own call log so caller names appear
without ever populating the system contacts database.
E. This gives two advantages at once:
1. Privacy, because nothing is placed into the global SQLite store
that other apps or sync adapters can read.
2. Functionality, because we still get caller ID, call history,
search, and messaging without leaking other people's numbers.
F. The only time the system contacts database must be touched is when
exporting the old contacts to VCF for import into the private app.
G. After import, the system contacts can be deleted and the SQLite
database can remain empty forever if desired.
H. Or, we can poison it with random garbage using FOSS tools
which are designed to randomize the SQLite contacts database
<
https://f-droid.org/en/packages/me.billdietrich.fake_contacts/>
I. This systematic approach avoids the extreme position of having
no contacts at all while still preventing the usual data flows
that leak other people's phone numbers to corporations sans consent.
8. Summary points that, I hope, take into account a reasonable assessment:
A. As Frank pointed out, the SQLite file is not the privacy problem
in and of itself. It is just a local store that sits on the device.
B. The real privacy problem is the chain of sync adapters, third-party
apps, backups and cross-border transfers that copy the data
elsewhere without the knowledge or consent of the people listed in
our address book. In my rule book, that's incredibly rude to do.
C. Any app with READ_CONTACTS can copy the entire address book which
leaks other people's phone numbers to corporations. Privacy is not
only about protecting ourselves, it is also about not exposing
other people's data without permission. And nobody asks permission.
D. Even if Google Contacts sync is disabled, Google Play Services or
OEM layers may re enable it after updates. Call logs are stored
separately so the social graph can still be inferred.
E. Using a private contacts app like DOpen Contacts avoids these data
flows because it keeps entries in a sandboxed database that no
other app can read. It still provides calling, texting, caller ID,
search and call history without ever populating the system contacts
provider. I'm looking at operating systems with a system approach.
F. The only time the system contacts database must be touched is when
exporting old entries to VCF for import into the private app. After
that the system database can be deleted or even poisoned with fake
entries if desired. To me, that's a far better privacy model than
the model that google marketing gave us out of the box for Android.
G. VCF remains the only universal future proof format for contacts. A
contacts app that cannot export or import VCF is not under our
control. A backup method that requires the Internet is even worse.
H. In short the privacy risk is not the SQLite file but the ecosystem
around it. When we grant contact access or enable sync we are not
only deciding for ourselves, we are also volunteering other
people's data into someone else's infrastructure and threat model.
That is rude in my opinion and it is one of the million privacy
issues most people do not know about because they only know five.
--
The interesting part about privacy is that most people know about a half
dozen of the million things you need to know to do to maintain privacy.
--- Synchronet 3.21b-Linux NewsLink 1.2