
Show HN: Self destructing, encrypted messaging with file upload - DanBlake
http://popbox.io/?hn
======
Havoc
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.

------
AlyssaRowan
What, this chestnut _again_?

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.

~~~
diafygi
Examples of similar products that meet your requirements?

~~~
david_shaw
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.

~~~
AlyssaRowan
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/](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 trust _ed_ by some, but they
have a long way to go to be trust _worthy_.

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.

~~~
jfindley
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.

------
gry
In the about page:

> 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.

[1] [http://tonyarcieri.com/whats-wrong-with-
webcrypto](http://tonyarcieri.com/whats-wrong-with-webcrypto)

~~~
diafygi
> 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] - Pervasive Monitoring Is an Attack -
[http://tools.ietf.org/html/rfc7258](http://tools.ietf.org/html/rfc7258)

~~~
gry
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_.

EDIT: clarity

~~~
superuser2
OT, but: on the _hook_. On the lam means you are trying to escape (re)capture
by the legal system.

~~~
gry
Thanks, you're right. I've misused the word for ages.

------
lettergram
First, I love the website layout. Kudos!

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. :)

------
barsonme
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.

------
DanBlake
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.

------
cheyne
There's a few things missing with this app. The data may be encrypted, but its
still available to anyone with the URL?

I think [https://www.noteshred.com](https://www.noteshred.com) does this
better. It requires a password to access and logs access information.

You can also demo and see their client side encryption features working here:
[https://www.noteshred.com/client-side-
encryption](https://www.noteshred.com/client-side-encryption)

~~~
DanBlake
>There's a few things missing with this app. The data may be encrypted, but
its still available to anyone with the URL?

>I think [https://www.noteshred.com](https://www.noteshred.com) does this
better. It requires a password to access and logs access information.

>You can also demo and see their client side encryption features working here:
[https://www.noteshred.com/client-side-
encryption](https://www.noteshred.com/client-side-encryption)

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.

------
jackpirate
I don't know what it means that the message "self destructs." I brief glance
in the FAQ and the about page didn't help either.

------
gizmo686
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.

~~~
diafygi
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.

------
jonahx
See also: [https://onetimesecret.com/](https://onetimesecret.com/)

------
droope
It says "self-destructing" and "encrypted".

How does this encryption protect me from anything, since the server controls
the key?

I also have no proof of the destruction of the file, once that time has
passed.

------
timmclean
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?

------
higherpurpose
Don't think I have any reason to use this over the P2P
[https://www.sharefest.me](https://www.sharefest.me)

~~~
Fastidious
Not related to the original post, but sharefest.me does not work with all
browsers.

------
yeleti
See also The SVYFT Project : [https://www.svyft.com](https://www.svyft.com)

* i'm part of the project.

------
jsfour
Assuming it works, awesome concept!

I was looking for something like this a few weeks ago.

