Why Android Calendar connects to Google without permission and where your Facebook contacts suggestions come from??

It is mentioned in Block Akamai and Google that some Android applications like Calendar, Facebook, "Google Services", etc have very "interesting" behavior: they do not want to be stopped and continue running even after device owner shut them down!

In this post I will illustrate this using Linux packet capture and analysis tool tcpdump.

Here's how you can reproduce my results:

1. go to Privacy menu and make sure "Back up my settings" is unchecked.
This means that you do NOT want device to synchronize your data with Google.

2. connect Android device (I used HTC Wildfire S) to your notebook or workstation.

3. go to Applications and shut down "Calendar", "Calendar Storage", "Calendar Widget", as well as all "Google *" stuff (Gmail, "Google Calendar Sync", "Google Contacts Sync", etc) by clicking "Clear data", which should force stop of the application/service.

4. select "Running" tab of "Applications" and check that Calendar service is not seen there.

5. on your notebook open a console, become a root (or use sudo) and enter this:

# tcpdump -nvSX -i usb0 -Z geo 'net 173.194' -w google-apr30.pcap

this will start packet capture on Google network 173.194.0.0/16, one of three major networks they use, -Z flag drops root privileges for this capture session (not needed if you use "sudo tcpdump")

6. on your notebook set your browser home page to local file so that there's no connectivity to Inet

7. open second console and start Firefox browser along with the netstat command I used in Akamai article:

$ firefox && netstat -tapecn

After a second (or two) Calendar will appear again in "Running" services and tcpdump console will start displaying the number of packets captured on Google network while netstat console will show you that device is trying to connect to Google IP addresses 173.194.32.x using SSH protocol (port 443).

Notice that we've already "stopped" Calendar and our browser is NOT connected to Internet, but to local html file! So it's just a trigger for Droid Calendar to re-appear!

Now all you have to do is wait for 3-4 minutes while they try to establish connections to 11 of their servers.

Second console with netstat is needed exactly for that - you can see HOW they change their servers and stop tcpdump when all Google connections disappear.

Reading file with captured packets can be done from regular user account.
First they try connecting to IP 173.194.32.1:

