How Google Nearby (really) works – and what else it does?
First rumors of Google Nearby appeared early June 2014 and many expected an announcement at Google I/O a few weeks later. Two Google I/Os later, it is finally out! So how does Google Nearby (really) work? And what data you have to give away to Google to make it work?
Nearby has two main APIs: Nearby.Connections and Nearby.Messages. Nearby.Connections allows the discovery of devices connected to be on the same Wi-Fi network using multicast packets sent over the access point. Nearby.Messages doesn’t require devices to be on the same Wi-Fi network. Instead, it uses various ad hoc radio technologies to broadcast a random token others can listen to. It does, however, require both devices to have their screen awake and to be online in order to work and we’ll see why next. In this post, we’ll only focus only on Nearby.Messages.
We are going to illustrate how Nearby.Messages works through the example above of an iPhone (left) discovering an Android (right). Messages works in five steps: first, the iPhone registers online to the Google Cloud providing the token it will advertise, here “TA” (step 1). At the same time, it can publish tagged data, the other devices will get upon discovery, here, its name “iPhone6” with the tag “name”. In order to get this data, the Android phone has to subscribe to data tagged with “name” (step 2). Then, the iPhone beacons its unique token using various means: Bluetooth Low Energy and an ultrasonic sound while the Android listens to announced tokens (step 3). Upon discovery of the token (step 4), the Andoid will report and match it online against the Google cloud to find out the relevant data behind (hence the need to always be connected). The Google Cloud will message the Android with the Message “iPhone6” since it subscribed to the tag “name” (step 5).
Any subsequent data exchange will go through the cloud. No data is actually being sent peer-to-peer. A bit disappointed? We are too!
Nearby Discovery Technologies
Nearby.Messages uses more “discovery” technologies as illustrated above and here we provide more details based on our findings.
Audio – as shown in the illustration and the screen capture below, a random token is broadcasted using the phone’s speaker during 3 seconds interleaved by 1s of silence, and this repeatedly. Devices capture the ultrasonic sound through their microphone and process it to find out the sent token. This approach has, by the way, already been used in thePhotoCircle App for 3 years to enable the addition of a nearby user to a photo circle and it works between iOS and Android. Audio range is limited to a few meters and any wall would block sound (remember, walls have the annoying tendency to only let through low frequencies like your neighbor’s subwoofer ;-). )
Wi-Fi – according to the Google’s permission request to the user when first using Nearby, an iOS device sends the current WiFi AP (SSID) it is currently connected to (if connected of course) and an Android sends the list of WiFi AP around (as Google does already in the background to improve their location services). If there is a match when reporting to the Google cloud, that is both devices are connected to the same Wi-Fi access point or see the same set of Wi-Fi, the Google cloud considers both devices to be nearby.
Bluetooth Classic and Bluetooth Low Energy – this is where iOS and Android differ most. While an iOS device advertises its token using Bluetooth Low energy (BLE) using the Bluetooth LE peripheral name, Android temporarily changes your device Bluetooth name to the token. To discover devices around, an Android would scan for BLE peripherals to discover other Android devices and also scan for BLE peripherals to discover iOS devices. To discover devices around, an iOS device scans for BLE peripherals to discover other iOS devices. So if you are still following you might legitimately ask how an iOS device can discover an Android device when out of “sound” range. It scans for Bluetooth devices? Nope, scanning for Bluetooth devices is not permitted in iOS (unless using private APIs). So how does it work then? Well, that’s where the Google Cloud comes into play once again: the Android device will actually discover the iOS device, report to the Google Cloud who would in turn notify the iOS device that an Android is nearby. This is the missing arrow in the illustration above.
So as you figured out, all data goes over the Google Cloud. This data includes discovered tokens but more might be sent such as Wi-Fi networks around (that is anyway done since long by Google and Apple to improve their location services), or other BLE or Bluetooth devices around (your fitbit, you bluetooth speakers). And remember that from discovery onwards, all data exchanes will flow through the Google cloud…
To conclude, Nearby introduced a very fancy way – although not novel – to discover nearby devices using sound. Nearby however suffers from two main limitations, which seriously hampers what you can do with it: devices need to have their screens awake at the same time and always be online. This limits Nearby’s potential for intentional interactions where two parties implicitly or explicitly agreed to use Nearby, such as sharing a podcast with a friend.
Nearby has still a lot of catching up to do. p2pkit already offers what Nearby provides, plus more: it works in the background, works off-grid without network connectivity and all that without draining your battery and in a privacy-preserving way.
With p2pkit, we believe proximity is the next mobile revolution, facilitating nearby interactions through your phone. For this to happen, we wanted to provide you with the least limitations as possible so that only your imagination and the sky is the limit to your great ideas. Get inspired by our latest video here.
Carpe Diem et Technicam!