Awesome Stuff: More Crowdfunding Attempts At Private And Secure Communications
from the creating-a-market dept
Back in July, we did one of our weekly awesome stuff crowdfunding posts about a variety of new crowdfunding projects designed to keep communications and activites online private and away from snooping governments. That was only a month into the NSA revelations. Last month, we wrote about a few more projects that would help people keep their data private, including the mail service Mailpile, who was back in the news this week. We’ve suggested that all these revelations would lead a number of individuals and companies to look to build more secure and private systems, so we’re back this week with two more crowdfunding projects that put security and privacy at the top of their lists.
- First up, we’ve got Trsst, which is more or less a distributed secure RSS-based platform that can be used to effectively create Twitter/Tumblr/blog-like features for public posting, but which also allows encrypted posting via public key encryption.
- Next up is Mailelf, who, like MailPile, are trying to build a much easier to use encrypted email system. There are a few things in the description that leave me scratching my head about what exactly it is they’re building, and frankly, the fact that it’s not entirely clear is a bit of a strike against the whole system. Is it local client software? Is it more like Mailvelope? Unclear. But it’s still good to see more attempts at making encrypted email much more user-friendly.
It’s definitely good to see more projects with this sort of focus, though it feels like we need a few more big projects, perhaps from larger companies that are much more focused on true security combined with ease of use before it really takes off.
Filed Under: awesome stuff, email, encryption, privacy, rss, security
Comments on “Awesome Stuff: More Crowdfunding Attempts At Private And Secure Communications”
These flailing and misguided email systems
It seems like a week doesn’t go by that someone doesn’t launch yet another feeble over-hyped attempt to “fix email”.
Invariably these projects fail to take into account decades of real-world experience, and equally invariably, they prove to be insecure even before they’re launched. Most of them make the enormous strategic design error of relying on a piece of software called “a web browser”, a choice which nicely maximizes the attack surface available to adversaries. Nearly all of them fail to ban HTML markup, an error which isn’t merely enormous, but catastrophic. A substantial number fail to comply with BCP 38. And so on.
The intentions are nice (well, except for the ones that are out-and-out scams). But the execution is miserable. Free clue, kids: if you haven’t personally administered an Internet-facing mail system which has at least 10,000 users (and no, Exchange doesn’t count) for at least 10 years, then you have no shot. Even if you have done that, you may not have much of one unless you’ve invested a great deal of time into carefully studying the success and failure of various real-world email systems.
Re: These flailing and misguided email systems
And your proof of this is… what, exactly?
And your proof of this is… what, exactly?
And your proof of this is… what, exactly?
And your proof of this is… what, exactly? In particular, please feel free to explain how a well-designed single-page application, backed by a well-designed Web service protocol, is intrinsically less secure than a desktop email program and existing standard email protocols.
And your proof of the catastrophic nature is… what, exactly? Now, if they don’t sanitize the HTML (e.g., strip out JavaScript, , etc.), I will agree with your assessment. But that’s a reasonably well-understood problem, employed in all sorts of Web apps, beyond Web-based email clients.
This would be relevant only for those projects that are offering hosted services, rather than software. Ingress filtering is incumbent upon the host, not the email software itself.
I think your second paragraph is reasonable (if a bit hyperbolic), and I think your general attitude (email is hard) is spot-on, but your first paragraph suffers from a surplus of hand-waving.
Re: Re: These flailing and misguided email systems
An offhand comment in TechDirt is not the place where I’m going to lay out a rigorous defense of those statements. I’ve done so elsewhere, and continue to do so. (Others have done the same, to varying degrees.)
However, I’m going to address two points, briefly.
First, “using a web browser” to access one’s email is a singularly bad idea at a fundamental level because the web browser (unless it’s something like w3m) has WAY too many capabilities. Contrast this with using an email client (and email protocols, e.g. SMTP/POP/IMAP) both of which are tremendously more limited, thus greatly reducing the opportunities for mischief. (Note : not to zero, though. That’d be too covenient.) We see broken/exploited code in browsers all day every day. We’ve seen it for many years. “Writing a secure web browser” is NOT a solved problem in computing and there is no sign it’ll be signed any time soon. So the hand-waving that’s taking place isn’t mine: it’s the people who are saying “oh, just use your browser” even though the typical browser out there is a cobbled-together piece of crap.
In other words, “webmail” is a horrible idea and any project using it may be immediately dismissed, with prejudice, as it has no chance of achieving end-to-end operational security in the real world.
Second point: actually, I’m going to invite you to think about this one for a while because you seem like a rather clueful individual and I think you’ll get it pretty quickly. Go find some email client that marks up messages with HTML — either a standalone client per se or something that runs in a browser. Now: use that client to send yourself 5 messages with different content. Pull those messages into a text editor. Strip out the content, leave the rest. Compare. Now, while staring at those stripped-of-content messages, consider how similar they are. Now consider: does this have value for an adversary who happens to be capturing packets flowing over an IMAPS connection?
Now you’re right: my tone is somewhat hyperbolic because I’m annoyed. I would like for someone to get this right, because that would be very nice. But what I’ve observed is failure after failure, and one of the unfortunate byproducts of that is that people are beginning to conclude that email itself is the problem. (And there is some basis for that: if we had SMTP to do over again today, no doubt we’d do it differently.) But the real problem with these services is that the people trying to launch them are not hardened, bitter, cynical, mail system admins who’ve had enough bad experiences to know what not to do.
Re: Re: Re: These flailing and misguided email systems
I agree with most of what you’ve written, but I think we may be closer to a secure web browser (however limited) than you say.
Man, I hope so. It would be a shame to have to completely abandon the internet at this late date. As someone who’s used it from its first years, I’m just sick over what’s being done to it by corporate/government interests who mean us no good.
I’m glad you’re holding people who are trying to build better internet communications to a high standard, but that’s only have the problem. We also have to make sure those people are who they say they are. I’m not sure it’s possible to be too paranoid these days.
Re: Re: Re:2 These flailing and misguided email systems
You seem to think that avoiding web browsers means “abandon[ing] the internet”. This is quite false, which makes me doubt you’ve “used [the internet] since its first years”. Not using a web browser makes using “the web” difficult but not impossible; more importantly, “the web” is not “the internet”. People were using the internet — for email, file transfers, etc — way before TB-L introduced the technology which led to the web’s existence.
Bitmessage
and FreeNet
and, storing the encrypted message in a Namecoin, to be decrypted by the recipient with PGP or something
and, layers of SSH encrypted tunnels from fully Libre systems
Syndie
i2p
The one thing we don’t have is a fucking bridge from any of those systems to and from that “name@domain.ext” scheme that everyone in the world is using for ALL of the Serious Business.
Re: Bitmessage
Maybe the “serious business” isn’t all it’s cracked up to be, despite all the marketing efforts.
Awesome Stuff: More Crowdfunding Attempts At Private And Secure Communications
How can we be sure that the NSA is not having some of its agents infiltrate this and submit software that has the encryption the NSA wants it to have.
Re: Awesome Stuff: More Crowdfunding Attempts At Private And Secure Communications
How can we be sure that the NSA is not having some of its agents infiltrate this and submit software that has the encryption the NSA wants it to have.
We can examine the code.
(Or, experts like Bruce Schneier, whom we trust, can examine it.)
Re: Re: Awesome Stuff: More Crowdfunding Attempts At Private And Secure Communications
Schneier is an expert cryptographer, and there are few people in the world who can match his qualifications in that field.
But he’s not the guy I’d want looking at code for buffer overflows, because that’s not his primary area of expertise. There are other people who I’d want checking that. Same for chip-level backdoors, inherent protocol weaknesses, and so on.
In other words, trying to QA the entire stack: the operating system, the network protocols, the cryptography, the application service software, the applications, etc. is a massive job that will take coordinated effort between a heck of a lot of people.
Complicating this is that (thanks to the NSA) we don’t know who’s on the side of security and privacy, and who’s not.
Complicating this further is that we don’t know how deep the rabbit hole goes.
Complicating this still further is that even if get past the last three problems (thereby doing three impossible things before breakfast) there’s still the problem of end-users, who nearly universally prefer convenience over security. (Example: everyone with a smartphone, everyone running Windows or MacOS, everyone with a net-connected gaming system, everyone using Google or Yahoo or MSN/Hotmail, everyone on any form of “social media/network”. All of these people have made enormous mistakes that have and will neatly undercut all the effort I just listed above, even if it’s successful.)
Dealing with that may be the hardest task of all. And I’m not sure it’s worth it.
Re: Re: Re: Awesome Stuff: More Crowdfunding Attempts At Private And Secure Communications
You don’t know much about software development do you…
Honestly I don’t even know where to start with this mess. The cryptography has nothing to do with buffer overflows so barely 10% into your post you’ve gone off the rails.
Sure buffer overflow is a hack, but that is irrelevant to if you are getting your email or logging into your WoW account.
more big projects, perhaps from larger companies
I can not trust large companies.
Oh and by the way Phil Zimmerman has been vindicated.
They (NSA) with CrowdFund this.. That’s there 1st in.
Ya know, legally if you want to know what people are thinking about a subject, simply by AdWords on Google – bet the NSA has.
Folks, I think that the crowdsourcing is the way to go!!!
[Meta] How does one make kickstarter embeds show with NoScript?
Does anyone here know how to configure NoScript not to completely hide the Kickstarter and Indiegogo embeds on the weekly Awesome Stuff posts? “Temporarily allow all this page” does nothing. I don’t even see Kickstarter there, nor placeholders, nor items under Blocked Objects. Iframe blocking off doesn’t help. Firefox’s object inspector shows the iframe and contained html, head, and body elements but shows the latter two as empty. Manually going to Kickstarter and adding it to Noscript’s trusted site list doesn’t make the embeds show on Techdirt pages either. I’m probably missing something “obvious”, but I can’t find it, and googling availed me of nothing. So … anyone?