deskconnect.md

DeskConnect Privacy Policy

The Privacy Policy doesn't really distinguish from user information like Name & Email versus data transferred by the product, and since it allows for business transfers of this data, it's troubling. There's also no data retention policy, so the things you quickly copy & paste may be retained forever.

On the tech level, there's no information on the type of encryption used and on which levels it's implemented. Of course, it'd be magical for this all to happen without the 'cloud' roundtrip and with zeroconf or something similar, but we all know how tricky that kind of tech can be to do smoothly.

Hey Tom! Thanks for your comments.

Just to give you some background: I'm a college student. Last year I took a gap year, interning at tech startup in Mountain View, and I put together DeskConnect during my free time over the course of the year, and launched it on the App Store together with my friend Ben last summer.

I'd be happy to fill in some details on our data policies. Your data is yours, and we have no intention of doing anything with it; we need to do a better job of letting our infrastructure and legal stuff make that clear.

• In terms of encryption, all traffic between your devices and our servers is encrypted via SSL, including uploading and downloading content.
• Content is stored on our servers temporarily for 30 days. It is currently stored unencrypted, which is not ideal, and I'm working on adding public/private end-to-end encryption for the next release of DeskConnect. (We don't allow anyone else access to our servers, so this shouldn't be a problem, but it's definitely not the right way to do it, though Dropbox doesn't currently encrypt their users' data either.)
• All data on our server is completely removed after 30 days. The data we retain for 30 days (for the sole purpose of allowing you to access it from your device) is the name of the thing you transferred, the URL, the corresponding file (if applicable), and some metadata (the date the item was sent, whether or not the item is unread, which device it was sent from, which device it was sent to, and the file size). All of this is deleted after 30 days.
• It'd be awesome for this to all work locally, with no cloud to worry about, but unfortunately like you said, this isn't nearly as smooth, because users have to worry about which networks their devices are on, or whether or not the devices are in range. That said, I'm working on a feature for the next version so that data is transferred locally if your devices do happen to be on the same network! (And you'll be able to tell beforehand)
• We don't keep any data about you other than your email address and your list of devices. We don't even have your name! We do use some analytics services, which collect stats about how people interact with the apps, what types of files are sent, which features of the app are used most frequently, etc.

You raise some good points about our privacy policy. Honestly I'm not really sure what's going on with that. If you read the opening of the privacy policy, you can see that it only applies to our web site, not the service itself. My partner, Ben, put this together, but it seems ill-fitting, because our site is static and does not collect any personal information whatsoever (though we do use Google Analytics, which collects some information, though I don't think it's personally-identifiable). I will look into this and figure out how we can fix it.

Please feel free to let me know if you have any other questions or suggestions! I appreciate your thoughts and I'm sorry we're not doing a perfect job of this; it's hard to get everything right!

Ari

Just wanted to add:

The document that applies to the actual DeskConnect service is our Terms of Service, which is unfortunately overly broad because we don't want to get sued because we left something out. I just read the legal mumbo jumbo for the first time in a while, and it's not great. For example, we require that you give us the right to "use, modify, reproduce, distribute, display, publish and perform Your Content for operational purposes of the Service," because technically converting file formats for compatibility constitutes "modifying" your data, uploading data to our server constitutes "using," "reproducing," and "distributing" it and showing you your own data may constitute "displaying", "publishing", and "performing" it. This really sucks and is absolutely ridiculous, and I'd like to see how we can make these terms more restrictive to better reflect the service.