
Trsst: a distributed secure blog platform for the open web - olafleur
http://www.kickstarter.com/projects/1904431672/trsst-a-distributed-secure-blog-platform-for-the-o
======
krcz
What programming language do you plan to use for the reference implementation?

~~~
mpowers
JS on the client, and that's the important bit where all the crypto happens.
Likely Java on the server, basically a drop-in servlet for any Tomcat, but
still TBD.

~~~
e12e
I hope you at least consider a java client as well, so there will be one
implementation that is actually usable - as javascript and crypto doesn't mix
(unless something is happening wrt api-support in the various
engines/browsers? But then I guess you'd say html5, not "javascript").

Should be much quicker to develop a common library for use by the server and a
(webstart) client - than to do two separate implementations? Also some of the
code (and most of the interfaces) could probably be used on Android as well.

If you _are_ doing javascript wouldn't nodejs on the server make sense?

~~~
mpowers
If normal people are going to use it, it has to run in a browser, hence JS.
There are working open source crypto libs in JS today, and kind of the nice
thing about them is that they're _not_ compiled, so (if unobfuscated) you can
literally just inspect the source.

That said, we plan to generate keys like bitcoin does, so there if you have a
bitcoin library in your language of choice, that part is done.

The server code will probably be less useful because there are so many
choices, everyone's got their own preferences, and the server is pretty dumb
compared to the client. Our leaning is to go with apache tomcat mainly because
it's apache and it's widely deployed and, not least, it's what we use.

~~~
tptacek
No, you can't. It's a pervasive and harmful meme that JS crypto code is easy
to inspect. But it's not:

* If 100 different users are served the code, it's easy to pick 1 unsophisticated user out and serve them something different.

* Even if your users are sophisticated, they effectively have to install the code _every time they use it_ , so any inspection they did yesterday will help them not-at-all today

* Browser Javascript code is influenced from all sorts of places across the DOM, meaning that you need element- by- element, attribute- by- attribute inspection of the entire page context (and this is before we get into things like caching) to have any clue what a piece of JS code might be doing

* The browser itself offers you no mechanism to hash and verify the whole runtime, so there's no way to lock in a specific inspected cryptosystem; even if you have the SHA2 hashes for your crypto .js, you won't have it for every point in the DOM that can override methods in that code

Leaning on browser javascript for cryptography is a bad idea that, I think,
shows a fundamental disrespect for the security needs of actual real people
who will be fooled into relying on it. I strongly advise you to go in some
different direction.

~~~
mpowers
If your device or browser is compromised, you have bigger problems than
someone subtly modifying your js runtime.

Similarly if a host is compromised to serve bad js files. We can't solve
endpoint security. And clearly NSA is now very good at breaking the endpoint
at both ends.

I agree that it's not useful to say "just inspect the code"; no one really
inspects their binary executables either, but we're committed to let you do
so.

Let me be clear that JS is not required; it's just how we're making our
reference client because we don't believe most people are going to download a
custom client.

You can write a working client with bash+openSSL+curl if you want. The whole
thing is simply signed text snippets over http.

~~~
timtadh
> If your device or _browser_ is compromised, you have bigger problems than
> someone subtly modifying your js runtime.

It is trivial to compromise the browser context of the page. In the case of a
browser bug another tab can interact badly with the current tab. In the case
of a MITM attack on (sadly quite possible given the potential adversary) the
attacker can modify the JS in flight to the browser. In the case of an
externally loaded resource embedded on the page that resource may modify the
execution of your crypto. There are also CSFR, XSS and other JS
vulnerabilities to account for.

Javascript is a hopelessly bad place to do crypto. Consider doing an signed
browser extension that does this on the desktop and native apps on the phone.
I would also suggest a native app on the desktop as well. People seem to
really like them for twitter.

~~~
mpowers
I appreciate your concern, but you can't fault JS for browser bugs or OS bugs.

It's also not clear to me why you're any more secure with a signed browser
extension or native app. Just because it's signed doesn't mean you can trust
it any more than you can trust JS that you download via HTTPS from a server.
What's worse, you didn't compile it from source, so how can you know there's
nothing sinister lurking in there?

You are correct that people like native apps for their microblogging, and we
want to encourage many native, hardened, peer-reviewed implementations for
every platform imaginable.

Because the client is just appending signed entries to the end of an RSS file,
send pushing and pulling those files over http, you could write a nice client
running inside emacs (if you trusted your os crypto libs).

~~~
e12e
> It's also not clear to me why you're any more secure with a signed browser
> extension or native app. Just because it's signed doesn't mean you can trust
> it any more than you can trust JS that you download via HTTPS from a server.

For one, one would hope that a team takes more care to manage their private
(code) signing key, than their ssl private key. The signing key should
probably be on an air gapped system. That isn't _feasible_ with the key use
for https/tls.

You could compromise ftp-servers all day without being able to generate a
valid signature for your bad code.

Now, on the subject of: Wouldn't it be possible, in the future, to create
mechanism where we could deliver signed js code in a more secure manner than
we do today? Absolutely. But it that future doesn't seem to be arriving any
time soon.

------
walid
Reminds me of App.net but with many price points and a Bitcoin twist. I hope
they succeed because we need all kinds of new ideas experimented with.

~~~
mpowers
Our thing is that we: (1) extend RSS to support self-signed/self-encrypted
entries, (2) specify rest apis for http servers to exchange RSS entries (kind
of like NNTP).

We'll make a reference implementation, but we want and need many providers to
experiment with price points and service options.

More importantly, anyone can roll-their-own provider on their server.

------
dholowiski
Looks like you posted this back on 8/18 as well. I guess you can get around
the rules by adding/removing a # from the URL.

~~~
mpowers
I didn't post this. But feel free to make unsubstantiated ad hominem attacks,
because: the internet. :)