geo@fermat:~$ /usr/sbin/tcpdump -r google-apr30.pcap
reading from file google-apr30.pcap, link-type EN10MB (Ethernet)
20:49:13.385983 IP 192.168.42.53.41134 > 173.194.32.1.https: Flags [S], seq 3687162654, win 5840, options [mss 1460,sackOK,TS val 112108 ecr 0,nop,wscale 5], length 0
20:49:13.503109 IP 173.194.32.1.https > 192.168.42.53.41134: Flags [S.], seq 2965674502, ack 3687162655, win 14180, options [mss 1400,sackOK,TS val 1033542434 ecr 112108,nop,wscale 6], length 0
20:49:13.625086 IP 192.168.42.53.41135 > 173.194.32.1.https: Flags [S], seq 3684478647, win 5840, options [mss 1460,sackOK,TS val 112168 ecr 0,nop,wscale 5], length 0
20:49:13.722800 IP 173.194.32.1.https > 192.168.42.53.41135: Flags [S.], seq 2973892174, ack 3684478648, win 14180, options [mss 1400,sackOK,TS val 1033542655 ecr 112168,nop,wscale 6], length 0
20:49:13.882937 IP 173.194.32.1.https > 192.168.42.53.41134: Flags [S.], seq 2965674502, ack 3687162655, win 14180, options [mss 1400,sackOK,TS val 1033542815 ecr 112108,nop,wscale 6], length 0
20:49:14.075287 IP 173.194.32.1.https > 192.168.42.53.41135: Flags [S.], seq 2973892174, ack 3684478648, win 14180, options [mss 1400,sackOK,TS val 1033542991 ecr 112168,nop,wscale 6], length 0
20:49:14.483160 IP 173.194.32.1.https > 192.168.42.53.41134: Flags [S.], seq 2965674502, ack 3687162655, win 14180, options [mss 1400,sackOK,TS val 1033543416 ecr 112108,nop,wscale 6], length 0
20:49:14.663915 IP 173.194.32.1.https > 192.168.42.53.41135: Flags [S.], seq 2973892174, ack 3684478648, win 14180, options [mss 1400,sackOK,TS val 1033543591 ecr 112168,nop,wscale 6], length 0
20:49:15.693212 IP 173.194.32.1.https > 192.168.42.53.41134: Flags [S.], seq 2965674502, ack 3687162655, win 14180, options [mss 1400,sackOK,TS val 1033544617 ecr 112108,nop,wscale 6], length 0
20:49:15.863109 IP 173.194.32.1.https > 192.168.42.53.41135: Flags [S.], seq 2973892174, ack 3684478648, win 14180, options [mss 1400,sackOK,TS val 1033544792 ecr 112168,nop,wscale 6], length 0
20:49:16.384907 IP 192.168.42.53.41134 > 173.194.32.1.https: Flags [S], seq 3687162654, win 5840, options [mss 1460,sackOK,TS val 112858 ecr 0,nop,wscale 5], length 0
20:49:16.483355 IP 173.194.32.1.https > 192.168.42.53.41134: Flags [S.], seq 2965674502, ack 3687162655, win 14180, options [mss 1400,sackOK,TS val 1033545413 ecr 112108,nop,wscale 6], length 0
20:49:16.624901 IP 192.168.42.53.41135 > 173.194.32.1.https: Flags [S], seq 3684478647, win 5840, options [mss 1460,sackOK,TS val 112918 ecr 0,nop,wscale 5], length 0
20:49:16.733046 IP 173.194.32.1.https > 192.168.42.53.41135: Flags [S.], seq 2973892174, ack 3684478648, win 14180, options [mss 1400,sackOK,TS val 1033545654 ecr 112168,nop,wscale 6], length 0
20:49:18.808545 IP 173.194.32.1.https > 192.168.42.53.41134: Flags [S.], seq 2965674502, ack 3687162655, win 14180, options [mss 1400,sackOK,TS val 1033547020 ecr 112108,nop,wscale 6], length 0
20:49:18.848424 IP 173.194.32.1.https > 192.168.42.53.41135: Flags [S.], seq 2973892174, ack 3684478648, win 14180, options [mss 1400,sackOK,TS val 1033547192 ecr 112168,nop,wscale 6], length 0
20:49:22.384906 IP 192.168.42.53.41134 > 173.194.32.1.https: Flags [S], seq 3687162654, win 5840, options [mss 1460,sackOK,TS val 114358 ecr 0,nop,wscale 5], length 0
20:49:22.624908 IP 192.168.42.53.41135 > 173.194.32.1.https: Flags [S], seq 3684478647, win 5840, options [mss 1460,sackOK,TS val 114418 ecr 0,nop,wscale 5], length 0
20:49:22.628535 IP 173.194.32.1.https > 192.168.42.53.41134: Flags [S.], seq 2965674502, ack 3687162655, win 14180, options [mss 1400,sackOK,TS val 1033551481 ecr 112108,nop,wscale 6], length 0
20:49:22.928591 IP 173.194.32.1.https > 192.168.42.53.41135: Flags [S.], seq 2973892174, ack 3684478648, win 14180, options [mss 1400,sackOK,TS val 1033551780 ecr 112168,nop,wscale 6], length 0
20:49:22.948482 IP 173.194.32.1.https > 192.168.42.53.41134: Flags [S.], seq 2965674502, ack 3687162655, win 14180, options [mss 1400,sackOK,TS val 1033551822 ecr 112108,nop,wscale 6], length 0
20:49:23.118642 IP 173.194.32.1.https > 192.168.42.53.41135: Flags [S.], seq 2973892174, ack 3684478648, win 14180, options [mss 1400,sackOK,TS val 1033551992 ecr 112168,nop,wscale 6], length 0

