

NoPlainText: One time, browser-encrypted messaging - zotz
https://noplaintext.com

======
SamReidHughes
It uses a 47.6 bit key?

Generated by Math.random()? (According to MDN, that's seeded from the current
time...)

Update: Another problem is that there is no message authentication. The server
can flip individual bits within the message.

Update: Also, obviously, we have to trust noplaintext.com to send us an
uncompromised web page.

But wait! View source!

<script type="text/javascript" async="" src="[https://ssl.google-
analytics.com/ga.js></script>](https://ssl.google-
analytics.com/ga.js></script>);

We _also_ have to trust Google, specifically google-analytics.com not to steal
the message.

<script type="text/javascript" src="[https://crypto-
js.googlecode.com/files/2.5.3-crypto-sha1-hma...](https://crypto-
js.googlecode.com/files/2.5.3-crypto-sha1-hmac-pbkdf2-blockmodes-
aes.js></script>);

AHHHHHHHHHHHH!

We _also_ have to trust whoever controls the crypto-js project _and_ the
people running googlecode.com.

~~~
ketralnis
> We also have to trust whoever controls the crypto-js project and the people
> running googlecode.com.

And every router between them and googlecode.com (or whatever that resolves to
in their DNS situation!)

~~~
SamReidHughes
The link is an HTTPS link so that's not true. You merely have to trust every
CA.

------
BCM43
The message you get when running noscript is almost condescending.

 _Please enable Javascript to use NoPlaintext._

 _Javascript is an integral part of modern websites and is very easy to
enable._

~~~
coderdude
Get used to it. People who make and own web sites do not like noscript users
or users who disable JS. For reasons that are perfectly reasonable, too:

\- No ads (= no revenue if you rely on ads and get paid per mille)

\- No analytics (frustrating when your site is being used in all sorts of
interesting ways but your information is limited to log files)

\- No behavior layer (great, another intentionally crippled client). You can
bring up graceful degradation but I'm fairly positive that trend came as a
result of spotty JS support. That era of spotty JS support has mostly come to
an end, at least as far as default configurations are concerned.

From the perspective of many (most?) of the sites you'll visit, js-disabled
clients are merely leeches. Like bots silently hitting your server logs,
slurping up your content for who knows why. (Unless you're otherwise creating
content for them, such as posting on HN -- or a paying customer.)

Just my point of view, but I'm willing to bet that other creators feel the
same way.

~~~
oblique63
I myself am a 'creator', but I would never think of no-script users as
"leeches" or "bots". The web is not some gated community (nor should it ever
turn into one), and everyone has the right to browse as they please. If they
don't think the value added by my site's interactivity is worthwhile enough
for them to enable their javascript, I'd much rather hear why, than present
them with a snarky remark about the 'modern web'; that way I can at least try
to improve the site's message so that future no-script users feel compelled to
use the site as it's meant to be used.

I used to be a no-script user too for a time, and while I stopped using it
because it became too inconvenient, I think it's everyone's prerogative to
decide whether or not a site can track them or show them ads. It might be
annoying for sites whose only means of monetization is ads, but again, the web
is free and that's just the nature of the beast.

~~~
coderdude
I seem to find myself tip-toeing through a minefield of things I didn't say or
mean to imply. I'm not sure where the gated community thing came from. They
aren't even related concepts. (Though I wouldn't mind hearing why you consider
them so closely related.) Everyone has the right to browse as they please, I
agree with you on that point. I don't think noscript users should get upset
when a site owner points out that their client is crippled if the site owner
wasn't delicate with their feelings in the process. It's a hindrance and an
annoyance (a conclusion that you even shared as a noscript _user_ over time).

>>I think it's everyone's prerogative to decide whether or not a site can
track them or show them ads

Or even work properly. (I felt that was important to include too since it's a
big deal.)

~~~
oblique63
Gated communities are exclusive by definition, so whenever a site posts up a
message saying essentially 'get with the times', I feel that basically treats
no-script users as a community that's being excluded. It's largely a
semantic/communication issue at this point, but there is a difference between
helping someone out by pointing them in the right direction ("oh hey, it seems
your javascript is off right now, but if you turn it on for us we can offer
you these cool features..."), and saying they aren't welcome here ("why is
your javascript off? every modern website uses it!"/"you're taking away from
our ad revenue!").

Now I'm not a huge 'graceful degradation' advocate by any means, since a lot
of sites (or 'apps' rather) would become totally useless without js, but all
those no-script users decided to block javascript for a reason and they know
very well what blocking javascript will entail, so I see no reason to be
condescending towards them or give them anything more than a simple
reminder/value-proposition so that they can turn js on for our sites.

We're probably on the same page, I just think the case against people who
block javascript is overstated; these users are a minority, and they can
evaluate it on their own whether your site's functionality is worth enabling
javascript for.

------
jugglinmike
There was a good discussion on this kind of service a while back--check out
"Javascript Cryptography Considered Harmful"

HN: <http://news.ycombinator.com/item?id=2935220> Direct link:
<http://www.matasano.com/articles/javascript-cryptography/>

~~~
Estragon
If the messaging was peer-to-peer, the objections in that post wouldn't apply
quite as much. Then you would connect to the NoPlainText server to download
the JS client by HTTPS, and use it to encrypt the direct connections to your
messaging partners. I think JS crypto could still sensibly be used for this
kind of "separation of trust" problem.

For instance, I am considering a service at the moment which would involve
people uploading confidential information. The uploads will be fairly large,
so a lot of bandwidth will be required (optimistically assuming it gets
traction.) One architecture I am considering is a small dedicated HTTPS server
which provides a self-contained webpage-plus-JS program to encrypt the upload
and send it for storage on Amazon S3. Then I will pull the results off Amazon
and decrypt them on a machine which is not even connected to the network. The
advantage to this architecture is that it will scale arbitrarily but require
me to secure only relatively modest dedicated resources, despite being used
for transmission of confidential information. Because it uses a dedicated
HTTPS server serving a self-contained page doing all the crypto, it avoids
tptacek's objections to JS crypto in the browser (E.g., the server can provide
the random seed in the JS itself, HTTPS prevents MITM attacks, etc.)

------
wwwtyro
I don't get it. If you're emailing the link anyway, wouldn't someone that
intercepts the email have access to the link? Is the point that your recipient
opens it before an interceptor does?

I'ts also unclear to me how the encryption scheme is working here. I don't see
how it's impossible for the server to decrypt the message when it is sending
you everything you need to decrypt it when you click the link. Am I missing
something?

~~~
zipdog
I think its aimed at medium priority info where convenience of both parties is
a factor. It seems the point is to send information that, although it could
still be compromised, you will know if that happens because your recipient
won't be able to access the message. So you have peace of mind that there was
no silent observation of the info en route. I think if you were trying to send
information that you didn't want to be compromised at all, you'd eschew the
convenience of this and use proper encryption on the message (both parties PGP
keys, etc).

Also, from what I understand, the system requires total trust in the
provider's servers to do their job. That is no different than trusting that an
anonymous email provider is doing their job (not storing logs, etc) and
there's a proven market for that (I think).

------
lucian1900
Except it uses crypto written in JavaScript, which is inherently broken.

~~~
wwwtyro
Isn't it fair to say, though, that _all_ crypto is broken to some degree, and
that javascript crypto lies somewhere on that that continuum? Surely AES with
a 256 bit key that you've downloaded to your browser and can inspect is better
than rot13?

~~~
lucian1900
No, it's not fair to say that at all. The website can MITM you at any time,
even without changing the crypto code it sends you.

Native crypto clients don't have this particular vulnerability.

~~~
wwwtyro
> The website can MITM you at any time, even without changing the crypto code
> it sends you.

I am not following you. If they send you the code, can't you inspect it? And
if you vet it, where's the concern for the MITM attack? You already have the
code.

> Native crypto clients don't have this particular vulnerability.

Isn't it exactly the same? You have to download the code at some point.

~~~
lucian1900
The website or any of the domains it includes JS from can at any time inject
some JS into your page, which could maybe replace AES with Base64, or anything
else it wished to do.

Native crypto clients don't arbitrarily download code from several domains
every time you turn on your app.

~~~
lucian1900
And I forgot to add, there's no way you can protect against other side-channel
attacks like timing attacks. JS as it is today makes it impossible.

~~~
wwwtyro
What keeps JS from protecting against timing attacks?

Even so, I would argue that it's fair to say that this pushes it along a
continuum towards less secure, not that it is "broken".

------
DanWaterworth
The problem is I have no assurance that the plain text never reaches the
server except for your word for it. It also doesn't solve the problem if the
message can be intercepted before the intended recipient can read it.

~~~
brownbat
Moreover, if the server stores enough information for a recipient to read the
message, then the server effectively stores the message.

~~~
brownbat
Hmm, oh, I think the stuff after the hash is the decryption key, and we're
assuming the server throws it away.

We still require a trusted third party here.

~~~
StavrosK
The HTML anchor never reaches the server in the request, it's for local use
only. Of course, malicious JS on the page can always send it anywhere.

------
vparat
This is similar to an app I wrote for fun to learn some nodejs,
<http://www.selinked.com>. I _think_ it's pretty secure but I am no encryption
expert. Main difference is that I store nothing but the encrypted messages and
for the chat and group chat nothing at all. You can also change the type of
encryption it uses, all js browser side. Group chat and chat are half baked,
there are a still few bugs in there. Would love some feedback on it.

------
Sami_Lehtinen
It's quite similar what I made just for fun: <https://off-the-
record.appspot.com/> Of course I could add javascript AES encryption, maybe
I'll do it. I have also planned to use Raspberry Pi as server instead of
Google's servers.

------
septnuits
Similar to <https://privnote.com>, but slightly quicker to use. It would be
neat to have an API-service like this, that could be useful for building
messaging plugins.

------
Boxer
I can just imagine receiving a link like this while I'm on a spotty WLAN,
trying to load it, it not loading properly, refreshing, and having it be
"expired".

------
abava
Check out secure notes: <http://sn.linkstore.ru> And it has got simple API

------
stcredzero
Doesn't work at all in Mobile Safari on the iPad with iOS 5.1

------
vizzah
nice idea to keep the key after the '#' tag. add binary data, 1mb would be
enough, and you'll rock.

