Some Questions (Because We Need More Transparency)

[gfygfygfy]

Hi,

I've questions about how Bleep is working.

You said Bleep is peer to peer, and I'm sure is true for conversations. But there are others functionalities, like the registration, search friends, invite them... How that is working?

For example, I've noticed Bleep sends informations to an Amazon AWS server: http://regserver.bittorrent.com :

 

First, when we search a friend :

http://regserver.bittorrent.com//find?user=XXX

With XXX as binary value.

 

Second, when we invite a friend :

http://regserver.bittorrent.com/invite?user=XXXX&latest=YYYY

Where XXXX is a binary value, and YYY a timestamp.
 

 

And maybe more (what about when we change our nickname or when we add a contact info like our phone number or email adress ?). I don't know.

On http://labs.bittorrent.com/bleep, you write :

 

We don’t store your messages or metadata, so there’s no risk of exposure.

 

Again, I'm convinced for messages. But we send you some metadatas and you do not tell us.

So, we need more informations. We need to know how Bleep finds users, how the invite engine is working, how the register (the database with correspondances between the "Bleep adresses" and phone numbers or email adresses) is used and where is it, etc.

And of course, we need an open source implementation. Without that, we can't trust you.

Thanks.

[0x25]

This post clarifies the concerns that security-oriented users have while cutting out all of the argumentative nonsense that has been thrown in to other discussions here.

 

We need to know how the few servers you do implement work, why they work how they do, and we need source code for the client. Without this, Bleep will fail miserably as a secure line of communication. It may succeed as a Skype replacement, but on the security side it will fail unless these needs are met. It isn't a matter that is up for debate. You either open things up and possibly become the next big thing in secure communication, or you keep things behind closed doors like you have been and become the newest Skype clone within a sea of Skype clones.

[crash893]

I do not think its unreasonable that if a claim is made that its explained in a detailed manner. 

[farid]

As described here, the calls to the server is made for the following tasks:

 

1- Lookup a public key based on email/phone number (obviously, if you add someone with a public key/QR code, this call is not made) 

2- Sending/receiving invitations. When sending the invitation, the server doesn't know who the invitation is from (the invitation is encrypted with the public key of the receiver) and the identity of the sender is a part of the encrypted payload. Even though as described in the above post and also here, metadata does not include "the graph of friends", we have designed our protocol to limit our exposure to this data too. we do the pulling of invites in a way that the server doesn't know who is pulling for invites. Users pull their invitations from the server by sending a part (not all) of hash of their IDs. The server then returns all of the invitations that are sent to that partial hash. The receiver can only decrypt the one that is encrypted with his/her own key. This way the server doesn't know exactly what invitation was pulled by what ID. We will describe this in details in our blog in a future post.

 

As you can imagine, the above functions are not a part of making/receiving calls that creates the metadata that we are protecting. The essential part of the process (i.e. actually making and receiving calls) is fully p2p in a way that even if our servers are down, our users will be able to communicate with each other.

 

We (or anybody else for that matter) won't know what user is talking to what user at what time and for how long.

 

We are also sending some stats (that we explained here).

[SEC]

Re: The essential part of the process (i.e. actually making and receiving calls) is fully p2p in a way that even if our servers are down, our users will be able to communicate with each other.

 

Farid, you recently explained that making and receiving calls is NOT fully p2p on this thread http://forum.bittorrent.com/topic/32025-if-bleep-is-not-p2p-whom-do-i-need-to-trust-and-when/.

 

On that thread you explain that making/receiving calls requires the Bittorrent relay servers to be up and running for a portion of the user base. Bleep users are expecting a straightforward answer regarding the extent of this server dependency:

 

- If the Bittorrent relay servers are down, what percentage of the Bleep users will be unable to make calls and what percentage will continue to be able to connect P2P?

 

An approximate answer to the above, based on current Bleep operational data would be much better than answers like "its always p2p" and then contradicting yourself later.

[farid]

As we mentioned clearly in our technical communications (e.g. here), we do use relay servers in the current version to connect two peers that cannot connect directly because of network conditions (i.e. NATs). Having said that (as I mentioned in the same thread that you are referring to), we will release a feature soon that allows users to disable the use of the relay server if a user doesn't want to use it and would prefer to only get connected directly. 

 

We currently don't have any specific data re the percentage of connections that go through the relay server (even though we are collecting some metrics as described here that should enable us to estimate this but we don't have any numbers yet.) Any "approximation" will be purely my guess and I am sure that's not what you want! 

 

We will continue to publish more information about the details of our protocols and will answer as many technical questions (given they are not loaded) as we can. I am sure our marketing and biz-dev folks will also be happy to address your non-technical questions or business inquires. 

 

Please keep in mind that a "direct" connection is not always more private than an indirect one. Even though, this particular feature is not currently supported in Bleep, but you can imagine that some users would not want to disclose their IP address to the person that they are talking to thus a direct connection is actually less private for them. As mentioned in this post, oversimplifying the problem (e.g. equating having a direct connection to privacy) is not the best approach. 

 

We appreciate your concerns about users' privacy and your ask for more transparency. However, please keep the conversation about a particular topic in its own thread so that other readers can follow the conversation. Posting about the same topic in multiple threads may cause confusion as some people may miss the original discussion. This can portray an inaccurate picture and I am sure that's not anyone's intention.

[Toxicle]

I've noticed a lot of mention of servers in this thread. How could we be sure that you (or Amazon) haven't been legally forced to compromise the servers a la the PRISM program? It seems like this would be inevitable if Bleep ever became big, or may already be the case given that Amazon is already huge. I thought the whole idea of distributed networks was to avoid this possibility altogether.

 

 

 

Please keep in mind that a "direct" connection is not always more private than an indirect one. Even though, this particular feature is not currently supported in Bleep, but you can imagine that some users would not want to disclose their IP address to the person that they are talking to thus a direct connection is actually less private for them. As mentioned in this post, oversimplifying the problem (e.g. equating having a direct connection to privacy) is not the best approach. 

With a direct connection you at least know who your IP is being exposed to. In most cases we know the people we talk to and usually trust them a lot more than some random server which may be compromised. So generally speaking, yes, direct connections are almost always the better option for privacy unless you suspect you're connected to an adversary. In those cases, there should be the option to use a proxy.