Then they make another 20 attempts trying connecting to address 173.194.32.2:

20:49:34.385260 IP 192.168.42.53.37721 > 173.194.32.2.https: Flags [S], seq 4008775003, win 5840, options [mss 1460,sackOK,TS val 117358 ecr 0,nop,wscale 5], length 0
20:49:34.625211 IP 192.168.42.53.37722 > 173.194.32.2.https: Flags [S], seq 4026971235, win 5840, options [mss 1460,sackOK,TS val 117418 ecr 0,nop,wscale 5], length 0
20:49:34.829448 IP 173.194.32.2.https > 192.168.42.53.37721: Flags [S.], seq 3291755311, ack 4008775004, win 14180, options [mss 1400,sackOK,TS val 1033560377 ecr 117358,nop,wscale 6], length 0
20:49:34.959263 IP 173.194.32.2.https > 192.168.42.53.37722: Flags [S.], seq 3301760138, ack 4026971236, win 14180, options [mss 1400,sackOK,TS val 1033560502 ecr 117418,nop,wscale 6], length 0
20:49:35.309539 IP 173.194.32.2.https > 192.168.42.53.37721: Flags [S.], seq 3291755311, ack 4008775004, win 14180, options [mss 1400,sackOK,TS val 1033560819 ecr 117358,nop,wscale 6], length 0
20:49:35.329166 IP 173.194.32.2.https > 192.168.42.53.37722: Flags [S.], seq 3301760138, ack 4026971236, win 14180, options [mss 1400,sackOK,TS val 1033560876 ecr 117418,nop,wscale 6], length 0
20:49:35.869635 IP 173.194.32.2.https > 192.168.42.53.37721: Flags [S.], seq 3291755311, ack 4008775004, win 14180, options [mss 1400,sackOK,TS val 1033561419 ecr 117358,nop,wscale 6], length 0
20:49:35.939243 IP 173.194.32.2.https > 192.168.42.53.37722: Flags [S.], seq 3301760138, ack 4026971236, win 14180, options [mss 1400,sackOK,TS val 1033561476 ecr 117418,nop,wscale 6], length 0
20:49:37.069546 IP 173.194.32.2.https > 192.168.42.53.37721: Flags [S.], seq 3291755311, ack 4008775004, win 14180, options [mss 1400,sackOK,TS val 1033562619 ecr 117358,nop,wscale 6], length 0
20:49:37.129502 IP 173.194.32.2.https > 192.168.42.53.37722: Flags [S.], seq 3301760138, ack 4026971236, win 14180, options [mss 1400,sackOK,TS val 1033562677 ecr 117418,nop,wscale 6], length 0
20:49:37.384904 IP 192.168.42.53.37721 > 173.194.32.2.https: Flags [S], seq 4008775003, win 5840, options [mss 1460,sackOK,TS val 118108 ecr 0,nop,wscale 5], length 0
20:49:37.624908 IP 192.168.42.53.37722 > 173.194.32.2.https: Flags [S], seq 4026971235, win 5840, options [mss 1460,sackOK,TS val 118168 ecr 0,nop,wscale 5], length 0
20:49:37.689411 IP 173.194.32.2.https > 192.168.42.53.37721: Flags [S.], seq 3291755311, ack 4008775004, win 14180, options [mss 1400,sackOK,TS val 1033563235 ecr 117358,nop,wscale 6], length 0
20:49:37.929447 IP 173.194.32.2.https > 192.168.42.53.37722: Flags [S.], seq 3301760138, ack 4026971236, win 14180, options [mss 1400,sackOK,TS val 1033563478 ecr 117418,nop,wscale 6], length 0
20:49:39.529775 IP 173.194.32.2.https > 192.168.42.53.37721: Flags [S.], seq 3291755311, ack 4008775004, win 14180, options [mss 1400,sackOK,TS val 1033565022 ecr 117358,nop,wscale 6], length 0
20:49:39.599622 IP 173.194.32.2.https > 192.168.42.53.37722: Flags [S.], seq 3301760138, ack 4026971236, win 14180, options [mss 1400,sackOK,TS val 1033565077 ecr 117418,nop,wscale 6], length 0
20:49:43.384904 IP 192.168.42.53.37721 > 173.194.32.2.https: Flags [S], seq 4008775003, win 5840, options [mss 1460,sackOK,TS val 119608 ecr 0,nop,wscale 5], length 0
20:49:43.619894 IP 173.194.32.2.https > 192.168.42.53.37721: Flags [S.], seq 3291755311, ack 4008775004, win 14180, options [mss 1400,sackOK,TS val 1033569169 ecr 117358,nop,wscale 6], length 0
20:49:43.625904 IP 192.168.42.53.37722 > 173.194.32.2.https: Flags [S], seq 4026971235, win 5840, options [mss 1460,sackOK,TS val 119668 ecr 0,nop,wscale 5], length 0
20:49:43.939835 IP 173.194.32.2.https > 192.168.42.53.37722: Flags [S.], seq 3301760138, ack 4026971236, win 14180, options [mss 1400,sackOK,TS val 1033569491 ecr 117418,nop,wscale 6], length 0
20:49:44.280415 IP 173.194.32.2.https > 192.168.42.53.37721: Flags [S.], seq 3291755311, ack 4008775004, win 14180, options [mss 1400,sackOK,TS val 1033569824 ecr 117358,nop,wscale 6], length 0
20:49:44.329673 IP 173.194.32.2.https > 192.168.42.53.37722: Flags [S.], seq 3301760138, ack 4026971236, win 14180, options [mss 1400,sackOK,TS val 1033569881 ecr 117418,nop,wscale 6], length 0

