Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

By "run", I more meant "distribute data" (probably with digital signatures to detect tampering, and probably also with encryption).

Even in the sense of "running" sites in a computational sense, projects like Ethereum and BOINC seem to suggest the feasability of such a distributed model without necessarily requiring TC. If the computation itself is actually performed in parallel by different nodes, then outlier nodes (e.g. ones trying to tamper with computation) can be ignored.

Of course, there's the possibility of an attack where the attacker has control over the majority of the nodes running that particular computation. Hopefully such a system could grow to the point where such an attack is infeasible.

Even with that aside, though, most websites nowadays already run to some extent on untrusted hardware (thanks to JavaScript), thus warranting measures to handle untrustworthy IPC.

All in all, it's a hard problem, but not one that's impossible to solve. We already have quite a few of the tools on hand.



> Even with that aside, though, most websites nowadays already run to some extent on untrusted hardware (thanks to JavaScript), thus warranting measures to handle untrustworthy IPC.

From a security perspective it is a very bad idea to rely on untrusted data (i.e. that only passed "client validation", but is not validated again on the server). In other words: If the client tampers with some of its data, only it itself should be affected from any problems that this causes.


Agreed, hence the clause "thus warranting measures to handle untrustworthy IPC".

So the question here would be one of replacing server-side verification of untrusted data with peer-to-peer distributed verification of untrusted data.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: