Replicant

I've not yet succeeded at getting a network trace of the issue but I've probably found where it comes from:

There is a stock application called 'phone' (probably also called dialer). In it there is a field with "Enter a name or phone number" and 3 dots on the right.

• Call History
• Import/export
  [...]
• Settings

• Display options
  [...]
• Phone number lookup "Loopup of unknown phone numbers"
  [...]

• "WhitePages (US)" as People lookup provider
• Google as Forward lookup provider
• "OpenCnam (US)" as reverse lookup provider

And All are activated!

• Find a way to trigger them to be able to test if they are disabled later
• Disable them by default and force the disabled defaults when settings are wiped for a reason or another
• Verify that they are really disabled by network traces and/or looking at the source code

Simply typing 0102030405 in the dialer form result in DNS querries to whitepages.com

I obtained the log by disabling orbot (force stop) on the smartphone and connecting it to a WiFi access point I made with hostapd on my laptop with a simple script to share the connection (https://framagit.org/GNUtoo/simple-nat), and the following extra dnsmasq configuration (added to dnsmasq.conf.local) to trace DNS querries:

log-queries=extra

This gave the following log (other queries removed):

dnsmasq: 13 192.168.10.246/27181 query[A] whitepages.com from 192.168.10.246
dnsmasq: 13 192.168.10.246/27181 forwarded whitepages.com to 192.168.10.3
dnsmasq: 13 192.168.10.246/27181 forwarded whitepages.com to 192.168.10.1
dnsmasq: 16 192.168.10.246/27181 query[A] whitepages.com from 192.168.10.246
dnsmasq: 16 192.168.10.246/27181 forwarded whitepages.com to 192.168.10.3
dnsmasq: 16 192.168.10.246/27181 forwarded whitepages.com to 192.168.10.1
dnsmasq: 18 192.168.10.246/28925 query[A] whitepages.com from 192.168.10.246
dnsmasq: 18 192.168.10.246/28925 forwarded whitepages.com to 192.168.10.3
dnsmasq: 18 192.168.10.246/28925 forwarded whitepages.com to 192.168.10.1
dnsmasq: 19 192.168.10.246/8626 query[A] whitepages.com from 192.168.10.246
dnsmasq: 19 192.168.10.246/8626 forwarded whitepages.com to 192.168.10.3
dnsmasq: 19 192.168.10.246/8626 forwarded whitepages.com to 192.168.10.1
dnsmasq: 20 192.168.10.246/30252 query[A] whitepages.com from 192.168.10.246
dnsmasq: 20 192.168.10.246/30252 forwarded whitepages.com to 192.168.10.3
dnsmasq: 20 192.168.10.246/30252 forwarded whitepages.com to 192.168.10.1
dnsmasq: 21 192.168.10.246/30431 query[A] whitepages.com from 192.168.10.246
dnsmasq: 21 192.168.10.246/30431 forwarded whitepages.com to 192.168.10.3
dnsmasq: 21 192.168.10.246/30431 forwarded whitepages.com to 192.168.10.1
dnsmasq: 22 192.168.10.246/32041 query[A] whitepages.com from 192.168.10.246
dnsmasq: 22 192.168.10.246/32041 forwarded whitepages.com to 192.168.10.3
dnsmasq: 22 192.168.10.246/32041 forwarded whitepages.com to 192.168.10.1
dnsmasq: 24 192.168.10.246/30431 query[A] whitepages.com from 192.168.10.246
dnsmasq: 24 192.168.10.246/30431 forwarded whitepages.com to 192.168.10.3
dnsmasq: 24 192.168.10.246/30431 forwarded whitepages.com to 192.168.10.1
dnsmasq: 25 192.168.10.246/28925 query[A] whitepages.com from 192.168.10.246
dnsmasq: 25 192.168.10.246/28925 forwarded whitepages.com to 192.168.10.3
dnsmasq: 25 192.168.10.246/28925 forwarded whitepages.com to 192.168.10.1
dnsmasq: 26 192.168.10.246/8626 query[A] whitepages.com from 192.168.10.246
dnsmasq: 26 192.168.10.246/8626 forwarded whitepages.com to 192.168.10.3
dnsmasq: 26 192.168.10.246/8626 forwarded whitepages.com to 192.168.10.1
dnsmasq: 27 192.168.10.246/30252 query[A] whitepages.com from 192.168.10.246
dnsmasq: 27 192.168.10.246/30252 forwarded whitepages.com to 192.168.10.3
dnsmasq: 27 192.168.10.246/30252 forwarded whitepages.com to 192.168.10.1
dnsmasq: 28 192.168.10.246/32041 query[A] whitepages.com from 192.168.10.246
dnsmasq: 28 192.168.10.246/32041 forwarded whitepages.com to 192.168.10.3
dnsmasq: 28 192.168.10.246/32041 forwarded whitepages.com to 192.168.10.1

Just curious, could this have anything to do with the fact that the USSD caller ID thing referenced here hasn't been implimented? https://redmine.replicant.us/issues/1011#note-10

I've no idea:
- I didn't look deep enough at the related dialer code
- I didn't have time to get (and analyze) more conclusive traces about the communication with such third party services.

Having a look at
packages/apps/Dialer/res/xml/lookup_settings.xml
shows that indeed the default value of all three settings is set to "false" (attribute android:defaultValue="false")

e.g.:

<SwitchPreference
        android:key="enable_reverse_lookup" 
        android:title="@string/enable_reverse_lookup_title" 
        android:summary="@string/enable_reverse_lookup_summary" 
        android:defaultValue="false" 
        android:persistent="false" />

But I can confirm that, in a fresh clean Replicant 6.0 install, all three settings are switched on by default in the mentioned menu (Phone-> [searchbar] -> Settings -> Phone number lookup)

It will be interesting to find where the default "off" value is overridden in the code or in the build/installation process..
I'm having a look into it right now..

The underlying database file related to phone number lookup settings is

/data/data/org.cyanogenmod.cmsettings/databases/cmsettings.db

Effectively, lookup settings are set to "true" in the database:
This is the result of running a query on a fresly-installed Replicant 6.0 image, after clearing data and cache.

1|root@i9300:/data/data/org.cyanogenmod.cmsettings/databases # sqlite3 cmsettings.db                                         
SQLite version 3.8.10.2 2017-07-21 04:08:41
Enter ".help" for usage hints.
sqlite> .tables
android_metadata  global            secure            system          
sqlite> select * from system
   ...> ;
1|qs_quick_pulldown|1
2|notification_light_brightness_level|255
3|notification_light_multiple_leds_enable|0
5|enable_forward_lookup|1
6|enable_people_lookup|1
7|enable_reverse_lookup|1
8|notification_light_pulse_custom_enable|0
9|swap_volume_keys_on_rotation|0
10|status_bar_battery_style|2
11|volume_adjust_sounds_enabled|1
12|system_profiles_enabled|1
13|display_color_adjustment|1.0 1.0 1.0
14|live_display_hinted|-2
15|edge_service_for_gestures|0

Relevant values are "enable_forward_lookup", "enable_people_lookup", "enable_reverse_lookup".
I can confirm that setting the values to "0" in the SQLite database results in the settings being switched off in the Phone GUI.
It remains to be tested whether disabling this settings actually prevents lookup queries (this should be trivial using the testing setup proposed by Denis).

Also, we need to know exactly WHEN and WHERE the default database file is generated during the build/installation/initial-configuration process.
Changing the default values should be trivial after that.

Does anybody have any clue about that???

Default values seem to be defined in

vendor/cmsdk/packages/CMSettingsProvider/res/values/defaults.xml

and they are indeed set to "True" by default:

    <!-- Default value of CMSettings.System.ENABLE_FORWARD_LOOKUP -->
    <integer name="def_forward_lookup">1</integer>

    <!-- Default value of CMSettings.System.ENABLE_PEOPLE_LOOKUP -->
    <integer name="def_people_lookup">1</integer>

    <!-- Default value of CMSettings.System.ENABLE_REVERSE_LOOKUP -->
    <integer name="def_reverse_lookup">1</integer>

This means that if we set them to "0" by default, the lookup "anti-features" should be disabled by default on first boot and until the user decides to switch them on. Furthermore, a factory reset is expected to restore these default values, and switch off lookup again.

I think I can come up with a patch in a few days.

I've conducted some deeper testing, both by debugging and by collecting network traces with wireshark and I can confirm that connections to third parties are only present when the lookup features are enabled in the settings.

This is how I tested it:
(Warning: long read ahead. Who's not interested in the full technical analysis can jump to Conclusions)

Debugging the source code:¶

It is quite difficult to manually perform static analysis to track down the precise path of code execution in the Dialer app, as in many other parts of the AOSP tree, because of all the asynchronous "callbacks", "providers", "handles" involved in the android-ish programming model and because of the lack of specific documentation for the mechanisms that are implemented in the miriad of classes, subclasses, fragments...
TL;DR: Android is a mess.

By the way, debugging the running code is not easy either, but it's a lot quicker to track the execution path this way..

All relevant code is at *packages/apps/Dialer/src/com/android/dialer/lookup*
Relevant classes are the generic *ForwardLookup*, *PeopleLookup*, *ReverseLookup* and all the children classes, specific to each provider (Google, OSM, WhitePages, Auskunft, etc.)

The settings about lookup services are managed by *LookupSettings*, and specifically these getters are accessed to retrieve the status of what service is enabled/disabled:

LookupSettings::isForwardLookupEnabled()
LookupSettings::isPeopleLookupEnabled()
LookupSettings::isReverseLookupEnabled()

When the Dialer's searchbar gets focus, a *PhoneNumberListAdapter* is instantiated which in turn initializes contacts lookup "directories", both "local" and "remote" (local directories are the ones in the contacts database, while remote ones are provided by the remote lookup services we're investigating).

PhoneNumberListAdapter.java:161 calls:

mExtendedDirectories = manager.getExtendedDirectories(mContext);

which is implemented at ExtendedLookupDirectories.java:40 and reads as follows:

        ArrayList<DirectoryPartition> list = new ArrayList<DirectoryPartition>();

        // The directories are shown in reverse order, so insert forward lookup
        // last to make it show up at the top

        if (LookupSettings.isPeopleLookupEnabled(context)) {
            DirectoryPartition dp = new DirectoryPartition(false, true);
            dp.setContentUri(LookupProvider.PEOPLE_LOOKUP_URI.toString());
            dp.setLabel(context.getString(R.string.people));
            dp.setPriorityDirectory(false);
            dp.setPhotoSupported(true);
            dp.setDisplayNumber(false);
            dp.setResultLimit(3);
            list.add(dp);
        } else {
            Log.i(TAG, "Forward lookup (people) is disabled");
        }

        if (LookupSettings.isForwardLookupEnabled(context)) {
            DirectoryPartition dp = new DirectoryPartition(false, true);
            dp.setContentUri(LookupProvider.NEARBY_LOOKUP_URI.toString());
            dp.setLabel(context.getString(R.string.nearby_places));
            dp.setPriorityDirectory(false);
            dp.setPhotoSupported(true);
            dp.setDisplayNumber(false);
            dp.setResultLimit(3);
            list.add(dp);
        } else {
            Log.i(TAG, "Forward lookup (nearby places) is disabled");
        }

        return list;

by which, it is evident that when remote lookup services are disabled in the settings no "remote lookup directory" is added to the list, so that subsequent searches are only performed on the local contacts database.

When lookup services are enabled, the actual remote queries are performed via HTTP requests to specifically created URLs, that are crafted based on the text the user types in the search bar. These requests originate from each specific implementation of the following abstract methods:

ForwardLookup.lookup(Context, String, Location)
ReverseLookup.lookupNumber(Context, String, String)
PeopleLookup.lookup(Context, String);

To confirm this, I put breakpoints on all specific implementations of the lookup methods and tried different settings.

1) Reverse Lookup only works when receiving incoming calls, so I didn't have a quick way to actively test it.
But the following lines at ReverseLookupService.java:60 indicate pretty clearly that no query is performed when the service is disabled:

        if (!LookupSettings.isReverseLookupEnabled(mContext)) {
            LookupCache.deleteCachedContacts(mContext);
            return;
        }