And they keep on trying up to IP 173.194.32.9 at which point they jump to IP 173.194.32.14 and when unsuccessful they fall back to IP 173.194.32.0 and then they stop their attempts for a while.

20:52:43.385209 IP 192.168.42.53.55920 > 173.194.32.0.https: Flags [S], seq 2694918729, win 5840, options [mss 1460,sackOK,TS val 164608 ecr 0,nop,wscale 5], length 0
20:52:43.625133 IP 192.168.42.53.55921 > 173.194.32.0.https: Flags [S], seq 2689311440, win 5840, options [mss 1460,sackOK,TS val 164668 ecr 0,nop,wscale 5], length 0
20:52:43.880518 IP 173.194.32.0.https > 192.168.42.53.55920: Flags [S.], seq 1944665748, ack 2694918730, win 14180, options [mss 1400,sackOK,TS val 1033754785 ecr 164608,nop,wscale 6], length 0
20:52:44.430645 IP 173.194.32.0.https > 192.168.42.53.55921: Flags [S.], seq 1964522581, ack 2689311441, win 14180, options [mss 1400,sackOK,TS val 1033755058 ecr 164668,nop,wscale 6], length 0
20:52:44.520344 IP 173.194.32.0.https > 192.168.42.53.55920: Flags [S.], seq 1944665748, ack 2694918730, win 14180, options [mss 1400,sackOK,TS val 1033755241 ecr 164608,nop,wscale 6], length 0
20:52:44.720492 IP 173.194.32.0.https > 192.168.42.53.55921: Flags [S.], seq 1964522581, ack 2689311441, win 14180, options [mss 1400,sackOK,TS val 1033755377 ecr 164668,nop,wscale 6], length 0
20:52:45.290630 IP 173.194.32.0.https > 192.168.42.53.55920: Flags [S.], seq 1944665748, ack 2694918730, win 14180, options [mss 1400,sackOK,TS val 1033755841 ecr 164608,nop,wscale 6], length 0
20:52:45.690638 IP 173.194.32.0.https > 192.168.42.53.55921: Flags [S.], seq 1964522581, ack 2689311441, win 14180, options [mss 1400,sackOK,TS val 1033755977 ecr 164668,nop,wscale 6], length 0
20:52:46.210462 IP 173.194.32.0.https > 192.168.42.53.55920: Flags [S.], seq 1944665748, ack 2694918730, win 14180, options [mss 1400,sackOK,TS val 1033757041 ecr 164608,nop,wscale 6], length 0
20:52:46.384900 IP 192.168.42.53.55920 > 173.194.32.0.https: Flags [S], seq 2694918729, win 5840, options [mss 1460,sackOK,TS val 165358 ecr 0,nop,wscale 5], length 0
20:52:46.420382 IP 173.194.32.0.https > 192.168.42.53.55921: Flags [S.], seq 1964522581, ack 2689311441, win 14180, options [mss 1400,sackOK,TS val 1033757177 ecr 164668,nop,wscale 6], length 0
20:52:46.624890 IP 192.168.42.53.55921 > 173.194.32.0.https: Flags [S], seq 2689311440, win 5840, options [mss 1460,sackOK,TS val 165418 ecr 0,nop,wscale 5], length 0
20:52:46.760380 IP 173.194.32.0.https > 192.168.42.53.55920: Flags [S.], seq 1944665748, ack 2694918730, win 14180, options [mss 1400,sackOK,TS val 1033757853 ecr 164608,nop,wscale 6], length 0
20:52:46.930490 IP 173.194.32.0.https > 192.168.42.53.55921: Flags [S.], seq 1964522581, ack 2689311441, win 14180, options [mss 1400,sackOK,TS val 1033758080 ecr 164668,nop,wscale 6], length 0
20:52:48.270685 IP 173.194.32.0.https > 192.168.42.53.55920: Flags [S.], seq 1944665748, ack 2694918730, win 14180, options [mss 1400,sackOK,TS val 1033759441 ecr 164608,nop,wscale 6], length 0
20:52:48.430549 IP 173.194.32.0.https > 192.168.42.53.55921: Flags [S.], seq 1964522581, ack 2689311441, win 14180, options [mss 1400,sackOK,TS val 1033759577 ecr 164668,nop,wscale 6], length 0
20:52:52.384904 IP 192.168.42.53.55920 > 173.194.32.0.https: Flags [S], seq 2694918729, win 5840, options [mss 1460,sackOK,TS val 166858 ecr 0,nop,wscale 5], length 0
20:52:52.611037 IP 173.194.32.0.https > 192.168.42.53.55920: Flags [S.], seq 1944665748, ack 2694918730, win 14180, options [mss 1400,sackOK,TS val 1033763789 ecr 164608,nop,wscale 6], length 0
20:52:52.624890 IP 192.168.42.53.55921 > 173.194.32.0.https: Flags [S], seq 2689311440, win 5840, options [mss 1460,sackOK,TS val 166918 ecr 0,nop,wscale 5], length 0
20:52:53.011029 IP 173.194.32.0.https > 192.168.42.53.55921: Flags [S.], seq 1964522581, ack 2689311441, win 14180, options [mss 1400,sackOK,TS val 1033764065 ecr 164668,nop,wscale 6], length 0
20:52:53.230937 IP 173.194.32.0.https > 192.168.42.53.55920: Flags [S.], seq 1944665748, ack 2694918730, win 14180, options [mss 1400,sackOK,TS val 1033764242 ecr 164608,nop,wscale 6], length 0
20:52:53.360888 IP 173.194.32.0.https > 192.168.42.53.55921: Flags [S.], seq 1964522581, ack 2689311441, win 14180, options [mss 1400,sackOK,TS val 1033764377 ecr 164668,nop,wscale 6], length 0
geo@fermat:~$

