Interview with Moby author Amogh Pradeep

At the Privacy Enhancing Technologies Symposium 2022, also known as PETS, Kee sat down with Amogh Pradeep, one of the authors of this paper outlining Moby, a blackout resistant anonymity network. The interview has been transcribed below and lightly edited for readability. If you wish to hear the audio of this interview, you can view the YouTube video embedded at the bottom of this article.

Kee: Hey guys, I’m here with Amogh, who worked on a protocol called Moby. Do you want to explain the protocol, the design of the application that you’re presenting here at PETS?

Amogh: Sure, so Moby is a blackout resistant anonymity tool for mobile devices. Essentially it’s a protocol for people to run on their phones which uses the internet to establish trust between a couple of users. So, people you want to talk to, you do this protocol with them, and when the blackout happens — a blackout being when someone shuts down the internet — you use this information that you established before the blackout to communicate with people. What it uses is essentially an ad hoc network, so people just peer-to-peer send messages to each other as they walk around a particular region, and you hope that the messages get through to the destination using this ad hoc network.

Kee: And you said in the talk that you use Epidemic routing, can you kind of explain or give an overview of how that routing works?

Amogh: So Epidemic routing is like a store and forward principle, so essentially you perform message exchanges with people that you come in contact with, that’s the first part of it, and what you hope is that they hold your messages and then go and pass them on to other people. So basically you send messages to everyone you can send them to, and they do the same, they send messages to everyone they can pass it on to. Of course, the amount of storage people have is limited, so each node in the system has to decide how many messages to hold. So you hold messages and then go try to spread the messages.

Kee:  I understand also that you have a research client implementation, can you explain the technology that you’re using for Epidemic routing? I’ve heard Bluetooth and WiFi direct, so what’s the range of that and when do you decide to use WiFi direct versus Bluetooth? 

Amogh: So the WiFi direct and Bluetooth combination is an outcome of how the Android system works. To establish a Bluetooth connection between two phones, you need the MAC address of the other device. There’s no way of emitting the MAC address with pure Bluetooth, because you don’t know what to connect to in order to get this message that they’re sending. So we use WiFi direct for that, essentially the you’d rename your WiFi direct name to ‘Moby’ followed by the MAC address, that’s kind of the give-away. So people listen for WiFi direct connections, and when they see this particular format with the MAC address, they’ll take that and use it to establish a Bluetooth connection, which then allows the message exchange to take place.

Kee: And at what range can this take place? Depending on what the device is I suppose, are we looking at 15-20m?

Amogh: In open air, with no obstructions, the range should be 100m. Obviously that’s the ideal case, and things change a lot based on where you are. In buildings made of wood, it’s almost like having no obstruction — obviously in concrete buildings things change. 

Kee: Have you also thought about iOS integration? I know that they perhaps have some different settings and limitations, or do you think the WiFi direct stuff would apply equally to iOS?

Amogh: So we never made an iOS app, we just made an Android app, and it was only a proof of concept. So the main thing with the study was investigating if this combination of techniques would be able to produce some good outcomes in a region, and not necessarily creating an actual tool. So we used to have other postdoc researchers on this project, and they would embed it in some human rights organisations. The person I’m referring to used to work with Doctors Without Borders, and the idea back then was to get a non-profit organisation like that to provide support for making an app like this. We’d need some sort of backing like that because it’s not easy to maintain something like this, and if we reached that phase in the project then we could think about iOS. But practically I don’t know how you would do it, I don’t have experience with iOS apps.

Kee: Since the app will be running in the background on your phone with WiFi direct and Bluetooth enabled, was there any consideration of battery draining faster due to this, is the app always on or does it check for people in range at set periods of time?

Amogh: So in our proof of concept app, it’s always on, and it actually doesn’t consume much power at all. We got a device from another research project which you physically plug into the battery and run a custom build of Android, which gives you extremely precise battery measurements for operations. What we saw was that PSI-CA was actually the most expensive operation for the battery, but just doing message exchanges and using Bluetooth was basically nothing at all.

Kee: Can you explain why you use the Private Set Intersection Cardinality (PSI-CA) protocol in this application. 

Amogh: Clients that use Moby need to initially do a trust-building protocol with anyone they want to talk to before the internet goes down. So we needed to figure out a way that you could trust someone who is on your contact list. So one of the ways is to figure out how often you speak to your contact, so if you speak often to someone in your contacts that will indicate that you can trust this person. But another method could be seeing if you have similar contacts. If you trust people that they also trust, that gives an indication that you can probably trust this person too. So to capture that we used PSI-CA, since we don’t want your contact lists to be exposed to the other party just to find out the overlap, or the cardinality. 

Kee: So that might tell us that we have 10 contacts in common for example, but wouldn’t tell either of us who those contacts are?

Amogh: Yes, that’s correct.

Kee: So where do you see this research going in the future, is there future work that you wanted to investigate regarding this?

Amogh: So I would love to see something like this be deployed. The good thing is that there are other projects, such as Briar for example which have been deployed in practice. So I was hoping that someone like that who is established in this field already would pick this research up and implement this into their systems. So anyone who is already building some kind of ad hoc communications, they could take some findings from this. And there’s also a lot of future work, such as with the trust establishment methods. The better that is, the better the system works, so if you could come up with better ways to know who you can trust in a region or better protocols that would be an improvement.

Kee: So have you spoken to any of these companies or app developers such as Briar? 

Amogh: No. I have met someone from the Briar team previously, but that was before I started working on this project. This is kind of on the backburner for me because I also submitted my PhD after this project so I’m not working in a related field at the moment. I’ve been more focused on data leakage in Android apps rather than anonymous communications. There is one problem in the field that still needs to be solved, and that is practical metadata privacy in communications. 

Kee: If anyone listens to this and wants to reach out to you, how can they get in contact.

Amogh: Email is the best option. You can google my handle to find me - amoghbl1. And my email is [email protected]

Kee: Alright thanks so much for giving us your time today Amogh.