2) When only Forward Lookup is enabled queries are only performed if Location services are enabled, and if the location of the device is known.

3) When People Lookup is enabled queries are always performed, regardless of any other setting; when any string is typed in the Dialer's search bar, the breakpoint at the specific lookup method implementation is always hit.
For example, when using Auskunft as a People lookup provider, this lines in *AuskunftPeopleLookup* are always executed:

    public ContactInfo[] lookup(Context context, String filter) {
        List<ContactInfo> infos = null;
        try {
            infos = AuskunftApi.query(filter, ContactBuilder.PEOPLE_LOOKUP, null, null);
        } catch (IOException e) {
            Log.e(TAG, "People lookup failed", e);
        }
        return (infos != null && !infos.isEmpty())
                ? infos.toArray(new ContactInfo[infos.size()]) : null;
    }

which results into calling *AuskunftApi*, that finally performs the actual HTTP request:

        // get all search entry sections
        List<String> entries = LookupUtils.allRegexResults(LookupUtils.httpGet(uri.toString(),
                null), SEARCH_RESULTS_REGEX, true);

4) When both People Lookup and Forward Lookup are disabled, the execution of the Dialer app does never reach any of the aforementioned instructions, which is pretty much a guarantee that no remote connection is made when all lookup services are disabled in the settings.

