Frank: Free, truly private, messaging for iOS
June 10, 2013 9:52 AM Subscribe
Frank: Free, truly private, messaging for iOS
In the wake of the recent wiretapping allegations, I thought this might be of interest. Frank is a fairly unique iOS app which we've developed for secure chat. It permits frictionless, accountless, completely anonymous, end-to-end encrypted conversations, voicemails etc. Free at this point, although we will have to start charging for it sooner or later to cover server costs. Elevator pitch below the fold.
Frank allows you to communicate messages, sound and pictures in complete privacy, without ever having to disclose your identity.
Frank requires no user account. Just give yourself a name and start chatting.
Frank allows for fully encrypted conversations, simply connect with another Frank user and regain control of your conversations.
Delete a message on Frank, and its gone. Everywhere.
Frank is as close as you can get to talking face to face in a private room — with no-one taking notes, and no possible way for anyone to record the conversation.
Starting a conversation is as simple as pointing two phones at each other.
In the wake of the recent wiretapping allegations, I thought this might be of interest. Frank is a fairly unique iOS app which we've developed for secure chat. It permits frictionless, accountless, completely anonymous, end-to-end encrypted conversations, voicemails etc. Free at this point, although we will have to start charging for it sooner or later to cover server costs. Elevator pitch below the fold.
Frank allows you to communicate messages, sound and pictures in complete privacy, without ever having to disclose your identity.
Frank requires no user account. Just give yourself a name and start chatting.
Frank allows for fully encrypted conversations, simply connect with another Frank user and regain control of your conversations.
Delete a message on Frank, and its gone. Everywhere.
Frank is as close as you can get to talking face to face in a private room — with no-one taking notes, and no possible way for anyone to record the conversation.
Starting a conversation is as simple as pointing two phones at each other.
Role: Founder of company
Hm, no I don't think we have. If you have specific questions I can get answers though. It's standard public/private key stuff, with the keys exchanged between handsets (and this can be done visually via a QR code so that there's no chance for the keys to be intercepted digitally). We never have the keys and know nothing except that some data is coming to and from a particular IP address. So it's up to the user to spoof or VPN that if they want to.
I should say that we prioritize privacy over security. What I mean by that is, a determined hacker can do things like compromise your handset, log your traffic and attempt to do sidechannel attacks and so on. We are not currently a solution for that kind of thing. But we are a solution to indiscriminate slurping of the variety currently under discussion, and if someone does come knocking on our door asking us to decrypt a conversation, we have no means of doing it.
Essentially we are hosting a server-proof (to the degree noted above) database which Frank instances can access and decrypt using the keys in their possession.
We wrote the app as a proof of concept more than anything. There's really no reason why all internet communication shouldn't be handled this way.
I am not the tech guy so I may not be 100% accurate in everything above but that's the bones of it.
We would love to do an Android version but we'd need to hire someone and we don't have money to do that right now. We would also like to roll out a server version for third parties to run their own networks, which could also potentially talk to one another.
Our usage stats are looking like a hockey stick right now, which is interesting...
posted by unSane at 1:02 PM on June 11, 2013
I should say that we prioritize privacy over security. What I mean by that is, a determined hacker can do things like compromise your handset, log your traffic and attempt to do sidechannel attacks and so on. We are not currently a solution for that kind of thing. But we are a solution to indiscriminate slurping of the variety currently under discussion, and if someone does come knocking on our door asking us to decrypt a conversation, we have no means of doing it.
Essentially we are hosting a server-proof (to the degree noted above) database which Frank instances can access and decrypt using the keys in their possession.
We wrote the app as a proof of concept more than anything. There's really no reason why all internet communication shouldn't be handled this way.
I am not the tech guy so I may not be 100% accurate in everything above but that's the bones of it.
We would love to do an Android version but we'd need to hire someone and we don't have money to do that right now. We would also like to roll out a server version for third parties to run their own networks, which could also potentially talk to one another.
Our usage stats are looking like a hockey stick right now, which is interesting...
posted by unSane at 1:02 PM on June 11, 2013
This is interesting and I appreciate that you've helped create it.
posted by dubold at 4:22 PM on June 13, 2013
posted by dubold at 4:22 PM on June 13, 2013
I installed the iPhone app and have a few comments:
1. With a security app, it's pretty important to describe your security architecture in a features or "white paper" section of your web site.
2. I see you use QR codes but it's not clear what that is doing (also did I read somewhere about "bumping"?) and what method(s) that is an alternative to (searching for a contact?).
3. I tried using the search function but nothing happened.
4. It's not clear to me why the app asked for access to my "Contacts".
I think the concept of encrypted communication is clear enough, but what's not clear is how the app is exchanging public keys, in particular how to set up people to communicate with if they are not in front of you for QR code scanning.
posted by Dansaman at 8:49 AM on June 21, 2013
1. With a security app, it's pretty important to describe your security architecture in a features or "white paper" section of your web site.
2. I see you use QR codes but it's not clear what that is doing (also did I read somewhere about "bumping"?) and what method(s) that is an alternative to (searching for a contact?).
3. I tried using the search function but nothing happened.
4. It's not clear to me why the app asked for access to my "Contacts".
I think the concept of encrypted communication is clear enough, but what's not clear is how the app is exchanging public keys, in particular how to set up people to communicate with if they are not in front of you for QR code scanning.
posted by Dansaman at 8:49 AM on June 21, 2013
1. I agree. We need to do that.
2. The QR code is how we share the key to the conversation. It is essentially a pointer to the conversation, plus a key to decrypt it. By using QR codes you are sure who you are sharing the key with (because they are physically present), and it is not vulnerable to a man-in-the-middle attack because it isn't transferred over the internet. Obviously it's your responsibility to make sure it isn't overlooked, and that your phone is properly secured.
Some of our target users are the kinds of people who will get on a plane rather than picking up a phone, so the question of establishing bona fides and being sure the key isn't compromised during transmission is extremely important to them.
If you touch the QR code on a conversation it will give you the option to invite people to the conversation by using one of --
-- SMS text (obviously insecure but good for casual use)
-- a contact from an existing conversation
-- phone call (using a string of letters and a password)
We do not support 'bumping'
3. The search field filters your current conversations for a contact with that name.
4. The app wants to use your contacts because one alternative to scanning the QR code is to send an invitation to an existing contact via SMS.
Frank really doesn't have a concept of a permanent contact. It really only knows about conversations. It has no way of associating participants in conversations with people in your address book. It's a deliberate design feature that participants in conversations are not identifiable, ie they don't have a permanent signature or fingerprint. It's up to you to confirm that the person calling themselves 'Sam' really is Sam.
If you want to keep permanent 'contacts', the way to do this is to keep a conversation open with them (my conversation with my son, for example, has been open for six months).
A directory feature is something we have discussed but we are trying to keep the app feature-lean for the moment to see how it's used.
posted by unSane at 10:25 AM on June 21, 2013
2. The QR code is how we share the key to the conversation. It is essentially a pointer to the conversation, plus a key to decrypt it. By using QR codes you are sure who you are sharing the key with (because they are physically present), and it is not vulnerable to a man-in-the-middle attack because it isn't transferred over the internet. Obviously it's your responsibility to make sure it isn't overlooked, and that your phone is properly secured.
Some of our target users are the kinds of people who will get on a plane rather than picking up a phone, so the question of establishing bona fides and being sure the key isn't compromised during transmission is extremely important to them.
If you touch the QR code on a conversation it will give you the option to invite people to the conversation by using one of --
-- SMS text (obviously insecure but good for casual use)
-- a contact from an existing conversation
-- phone call (using a string of letters and a password)
We do not support 'bumping'
3. The search field filters your current conversations for a contact with that name.
4. The app wants to use your contacts because one alternative to scanning the QR code is to send an invitation to an existing contact via SMS.
Frank really doesn't have a concept of a permanent contact. It really only knows about conversations. It has no way of associating participants in conversations with people in your address book. It's a deliberate design feature that participants in conversations are not identifiable, ie they don't have a permanent signature or fingerprint. It's up to you to confirm that the person calling themselves 'Sam' really is Sam.
If you want to keep permanent 'contacts', the way to do this is to keep a conversation open with them (my conversation with my son, for example, has been open for six months).
A directory feature is something we have discussed but we are trying to keep the app feature-lean for the moment to see how it's used.
posted by unSane at 10:25 AM on June 21, 2013
« Older Make Your Own Visual Novel... | Learn programming with Reeborg... Newer »
posted by carsonb at 12:17 PM on June 10, 2013 [1 favorite]