XPost: comp.mobile.android, alt.comp.freeware   
   From: jj4public@vfemail.net   
      
   On Wed, 3 Jun 2020 17:28:59 -0000 (UTC), Arlen Holder wrote:   
   >   
   > I _still_ can't tell from your answer whether you're aware of them.   
   > o Are you?   
   >   
   > Note: It doesn't matter to the question whether you're aware of them; but   
   > you were responding to a known ignorant troll with the line:   
   >  "> Because sqlite databases on your phone aren't private, Arlen?   
   >  "It's not, if one has something to hide."   
   >   
   > Usenet is useful for purposefully helpful adults...   
   > o That's two things: (a) purposefully helpful, and (b) adults.   
   >   
   > You were responding to a troll who is not an adult, which isn't important   
   > because that troll is clearly ignorant of the sqlite privacy holes.   
   >   
   > I don't care about that ignorant troll... but I do care about you.   
   >   
   > Assuming you're (a) purposefully helpful, and (b) an adult...   
   > o I simply ask you a single question which is relevant to your post:   
   >   
   > Q: Are you aware of the known sqlite privacy holes, JJ?   
   >   
   > NOTE: If you are, then why did you respond the way you did to the troll?   
   > If not, then all I ask is you try to _understand_ them; that's all.   
      
   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.   
      
   I don't label non adults as trolls, because even adults can be trolls too.   
   In fact, adults can be worse. What I do label are trash of society - no   
   matter how old they are, what gender are they, or what rank/occupation they   
   have. Those who never contribute to the community and don't care about their   
   surroundings. I do believe that people are mostly good in nature, so with   
   caution, I put trust on people first, even though I don't yet know enough   
   their behavior.   
      
   > And _then_, we can get back to the TOPIC of this thread, which is:   
   > Q: How does incoming caller ID work - and more specifically - can caller ID   
   > source data be controlled?   
   >   
   > Note this is a TECHNICAL question which affects multiple cascaded levels:   
   > 1. carrier CNI information   
   > 2. sqlite db contacts lookup   
   > 3. caller id app interception   
   > 4. personal privacy database lookup   
   >   
   > The goal is to freely attain caller ID display _without_ #2 above.   
   > o That's a technical question which the trolls can't possibly help with.   
      
   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.   
      
   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.   
      
   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.   
      
   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.   
      
   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   
   [2] the current (default) SMS application doesn't provide any plugin API for   
   third party applications. For caller ID, neither the Telephony or the Phone   
   applications provide any plugin API for third party applications.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)