------
ctz
'decentralized' yet needs $15000 PA for server hosting?

~~~
walid
As decentralized as WordPress. The project is open source.

~~~
aray
So why not start out as an open source project, then kickstart the hosting/etc
after its been built and tested?

Many open source software projects (some huge ones today) came out of the
woodwork with no funding and little community support.

------
davignon
You say backers would be opted-out "ads or sponsored posts if we ever have to
resort to that". How would you implement ads in a decentralised, open
standard?

------
w1ntermute
Horrible name - please change it. People are going to have _no idea_ how to
pronounce that. Just because you were able to get a 5 character .com domain
name doesn't mean you should use it for your new venture.

~~~
wahsd
ummm ... trust? I didn't find it that difficult. What does Facebook tell us
about its service? Reminds me of a perpetrator log, which, I guess it has kind
of revealed itself as with revelations that facebook is essentially a mass
surveillance dossier system.

But I get your point, it will need some marketing to get people to understand
what it is all about. But it's not like we knew what Twitter was at first. Did
we?

~~~
w1ntermute
> But I get your point

No, you don't. It's not a matter of understanding the meaning, it's a matter
of _pronunciation_.

------
pokstad
Create a CouchApp. Problem solved.

------
zeckalpha
Their screenshots are of twitter.

~~~
mpowers
Our use cases are of Twitter too, so it makes a certain sense. We haven't
designed the UX yet, but it's meant to convey the idea.

That said, the architecture supports not only Twitter but FB-style friending
and private group shares; we want to encourage different clients in different
form factors, with the advantage being that they'd all interop. No more
siloes.

~~~
skore
Yeah, sorry, all of that is irrelevant. You use somebody elses UI on your
kickstarter. That is a terrible, terrible idea.

It's an idea terrible enough that it _will_ make people doubt your competence.
For me, personally, "building strong crypto" and "lifting the twitter UI
because too lazy to whip up some visualization of a simple roadmap" don't go
together.

~~~
mpowers
Agree, I yield. It's gone now.

------
talles
The name is awful.

What it stands for anyway?

~~~
wahsd
Trust? Doesn't seem all that diffcult, especially with some marketing. Are you
trying to say that Facebook and Twitter are better names?

~~~
talles
I'm not trying to say anything besides the name is not really good IMO.

But since you bring up, Facebook and Twitter are way better names.

IMHO it is not a good name because: * Not obvious at first glance that means
'trust' * How do you pronounce that? just say 'trust', spell it or try to say
it in some bizarre way with a mute 't'? * Doesn't look pretty

For me the only good thing about the name is that is unique.

