mpowers

6 ms·

1.
by mpowers 13y ago
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
2.
by mpowers 13y ago
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 me
3.
by mpowers 13y ago
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
4.
by mpowers 13y ago
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. (O
5.
by mpowers 13y ago
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
6.
by mpowers 13y ago
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 hav
7.
by mpowers 13y ago
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 s
8.
by mpowers 13y ago
Agree, I yield. It's gone now.
9.
by mpowers 13y ago
I didn't post this. But feel free to make unsubstantiated ad hominem attacks, because: the internet. :)
10.
by mpowers 13y ago
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
11.
by mpowers 13y ago
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
12.
by mpowers 13y ago
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
13.
by mpowers 13y ago
(fyi, these replies are meant to be read in reverse order from how they're displayed, i think...)
14.
by mpowers 13y ago
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 h
15.
by mpowers 13y ago
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 lite
16.
by mpowers 13y ago
Well, it's a kickstarter, so it's by definition trying to get backing for a vaporware product. But fair point.
17.
by mpowers 13y ago
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 shar
18.
by mpowers 13y ago
It's ending up either trust or tryst. Kind of like GIF vs. JIF. That said, we'd have probably half the mainstream press coverage without that name.
19.
by mpowers 13y ago
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.
20.
by mpowers 13y ago
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 ma
21.
Trsst: a distributed secure microblog standard for the open web(kickstarter.com)
4 points by mpowers 13y ago|0 comments