> 1) third party broad spectrum surveillance from cromnibus.
Metadata wise this is a real problem with the system as currently
envisaged, but would frankly apply to any hosted-ciphertext platform.
> “Instead of dealing with key storage, Peerio generates a user’s
> private key from his passphrase every time he or she logs in.”
> from:
> http://www.wired.com/2015/01/peerio-free-encryption-app/
> That may or may not accurately describe the process, however.
This is correct; Peerio uses MiniLock under the hood for crypto, and
private keys for minilock are generated deterministically; when you “log
out” the key is not stored permanently (although JS can’t wipe RAM so a
closer-to-metal client would be nice).
> 3) Free, or not?
> Apparently there is a paid option, and a free option initially at
> launch, there is a open source repository on github. To the extent
> that the crypto is tied to a company (kind of assumed, if there is a
> paid option and there is an LLC or something like that), then the
> corporation is vulnerable to being shut down or at the very least
> “conditioned” ~ being told what to do when “crypto licenses” come
They’re in free beta, my understanding is they’ll charge for storage.
There’s not much that can be done to wind back the crypto as it’s all
client-side, and if their server were shut down, as I’ve mentioned
before, the server behaviour is all documented on Github.
One useful way to look at this: GPG is what most recommend for crypto,
but it’s metadata rich and requires usually closed platforms to
distribute ciphertexts (you may not use Yahooglesoft but your recipients
will usually). In recent discussions on this list, the use of a
centralised key distribution *company*, keybase, has also been accepted
to some extent (though I’m not too happy..).
miniLock is designed as a spiritual descendent of PGP with many use-case
improvements and a much simpler threat model. You can use miniLock
instead of GPG across email, and it will leak less metadata than GPG by
virtue of using ephemeral keys that don’t directly link a message to its
sender or recipients.
Peerio is like Gmail plus Keybase for miniLock; it serves exactly those
purposes. We would all (me emphatically included) rather if it ran on a
store/forward PGP mixnet, provided it retained good UX to appeal to the
masses, but right now, it’s a centralised service that hides the content
and format of communications while unavoidably having total access to
the metadata of from who, to whom, and when.
So yea, centralised and closed ain’t good. They are the warts I’d like
to see fixed with a federated and/or mixed backend. But the frontend is
just as open as GPG is, and we already generally endorse the use of open
front-ends to work around closed back-ends.
I may be motivated soon to re-implement miniLock in Go as a learning
excercise (still a Golang noob here), in which case it could be a short
hop from there to a server/client implementation for Peerio, too. But,
I’m not committed to that yet and have written not an `iota` of code
yet, so by all means beat me to it