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:
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.
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'.
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.
You are right in your observation that the exchange of secrets through Sharelock.io is only secure if you trust the integrity of the service and the people behind it. To mitigate this concern we offer Sharelock as an open source project on GitHub, which allows anyone to create their own island of trust by hosting an instance and controlling cryptographic keys.
There are many ways to organize a secure exchange of secrets, each of them with different trade offs between usability and allocation of trust. With Sharelock we aspired to create a system that is maximally usable by leveraging existing social identity providers and remaining agnostic to the mechanism used to transfer ciphertext. We believe this approach makes Sharelock.io more widely applicable to a broad range of scenarios.
Then how is your service any more secure than any file upload service with ssl? It just seems misleading, whats the point of a safe when the key is glued to the door.
An encryption service that requires people trust its owners just isnt secure. You could be perfect with the utmost of integrity even under insurmountable legal pressure, but even then, if your system has a way of knowing the keys its leaving the door open.
We aspired to create a service that is similarly secure to a file upload service with SSL, but more usable at the same time by not tying the user to a partcular data exchange mechanism (you can sent the sharelock URL via e-mail, Tweet it, or publish in a New York Times).
Having said that, exposure of the user of sharelock.io can be argued to be lower than in case of a service which durably stores user's data. While sharelock.io keeps the cryptographic credentials, it does not durably store users' secrets or ciphertext.
Looks useful, thanks for sharing. Could probably get some good traction if the UI was as polished as Sharelock, its a real pain point working with confidential files and non tech savvy clients.
Have any of the improvements in javascript engines/web standards made javascript based public key encryption more viable?
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.
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'.
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.
Thoughts?