To further confirm, I went even further and captured some network traces:

Analysis of Network activity:¶

I put up the testing environment described by GNUtoo, connecting my i9300 to my laptop's WiFi hotspot.
I then captured the network traffic of my laptop's wlan interface using Wireshark, while using the Dialer's app search bar on the i9300, with different combinations of Lookup Settings.
This is what I registered:

1) When lookup services are all disabled in the settings, the only network activity present consist of NTP queries, and no TCP connection is made to any host whatsoever.

2) When People Lookup is enabled and uses WhitePages as provider, some TCP traffic is generated towards this IP address: 54.201.217.74, which resolves to "whitepages.com"

3) When People Lookup is enabled and uses Auskunft as provider, some TCP traffic is generated towards this IP address: 91.195.199.133, which resolves to "auskunft.at"

I did not test Forward and Reverse lookup, for the reasons mentioned above, but it seems reasonable to suppose they would show analogous behaviour.

Conclusions:¶

All the tests I performed clearly indicate that no network activity is generated to any third party host when all lookup anti-features are disabled in the settings.
It is otherwise proved that enabling phone number lookup results in silent background connections to online services, exposing users' searches in their own contact list to third parties.

All this being said, my personal opinion is that simply disabling those services via the settings is to be considered safe enough for the users' privacy, and that there's no strong motivation to completely remove them from Replicant.