I am wanting to develop a web service (classic client/server) where the server is not trusted, so is kept (cryptographically) ignorant about the actual content/messages.

Obviously, if you don't trust the server, then you shouldn't trust any client that server hands you. So our client would have "no moving parts" - that is, one composed entirely of static files (no PHP/Ruby/whatever, no database), just a bundle of JS/HTML/CSS to be distributed separately.

A client like this could run locally on people's computers, or as a GitHub page, or via any webserver. The idea is that more people are capable of extracting a ZIP onto their computer (or using simple FTP) than would ever be likely to host their own server or configuring a database appropriately.

I'm not trying to guard against being individually targeted - I'm trying to guard against a single centralised point of attack, so every client would have to be compromised individually to get the messages for a particular user/group.

What would be the security implications/drawbacks of a setup like this?

Clarification: the method by which the ZIP of the client is obtained is not the issue I'm interested in. Technologies already exist for that (public-key signatures of hashes, et cetera). The issue of "How do I make sure I have a good copy of the client" is completely equivalent to "How do I make sure I have a good copy of my browser/Cygwin/antivirus" - I'm not interested in any concerns about this that could also be applied to installing FireFox, for instance.

What I'm interested in is any security issues with the setup, assuming that a verified version of the client is available.

P.S. - I'm aware that JavaScript crypto is frowned upon (example article here). However, the criticisms seem to be:

  1. You rely on obtaining a secure client from the untrusted server
  2. JavaScript code can't be sure that the VM running it is secure

#1 is exactly what I'm trying to tackle here, and for #2: if your browser's JavaScript VM is dodgy, then all websites are unsafe, as well as your credit-card details.

  • 1
    If you don't trust the server providing the client, what is to prevent the server from altering the client to send the information back to it? If they have to get the client elsewhere, why limit it to web technologies when native can do a far more secure and efficient job? – AJ Henderson Nov 4 '13 at 17:57
  • (1) Second paragraph, first sentence - I don't get the client from the server. – cloudfeet Nov 4 '13 at 18:04
  • (2) Web technologies are sandboxed - the user can be fairly confident that however corrupt it is, an HTML file can't do any actual damage to the rest of their system. – cloudfeet Nov 4 '13 at 18:05
  • Also, I do want this to be possibly available from anywhere - like checking email/Facebook at a friend's house. For that, you need it to be web-accessible - so I'm also trying to make self-hosting the client as simple as possible (static files, no other requirements/config). – cloudfeet Nov 4 '13 at 18:09
  • 1
    ok, sure, but you still need to get the client from somewhere and that server ends up being trusted since it is the source of the client. The only way around that would be to use existing technologies and let someone build their own client based on an open protocol. – AJ Henderson Nov 4 '13 at 18:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.