modred team mailing list archive

[Scott Lawrence <bytbox@xxxxxxxxx>]

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
>


-- 
Scott Lawrence

Webmaster
The Blair Robot Project
Montgomery Blair High School