It's even worse than that. The sources of entropy you have available to you in the browser are servers which you obviously can't use in this case and the user which would be a UX disaster.
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.
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.
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.)
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.
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.)
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?
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).
The claim of how the server doesn't have the information to decrypt seems valid. The key is computed locally and never sent to the sever. That doesn't make this a good idea, but I see plenty of comments already pointing to the specifics of bad RNG, crypto in Javascript being problematic, etc.
> Is the point that your recipient opens it before an interceptor does?
Yes, the idea is simply to avoid having the sensitive data stored somewhere forever, like on their gmail account. Obviously if you think you have a 3rd party listening in on your on-going conversation, you need something more secure.
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?
> 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.
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.
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.
I think the appeal of the service is the convenience. If the message was important enough to warrant no third-party trust, you'd just go the extra hassle of PGP keys from both parties, etc.
The target seems to be people who were previously just emailing their confidential info. And though trust is an issue, people happily trust anonymous emailers, commercial encryption providers (where source is not available), etc.
How is this different than any other security functionality, though? Unless you plan to cipher your message yourself, you always need to trust that whatever encryption you're using works as designed.
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.
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.
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.
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".
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>;
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...;
AHHHHHHHHHHHH!
We also have to trust whoever controls the crypto-js project and the people running googlecode.com.