As share spreads, we’ve been getting more specific questions about how it works: for example, what do we mean when we say that share is a “private and secure environment” to share files, or what kind of chat infrastructure or protocols we are using. These are important topics since we want share to be useful in both personal and work environments. So I wanted to take some time to explain the basics without getting lost in technical details (maybe there isn’t much chance of that, but I’ll try).
Private? Secure? Really?
“Private and secure” are terms that are widely over- and mis-used in a variety of contexts and that can concievably be spun pretty much whichever way you want. The most obvious way to spin their meaning is by attaching conditions to them. Take this imaginary excerpt from the imaginary press release of an imaginary product:
“BoondogleGadget™ is fully secure.
**Support note: BoondogleGadget™ is fully secure only if you disable half the services and enable the security functionality that we ship built-in, but forgot to turn on for the release.”
Ok, maybe this is not so “imaginary,” as it would describe a good number of applications and environments, and I’m sure one or two come to mind more easily than others.
That last bit might appear to be a digression, but it’s not. Why? Because
security cannot be optional.
In
share, if you can see a contact as online, then it means that a) you have them in your contact list and have approved their contact, and b) that a secure (read: encrypted, one-to-one) connection has been established between you and your contact, in many cases a direct connection (a relayed connection is possible, I’ll get to this in a moment).
All the information (and I mean
all the information) transferred through share goes through that encrypted, authenticated channel. Connections made to our servers for authentication or data retrieval purposes (such as obtaining your contact list) are made over HTTPS. As far as connections between you and your contacts, encryption is negotiated on a user-to-user basis: someone talking to you would have no way of reading what you are telling someone else, even if they could intercept the connection (which is possible, although extremely difficult to do). Finally, your personal share network is
by default private. You have to go into your preferences in your share account and explicitly share your contact list with others, and even then they could only see who you know, but they wouldn’t have a way of knowing what you are exchanging with them (actually the “share your network with your friends” feature isn’t enabled yet, but it will be soon).
Let’s say, though, that you were half asleep and let someone you don’t know into your network. They are online, and connected to you. Eventually you’ll realize this, and remove them from your contact list. But in the meantime? In the meantime, nothing will happen, because share only gives access to data that you have explicitly shared with a contact. (Now, if you’re consciously sharing your personal files with strangers, that’s another matter entirely, there isn’t much we can do about that).
Encryption is not optional, it can’t be turned off, it can’t be disabled from the application or any of the preferences. One-to-one channels can’t be turned off. You can’t see the folders or files
that haven’t been explicitly shared with you by others, and viceversa.
This isn’t to say that it is impossible to break into the system: not only that’s a negative that can’t be proven; I’d be foolish to say that’s the case even if I
hoped that was true. But the nature of the application (small groups in closed circles, no broadcast capabilities, secure one-to-one channels) means that at a minimum it is extremely difficult to do so. And even if you
do get in, somehow, somewhere, what could you see?
The answer is: not much, since they would be constrained by the way information propagates in share, and, more specifically on how connections are handled.
The connection sequence
When it connects, share attempts to open connections using a fallback sequence, attempting first to establish direct communication, then relayed. This means that if you are behind a closed firewall and want to share with, say, your coworkers, you can, as long as HTTPS connections out are allowed. If the network is completely disconnected from the Internet or does not allow HTTPS access, you will not be able to connect (we are looking at ways to improve this of course, but that’s the situation at the moment).
The default port for share is TCP 7001 (this can be changed in the Preferences). If you are at home, and, say, map port 7001 from your firewall to your machine,
every person that connects to you will do so directly. If no direct connection can be established, a relay will be used (if possible–this isn’t guaranteed either, after all, your access to the Internet might be highly restricted). As mentioned above, communications are encrypted, and, since the encryption is user-to-user, the relay can’t “see” what’s being transferred, it simply passes packets along. The information is only accessible on the sender and receiver end.
Direct connections are also crucial for speed on local networks. See it for yourself: load up share on two machines (you’ll need two identities for now, eventually you won’t, but that’s a topic for another day) on the same intranet, and transfer a few big files (try setting the “maximum simultanous uploads” and “max uploads per user” to a relatively high number—say, 10). On intranet connections, we have seen aggregate transfer rates that routinely max out an Ethernet LAN.
You own your data
“But you have servers right?” Would be the logical question to follow the above. And it’s a fair question. What do we store? How do we deal with what we store?
To a large degree, we have a server-side infrastructure to make the service easy to use and reliable: to backup your contact list and some of your preferences, to provide enough to the clients so that they have the best chance of communicating directly, and so on.
But, specifically, what do we store? We store your email address and name, and preferences, and whether you are online or not (not the specific status, such as “Busy"—
that is communicated directly between you and your contacts), as well as your contact list. No information is public, and once we enable the “sociable” (read: social software) features, not only they will all be optional, but the settings will default to maximum privacy. You will have to turn things on explicitly to share information with others.
What we
do not store is any information whatsoever related to data transfers, communications, chats, and so on. In fact, we really have no way of knowing any of that, since connections are (one more time, all together now) one-to-one, encrypted, and typically direct between participants.
As to the data we
do store (or even know about) we have a pretty strict
privacy policy.
In short: We do believe “that you own your data” and
share has been designed so that it stays that way. We have done our best to make share as secure as we can, and we’ll continue looking for ways to improve it.
This ended up being a bit longer than I intended originally, but hopefully it wasn’t
completely boring. Anyway, that’s it for now.
And as always, comments, questions, and suggestions will be appreciated!
[
the cactus log!]