In a second packet capture session you can see them trying connecting to same IPs but in a different order: first 173.194.32.9, then 173.194.32.14, then 173.194.32.0 to 173.194.32.8.

Suppose you started browser without stopping all those ever running services?
Here's what you are going to see in the output of netstat:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      0          5900        -               
tcp        0      0 192.168.42.220:24234    63.245.217.161:443      TIME_WAIT   0          0           -               
tcp        0      1 192.168.42.220:21020    173.194.71.103:80       SYN_SENT    1000       18766       2308/firefox-bin
tcp        1      0 192.168.42.220:52085    72.51.46.230:80         CLOSE_WAIT  1000       18809       2308/firefox-bin
tcp        0      0 192.168.42.220:61450    87.248.122.122:80       ESTABLISHED 1000       18771       2308/firefox-bin
tcp        1      0 192.168.42.220:52081    72.51.46.230:80         CLOSE_WAIT  1000       18769       2308/firefox-bin
tcp        0      0 192.168.42.220:24233    63.245.217.161:443      TIME_WAIT   0          0           -               
tcp        0      0 192.168.42.220:12549    91.198.174.225:80       ESTABLISHED 1000       18770       2308/firefox-bin
tcp        0      0 192.168.42.220:30908    72.21.214.128:80        ESTABLISHED 1000       18767       2308/firefox-bin
tcp        0      0 192.168.42.220:17076    66.211.181.161:80       ESTABLISHED 1000       18768       2308/firefox-bin
tcp        0      0 192.168.42.220:32550    67.196.156.65:80        ESTABLISHED 1000       18772       2308/firefox-bin
^C

