Trsst: a distributed secure blog platform for the open web(kickstarter.com)
kickstarter.com
Trsst: a distributed secure blog platform for the open web
http://www.kickstarter.com/projects/1904431672/trsst-a-distributed-secure-blog-platform-for-the-o
9 comments
What programming language do you plan to use for the reference implementation?
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.
Why do you need Kickstarter for this?
Why don't you build it first and if it gets popular then ask for donations?
What about the open source projects you're building on top of? Are you going to give any of those programmers some money?
> Yes. We're starting with the critical bit - the client - out in the open in JS w/ off-the-shelf open-source. Needs many eyes.
Frankly, I'm sick of people jumping on the "open-source" bandwagon and diverting resources from those who truly deserve it or who have a track record in the field they are asking funds for.
You know, people like Stallman and Torvalds took risk and bore the opportunity cost of spending time to build things they believed in and had passion for.
It seems too many of todays entrepreneurs are afraid of taking risk and want to pass it onto the public. I especially dislike what App.net did, conning people into giving money to build a closed source platform and then selling part of that company to venture capitalists.
Why don't you build it first and if it gets popular then ask for donations?
What about the open source projects you're building on top of? Are you going to give any of those programmers some money?
> Yes. We're starting with the critical bit - the client - out in the open in JS w/ off-the-shelf open-source. Needs many eyes.
Frankly, I'm sick of people jumping on the "open-source" bandwagon and diverting resources from those who truly deserve it or who have a track record in the field they are asking funds for.
You know, people like Stallman and Torvalds took risk and bore the opportunity cost of spending time to build things they believed in and had passion for.
It seems too many of todays entrepreneurs are afraid of taking risk and want to pass it onto the public. I especially dislike what App.net did, conning people into giving money to build a closed source platform and then selling part of that company to venture capitalists.
> Frankly, I'm sick of people jumping on the "open-source" bandwagon and diverting resources from those who truly deserve it
Is there a list of deserving people that gets curated by someone? I think that those who deserve are those that get support because what is being advertised is what people will pay for if they want it.
On the same note as those who truly deserve it I think that there are so many ideas and open source is not about a list of people but about whatever you want or need. Pushing back on new ideas is not necessarily the right thing to do. Vote with your money; support if you like something and walk away if you don't.
Is there a list of deserving people that gets curated by someone? I think that those who deserve are those that get support because what is being advertised is what people will pay for if they want it.
On the same note as those who truly deserve it I think that there are so many ideas and open source is not about a list of people but about whatever you want or need. Pushing back on new ideas is not necessarily the right thing to do. Vote with your money; support if you like something and walk away if you don't.
The problem I see is that if the public donate several times to projects which don't work out, by the time the true domain experts get around to setting up a Kickstarter, the public are already tapped out.
I get where you're coming from, but I was sitting at an Eclipse game with ESR last week (where he beat me on the tiebreaker but I digress) and he thought our approach was great. KS didn't exist back then. If it did, it might have funded some of the great foss projects. #truestory
You're right that this is relatively new so we don't know how things will pan out. For example, will third party contributors be discouraged from helping if they don't get some form of compensation?
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?
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?
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.
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.
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.
* 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.
While I agree with your general point, there has been some recent work < http://www.defensivejs.com/ > on isolation of javascript from the rest of the DOM/session. What's your take on this kind of static analysis?
Also, if a given, well-known resource could be pinned to a specific hash and third-parties could easily certify that specific hash, would that ameliorate the primary concerns with JS cryptosystems?
Thanks for your time.
Also, if a given, well-known resource could be pinned to a specific hash and third-parties could easily certify that specific hash, would that ameliorate the primary concerns with JS cryptosystems?
Thanks for your time.
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.
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.
> 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.
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.
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).
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).
> 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.
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.
I don't even know how to respond to this: "the endpoints might be compromised, so why bother making the crypto secure"? That's the idea?
Browser JS is a uniquely terrible vector for delivering crypto to end users. Use something different.
Browser JS is a uniquely terrible vector for delivering crypto to end users. Use something different.
Your logical fallacy is: putting words into my mouth (argumentum ad logicam). I didn't say "why bother making the crypto" secure. I said that you can't point to endpoint security as a reason to fault JS more than you can fault every other crypto implementation.
Schneier thinks NSA may have already compromised certain binaries and checksums, and John Gilmore is wondering if certain source trees have been compromised.
JS is not immune to these kinds of attacks, nor is it any more susceptible. All we can do is make sure our implementation is clear and correct and avoids browser exploits. We can't control your binaries, OS, browser, or otherwise.
Schneier thinks NSA may have already compromised certain binaries and checksums, and John Gilmore is wondering if certain source trees have been compromised.
JS is not immune to these kinds of attacks, nor is it any more susceptible. All we can do is make sure our implementation is clear and correct and avoids browser exploits. We can't control your binaries, OS, browser, or otherwise.
Shrinking that to a sound-bite: JS crypto is the NSA's wet dream.
That said, the js crypto isn't the part I'm worried about. It's all the scripting vulnerabilities to guard against in the browser.
Still, if anyone has mission-critical privacy they want to protect, we expect there will be hardened native clients to choose from.
Most posts from most people are going to be public anyway. We keep the public stuff public, but signed and search-indexable, and we let you do private stuff securely if you want to.
Still, if anyone has mission-critical privacy they want to protect, we expect there will be hardened native clients to choose from.
Most posts from most people are going to be public anyway. We keep the public stuff public, but signed and search-indexable, and we let you do private stuff securely if you want to.
I think it's a bad idea to mix a system that isn't expected to be secure, with ones that are expected to be secure.
Just like how sending a gpg encrypted email to (some) users of hushmail wasn't secure, because in the end hushmail encouraged insecure handling of the private keys.
In the end, the only rational, informed choice, is to regard the whole system as (in)secure as its least secure part.
If there is to be any point to a "secure social network", the trust you can place in the network (implementation) should be at least as high as the trust you place in those you share with?
Will you be able to take reasonable steps to prevent private keys to be written to (unencrypted) swap, for instance?
Promising a "secure" social network, kind of implies that data you share is secure from your spouse, for example.
Just like how sending a gpg encrypted email to (some) users of hushmail wasn't secure, because in the end hushmail encouraged insecure handling of the private keys.
In the end, the only rational, informed choice, is to regard the whole system as (in)secure as its least secure part.
If there is to be any point to a "secure social network", the trust you can place in the network (implementation) should be at least as high as the trust you place in those you share with?
Will you be able to take reasonable steps to prevent private keys to be written to (unencrypted) swap, for instance?
Promising a "secure" social network, kind of implies that data you share is secure from your spouse, for example.
(fyi, these replies are meant to be read in reverse order from how they're displayed, i think...)
Java/Tomcat is an unsavory prospect for many folks. The options for building the server side are numerous; Tomcat is a clunky, resource-hungry PITA that many folks, myself included, go out of their way to avoid. If the devs are Java guys then that's their business, but the choice will almost certainly decrease the user base.
Yes, this is the kind of feedback we're looking for with regard to another comment here. This is why we haven't committed to a language for the server-side reference impl yet, because we're not sure what would be useful. (Our prototype is java, fwiw.)
Read "JavaScript Crypto considered harmful"
http://www.matasano.com/articles/javascript-cryptography/
http://www.matasano.com/articles/javascript-cryptography/
Gah, HN is rate-limiting my responses.
Very familiar with the document, but it mainly just boils down to watch-out for XSS attacks. We require SSL to deliver the entire page with no external libraries or references. His response to this doesn't really say anything. See: "WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE?" We need the crypto for keygen and signing and encryption, so he's missing the point completely.
To the other point made above along the same lines, the protocol is the key and you are free to choose your own client. No matter which you choose, you have to trust the source.
Our goal is to get the protocol adopted and used as widely as possible. Mass adoption is only possible if there's a web client with JS crypto, and there's no way around the need to trust the server you download it from.
Very familiar with the document, but it mainly just boils down to watch-out for XSS attacks. We require SSL to deliver the entire page with no external libraries or references. His response to this doesn't really say anything. See: "WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE?" We need the crypto for keygen and signing and encryption, so he's missing the point completely.
To the other point made above along the same lines, the protocol is the key and you are free to choose your own client. No matter which you choose, you have to trust the source.
Our goal is to get the protocol adopted and used as widely as possible. Mass adoption is only possible if there's a web client with JS crypto, and there's no way around the need to trust the server you download it from.
Assume for a moment that JS crypto is insecure. If you use a web client with JS crypto to bootstrap acceptance, then the majority of your clients will end up using JS crypto. If the majority of the clients on the 'network' are insecure, then what's really the point?
A single client isn't weakened by other compromised clients.
If you run a hardened trustworthy client, your own public posts are still verifiable, and private posts meant for you are decodable only by you.
You would just need to make sure to send your private posts only to others that use trustworthy clients. But, because you're sending them a secret message in the first place, you already implicitly trust them.
If you run a hardened trustworthy client, your own public posts are still verifiable, and private posts meant for you are decodable only by you.
You would just need to make sure to send your private posts only to others that use trustworthy clients. But, because you're sending them a secret message in the first place, you already implicitly trust them.
> You would just need to make sure to send your private posts only to others that use trustworthy clients.
And how would you make sure of that? Is there a field in the user data that says: "419 I speak the protocol, but I don't give security grantees - fool you for talking with me?". Is there planned an easy UI for showing you which of your contacts are part of the secure network, and which ones are backdoors into the network?
And how would you make sure of that? Is there a field in the user data that says: "419 I speak the protocol, but I don't give security grantees - fool you for talking with me?". Is there planned an easy UI for showing you which of your contacts are part of the secure network, and which ones are backdoors into the network?
Dismissing one of the leading penetration tester's essays with it mainly just boils down to watch-out for XSS attacks. seems unwise.
I'm not being flip about it. Granted, entropy is an issue with in-browser JS, but the rest of it is really just cautionary about browser bugs, compromised browsers, and known page-based browser attacks. Very little doesn't also apply to every crypto system on every platform. If you can't trust your OS or browser, you've got bigger problems.
I'll submit that because it's in-browser it's additionally difficult - very difficult - to get right, but I don't see that it's impossible.
I'll submit that because it's in-browser it's additionally difficult - very difficult - to get right, but I don't see that it's impossible.
Likely? So you don't even have a solid plan how to build your app?
Well, it's kickstarter so we're deferring some decisions until it closes, and leaving room to listen to our backers.
I know you probably meant to snark, but to take your question seriously, the question we have is: do we open up our working prototype, or write a reference impl from scratch in a language more useful to our community.
I know you probably meant to snark, but to take your question seriously, the question we have is: do we open up our working prototype, or write a reference impl from scratch in a language more useful to our community.
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.
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.
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.
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.
I didn't post this. But feel free to make unsubstantiated ad hominem attacks, because: the internet. :)
'decentralized' yet needs $15000 PA for server hosting?
Agree, wordpress is an apt comparable. Some of the KS tiers are that we're providing hosting for early backers, so we need to provide hosting for early backers.
The intent is to extend an existing standard, RSS, with an http protocol to support it. We need to one of many providers for the system to work as intended.
The intent is to extend an existing standard, RSS, with an http protocol to support it. We need to one of many providers for the system to work as intended.
As decentralized as WordPress. The project is open source.
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.
Many open source software projects (some huge ones today) came out of the woodwork with no funding and little community support.
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?
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.
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?
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?
> But I get your point
No, you don't. It's not a matter of understanding the meaning, it's a matter of pronunciation.
No, you don't. It's not a matter of understanding the meaning, it's a matter of pronunciation.
Create a CouchApp. Problem solved.
Their screenshots are of twitter.
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.
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.
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.
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.
Agree, I yield. It's gone now.
WJW: https://s3.amazonaws.com/ksr/assets/000/499/002/9bbefc6069c0...
A hand-drawn sketch of the planned UI would look less vaporwarey.
A hand-drawn sketch of the planned UI would look less vaporwarey.
Well, it's a kickstarter, so it's by definition trying to get backing for a vaporware product. But fair point.
The name is awful.
What it stands for anyway?
What it stands for anyway?
Trust? Doesn't seem all that diffcult, especially with some marketing. Are you trying to say that Facebook and Twitter are better names?
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.
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.
Play on the word trust + rss? tRSSt?