Re: How does incoming caller ID work - and more specifically - can caller ID source data be controlled?

On Sat, 6 Jun 2020 13:07:12 +1000, Gary R. Schmidt wrote:

> Please try to be accurate about things.  Saying that an internal door 
> without a lock is insecure when it relies on the external door(s) being 
> lockable only makes you look foolish.

Hi Gary,

Thanks for that purposefully helpful advice...
o Where I'm all about enacting a general purpose working solution.

I don't disagree with you on being more precise about the problem set.
o If you have a _better_ working solution to the problem set, I'm all ears.

Even so, yours is good advice, particularly since we're trying to figure
out how to have an empty default sqlite contacts database and _still_ get
caller id display.

While one possible approach to the problem is to (somehow) "protect" the
default sqlite contacts database, the approach I'm first taking is to
simply eliminate that default sqlite contacts database.

If you, or anyone else, knows how to "protect" that default sqlite contacts
database, I'm all ears, as that would work even better than having an empty
default sqlite contacts database, simply because a _lot_ of important
programs _expect_ the default sqlite contacts database to not be empty.
a. The "Phone app" uses it, by default, to display known contact caller id
b. The "SMS app" uses it, by default, to display known contact caller id
c. Even the "Dialer app" & "Contacts app" use it, by default.

Luckily, I've solved the lack-of-protection problem simply by wiping out
the default sqlite contacts database, and then installing non-Google apps
that don't use that default sqlite contacts database...

But if you have a _better_ working solution to the problem, I'm all ears.
-- 
It takes effort to undo the fact that MARKETING herds us to slaughter.