From: mariasophia@comprehension.com   
      
   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.  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.   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)