Ask HN: How would you implement a verifiable open-source web application?

Decouple the application from the DB. Use a DB as a service that has an HTTP API. The application encrypts/decrypts all data with public/private key pair. The user, your client generates their own key pair.

This is the scenario we are testing out with http://schemafreedb.com/

You do not have the private key so you cannot see the data but you still can offer the data portion as a service. Your client does need to host the application depending on your target client node may be a good choice or if you want to go mainstream go with something like php.

When ever you have update to the code you can provide a diff of the changes.

There is no way to know that some remote blackbox is genuine, except to feed all the inputs that you are feeding to that blackbox also to a trusted blackbox, and verify that the outputs are identical. This breaks down as soon as random numbers are involved (session keys, etc).

Also, even this does not assure you that the blackbox isn't doing something bad via a side channel. For instance, if we trust the genuine blackbox not to transmit personal data somewhere, how do we know that the BUT (blacbox-under-test) isn't doing that? We have to isolate the blackbox, and then destroy it at the end of the test (so it can't store something and transmit later). You can't isolate a remote box. A remote box has inputs and outputs unknown to you that you cannot monitor.

Trust is a big problem with the SaaS model. When you're trusting a SaaS application, you're really trusting the provider who is hosting that application. There is no way around that.

I think, however, that there is an intermediate wortwhile goal: to have assurance that you're trusting only the host of the application!

That is to say, that the SaaS application doesn't contain malware which was not intentionally injected by the provider, but somehow got there via an upstream code source or through some exploit or whatever.

If you can provide a way that the SaaS provider itself can check that it's running the code that it thinks it is running, that is valuable. If the SaaS is rogue and customizes the code to do things that the users don't agree with, that's a separate concern.

There is a testnet that works right now, but should not be used in production yet (I think it gets reset regularly? Not sure.). Within a few months, it is expected that the first version of "the real thing" will be up, but I don't think putting things on it quite then would necessarily be a good idea (probably depends on what things one is considering putting on it), because it is set up so that after a certain time, there will be a change to a new version, and while all balances will be carried over across that change to the new version, other parts of the state of the system won't be, so anything built on it would have to be set up again. (which could just be a matter of sending the same message again, so it might not be that much of a problem to set it up before the change I guess.)

Also, its probably important to note that a contract is run by every miner (or, every miner on a certain part of the network, depending on how the scalability thing ends up being done?), and that as such, you will want to keep any computation done by a contract to be computationally cheap, so that it will be cheap to use. Instead of having the computation do the computation that needs to be done, it may in some cases work better to just have the contract verify the accuracy of computations that have been done.

However, now that I think of it, I'm not sure that Ethereum would solve all of the problems OP gives, because one of the problems OP wanted to solve was that they wanted to demonstrate that they were not storing information that they shouldn't be. But with Ethereum, because the contracts are executed by "everyone", everyone has to have access to the data the contracts are using to run, and there is no way to insure that they don't hold onto that data.

One way to solve this could maybe be doing computations on shared secrets (as talked about in one of the Ethereum blog posts, but which is not something Ethereum is to have), but this might require more messages to be sent over the network than one is willing to use. Still much more practical than homeomorphic encryption though I think. (If one was using the shared secret thing, I'm not sure one would do it with Ethereum.)

Ethereum could/would solve the problem of ensuring that the program being run is exactly as claimed, but it might not keep certain information private. Depending on the specific problem at hand, there might be ways around that though?

EDIT: ok, so, something suggested that homeomorphic encryption might have gotten an improvement to the point of practicality recently? I wasn't aware of that. May make this post slightly out of date.

I don't know the answer but if you figure it out you'll be a trillionaire.

http://en.wikipedia.org/wiki/Code_signing seems relevant. This case is more about having the software itself sign its own output. Relevant search terms:

* software "sign its own output"

* software "encrypt its own output"

* software "encrypt its output"

* software "sign its output"

Some interesting results:

* Computer scientists develop 'mathematical jigsaw puzzles' to encrypt software (UCLA) #comment by zblaxell http://lwn.net/Articles/562113/

* Cryptographic Verification of Test Coverage Claims http://www.cs.ucdavis.edu/~devanbu/doc.ps

* Study of Security in Multi-Agent Architectures §3.4 http://www.ecs.soton.ac.uk/~lavm/papers/sec.pdf