Apart from Google (173.194.71.103) you are going to get connected to Yahoo (87.248.122.122), eBay (66.211.181.161), Net Access Coproration/Answers.com (67.196.156.65), Amazon.com (72.21.214.128), Wikimedia (91.198.174.225) and more.

Here is list of some of Google IP ranges that I came across in process of blocking their numerous hacking attempts, along with iptables and Apache .htaccess rules you may use to block Cyber Bolsheviks:

deny from 35.208.0.0/12
deny from 35.240.0.0/13
deny from 35.224.0.0/12
. 
 iptables -A INPUT -s 35.192.0.0/12 -j DROP
 iptables -A INPUT -s 35.184.0.0/13 -j DROP

 iptables -A INPUT -s 64.233.160.0/19 -j DROP
 iptables -A INPUT -s 66.249.64.0/19 -j DROP

 iptables -A INPUT -s 72.14.192.0/18 -j DROP

 iptables -A INPUT -s 104.132.0.0/14 -j DROP
 iptables -A INPUT -s 104.154.0.0/15 -j DROP
 iptables -A INPUT -s 104.196.0.0/14 -j DROP
 iptables -A INPUT -s 108.177.0.0/17 -j DROP

 iptables -A INPUT -s 130.211.0.0/16 -j DROP
 iptables -A INPUT -s 136.32.0.0/11 -j DROP

 iptables -A INPUT -s 172.217.0.0/16 -j DROP
 iptables -A OUTPUT -s 172.217.0.0/16 -j DROP

 iptables -A INPUT -s 173.194.0.0/16-j DROP
 iptables -A OUTPUT -s 173.194.0.0/16 -j DROP

 iptables -A INPUT -s 192.178.0.0/15 -j DROP

 iptables -A INPUT -s 216.58.192.0/19 -j DROP
.

It might be a good idea to add OUTPUT rule for every Google IP range on the list above, just to be on the safer side!

All this "connectivity" happens without user permission or knowledge!

The end result:

  1. data traffic between device and external networks for which device owner effectively pays his/her mobile operator

  2. violation of device owner privacy and (very likely) compromized personal data

SECOND and much simpler experiment is this:

Create new Facebook profile using some name that is NOT popular in the part of the world you are living in.

