Well, I'm glad someone expresses opinions I don't agree with...
I think Mikey's objection to privacy concerns is that it's so
problem-specific, we can't reasonably expect to have a general
implementation. But if the user specifies which parts of the data are
private, the Modred hub just has to be sure to divvy up tasks in a way
that gives those bits of information only to the trusted, dedicated
servers.
For the purposes of clarity, I will be referring to dedicated servers
as simply "servers", and the central server as the "hub".
I don't see the need for a sandbox. Could you present some specific
attacks that a sandbox would fix?
On 12/28/09, Michael Cohen <gnurdux@xxxxxxxxx> wrote:
It seems to me that dealing with privacy concerns is an extremely
problem-specific issue. In any given case you need to work out how much
you can give to people without letting private information leak, but the
details vary greatly from problem to problem. That isn't our business,
and I don't think we should concern ourselves with it too much. The way
I see it there are two options:
1. make this designed for stuff without privacy concerns
I think this is both the easiest and the best option. I don't really
like the idea of a public, free service doing computations for an evil
corporation anyway; if it's being done BY the public it should be done
FOR the public.
2. add in a small amount of functionality designed to facilitate dealing
with privacy concerns
At the level of this project, that would probably just be the controls
on what data gets sent to what people. There might be reasons for
adding such controls anyway; some tasks could be designated for only
"trusted" users.
Either way I doubt that this will be a big issue. I think maybe a
bigger issue is how to run arbitrary code efficiently and securely.
I see only a few solutions
Don't allow arbitrary code, but only a defined set of tasks. Or,
similarly, allow some "trusted" set of tasks, each separately ported to
each platform (like boinc).
Use Java. This lets us easily sandbox it and is cross-platform, but
sacrifices a bit on efficiency. Also, Java can be annoying (although
other JVM languages would also work in this situation).
There are ways of running cross-platform, C/C++ code in a sandbox as
well. One possibility is to use LLVM, although the LLVM developers
specifically say that LLVM is NOT designed to be used this way. Another
possibility is to use a sandboxed code system that works on multiple
operating systems but only on x86. This includes things like VX32,
which is apparently portable to Windows, but hasn't been ported. I
don't know whether or not that sort of thing is within our abilities.
Another option might be Google Native Client; that is designed to be
used in a web browser but I don't know how hard it would be to "rip out"
the sandboxing/cross-OS x86 code stuff.
Michael Cohen
_______________________________________________
Mailing list: https://launchpad.net/~modred
Post to : modred@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~modred
More help : https://help.launchpad.net/ListHelp
