I've got a vague grasp of IT security and crypto etc and I must say I find it very difficult to reconcile the world "self-destructing" with any kind of technical concept. I can sorta see what is meant on a colloquial level...but the tech side of me keeps thinking "what does that even mean".
On to more positive aspects...the overall website looks smooth. 9.5 out of 10 - well above par even for startup type sites. Something about the width/look of that encrypt button bothers me, but I can't quite place whats wrong so we'll let that slide.
Advice: You say its encrypted. Cool - means nothing to me. Add a link to an info page of whats happening (pictures, flowcharts etc). Right at the start of that overview page add a comment saying something along the lines of "This article provides a broad overview of the encryption process - should you want to view the technical details please see this link". i.e. Tell people why its safe and secondly split it into people wanting general assurance that its safe vs people wanting to know why you used SHA instead of Skein. The info these two groups need is very different.
I'll say what I said the last time something like this came up, which was something like last week: It is impossible for you to prove that you've destroyed the data. That requires a Trent, a trusted party; it is unverifiable.
Especially in the US, Trent is one NSL away from being falsely trusted (see Lavabit). In fact, as far as I can see, you're not even positively claiming you are destroying the messages: "We may retain personal information indefinitely." Are you able to explain that item in the privacy policy?
In general, please try not to design cryptosystems which require Trent in the post-Snowden era. That is a sign you've either failed in your design, are trying to solve the wrong problem, or aren't being creative enough.
I think the point is that, unless you have insider information, it's impossible to trust any third-party product that works with these assumptions.
Really, if you're trying to share a file with someone over the Internet, your best bet is public-key encryption. You can safely share an ASCII armored GPG file over something like Pastebin (or email) without worrying about the confidentiality of the message. The problem, of course, would be that there is still (somewhat public) evidence of the communication.
Web-based end-to-end encrypted (and, better yet, ethereal) messaging isn't really solved yet. I think the "grandparent" poster is just trying to illustrate that publishing the same idea -- all hinging on "but really, trust us!" -- doesn't make much difference.
More or less, yes. There's already plenty of snakeoil out there claiming to erase ciphertext or keys anyway - with zero verifiability, and often the claims have been demonstrably false. I could name two right off the bat: Snapchat. Cryptolocker.
If you want ephemeral communications, GPG actually won't do the trick, the public encryption asymmetric subkeys are pretty long-term; ephemeral communications have key lifespans measured in seconds, not months or years. The closest you can get to what you want right now is probably Axolotl as used by TextSecure/Signal, or perhaps OTR, or perhaps Pond: good designs try to not to need to trust third-parties to destroy things and try to instead make sure third-parties don't see things that are too useful to Eve or Mallory in the future. (Even there, metadata is still a nightmarish concern which is hard to protect and very valuable to Eve, sometimes moreso than content.)
Even trusting the first or second party to clear things, you may have some problems. Did you really clear that memory? Are you certain the compiler didn't 'helpfully' optimise out your memset? (See also: explicit_bzero(), etc.) Did Bob secretly take a copy, or can you trust him not to? (You pretty much have to trust Bob to follow the protocol there; that is the impossible problem behind DRM! If Bob wants to cheat, he's got physical access and all the time in the world: he always wins.) And if Bob is honest, if jackboots bust down Bob's door, does Alice still have to worry about a cold-boot attack? (Probably, yes.) Or Mallory playing really dirty and rooting Alice or Bob's machine, which is always, possibly short of the $5 wrench/rubber-hose attack, the easiest route. (See also: Firewire and Thunderbolt DMA attacks, exploitable USB stack bugs, etc.)
It's possible to try to do trusted ICs with tamper-resistant low-retention EEPROM storage, such as you might find on a specialised smartcard/crypto token or TPM - Pond tries to use a TPM's key storage if one's available, I think? - but these devices are often black boxes with far too little external auditing from the good guys and it is something of a blind spot to prove it is above tampering. (There are a couple of open-source efforts to develop trusted cryptography/security cores, including https://cryptech.is/ for example, but verification that hardware objects came from sources and weren't trojaned even as low as at the gate doping level is Very Hard™!; much harder than deterministic assembly/compilation for software.) They may be trusted by some, but they have a long way to go to be trustworthy.
Rolling along with a pretty website is lovely, but doesn't help with any of these problems. Worse, it may give people a false sense of security. Please, no. The doghouse has enough dogs it in already.
While I don't disagree with anything you've written, depending on your risk appetite there is a difference between compromises that require physical access and those that don't - not that I think this particular product is a good idea at all, but not everything needs full local security.
For some users a secure messaging protocol that protects messages as long as Alice & Bob's machines aren't rooted is Good Enough, and I don't see anything wrong with creating a product that offers this (as long as it's made explicit that this is the case - Google's End-to-End is a good example of providing this level of security and being clear about this limitation).
Also, re: metadata, I really liked the work in Pond to massage the data stream so that it didn't look like encrypted data, which while certainly doesn't solve the metadata problem is one step along that path. And yes, it does use a TPM if available.
I'd be very interested to hear more about TPMs that are open, well audited and trusted, if such a thing exists.
> Using client-side cryptography, your files and text are protected with a special password that is never sent to our servers.
However, the .js file is still sent server-side.
Tony Arcieri notes "there’s nothing to stop anyone who has sufficient access from injecting a malicious payload into it at any point in time." [1] This is a false promise; a user still must trust the server.
> This is a false promise; a user still must trust the server.
How is this any different than trusting mozilla.org when you download Firefox? Unless you write the software yourself, you have to trust a server at some point. So I think what you meant to say was, "A user still must trust the server every time they load the program, which is different from only trusting it at install time".
To which my reply is, yes, they do. However, it's simply the best we can do right now while still making it user-friendly for this audience. What is your alternative proposal?
Apps like this are trying to address the root bug[1] using a go-where-the-people-are strategy. Tons of people use the web, therefore we should make apps that use the web. Asking them to change their behavior is incredibly difficult, especially when they don't see any tangible value out of changing.
So here's some questions for you:
1. What is your proposal to addressing the root bug[1]?
2. What will people's reactions be when you ask them to use your proposal?
Empathy for the user is one of the biggest things that I think most crypto projects are missing. These kinds of apps at least attempt to consider user adoption in their scope.
EDIT: The cool thing that this project does that I haven't seen before is just put the encryption password in the URL fragment. That way, it can be automatically read by the client javascript for decryption, but it will not be sent to the server as part of the request. Clever!
1. I think the best option is for the client to encrypt using a local library, like NaCl before sending anything to the server. The server should not provide the encryption algorithm. The client and server must agree in the algorithm, but neither provide it.
2. Yes, it defers trust and responsibility. Now Mozilla, Google, Apple, Microsoft, and Opera are on the lam for issuing a competent browser encryption.
The messed up thing is, all it does is defer trust. What I'm trying to say about the current state of client-side web crypto as far as I understand it, deferring trust doesn't do a damned thing. It's still the source of the crypto lib, which is you.
You might be interested in this client side encryption I worked on if you're looking for something like this https://github.com/abemassry/wsend-gpg it is a command line app though, I couldn't get it to work in the browser.
Also, "Destroying" (or self destructing) a message is pretty difficult, once the information is on the hard drive software can often retrieve it even if it is deleted.
That being said, explaining how it is destroyed would be advantageous to the project. Which would make me (and likely others) more likely to use your service/application.
With this in mind, defining the form of encryption would be beneficial as well. :)
I like the idea, but my only nitpick isn't with popbox itself, it's with the background canvas.
Replace it with a normal grey background or something. It looks pretty, but causes my browser to become sluggish. Firefox's CPU usage goes from about 5% to bouncing from 60-80% when I open the tab, and goes back down when I close it.
This was a side project for a few of us at the office. It is for casual users who want 'better than nothing at all' encryption. We are well aware of the limitations of serverside JS encryption, but we aim for usability first which means a sacrifice in security, since that would require a download. Think snapchat.
We mainly think it will be used for things like promo codes and whatnot, but I personally use it to send things around the office I dont want stuck in my IM history.
We have addressed several of the points in this article in the FAQ- thanks for everyones comments.
Read the FAQ about how it works. It has a password. Also, this is totally free with no accounts or upgrades needed whereas noteshred is not. Also, you own noteshred so a disclaimer would have probably been prudent :P
This is just a weekend project though, so no worries either way.
I agree with the general concern about the JS crypto, however that could easily be solved with a native front-end to the website, and a systematic compromise could easily be detected.
My bigger concern is that, even assuming uncomprosied client side code, the server can still access the decrypted content when someone access it, becuase the nessasary password is still sent to the server in the url.
It's actually not sent to the server. The password is part of the URL fragment, which is not included in the HTTP request. A very clever hack, in my opinion.
It's not safe to use this for anything serious, of course, since it uses crypto in a web page. Were there any real intended uses for this, or was it just a fun side project?
On to more positive aspects...the overall website looks smooth. 9.5 out of 10 - well above par even for startup type sites. Something about the width/look of that encrypt button bothers me, but I can't quite place whats wrong so we'll let that slide.
Advice: You say its encrypted. Cool - means nothing to me. Add a link to an info page of whats happening (pictures, flowcharts etc). Right at the start of that overview page add a comment saying something along the lines of "This article provides a broad overview of the encryption process - should you want to view the technical details please see this link". i.e. Tell people why its safe and secondly split it into people wanting general assurance that its safe vs people wanting to know why you used SHA instead of Skein. The info these two groups need is very different.