For example, if you are based in Americas, you can try names like Vasily Chapaev or Petka (anecdotal personalities from post Bolshevik Civil war in Russia). And when you create new account try using mobile phone option given by Facebook!

After you first login into your new account you may be VERY SURPRIZED to know that Facebook somehow recognized the names of the people from your region who are your REAL contacts!

HOW on Earth could they do that?

Answer: Read about Droid Calendar "strange" behavior above and those "data synchronization sessions" Google quietly conducts using Android mobile CLOSED source components and SSL secure data transfer protocol!

They simply "extract" people data from mobile devices together with ALL PRIVATE DATA people store on their mobiles! And then Facebook (Google company), as well as North American/Israel security services use your data!!!

LATEST NEWS: On November 11, 2017 I posted news about my new Rational Points generation ABC algorithm and Elliptic Curve Applet version 7.0 which implements it, on my Facebook profile (using pseudo - name) and then shared it on Mathematics group for approval.

The reaction was QUITE INTERESTING!

Soon after sharing my post I noticed more than a dozen visits from FB IPs 173.252.124.{71,22,234,71} and from 173.252.{100.208, 88.250, 124.234}. Later same day I noticed a visit from IP 89.27.101.109 (central Helsinki?).

Finally after loggin into FB and checking status of my post (pending approval) I was offered, for no good reason(!), to verify my identity (while still being logged in). Several attempts to use 5 or 6 verification numbers they sent me over sms failed, always suggesting "try later".

On Sunday 12 November 2017, I noticed that my profile (R... T....) did NOT show up in search or when using direct URL! They have simply blocked my access to my own profile!!!

Sharing research infomation about Rational Points on Elliptic Curve is a CRIME in Bolsheviks ruled USA???
It certainly looks so!

All this means that Bloody Satanic Bolsheviks have already taken over USA and are preparing American version of 1917 in Russia and RED TERROR for North America (USA and Canada).

Dear fellow North Americans! Your freedoms and democracy are in GREAT DANGER!
Get United and Never give up your ARMS and RIGHTS and FREEDOMS!!!

RED DEVIL is knocking on your door!

Summary:

Calendar is one of the key Android applications and has access to key user information: contacts, email accounts, events, location, emails, messages, etc as well as device global system settings, storage, hardware controls, etc.

What exactly they are trying to "synchronize" with Google internal database is an open question (unless you want to dig into SSH), but potentially all user private information like contacts, passwords, bank PIN codes people store on their SIM cards etc, could end up on the other end of cryptographically protected connection.

The fact that Android simply ignores user demands to stop applications and services like Calendar, "Google Services", Facebook, Maps, etc is really quite telling.

It is hard to believe that this is a technical negligence or a "bug". Clearly this is done by design to maximize traffic between droid device and social networks and increase Google's revenue based on advertizing on those networks.

And user's personal information "leakage" is another "side-effect"(or goal?) of Android unstoppable services and synchronizations.

According to Intellipedia article on Wikipedia Google servers and software enables US spy agencies CIA and NGA integration of social networks into their daily activities.

That is why I call applications and services ignoring user input "spider-ware", not soft-ware.

The only way user of Android device can stop such application is by becoming a "root" and removing those closed source application!
Given technical difficulty of such operation (it involves several steps and requires at least "some" Linux/Unix skills) and risk to "brick" the device, it is very unlikely that average Android user will be able to accomplish this.

All of the above as well as previously *documented* attempts by Google to "sniff" private information without permission from WiFi networks in Germany:

and cheating on customers using Safari browser cookies (see my blog item here) make me think that recommendations in my article "Block Akamai and Google" are correct.

Technologies change but Bolsheviks genes are still the same and will always try

to achieve the same paranoid goals as previous generations of the VIRUS, this time using cyber space.

P.S. Java/Linux platform provides excellent opportunities for development. But there is one "tiny" problem with Googles implementation of it:"google boys" and their Bolshevik heritage and practices.