Update - June 10, 2016: Despite the criticisms outlined here well over two years ago, Unseen.is has not made any effort to resolve them. They are removing critical support questions, and their cryptography is still most likely broken.
My recommendation remains unchanged; avoid Unseen.is at all costs.
It took a bit longer than I expected before I had the time to make this post, but here it finally is.
Not too long ago, I ran across some Anonymous-related Twitter accounts promoting Unseen.is. Unseen is, in their own words, a "private and secure messaging, calling and e-mail application" - which seems great, but really isn't. As it turns out, there are plenty of reasons why you shouldn't ever use them.
They seem to use home-grown cryptography.
The mortal sin of cryptography. You should never, ever, ever roll your own cryptography - or rather, if you do, you shouldn't actually use it in production, or publish it at all. Cryptography is hard to do right, and you will almost certainly fuck up, exposing all your users in the process.
The unseen.is FAQ (mirror) page says the following:
Messages on our service are sent using 4096-bit encryption, which is considered extremely strong. you generate your keys with extremely strong lattice based encryption. To that, we add an advanced symmetrical encryption which is very easy to use with keys 16x longer than those found in AES256, an industry standard. According to our engineers, this will take 23840 times longer to crack than aes256, which is commonly known as "military grade" encryption.
Aside from the clear snake-oil marketing there - the amount of bits is absolutely meaningless without context - there is absolutely no mention of what algorithm they use. None whatsoever. According to a thread on StackExchange, they do actually use an existing algorithm, but misrepresent the implications of it in their FAQ. In reality, we have no idea whether they rolled their own or not, because...
It's closed source.
Aside from the ethical side of open-source versus closed-source software, there is a very simple practical reason for open-sourcing any code related to security or cryptography: it allows anybody to audit it. Open-source in cryptography is an absolute necessity. This is not a new idea - it has been around since at least the late 19th century as Kerckhoffs's principle, and was a leading principle behind, for example, the legendary Enigma encryption machines. Even if you're not willing to let people reuse and redistribute your code, your code should at the very least be publicly visible and auditable.
Unseen's code is not. It's completely proprietary, opaque, and unavailable for review. Realistically, you have no idea what the code does, how the cryptography is implemented, or whether it's doing what it advertises at all. You have to trust that it really is as secure as they claim. And if you're going to trust an unfamiliar single party anyway, then why are you looking for a 'private and secure' communications platform in the first place?
You get less security on a free account.
From the FAQ:
The free version provides a modest amount of free encrypted storage and allows sharing of files of up to 50MB. The premium version provides 2GB of encrypted storage, file sharing up to 40GB, group audio/video calling, and premium users can generate and store their own private key.
Perhaps it'd be more appropriate to say "no security". This text implies that, on a free account, Unseen would generate and store your private key. This would mean, quite simply, that they could impersonate you and/or decrypt anything at will. At this point, you're effectively just relying on trusting them not to do so - there's absolutely nothing left of the original client-side-cryptography model. Again, why were you looking for a 'private and secure' service to begin with?
They rely on security through obscurity
From the FAQ:
The chat feature is only from Unseen user to Unseen user.. For chat we use a very specific encryption that no other services use, so they would never be able to read the messages you sent them. As a result the chat is a closed system. This makes the chat system significantly more secure.
Either they are really bad at wording things, or they claim that their chat being a "closed system" makes it "significantly more secure". This is pretty much a textbook example of "security through obscurity", and is the second mortal sin in cryptography. It is completely fallacious reasoning, and the biggest red flag you could possibly find for a supposedly 'secure' communications provider. There's really not much more to be said about this, other than emphasizing yet again how incredibly bad this is.
They evade critical questions
From the FAQ:
Isn’t a web service less secure?
Our services are developed to provide the highest level of security widely available on the web. We expect to continue improving and developing better solutions to protect your information. Applications specific to a particular operating system do offer more security, but the web is extremely convenient because you can get your messages anywhere, even if you are borrowing someone elses computer.
Rather than giving a straight-to-the-point answer, they bury an almost tacit admission in a pile of snake-oil marketing. They're clearly more interested in telling you how 'secure' they are, than they are in honestly informing you of how inherently broken browser cryptography is. Their choice to prioritize marketing over honest information, should give you a hint as to whether you should trust them with your data or security.
They are not sufficiently technically competent.
A quick search on Google turned up this very interesting article (mirror), which states the following:
The first thing you’ll notice on line 10 (London) and line 17 (the last router in Iceland) are the large percentage of lost packets. This degrades the performance getting to the server in Iceland. Line 17 is the last router you touch at our data center in Iceland, it’s just a few feet away from our servers and you can see the other hops are all behaving normally. According to our ISP, the only customer that was having problems with their switch was Unseen.is. That shows targeting of packets based on a web site.
Notice the high percentage of dropped packets at the same time in London, over 40%.
Once our ISP made a fix to the router in Iceland, the next morning, notice what happened to the router in London:
Now, 88% of the packets were being dropped in London!! Try to get through that!!
Kind of interesting that as soon as one of the routers got repaired that the other one acted up even more?!? This is definitely a good way to block traffic to a site, just degrade the performance until people can’t get through, but don’t make it a 100% blockage. It would be a good bet that they also have tools to see exactly who and how many people are getting bounced from a web page or site.
[...]
First, we’re encouraged about the state of our encryption. It must be pretty good because it takes a lot of work for a security agency to do a truck roll in Finland to hack into our new product manager’s computer and then to control these routers to degrade the traffic to our web site. They wouldn’t waste their time on easily broken “military grade” encryption.
A few things become painfully obvious from this excerpt.
- The person who wrote this - who is part of Unseen.is, according to the article metadata - lacks basic and essential knowledge of networking, and how ICMP is treated by routers. This phenomenon is very easily explained by understanding ICMP de-prioritization (or your term of choice), and almost certainly has nothing to do with censorship of any kind.
- They use their - incorrect - conclusion about these traceroutes, as a reason to pat themselves on the back for "having such awesome encryption". This is exactly the wrong attitude to take - if one really does roll their own cryptography, they should be constantly alert and distrusting of their own implementation, and never assume that it is infallible - especially not on such shaky grounds as these.
- They employ conspiracy thinking. At the vaguest hint of a phenomenon that could possibly be explained as a conspiracy against them, they grab the chance to pinpoint that as the reason - critical thinking completely absent. And that brings us to the next point...
They are over-the-top conspiracy theorists.
It's not just their short-circuited reasoning that "there is packet loss, so there must be governments trying to block us" - the actual roots of Unseen are in the conspiracy theorist scene. Some digging brought up this thread (mirror), which clearly outlines a connection between Unseen.is and BeforeItsNews.com, a connection that is even confirmed in this post (mirror) on the Unseen.is blog.
3 Are we linked to Before It’s News? The companies are completely separate and independent, but we share many of the same shareholders. Before It’s News uses the same mailing box to save money. In fact, we got the idea for Unseen from running Before It’s News.
To provide a little context, BeforeItsNews is apparently so bad, that even AboveTopSecret doesn't want their content (mirror).
To run a company providing 'private and secure' communications services, you need to be level-headed. You need to be able to rationally analyze situations, and rationally mitigate threats. This is completely in contrast with conspiracy thinking, where the default modus operandi is to jump to conclusions and "take sides", regardless of any information at your disposal.
They claim to be located in Iceland.
Regardless of whether they actually are (and the traceroute screenshots certainly raise some questions about that), why would this matter? If they offered truly private and secure services - which means no single point of failure, fully client-side cryptography, no ability for Unseen.is to compromise anybody's security - it simply wouldn't matter where they are located, or what the local privacy-related legislation is like. That they feel the need to use "Iceland" as a marketing point, implies that they are unlikely to be as secure as they claim.
Perhaps there are some problems I missed, but I feel that these points in themselves are more than enough to never use Unseen.is.
If you value your security and privacy, I suggest you take the same approach.