Live data from Hacker News

Trsst: a distributed secure blog platform for the open web

kickstarter.com

41–50 of 58 posts

Re: Trsst: a distributed secure blog platform for the open web

#41
post #33
post #26

Earlier quoted context omitted.

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…

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.

Re: Trsst: a distributed secure blog platform for the open web

#42
post #32
post #8

Earlier quoted context omitted.

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"…

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

Re: Trsst: a distributed secure blog platform for the open web

#43
post #29

'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.

Re: Trsst: a distributed secure blog platform for the open web

#44
post #38
post #29

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

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.

Re: Trsst: a distributed secure blog platform for the open web

#45
post #42
post #32

Earlier quoted context omitted.

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"…

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?

Re: Trsst: a distributed secure blog platform for the open web

#46
post #37
post #32

Earlier quoted context omitted.

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"…

> 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…

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.

Re: Trsst: a distributed secure blog platform for the open web

#47
post #23
post #14

Earlier quoted context omitted.

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…

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 Java…

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.

Re: Trsst: a distributed secure blog platform for the open web

#48
post #8
post #5

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.

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.

Re: Trsst: a distributed secure blog platform for the open web

#50
post #26

Earlier quoted context omitted.

Read "JavaScript Crypto considered harmful" 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…

Dismissing one of the leading penetration tester's essays with it mainly just boils down to watch-out for XSS attacks. seems unwise.
Post reply on HN