XPost: comp.mobile.android, alt.comp.freeware   
   From: arlenholder@newmachine.com   
      
   On Fri, 5 Jun 2020 12:23:46 +0700, JJ wrote:   
      
   > Yes, I do aware of privacy problem of SQLite database. It's the same problem   
   > most other database formats have. But for SQLite, the term "privacy/security   
   > hole" is not applicable, because it doesn't even have any (native) security   
   > feature in the first place.   
      
   Hi JJ,   
      
   Much appreciated your clarification as I'm well aware of the dangers of   
   trying to help someone on Usenet, where Usenet takes particular patience   
   since we have to infer "intent" with "sublety" from the written word.   
      
   Hence I thank you for patiently explaining that you know about the sqlite   
   db privacy flaws as my goal, always, is to create a general purpose   
   solution (by definition, which is free) that anyone can use, which is why   
   I've written, oh, I can't count them, many tutorials on the net so that   
   others may follow.   
      
   I'm likely the only one you've ever met who has an empty sqlite db. :)   
   o But, there _are_ apps that understand the need (e.g., Simple Contacts).   
      
   So I'm not the only one out there who wants his contacts to remain private.   
      
   Since I'm always about helping others in everything that I do...   
   o I'm hoping, in the end, to have a tutorial for privacy based contacts.   
      
   As long as _you_ are aware that there _are_ privacy issues with the default   
   sqlite database, we don't have to waste any more time on that question.   
      
   While you brought up _other_ privacy issues with the default contacts   
   sqlite db, the key privacy issue I see, is that the instant you use a   
   Google App, such as GMail, it _insists_ on uploading that sqlite contacts   
   database, whether you like it or not. From my tests, it doesn't matter   
   _what_ you want or what you set up; it will do it anyway (I have a thread   
   on that somewhere).   
      
   Given I don't test all Google Apps (e.g., the Google messenger & Dialer and   
   Google Voice, and Hangouts, etc., I just can't _trust_ any Google app once   
   I found that out, by experience) - so I don't use Google apps - but I'm   
   still trying to solve the general purpose issue for everyone - where my   
   solution has to take into account _other_ people use Google apps.   
      
   So the _only_ private sqlite contacts database is an _empty_ one, IMHO.   
      
   That should be fine on Android since it's "just" a file; but it's a file   
   that some SMS/Phone/Contact/Mail apps default to, which is why I choose and   
   set up my apps to not use that default sqlite contacts database.   
      
   I pretty much have it all working fine except that the caller ID display   
   isn't coming through, but I haven't tested yet the Internet-based caller-id   
   programs, where my hope is to find one that allows me to manage its own   
   on-the-phone lookup table.   
      
   The fact is that these caller-id apps, if they work, must "intercept" the   
   caller ID information somewhere in this four-step chain:   
   1. First the carrier supplies a caller ID (mine doesn't do that for free)   
   2. Then the default sqlite contacts database supplies a caller id   
   3. Then, I think, the caller-id apps can intercept this caller-id display   
   4. And, lastly, I hope to find a "dialer" that has its own caller id db.   
      
   > First of all, you should know that SQLite database doesn't support native   
   > encryption. Yes, an SQLite can have encrypted data, but _only_ if the SQLite   
   > database engine is custom built with encryption in mind.   
      
   This is good to know, as I'm always seeking a general-purpose privacy-based   
   solution that is freely available, where, in the future, instead of   
   designing a system with an "empty" sqlite db, maybe an encrypted one might   
   be better - where the goal is, mostly, to hide from Google apps   
   automatically grabbing this information and uploading it to the net.   
      
   To be clear, I think it should be a criminal offense, punishable by death,   
   whenever someone uploads my contact information, and that of my kids and   
   their kids, to the net, without asking for my permission (which I would   
   never give them).   
      
   I think as a substitute for a simple death by hanging on the yardarms,   
   drawing and quartering would be appropriate for this offense of uploading   
   _my_ private contact data to the Internet without my permission.   
      
   If they simply promise to empty out their sqlite database, then I would   
   likely petition the governor to grant them a reprieve. :)   
      
   > What I know is that, In Android, contact list is owned and managed by the   
   > Contacts Storage (system) application. If you want a secure contact list,   
   > that application will need to be replaced.   
      
   I think that's a good solution, if I can find it, but in the meantime,   
   there's a workaround of simply having an _empty_ sqlite contacts database.   
      
   > As for caller ID, that is to altering the caller ID data, or even removing   
   > the caller ID from the remote call event; outside of the system components,   
   > everything is handled by a telephony system application which I'm not yet   
   > sure exactly which one. But whichever that is, it needs to be replaced.   
      
   This is understood, that "some" telephony application is "intercepting" the   
   caller-id information from one or more of four currently identified   
   locations:   
   1. The cid information from the carrier (mine is empty)   
   2. The cid information in the contacts sqlite db (mine is empty)   
   3. The cid information inherent in these cid-display apps (untested by me)   
   4. The cid information in the "telephony" app itself (untested by me).   
      
   I'll attempt to solve #3 but I'm working on a ton of other issues, e.g.,   
   o *Is there freeware extent to convert Win10S to Win10H WITHOUT enabling the   
   Win10S laptop Wi-Fi?*   
      
      
   > Third party applications, whether it's installed as system applications or   
   > not, can not simply "plugs in" and intercept core events. That's a big   
   > security hole. The only way to "intercept" the events is to replace the   
   > applications which receive the events themselves.   
      
   This is good to keep in mind, where I have no problem with an empty sqlite   
   contacts database in getting PulseSMS to identify contacts (after the   
   fact), and I have no problem searching a non-sqlite contacts vcard file to   
   initiate calls using SimpleMobileTools' SimpleContacts and/or SimpleDialer.   
      
   Given I almost never fail, and yet, the _only_ major problem I haven't   
   resolved yet is the caller-id display, that's why I'm focusing on how   
   caller-id works.   
      
   Once I better understand how it works, I can better come up with a general   
   purpose freeware solution that everyone can then benefit from.   
      
   > It's a similar case to why there is no third party application that can   
   > filter/block SMS or Class 1 SMS (i.e. popup SMS) messages while preserving   
   > the current (default) SMS application. Mainly because [1] the current   
   > Android architecture doen't provide the needed interception mechanism; and   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)