From the "Security" page:<p>> <i>Urls are ephemeral, they are NOT stored anywhere (neither your secrets). The content you share lives encrypted in the URL.</i><p>> <i>The decrypted content can ONLY be accessed by the people that you shared shared the data with by means of login and email verification (as opposed to, let's say, Dropbox links which can be accessed by anyone who has the link).</i><p>(note: "shared shared" is present in the original. I hope that gets fixed)<p>> <i>Secrets are signed with HMAC SHA256 and encrypted with AES 256 CTR using keys that live on the Sharelock server</i><p>So it seems that the server holds the keys, and doles them out to users that prove their identity. And the URL holds the secret. So we're pretty much taking it on faith that the server never logs the URL anywhere (not just in the actual backend, but in access logs for any middleware or load balancers or anything else).<p>As for authentication, the animated slideshow on the front of the site says the user has to login with a Google, Facebook, Microsoft, or Twitter account (I assume that secrets shared with twitter handles must use the Twitter login, but for emails it presumably uses any of them).<p>I'm a bit concerned about the identity verification angle. If someone manages to compromise any of those 4 accounts, then that means they can then decrypt any URLs shared with that user (if they manage to get at the URL). Twitter accounts being compromised is not that uncommon. And it would be especially bad if the sharelock URLs are then sent via Twitter (say, Twitter DMs) to that user, because then the attacker has both the URL and the keys. Or perhaps the user doesn't even realize they have an old Microsoft account, one with a pathetically weak password, and the attacker breaks into that.<p>In fact, that may very well apply to me (I don't use anything that requires a Microsoft login, but I did once have a (rarely-used) Windows Live login, and if Microsoft converted those into whatever their current authentication setup is, then I probably have an account with a terribly weak password).
I tried it from my browser to my cellphone. I use a Nexus 5 and it worked very well. I didn't have to install the app making it even easier.<p>Good job.
As others have point out this just means you have to trust Sharelock. While its slightly less user friendly, and it has its own security issues would the following be viable:<p>1) Sender clicks 'share a file' and no file is uploaded yet.
2) Email is sent to recipient, explaining that they have an encrypted file waiting for them, and takes them through creating a public key done in their browser via JavaScript (biggest vulnerability....)
3) Original user receives email/notification with senders public key, and uploads a file that is encrypted with that public key.
4) Recipient receives notification that the file is now ready, and decrypt it with their client side JavaScript.<p>That way Sharelock or another service will never store the unencrypted files, and this service can be made more secure with open source uploader/key generation (e.g. for people more security conscious they dont use the webapp, but they use an API with their local app). Sharelock should commit to never holding backups of user data, and deleting all files after they have been 'received'.<p>It makes sending encrypted files as convenient as is possible, and be useful for many projects where the client doesnt want to share the plaintext data but it needs to be easy to use.<p>Thoughts?
If it's text only, there's also zerobin (<a href="http://sebsauvage.net/wiki/doku.php?id=php:zerobin" rel="nofollow">http://sebsauvage.net/wiki/doku.php?id=php:zerobin</a>) that has a lot of features and the added bonus of not storing the key on the server (it's using the anchor part)
Since this is limited to about the length of a tweet and requires to fully trust a third party (Sharelock), why not just send the message directly on Google, Facebook or Twitter?<p>What is Sharelock adding here other than a false sense of security? Are we supposed to trust Sharelock more than the aforementioned services?
Does anyone here have experience with Tresorit? [1] They claim to offer something similar in terms of secure sharing, but with zero-knowledge encryption, i.e. without storing keys on the server. [2]
Trouble is that the service seems very new, so not many reviews exist. The client being closed-source doesn't help, and I'm not in a position to evaluate their bounty program.<p>[1] <a href="https://tresorit.com/features" rel="nofollow">https://tresorit.com/features</a><p>[2] <a href="https://tresorit.com/files/encrypted-link-whitepaper.pdf" rel="nofollow">https://tresorit.com/files/encrypted-link-whitepaper.pdf</a>
No comment on the underlying technology or security, but damned if that isn't one of the best "explainer" animations I've ever seen. I'm adding this to my personal "awesome onboarding" catalogue.
Sign in with google? Facebook?<p>So you have to trust them, since they can get your data. No?<p>If anything, Apple's iMessage already lets you send secure data this way. Apple doesn't hold the keys, and messages are encrypted locally.<p>The site doesn't scroll properly on iPhone 5. Probably was designed with iPhone 6 in mind.<p>Otherwise - this is a cool concept! Just fix the auth.
Strange coincidence that we share same name with bit similar concept under different tld. Mine is <a href="http://sharelock.co" rel="nofollow">http://sharelock.co</a>
Kudos for nice ui