> This is only sensible in the use case of a stand-alone application. In > the context of a web application this recommendation makes little to no > sense: > - in much cases the web application will connect to a back-end on the > same server or a server within a trusted network, without an other end > to do end-to-end encryption to
Currently this is often the case, although I'd say the future is unclear as to whether this will remain the most common case. For example, Chesspark uses a stand alone connection manager that makes an XMPP connection to an arbitrary XMPP server. The client can't know or trust that the connection manager is encrypting the connection. You can make a case that you are trusting the proxy since you trust the domain, and that's fine. What happens when things like flXHR are other cross domain solutions are employed? > - when the web application facilitates connections to an end that does > or might) support end-to-end encryption, the trustworthiness of the > browser-side part of the web application is very debatable: it is almost > impossible to audit the web application on cryptographic weaknesses or > backdoors each time it is loaded in the browser (opposed to a > stand-alone application, where auditing is more or less possible). I think this is a real problem but one with real solutions. For example, you can imagine the case where the apps had some kind of hash you could check. We're already part way there with common hosting of libraries like jQuery and Dojo, etc by places like Google. The piece we're missing is for the browser to actually check the hashes. I also don't think this is terribly different from most applications. OpenSSL has seen lots of security review. How do I know that Firefox didn't change the library in a bad way? This issue doesn't just exist on the Web, but it surfaces there because we're more aware of the sandboxing issues. > So in the context of a webapplication end-to-end encryption makes little > sense. It makes as much sense as anywhere else I think, but perhaps I'm misunderstanding your argument. > NB: the only situation I can imagine where it might make sense is > in the project I am maintaining (HelpIM). There the users might trust me > with software and servers, but still don't want me to be able to see, > sniff or store in readable format the content of the chats. In other > words: they trust me in serving a correct end-to-end encryption from my > server, but still don't want me to be able to see the content of the chats. That same argument applies to standards XMPP connections as well. The threat model is to prevent server operators from viewing your traffic. You'd already protected for the most part from the world by TLS between the endpoints. > Now back to the changes in XEP-0124: Maybe it is better to limit this > recommendation to the use in stand-alone clients. When using BOSH in the > context of a web application, it only is only in esoteric situations a > useful recommendation. I do think the recommendation should be relaxed, but not for any Web app reasons. I think the same reasons apply to other contexts and are just as valid. jack.
