Seems kinda similar to justleak.it. But I would have to give the link to the person manually.
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.
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.
I think this is neat. I can't imagine a use for it but I like the UI.
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.
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.
Offer end-to-end encryption could be solved using a javascript library which encrypts/decrypts the secret in the browser, and passing the key behind a #, kind of the way mega.co.nz does it. Than you can always verify that what you typed actually never get's submitted to the host unencrypted.
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.
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?
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".
Every time some service like this is submitted there's someone complaining about screenshots.
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.
Without the other context the random password itself is not useful to the 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.
> you know they were the only ones to ever read it,
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.
You could use it for sending things like passwords. You may want to give someone access to something but not have it stored in chat or email records. If anyone else were to look up the link later, presumably it's no longer there as the recipient already clicked the link.
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?
Do the people who own the Kevlar trademark also create software?
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.
There used to be a FTP client for linux called kevlarftp (it was a OSS clone of the bulletproof ftp client). Dupont lawyers raised copyright issues against the product name. The author promptly gave up and the software was renamed to "kftp"
Isn't there something that once a word is used enough and becomes an actual word in English you're not able to claim a trademark on it anymore? Or am I dreaming this up..
Tell your friend to store only an encrypted version of the message on their server and add the encryption key to the message url as a hash. Decrypt it in the browser for the reader.
Sending unencrypted text over http isn't what I'd choose for my top secret messages.
While I like the UI and such, the principle is basically flawed, as users had to implicitely trust the server administrators, their hosting providers and their CA (assuming https). Even iMessage offers a better trust model - you only need to trust apple, and, if what apple says is true, messages cannot be read by apple nor anyone else.
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.
52 comments
[ 3.4 ms ] story [ 83.0 ms ] threador http://yaap.it/ (https://github.com/SeyZ/yaapit)
or even http://g0bin-demo.appspot.com/new/ (https://github.com/jyap808/g0bin)
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?
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.
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.
*friend
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?
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".
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.
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?
https://en.wikipedia.org/wiki/Kevlar
https://github.com/rafaqueque/weezper
"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.
Edit: Also see: https://oneshar.es/
Sending unencrypted text over http isn't what I'd choose for my top secret messages.
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.
A link unclicked for an amount of time after it has made live will expire. Opening it before the counter expires resets the counter.