Become aware of nearby friends without continuous tracking
Please send an email to uhengart+nearbyfriend@cs.uwaterloo.ca.
Proximity is determined based on the two devices' position in a grid. The two devices are considered nearby if they are in the same grid cell, in two neighbouring cells, or in two diagonally touching cells. To determine a device's cell, the algorithm converts its current longitude and latitude, as determined with GPS for the Android and BlackBerry applications or with Skyhook Wireless for the Pidgin plugin, to metric x/y coordinates. Then, the x/y coordinates are divided by 100 to get the grid cell. This way, if the two devices are at most 100 meters apart, the algorithm will always detect their proximity. The algorithm might be able to detect proximity for distances up to 250 meters. (See the paper for details.) Of course, you can change the distance that is considered nearby in the source code. In the Android and BlackBerry applications, you can also manually enter a grid cell.
This is a proof-of-concept implementation of the Pierre protocol proposed in our paper. There are some security weaknesses in the current implementation. First, there is no message integrity, that is, an attacker can modify messages without being detected while they are in flight between two devices. However, it is impossible for the attacker to learn your location from intercepting or modifying messages. Second, there is no end-to-end authentication, that is, your program might communicate with an attacker's program, instead of with your friend's. Therefore, for the Pidgin plugin, we recommend that you run the NearbyFriend plugin together with the Off-the-Record (OTR) messaging plugin, which provides message integrity and end-to-end authentication. (Also, OTR provides message fragmentation, which is necessary to enable some instant messaging protocols to transmit the large messages generated by the NearbyFriend plugin.) There is currently no such possibility for the Android and BlackBerry applications. Whereas we could build a framework for secure end-to-end communication between two devices, we think that the right approach is to deploy our protocol on top of an existing framework instead.
As shown in our paper, the performance overhead caused by our protocol is comparable to establishing an SSL/TLS connection. So if a device is able to set up an SSL/TLS connection quickly, as it is the case for an Android or BlackBerry device, the device will also be able to run our protocol quickly.
Often, a device's IP address leaks information about its current location. Therefore, if we had the two devices communicate directly with each other, they might be able to infer information about the other device's location from its IP address, which would violate privacy. The proxy server shields a device's IP address from the other device. Of course, this might allow the proxy server to learn information about a device's location. Ideally, an anonymous communication network (e.g., Tor) is used for communication.
Location is determined with the help of technology from Skyhook Wireless. In the first step, the plugin scans for nearby WiFi access points and sends their identities to Skyhook Wireless. Skyhook Wireless then looks up the location of these access points in a database and informs the plugin of its location. If the first step fails, Skyhook Wireless will try to find a location based on the plugin's IP address. See http://www.skyhookwireless.com/howitworks for details.
See http://www.skyhookwireless.com/whoweare/privacypolicy.php.
If you fail to see the NearbyFriend plugin in the list of plugins in the Tools menu, open the Debug Window in the Help menu. Close and re-open the list of plugins and watch out for error messages. If you fail to get information about your friend's location, make sure that the Off-the-Record (OTR) plugin is enabled and that the communication is private. Also, close and re-start the conversation. You should now see a message confirming that the NearbyFriend application is running.