3 ms·

An untrusted host seems like exactly the wrong case for web applications. What's to stop the host from adding in some key-logging Javascript? If it's cleverly h

An untrusted host seems like exactly the wrong case for web applications. What's to stop the host from adding in some key-logging Javascript? If it's cleverly hidden, or inserted only for certain IPs, chances are low that anybody would notice. Then the host would have your encrypted text and passphrase. It would be better to have a desktop application, with source code the user can verify. Then no matter what the host changes on their end, I can know that only the encrypted text is being sent. Even better, host-based applications can tie into existing frameworks like GNOME Keyring and GnuPG, for even better security than can be provided by a 128-byte passphrase.

tyleroderkirk 17y ago
Agreed. Web browsers are infamous for being vulnerable to remote attack - I want to keep my sensitive data away from them as much as possible. This concept of "host-proof hosting" seems to encourage that we discard well-proven methods in favor of implementing new crypto schemes in the hostile browser-space. Are web end-users really better equipped to ensure application security than web host administrators? </rhetorical>
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 ago
  I 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 ago
    These 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.

tyleroderkirk 17y ago

Agreed. Web browsers are infamous for being vulnerable to remote attack - I want to keep my sensitive data away from them as much as possible. This concept of "host-proof hosting" seems to encourage that we discard well-proven methods in favor of implementing new crypto schemes in the hostile browser-space. Are web end-users really better equipped to ensure application security than web host administrators? </rhetorical>

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 ago
I 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 ago
  These 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.