[tjanczuk17]

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.

[psandersen]

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.

[tjanczuk17]

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.

[psandersen]

Then to put it bluntly your service is misleading, and is the encryption equivalent of selling a leather jacket as a bullet proof vest.

[zmanian]

What kind of adversary would be defeated by Sharelock but could overcome TLS?