XPost: comp.mobile.android, alt.privacy   
   From: Jeff@invalid.invalid   
      
   On 07/11/2022 15:38, Andy Burnelli wrote:   
   > Jeff Layman wrote:   
   >   
   >> Other than what you and others have suggested, the problem is it's an   
   >> unknown moving target.   
   >   
   > Hi Jeff,   
   >   
   > I want to learn whatever I can from people like you and Jeff Liebermann!   
      
   I doubt you'll learn anything from me you don't already know, except   
   perhaps to be overcautious and not use your phone for *anything* where   
   you require even the smallest amount of privacy.   
      
   > Yes. Indeed. You are completely correct. We can only protect against what   
   > we already know to be a threat (usually based on a news article or two).   
   >   
   > Hence I agree with your observation that it's not only a "moving" target,   
   > it's a "growing" target, like snowball rolling down the hill on soft snow.   
   >   
   > That's why, I think, we need each other. You know a lot. I know a lot.   
   > Jeff Liebermann knows a lot.   
   >   
   > Lot's of people know a lot more than any one of us.   
   >   
   >> You noticed your unwanted Google account being created from using Gmail   
   >> on the phone.   
   >   
   > Yes Jeff. I noticed this _only_ accidentally, since all of a sudden I had a   
   > Google Account on my phone. WTF? Where'd that come from, I thought. So I   
   > deleted it. And then it came back. That's when I was able to reproduce why.   
   > (Same with Google Voice, or logging into Google Maps, etc., as I recall).   
   >   
   > Some privacy things we notice because they're overt, such as the SSID_nomap   
   > privacy items, but some aren't obvious - such as the fact Wigle does NOT   
   > respect the _nomap request (AFAIK).   
   >   
   > Then you have to come up with things that are NOT obvious, which is why   
   > a.i.w is involved in this thread, since your SOHO router comes into play   
   > with mobile phone privacy. Allow me to outline, briefly, what that's so...   
   >   
   > a. You know about butterfly hash tables so you set your SOHO SSID unique   
   > b. In addition, you know about _nomap (& _optout_) for Google/Mozilla   
   > c. And you know it's not only your SSID but your unique SSN & GPS location   
   > d. Where SSN in here points out that the _AP MAC is unique_ to you alone   
   > e. And no, as Jeff Liebermann knows, that AP MAC can not easily be spoofed   
   > f. So you dutifully set the (already unique) SOHO SSID to append _nomap   
   > g. You "think" that _nomaop prevents it being "uploaded" to Google/Mozilla   
   > h. But (almost) every Android phone _still_ uploads your SSID to the net!   
   > i. WTF? Then you realize, it's on the Google server the _nomap is respected   
   > j. Worse, you find out that Wigle & NetStumbler maybe don't respect _nomap   
   > k. Now what? You think. You ponder. You google. You search.   
   > l. You come up with an idea after testing how Android handles hidden SSIDs   
   > m. What if you make the SSID _hidden_ (i.e., not broadcast) you ponder?   
   > n. You search a bit more and you find it that maybe that will work   
   > o. If you don't broadcast the SSID, then it's NOT uploaded to the net!   
   > p. At least not for most Android phones that don't have Wigle/Netstumbler   
   > q. But a hidden SSID opens up another privacy can of worms, doesn't it.   
   > r. Now you have to set your phone to _look_ for that hidden SSID   
   > s. That means everywhere you go, your phone _broadcasts_ that hidden SSID   
   > t. Yikes! So you set your phone to NOT re-connect after losing signal   
   > u. While you're at it, you set Android 10+ to a random MAC per SSID   
   > v. On Android 11+ Developer options, you set a random MAC per connection   
   > w. So now, when the connection drops, it doesn't ask to reconnect at home   
   > x. But the benefit is it doesn't broadcast your unique SSID outside home   
   > y. You could have accomplished that task with an automated home geofence   
   > z. But that would necessitate location - which is another can of worms!   
   >   
   > Jeff... I ran out of letters, so I'll stop there... but it goes on,   
   > which is your point and which is mine where, I can't help but logically   
   > and rationally reasonably agree with you that it's hard to protect   
   > against what we don't know about...   
      
   Indeed. This is the Android equivalent of Rumsfeld's "unknown unknowns"!   
      
   > But at least we can protect against what we _do_ know about.   
      
   We can try, but, with a moving target we can't always be sure we'll   
   succeed. What is successful today might not work tomorrow.   
      
   >> More to the point is when it's not obvious what Google is   
   >> doing in the background. And, to be fair, it's not only Google.   
   >   
   > Oh indeed!   
   > Take the case of turning on location (which comes after "z" above)!   
   >   
   > How many people know that when Google Maps turns on "location" it uses its   
   > own Google-specific activity which is different from the "normal" location.   
   > Action = ACTION.MAIN (android.intent.action.MAIN)   
   >   Package Name = com.google.android.gms   
   >   Class Name = com.google.android.gms.location.settings.Locati   
   nAccuracyActivity   
   >   Category = CATEGORY.LAUNCHER (android.intent.category.LAUNCHER)   
   >   
   > Every other method to turn on location does _not_ use that - they use this:   
   >   ACTION: "android.intent.action.MAIN"   
   >   PACKAGE: "com.android.settings"   
   >   CLASS: "com.android.settings.Settings$ScanningSettingsActivity"   
   >   
   > They do different things!   
   > Pop Quiz!   
   >   
   > Guess which one turns on lots more privacy losing stuff, Jeff!   
   > C'mon. Guess!   
   >   
   >   C:\> adb shell am start -n com.google.android.gms/.location.   
   ettings.LocationAccuracyActivity   
   >   
   >> I have a   
   >> Huawei phone which, like many manufacturers, runs a modified version of   
   >> Android (particularly so with Chinese phones after their disagreement   
   >> with Google). So what is /that/ version doing in the background? It   
   >> might be different from what Google Android is doing. Let's not forget   
   >> that the hardware is supplied by Huawei too; any "backdoors" in those   
   >> chips? And then, of course, you have the cellphone signal provider.   
   >> Everything goes through them, so if it's unencrypted...   
   >   
   > Yup. We need debugging information.   
   > We can use adb for "some" of that, but the problem I have with adb is that   
   > I don't understand yet how best to cull the output into something usable.   
   >   
   >   C:\> adb shell am start -n com.google.android.gms/.gcm.GcmDiagnostics   
   >        (take a look at the mtalk.google.com traffic, for example)   
   >   
   >> As it's possible to have more than one Google account associated with a   
   >> single cellphone, perhaps jumping between accounts when using the phone   
   >> might cause some confusion at Google HQ (although I'm sure they can work   
   >> their way round that).   
   >   
   > Hmmmmm...... I never thought of having even one account, let alone multiple   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)