Show HN: Kevlar.io – Secrets that when accessed are deleted permanently
kevlar.io
kevlar.io
The fundamental problem with this:
There's no way to prove that the secret has been deleted and / or not copied. You have access to the plaintext and the password / url (presumably an encryption key). You (the malicious server operator or the compromised server) can do anything you want with the information.
This would be interesting if you could:
1) Offer end-to-end encryption. This would require encryption in the client which has its own issues.
2) Be able to provide proof that the information has been made inaccessible. This is not the same thing as having the link return a 404 the second time.
Would you mind discussing your product over on Product Hunt? What's your twitter id?
in terms of end-to-end encryption, what kind of client-encryption do you have in mind? usually, this involves steps that regular internet-users are not able or willing to handle. that's why i think such a service might be a great thing.
to your second point, how would you ever be able to proof that?
> in terms of end-to-end encryption, what kind of client-encryption do you have in mind?
I didn't have something in mind, but Stanford has a good, relatively hard to screw up (by configuration) JS crypto library. But that's only part of the battle since we can't trust the delivery channel or the browser.
> usually, this involves steps that regular internet-users are not able or willing to handle.
That's right and underlines the single biggest reason crypto isn't really used by most people apart from HTTPS.
> to your second point, how would you ever be able to proof that?
That's a really interesting question. It might not be provable. I wasn't trying to be cryptic (excuse the pun) but that was really the point I was making.
http://matasano.com/articles/javascript-cryptography/
http://tonyarcieri.com/whats-wrong-with-webcrypto
I'd say the main issue with that is sending an encryption package over an insecure channel. While you could verify the package independently (check a hash against a publicly known one) you're already into advanced user territory and the "encryption for everyone" point of this is gone.
You shouldn't be launching a site in 2014 without https: that could handle 'secrets', or even any personal information, or really at all!
Also, as said above, you can't actually prove destruction (as far as I know, without a Trent i.e. trusted party to do it), which is a big theoretical flaw in the whole idea.
Of course they can take screenshots, that's not the use case.
People can also memorize things, or create fake pages and screenshots. Or film the screen of their phones, or take photos of their TV.
You can't just send beams magically to their head and then make all evidence and memory of it magically disappear.
The use case is for when you want to send someone a password or a small message, instead of sending it to live in their IM history or email inbox, you send it with something like this, so if they can successfully read it, you know they were the only ones to ever read it, otherwise they would not be able to read it.
Is it for super secret stuff? No.
Is it good enough for many use cases? Yes.
In case of password, you'd communicate URL, username etc regularly and just use something like this for password, so even if this thing itself is not terribly secure, it's missing context so it's still fine.
Example:
Hey John, here's the login details for the grocery manager: username: blahblah login url: http://example.com/login password: get it from http://kevlar.io/QlIk6NKFfX78dRq3ZES5yw
No, this is a terrible service for it for a few reasons:
- it doesn't force https, so you should never send any password through it
- you have no control over it, so for all we know all secrets will be saved forever on an insecure server
- you have no idea who runs the service, so for all we know all secrets will be published in a year, available for everyone to download
Best way to collect lots of logins, passwords, cc details? Start your own "secure" storage service.
People exchange full login details in email and IM all the time, this simply helps with the problem of having them sit in the history and archives indefinitely.
Security is a spectrum not an absolute measure.
This is the problem. If you could prove that they're the only ones that ever read it, it'd be great.
But it's data hosted on someone else's closed source service most likely running on a VPS somewhere that yet another third party entity is running, connecting to your browser over unencrypted HTTP.
or http://yaap.it/ (https://github.com/SeyZ/yaapit)
or even http://g0bin-demo.appspot.com/new/ (https://github.com/jyap808/g0bin)
It could be a different thing if the service was installed locally, i.e. under the control of one of the participants in the information exchange (and then the "burn after reading" feature is pointless).
If a user would really want to pass along secrets without those things she should use XMPP/OTR instead (i.e. pidgin/adium). Which is really not that hard to use.
"Trademark. 1. a brand of aramid fiber."
That is like calling it Nike or Adidas.
I agree that it's probably foolhardy to use somethin that is an existing trademark I can't see the Kevlar-the-fibre people winning any lawsuit. Although just the process is probably harmful to the Kevlar-the-software people.
Sending unencrypted text over http isn't what I'd choose for my top secret messages.
There are tons of services doing exactly the same thing, some even on Tor.
which other alternatives are there you are talking about? i would like to have a look at them.
in terms of trust, lot's of people put their data on facebook, so there is that... specifically for you, would it help if you can audit such an application?
See, the thing is, having seen Leak i immediately wanted to use it, and actually did use it. Seeing your thing, I just tried it for myself and don't really see a use in my life for it.
So what's your plan on the service?
Edit: Also see: https://oneshar.es/
I think that's actually something worth clarifying about this service. Assuming that a link is created with a secret, but not accessed, how long is it stored for? Is it ever deleted otherwise?
Don't know if it's down, but every attempt I try gets "404 - It's most likely your seeing this page because a message has already been accessed and deleted".
A link unclicked for an amount of time after it has made live will expire. Opening it before the counter expires resets the counter.
*friend