XPost: alt.comp.os.windows-10, comp.mobile.android, misc.phone.mobile.iphone   
   From: marianjones@helpfulpeople.com   
      
   Marian wrote:   
   > If no client ever sends out a directed probe request, then the SSID will   
   > never be found in any packet that can be sniffed by any nearby scanner.   
      
   Now we need to look at what frames the random iOS/Android phone scans.   
      
   We need to keep in mind that collecting client frames and subsequent   
   Client/AP association traffic would expose user behavior (when/where   
   someone connects) which would be a privacy violation.   
      
   On each channel that the AP is set to be on...   
   a. beacon frame (AP sends out every 100ms, does not contain a hidden SSID)   
   b. wildcard probe request (client request will not contain the hidden SSID)   
   b. directed probe request (client request will contain the hidden SSID)   
   c. wildcard probe response (AP response will not contain the hidden SSID)   
   c. directed probe response (AP response will contain the hidden SSID)   
   d. association request (client request will contain the hidden SSID)   
   e. association response (AP response will contain the hidden SSID)   
      
   We have to assume, logically (if not legally) that Apple/Google rely on   
   a. beacon frame (AP sends out every 100ms, does not contain a hidden SSID)   
   c. wildcard probe response (AP response will not contain the hidden SSID)   
   c. directed probe response (AP response will contain the hidden SSID)   
   Because, we may assume, collecting client frames and access-point   
   association frames would likely raise huge privacy/security concerns.   
      
   So there are only three ways for a random phone to learn your SSID:   
   1. The random phone can passively listen to AP beacon frames   
   2. The random phone can passively listen to AP probe responses   
   3. The random phone can itself actively send a wildcard probe request   
      (to which the AP will respond but without the hidden SSID included)   
   The random phone can hear client activity and association activity, but we   
   must assume Google/Apple do not collect them for legal/privacy reasons.   
      
   In summary, what Apple/Google WPS most likely rely on are   
   a. AP beacons (AP broadcast every 100ms or so but the SSID is hidden)   
   c. AP probe responses (wildcard or directed)   
   Where the hidden SSID is only contained in directed AP probe responses once   
   per connection.   
      
   Given that reality check, if your phone is set to not automatically   
   reconnect, and if your access point is set to hidden, the "window" that a   
   random iOS/Android phone has to sniff out your SSID is vanishingly small.   
      
   The only time your SSID is in any of the access point packets is at the   
   time of the initial connection, which could have happened a month ago.   
      
   So the question that needs to be answered given that even if the SSID is   
   hidden, the BSSID + channel + RSSI + GPS + timestamp are still available in   
   the access point beacons and probe responses, what is Google/Apple policy   
   for how they have set, by default, the random iOS/Android phone to do?   
      
   Do they follow Mozilla precedent to NOT "collect" BSSIDs of hidden APs?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)