3 ms·
The point is that all hosts should be "untrusted", because no host is 100% secure, and no host is controlled by a 100% trustworthy entity. This fact is inconven
by cortesi 17y ago
The point is that all hosts should be "untrusted", because no host is 100% secure, and no host is controlled by a 100% trustworthy entity. This fact is inconvenient, so it's pretty much ignored in the current generation of web applications. Host-proof app developers don't say that their hosts are somehow less _trustworthy_ - we recognize that all hosts, including our own, are untrustworthy, and try to design applications that take this into account.
It's early days, but I think that given published client-side source, enough users to provide vigorous peer review, and a verification mechanism like AppHash (which guards against exactly the kind of injection you talk about), it's possible to get it right.
- NateLawson 17y agoI read that as: "current web app designs are bad, and this is no worse." But that assumes we can only choose your JS crypto or other bad web app designs, a false alternative. There is a third option. What ever happened to all the other non-web-app crypto that has been doing much better for the past 20 years (PGP, SSL, /dev/urandom)? How does your solution compare to those?
- cortesi 17y agoThese things are entirely orthogonal. The "host-proof" paradigm is specifically a web application design paradigm - the question we're asking is "how can we do web apps better". Unless you're able to convince your mom to interact with Facebook using PGP, it's just not relevant to this discussion. As an aside, I would _love_ for browsers to expose a good, standardized set of crypto routines. They don't, so we do the only thing we can - implement them in Javascript. This makes me as queasy as anyone, but it's the best we can do at the moment.