Sun Microsystems will make all the Java code they own available under the GPL:
http://www.sun.com/software/opensource/java/
This is a very major step. IMHO we should now make Java core part of our own strategy, as it's one of the best ways to deliver interactive content (high quality animations, learning tools, etc.). There are large numbers of free applets that we can potentially use, esp. in Wikipedia and Wikiversity.
My main question is: Are there security considerations with enabling the upload and embedding of Java Applets? According to
one of the capabilities of applets is to open a connection to the originating host. Could this be used, e.g., to create auto-vandalism applets and if so, can we somehow protect against it?
If security is a major issue, might it be feasible to maintain a whitelist of certificates (to allow applets from trusted authority to be uploaded directly), and to flag all other applets as "non-embeddable" until a sysop flips a switch, so they can be reviewed for security? We could add a big fat warning on the file description page.
On 14/11/06, Erik Moeller erik@wikimedia.org wrote:
Sun Microsystems will make all the Java code they own available under the GPL: http://www.sun.com/software/opensource/java/ This is a very major step. IMHO we should now make Java core part of our own strategy, as it's one of the best ways to deliver interactive content (high quality animations, learning tools, etc.). There are large numbers of free applets that we can potentially use, esp. in Wikipedia and Wikiversity.
Certainly as soon as there's actually a free-software JRE (with classes) the good Java media players should be accessible from all image and media pages with just a click.
- d.
On 11/13/06, Erik Moeller erik@wikimedia.org wrote: [snip]
My main question is: Are there security considerations with enabling the upload and embedding of Java Applets? According to
[snip]
When I first put up the Java Vorbis player I needed to make a connection to an outside host (upload.wikimedia.org). Since I don't have a signing cert I put it up without one, and users had to agree with a "allow this to 0wn my machine" warning for it to play. In these first couple of days before I fixed it to run in the sandbox over 10,000 people allowed their java to bypass security.
As such I could never support a general proposal user submitted java.
Even ignoring the sandbox breakout issues, the halting problem ultimately means that we can not determine what arbitrary code will do... The possibilities for vandalism are endless.. Imagine a little animation of an atom turns into dancing penises for ten minutes on alternate tuesdays.
one of the capabilities of applets is to open a connection to the originating host. Could this be used, e.g., to create auto-vandalism applets and if so, can we somehow protect against it?
Yes. Originate the Java from a host that does nothing but originate Java... and better yet, as above don't allow arbitrary code.
[snip]
"non-embeddable" until a sysop flips a switch, so they can be reviewed for security? We could add a big fat warning on the file description page.
I think you're stepping two far... How about we start off treating java like extensions? We can obtain or build some nice general tools (java graphers, etc)..
All of this is ignoring the amazing accessibility problems of Java. Not only will all of this be totally inaccessible to people on low tech devices and the visually impaired, but a huge amount of our viewers just don't have java installed (I posted numbers on this previously).
Fortunately, we have time to think about this.. Sun's complete java suite will not be opensourced until March 2007...
Gregory Maxwell wrote:
Even ignoring the sandbox breakout issues, the halting problem ultimately means that we can not determine what arbitrary code will do... The possibilities for vandalism are endless.. Imagine a little animation of an atom turns into dancing penises for ten minutes on alternate tuesdays.
Humans can't solve the halting problem either, but despite that, I can guarantee that there are no hidden dancing penises embedded in the MediaWiki core. I can do that because it is possible to classify programs into three categories: bad, suspicious and good. We can reject the suspicious programs, making it irrelevant what the programmer has hidden in them.
That's not to say I would support having user-supplied Java applets. I agree with all your other concerns. And it would indeed be difficult (but not impossible) to review applets.
We've been talking about putting Jmol Java applets on chemical compound pages, with a MediaWiki extension. When I posted a demo link to #wikipedia, all I got back were complaints about the long load time, and the performance impact of starting Java. A JavaScript "click to load" link would be necessary for usability.
-- Tim Starling
On 11/14/06, Tim Starling tstarling@wikimedia.org wrote:
A JavaScript "click to load" link would be necessary for usability.
That makes perfect sense -- most people don't like surprises on webpages.
On 11/13/06, Gregory Maxwell gmaxwell@gmail.com wrote:
All of this is ignoring the amazing accessibility problems of Java. Not only will all of this be totally inaccessible to people on low tech devices and the visually impaired, but a huge amount of our viewers just don't have java installed (I posted numbers on this previously).
I don't see client-side Java as serving any major purpose beyond providing an alternative platform-independent way to deliver multimedia content for people who don't have native players installed. Trying to implement any of the core application in Java at the client end targets too small of a usability segment; many people have no JRE installed in their computer (or at least no JRE extension in their web browser), and even if they do they have a JRE that only supports version 1.2 or even 1.1 of the specification.
Kelly
On 11/14/06, Kelly Martin kelly.lynn.martin@gmail.com wrote:
I don't see client-side Java as serving any major purpose beyond providing an alternative platform-independent way to deliver multimedia content for people who don't have native players installed. Trying to implement any of the core application in Java at the client end targets too small of a usability segment; many people have no JRE installed in their computer (or at least no JRE extension in their web browser), and even if they do they have a JRE that only supports version 1.2 or even 1.1 of the specification.
The major application right now is probably Wikiversity. Interactive applications could be extremely useful to them for a wide variety of purposes, such as quizzes or physics demonstrations.
On 11/14/06, Gregory Maxwell gmaxwell@gmail.com wrote:
Even ignoring the sandbox breakout issues, the halting problem ultimately means that we can not determine what arbitrary code will do... The possibilities for vandalism are endless.. Imagine a little animation of an atom turns into dancing penises for ten minutes on alternate tuesdays.
Work with people and resources you can trust and, in cases where such trust cannot be established, at least have a process in place for open source code review (which may take a while, but it's better than denying a submission altogether). Even with the best security, there may be the occasional penis hokey pokey -- just like even the biggest software companies occasionally end up shipping products that have been tainted by disgruntled engineers.
We allow any sysop to edit the site JavaScript. What is more, many ordinary users copy & paste JavaScript code they have not looked at from other users. I'm not aware of any major exploit that has ever resulted from this. On the other hand, editable user JavaScript has enabled rapid innovation in client-side scripting. I'm confident that we will be able to come up with a security approach for Java applets that works just as well.
All of this is ignoring the amazing accessibility problems of Java. Not only will all of this be totally inaccessible to people on low tech devices and the visually impaired, but a huge amount of our viewers just don't have java installed (I posted numbers on this previously).
Accessibility does not mean making everyone equally disadvantaged. We do not discourage images because some people cannot see them. Nor should we deny interactive learning resources to those who have computers capable of running them in order to accommodate people who do not. Certainly, if we allow applets, some people will propose using them in situations where it does not make sense or only offers marginal advantages over more commonly usable formats such as GIF animations. These applets should then either be eliminated or complemented with alternative resources. That is a matter of policy.
The installation basis of JREs is of secondary importance. Most people do not have Ogg Vorbis players installed on their systems either, yet we use Ogg Vorbis as our primary audio format. What matters is identifying and establishing a free software solution for interactive content in Wikimedia sites, and providing generally understandable instructions for its use. There are large repositories of Java applets that can be used in an instructional context, e.g.:
http://www.mste.uiuc.edu/users/Murphy/JavaOverview/default.html http://www.arcytech.org/java/ http://www.cs.brown.edu/exploratories/freeSoftware/catalogs/repositoryApplet...
Many of these are free software, or their authors might be persuaded to release them as such. We should find a way to make use of these resources, rather than hiding under a false security blanket. For a project like Wikiversity, finding a solution to this problem is not optional -- it is necessary. This is an example where Wikipedia-centric thinking must not dominate the decision-making process in Wikimedia.
A community review process, where open source applets can be nominated for inclusion in Wikimedia, or particular resources / applet authors can be community-certified as trustworthy, with the final step being implemented by a sysop or bureaucrat, strikes me as a reasonable compromise between security and ease of inclusion.
On 11/13/06, Erik Moeller erik@wikimedia.org wrote:
If security is a major issue, might it be feasible to maintain a whitelist of certificates (to allow applets from trusted authority to be uploaded directly), and to flag all other applets as "non-embeddable" until a sysop flips a switch, so they can be reviewed for security? We could add a big fat warning on the file description page.
It makes more sense to me to use the system we use for JavaScript, i.e., only sysops can add it to begin with. Allowing applets from trusted authorities is an interesting idea, but what does "trusted" mean? Trusted to not take up too many CPU cycles, to avoid playing sound unless the user permits it explicitly, to not include material that would be vulgar and thus attractive to vandals?
I definitely don't think anything whatsoever should be available to non-sysops at all unless uploaded by a sysop, no matter how large the warning message. People are *way* too used to ignoring warning messages.
Simetrical wrote:
On 11/13/06, Erik Moeller erik@wikimedia.org wrote:
If security is a major issue, might it be feasible to maintain a whitelist of certificates (to allow applets from trusted authority to be uploaded directly), and to flag all other applets as "non-embeddable" until a sysop flips a switch, so they can be reviewed for security? We could add a big fat warning on the file description page.
It makes more sense to me to use the system we use for JavaScript, i.e., only sysops can add it to begin with. Allowing applets from trusted authorities is an interesting idea, but what does "trusted" mean? Trusted to not take up too many CPU cycles, to avoid playing sound unless the user permits it explicitly, to not include material that would be vulgar and thus attractive to vandals?
I definitely don't think anything whatsoever should be available to non-sysops at all unless uploaded by a sysop, no matter how large the warning message. People are *way* too used to ignoring warning messages.
Here's a related idea: if we can't get "confirmed email required before uploads enabled" for Commons, could we get uploads disabled for non-sysops? Surely images in general are similarly "dangerous" (if not for system & vandalism reasons, for copyright reasons)?
(Cross-posting to Commons-l)
On 11/14/06, Simetrical Simetrical+wikitech@gmail.com wrote:
I definitely don't think anything whatsoever should be available to non-sysops at all unless uploaded by a sysop, no matter how large the warning message. People are *way* too used to ignoring warning messages.
I was talking about a scenario where you could upload an applet class file, but where Wikimedia would not embed it in a runnable form. You would have to explicitly download and run such an applet (using the appletviewer application or by embedding it into a webpage). I think under such a setting, an applet is unlikely to do much harm (not to mention that it would not be run from any Wikimedia domain), since the users who are the most likely to do something stupid are the least likely to be able to figure out how to run the thing in the first place.
On 11/14/06, Erik Moeller erik@wikimedia.org wrote:
Sun Microsystems will make all the Java code they own available under the GPL:
and on wikitech-l Erik wrote:
A community review process, where open source applets can be nominated for inclusion in Wikimedia, or particular resources / applet authors can be community-certified as trustworthy, with the final step being implemented by a sysop or bureaucrat, strikes me as a reasonable compromise between security and ease of inclusion.
Check this out - I'm an English Wikiversity bureaucrat, and I haven't a clue about how any of this works or could/should be managed! In my opinion, in order to most productively conduct this conversation, we need to think of the people on the projects this will impact - by asking things like the following:
*Is an "evil" java resource going to be easily spotted by a project sysop/bureaucrat? (How do you spot an "evil" or potentially evil resource?) *How would java resources be added to a project? The same as - or similar to - a file? Or simply through adding code into a page? (and consequently) *How much patrolling will this require?
I'd of course be incredibly excited to have engaging learning materials added to Wikiversity, as well as applications for all our projects. I'm just trying here to imagine how we would deal with this "in the trenches", so to speak.
Please pardon my war-like language here - must be a hangover from the [[w:Armistice]] weekend :-)
Cormac
Cormac Lawler wrote:
*Is an "evil" java resource going to be easily spotted by a project sysop/bureaucrat?
That's the wrong question. A better set of questions would be: * Does every project have at least one sysop/bureaucrat who can spot "evil" Java resources? * Does every sysop/bureaucrat who does not have this skill, acknowledge that they don't and consequently leave the approval queue alone? (from your message, it appears that you do, so you're fine)
On 11/14/06, Timwi timwi@gmx.net wrote:
That's the wrong question. A better set of questions would be:
- Does every project have at least one sysop/bureaucrat who can spot
"evil" Java resources?
- Does every sysop/bureaucrat who does not have this skill, acknowledge
that they don't and consequently leave the approval queue alone? (from your message, it appears that you do, so you're fine)
It's not a question of skill: No matter how skilled no human can tell a malicious java app in binary form from a good java app.
Only through a careful audit of the source code could we expect to have any confidence... and thats a question of both time and skill...
On Tue, Nov 14, 2006 at 03:01:24PM -0500, Gregory Maxwell wrote:
On 11/14/06, Timwi timwi@gmx.net wrote:
That's the wrong question. A better set of questions would be:
- Does every project have at least one sysop/bureaucrat who can spot
"evil" Java resources?
- Does every sysop/bureaucrat who does not have this skill, acknowledge
that they don't and consequently leave the approval queue alone? (from your message, it appears that you do, so you're fine)
It's not a question of skill: No matter how skilled no human can tell a malicious java app in binary form from a good java app.
Only through a careful audit of the source code could we expect to have any confidence... and thats a question of both time and skill...
. . . and at that point, you're back to wondering if the sysops/bureaucrats who don't have the skill will leave the approval queue alone. Since this is a preventative measure, and not an active measure, it introduces problems later down the road, because the real question isn't "Does every sysop/bureaucrat who does not have the skill acknowledge that they don't and consequently leave the approval queue alone?" Instead, the question is:
"Will every sysop/bureaucrat forevermore who does not have the skill be reasonably expected that they don't have the skill and consequently leave the approval queue alone, or do we think there's a nontrivial likelihood that new sysops/bureaucrats will potentially become a problem in this regard in the future?"
Unfortunately, if you want something approaching complete safety in this regard, I don't think you're going to get it. I guess it all depends on how much you're willing to risk it.
On 11/14/06, Chad Perrin perrin@apotheon.com wrote:
. . . and at that point, you're back to wondering if the sysops/bureaucrats who don't have the skill will leave the approval queue alone.
I think, psychologically, that requiring people to personally and informally propose things on talk pages will better stave off overconfident sysops than some kind of queue or formal mechanism. The latter is, I suspect, more prone to clear-the-backlog-osis, and less likely to make people realize that by submitting it they're taking responsibility for it.
That said, there's no reason to be paranoid. Yes, there will always be vulnerabilities, but they'll be doubly limited by the approval process *and* the sandbox. We aren't distributing arbitrary machine code, we're distributing Java, which as far as I know can't do anything like take over your computer or wipe your hard drive. Running arbitrary Java is not to my knowledge a real security risk, at least no more than arbitrary JavaScript (which can spy on you to an extent), and this Java won't even be arbitrary: it will be vetted first, however imperfectly.
On Tue, Nov 14, 2006 at 05:39:05PM -0500, Simetrical wrote:
That said, there's no reason to be paranoid. Yes, there will always be vulnerabilities, but they'll be doubly limited by the approval process *and* the sandbox. We aren't distributing arbitrary machine code, we're distributing Java, which as far as I know can't do anything like take over your computer or wipe your hard drive. Running arbitrary Java is not to my knowledge a real security risk, at least no more than arbitrary JavaScript (which can spy on you to an extent), and this Java won't even be arbitrary: it will be vetted first, however imperfectly.
The idea that Java cannot take over your computer or wipe your hard drive may (and I emphasize the use of "may" here) be true for applets, but for other uses of Java it is anything but true.
Hey, if we're going to start including virtual machine run bytecode content, maybe we should include other VMs than Java's. For instance, there's OCaml's toplevel VM, Parrot, and Smalltalk out there. Could be fun.
Okay, I'm not very serious about that.
On Tue, Nov 14, 2006 at 03:51:09PM -0700, Chad Perrin wrote:
Hey, if we're going to start including virtual machine run bytecode content, maybe we should include other VMs than Java's. For instance, there's OCaml's toplevel VM, Parrot, and Smalltalk out there. Could be fun.
Okay, I'm not very serious about that.
Given the nuber of top-halves that write to Parrot... maybe so. That's the nice thing about that (unless I vastly misunderstand it): you can sandbox *Parrot*, and then everything that runs atop it is the same amount of safer.
Cheers, -- jra
On 11/14/06, Simetrical Simetrical+wikitech@gmail.com wrote:
That said, there's no reason to be paranoid. Yes, there will always be vulnerabilities, but they'll be doubly limited by the approval process *and* the sandbox. We aren't distributing arbitrary machine code, we're distributing Java, which as far as I know can't do anything like take over your computer or wipe your hard drive. Running arbitrary Java is not to my knowledge a real security risk, at least no more than arbitrary JavaScript (which can spy on you to an extent), and this Java won't even be arbitrary: it will be vetted first, however imperfectly.
In the best case arbitrary java can ask the user to let it out of the sandbox and most users will, in the worst it can just get out on its own (JVM doesn't have a great track record). Once running in trusted mode java can do anything any other binary on your system can do.
Even ignoring that sort of vulnerability, if we allow people to upload java binaries the binaries could decide to display penises every second tuesday. Just limiting it to sysops won't fix it because sysops will be (mostly) adding java which was given to them by (untrusted) third parties. We can't demand the sysops check the java, because no human could be expected to detect such problems.
So we're left with demanding that people submit java in source form (which I suppose is good for other reasons), and then we'll expect qualified admins to audit, compile, then install the code.. yuck.
Better to just write a sandboxed ecmascript or python interpreter which runs in sandboxed Java... and then make an extension that lets you directly input the script code, which will then be handed out to clients. This then reduces the risk of it displaying penises on second tuesdays to the same risk as template code displaying penises on second tuesdays.
It's actually not the far out of an idea... there is already a python implementation in java (jython, http://www.jython.org/Project/index.html) and several of the python plotting libraries will work in jython (http://www.eckhartarnold.de/apppages/pyplotter.html). I imagine that interactive graphs are the largest driver for java apples beyond audio/video playback.
A solution like this would give us real wikieditable software which we could open to the world, and not confine to sysop priests with java compilers and the patience to work offline.
Unfortunately jython needs non-sandboxed java because it mucks about with the VM for the ability to call arbritary java and native code functions. :-/
If anyone is aware of any dynamic languages which will run in sandboxed java and which have decent graphing libraries, I'd love to hear about it. :)
On Tue, Nov 14, 2006 at 05:55:43PM -0500, Gregory Maxwell wrote:
Better to just write a sandboxed ecmascript or python interpreter which runs in sandboxed Java... and then make an extension that lets you directly input the script code, which will then be handed out to clients. This then reduces the risk of it displaying penises on second tuesdays to the same risk as template code displaying penises on second tuesdays.
It's actually not the far out of an idea... there is already a python implementation in java (jython, http://www.jython.org/Project/index.html) and several of the python plotting libraries will work in jython (http://www.eckhartarnold.de/apppages/pyplotter.html). I imagine that interactive graphs are the largest driver for java apples beyond audio/video playback.
For that matter, I think there are JVM-embedded Ruby and Perl interpreters as well. Might as well allow it all, if you're going to do it that way.
A solution like this would give us real wikieditable software which we could open to the world, and not confine to sysop priests with java compilers and the patience to work offline.
That's an excellent point about the social significance of how we handle it.
Unfortunately jython needs non-sandboxed java because it mucks about with the VM for the ability to call arbritary java and native code functions. :-/
If anyone is aware of any dynamic languages which will run in sandboxed java and which have decent graphing libraries, I'd love to hear about it. :)
I don't know whether Ruby's implementations (there are several, in fact) within the JVM allow them to be run sandboxed and, believe it or not, I don't actually know for sure whether there's a Perl implementation to compare, even though I probably use Perl at least as often as any other single language (and significantly more than Ruby).
On 11/14/06, Chad Perrin perrin@apotheon.com wrote: [snip]
For that matter, I think there are JVM-embedded Ruby and Perl interpreters as well. Might as well allow it all, if you're going to do it that way.
I'd prefer we only have one.. simply because I'd rather have one large base of wikipedians speaking the same language than four fragmented groups. .... But I don't really care which one it is.
A solution like this would give us real wikieditable software which we could open to the world, and not confine to sysop priests with java compilers and the patience to work offline.
That's an excellent point about the social significance of how we handle it.
Our site is innovative in many ways...(nearly) instant gratification, open access, revision control (never forget), Free Content, low barriers to entry.. etc.. as we step into the realm of executable content we should not abandon all the things that have made us grand.
I don't know whether Ruby's implementations (there are several, in fact) within the JVM allow them to be run sandboxed and, believe it or not, I don't actually know for sure whether there's a Perl implementation to compare, even though I probably use Perl at least as often as any other single language (and significantly more than Ruby).
Perl .. yuck.. But sure, as I said... I don't care what language. I was hoping there would be some good ECMAscript interpreters in java but because of 'javascript' it's darn difficult to search for.
We need:
0) Can run safely in the JVM. 1) Can perform graphics in the JVM, hopefully sound. 2) near enough to interpreted (compile at preview would be a bummer :) Plus new programmers really enjoy the ability to sit at a prompt and type in code). 3) Used in the outside world (we already have one home grown programming language, we don't need another) 4) Is broadly compatible with the JVMs on client systems. 5) Decent libraries for data handling, graphing, etc a big plus.
I'd rather not make performance a goal.. I'd rather they have facilities for calling java classes we provide.. and we can provide (audited) java classes for anything performance critical... for example video/audio playback or 3D rendering.
On Tue, Nov 14, 2006 at 06:31:50PM -0500, Gregory Maxwell wrote:
On 11/14/06, Chad Perrin perrin@apotheon.com wrote: [snip]
For that matter, I think there are JVM-embedded Ruby and Perl interpreters as well. Might as well allow it all, if you're going to do it that way.
I'd prefer we only have one.. simply because I'd rather have one large base of wikipedians speaking the same language than four fragmented groups. .... But I don't really care which one it is.
In this case, I think the fact that a lot of people will care might reduce the number of people willing to participate, to say nothing of the fact that the way you presented the idea it sounds like the Wikimedia collection of content (and the philosophy of how that content is handled and distributed) would be extended to client-side code. This being the case, it seems inconsistent and exclusionary to only "allow" a single client-side programming language outside of Javascript. Maybe that's just me, though.
Our site is innovative in many ways...(nearly) instant gratification, open access, revision control (never forget), Free Content, low barriers to entry.. etc.. as we step into the realm of executable content we should not abandon all the things that have made us grand.
Thus, my concern about the extension of the philosophy of content to executable content, and being inclusive in terms of interpreted source code that can be used.
We need:
- Can run safely in the JVM.
- Can perform graphics in the JVM, hopefully sound.
- near enough to interpreted (compile at preview would be a bummer :)
Plus new programmers really enjoy the ability to sit at a prompt and type in code). 3) Used in the outside world (we already have one home grown programming language, we don't need another) 4) Is broadly compatible with the JVMs on client systems. 5) Decent libraries for data handling, graphing, etc a big plus.
Agreed on each point, I think. The biggest problems are likely to be a working definition of "safely" and sorting out JVM compatibility on client systems.
On Tue, 2006-11-14 at 18:31 -0500, Gregory Maxwell wrote:
Perl .. yuck.. But sure, as I said... I don't care what language. I was hoping there would be some good ECMAscript interpreters in java but because of 'javascript' it's darn difficult to search for.
I only know of one, Rhino (http://www.mozilla.org/rhino/). Looking from outside, it seems to be a good implementation -- it's actively maintained, and has a nice feature list -- but I've never actually used it.
I'd rather not make performance a goal.. I'd rather they have facilities for calling java classes we provide.. and we can provide (audited) java classes for anything performance critical... for example video/audio playback or 3D rendering.
"... we can provide (audited) java classes for anything performance critical..." Really? Including fluid dynamics simulators, rigid-body kinematics with collision detection, Game of Life simulators, and chess-playing programs? These are just a few possibilities for (the performance-critical part of) educational applets that I came up with off the top of my head; I'm sure there are many more.
The JVM-based interpreter may still be the right thing to do, but people need to be aware that there are whole realms of creative educational possibilities that are far less feasible with that approach.
How does a Java applet go about asking for more privileges? Is that something we can easily audit to avoid (for instance, by checking .class files to make sure they only use standard Java classes and methods that are in a whitelist, not to include reflection)?
If the embedded-in-JVM interpreters let you interact with Java, then you will probably be able to write scripts that ask for more privileges; and that can't be fixed by outlawing reflection, since the interpreter has to use reflection. For this reason, compiled Java may actually be easier to secure than an interpreter.
Can we write our own security manager, ensure that all calls to uploaded .class files are "wrapped" by our security manager, and implement our own restrictive security policy that way?
Carl Witty
On 11/14/06, Carl Witty cwitty@newtonlabs.com wrote:>
"... we can provide (audited) java classes for anything performance critical..." Really? Including fluid dynamics simulators, rigid-body kinematics with collision detection, Game of Life simulators, and chess-playing programs? These are just a few possibilities for (the performance-critical part of) educational applets that I came up with off the top of my head; I'm sure there are many more.
Um. I promise that Game of Life will not be a problem. I've coded a game of life simulation in freeking qbasic on a 286 which was faster than the screen refresh rate.
Fluid dynamics, rigid-body kinematics, and chess... I'm not sure if you are more confused by how slow 'not performance critical' is or if you have totally unrealistic expectations about what is needed to educate people. People not only learned but conducted serious science with software in these fields on the computers of a decade ago, even with interpreted languages far slower than what we'd use today... I wouldn't expect a modern interpreted language to be any slower...
When I played with jython before it was about half the speed of cpython (without psyco) on the same code, with a simmlar difference compared to raw java.
Moreover, I hope you realize that the limiting factor for any of this will be authoring the code. If a poor security model or editing model keeps us from tapping into the public at large we will not do well.
The JVM-based interpreter may still be the right thing to do, but people need to be aware that there are whole realms of creative educational possibilities that are far less feasible with that approach.
I don't understand your argument. Java classes + an available interpreter can not be slower than java classes alone.
How does a Java applet go about asking for more privileges? Is that something we can easily audit to avoid (for instance, by checking .class files to make sure they only use standard Java classes and methods that are in a whitelist, not to include reflection)?
It's not easy to audit if we're working with bytecode, ... if we're working with sourcecode thats another matter.
If the embedded-in-JVM interpreters let you interact with Java, then you will probably be able to write scripts that ask for more privileges; and that can't be fixed by outlawing reflection, since the interpreter has to use reflection. For this reason, compiled Java may actually be easier to secure than an interpreter.
You control what methods they can access by what you choose to expose, and you don't like the interpreter otherwise much with the VM. This is why jython is currently a non-starter (and in general, python has been difficult to lock down).
Can we write our own security manager, ensure that all calls to uploaded .class files are "wrapped" by our security manager, and implement our own restrictive security policy that way?
You have to have signed code to hook in as a security manager.. but lets assume we could:
This would do nothing to stop mistery meat code from displaying penises every second tuesday. The only way to handle that is to keep size down, readability up, and always work with source.
In any case, it's pointless to debate what loft applications we'd exclude with a particular implementation when none of these pieces of software currently exist.
On Tue, 2006-11-14 at 21:50 -0500, Gregory Maxwell wrote:
On 11/14/06, Carl Witty cwitty@newtonlabs.com wrote:>
"... we can provide (audited) java classes for anything performance critical..." Really? Including fluid dynamics simulators, rigid-body kinematics with collision detection, Game of Life simulators, and chess-playing programs? These are just a few possibilities for (the performance-critical part of) educational applets that I came up with off the top of my head; I'm sure there are many more.
Um. I promise that Game of Life will not be a problem. I've coded a game of life simulation in freeking qbasic on a 286 which was faster than the screen refresh rate.
Using what size grid? Would it have been that fast on Paul Rendell's Game of Life Turing Machine (1714 x 1647 cells)? What if you want to run much faster than the screen refresh rate ("what will this pattern look like after a million generations")?
Fluid dynamics, rigid-body kinematics, and chess... I'm not sure if you are more confused by how slow 'not performance critical' is or if you have totally unrealistic expectations about what is needed to educate people. People not only learned but conducted serious science with software in these fields on the computers of a decade ago, even with interpreted languages far slower than what we'd use today... I wouldn't expect a modern interpreted language to be any slower...
I contend that the performance requirements for serious science are far less than the performance requirements for an educational applet. A scientist will be willing to spend a lot of time carefully designing small experiments that will test a hypothesis, and then spend a week running the experiment; if an applet takes more than a minute to set up an experiment and get results, you'll lose a lot of viewers (a couple of seconds is a much more desirable time).
I guess partly it depends on the goals for these applets. Do we want to reach only people who are "captive" (studying this material for a course, or intensely curious about the material) or do we also want to try to "grab" people who are only mildly curious?
Perhaps my particular examples were poorly chosen, but I'm having a hard time believing that there are no examples where a more-than-an-order-of-magnitude improvement in speed would make a significant difference in the educational impact of an applet.
When I played with jython before it was about half the speed of cpython (without psyco) on the same code, with a simmlar difference compared to raw java.
I'm having a hard time parsing your sentence, but I think you're saying that cpython is about as fast as raw Java? That's going to depend heavily on your workload. I realize it's a bad idea to draw conclusions from a small set of flawed benchmarks, but I'm going to try anyway (attempting to be conservative). Looking at http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python... indicates to me that Python is comparable in speed with Java when most of the time is spent doing things that Python has C libraries for (regular expression matching, hash tables, arbitrary precision arithmetic), but that Python is much slower than Java (more than an order of magnitude) at doing things like fluid dynamics, where the inner loop has a lot of floating-point math and is not sped up by libraries.
Moreover, I hope you realize that the limiting factor for any of this will be authoring the code. If a poor security model or editing model keeps us from tapping into the public at large we will not do well.
Definitely true!
The JVM-based interpreter may still be the right thing to do, but people need to be aware that there are whole realms of creative educational possibilities that are far less feasible with that approach.
I don't understand your argument. Java classes + an available interpreter can not be slower than java classes alone.
If you require that Java code be heavily audited, and that interpreted code only needs to be lightly audited, and if your supply of people willing and capable of doing heavy auditing is limited, then you'll end up with slower code than if you allow lightly audited Java code.
How does a Java applet go about asking for more privileges? Is that something we can easily audit to avoid (for instance, by checking .class files to make sure they only use standard Java classes and methods that are in a whitelist, not to include reflection)?
It's not easy to audit if we're working with bytecode, ... if we're working with sourcecode thats another matter.
In the specific case of auditing that only classes and methods from a whitelist are used, I still think that the easiest method is to write an automated tool that examines the .class file. Other kinds of auditing, of course, are totally infeasible on the bytecode, and require source code.
If the embedded-in-JVM interpreters let you interact with Java, then you will probably be able to write scripts that ask for more privileges; and that can't be fixed by outlawing reflection, since the interpreter has to use reflection. For this reason, compiled Java may actually be easier to secure than an interpreter.
You control what methods they can access by what you choose to expose, and you don't like the interpreter otherwise much with the VM. This is why jython is currently a non-starter (and in general, python has been difficult to lock down).
I would think that most JVM-based interpreters would use reflection to allow access to arbitrary Java classes and methods; this would normally be considered an advantage, and would be a big selling point ("allows seamless integration with Java!") for the interpreter.
Can we write our own security manager, ensure that all calls to uploaded .class files are "wrapped" by our security manager, and implement our own restrictive security policy that way?
You have to have signed code to hook in as a security manager.. but lets assume we could:
This would do nothing to stop mistery meat code from displaying penises every second tuesday. The only way to handle that is to keep size down, readability up, and always work with source.
True. But that has nothing to do with whether we allow raw Java or whether we require some sort of interpreter.
In any case, it's pointless to debate what loft applications we'd exclude with a particular implementation when none of these pieces of software currently exist.
As long as we're not setting policies now that will be difficult to change later...
Carl Witty
Carl Witty wrote:
On Tue, 2006-11-14 at 21:50 -0500, Gregory Maxwell wrote:
On 11/14/06, Carl Witty cwitty@newtonlabs.com wrote:>
Um. I promise that Game of Life will not be a problem. I've coded a game of life simulation in freeking qbasic on a 286 which was faster than the screen refresh rate.
Using what size grid? Would it have been that fast on Paul Rendell's Game of Life Turing Machine (1714 x 1647 cells)? What if you want to run much faster than the screen refresh rate ("what will this pattern look like after a million generations")?
Then you use a Hashlife algorithm, which is complex enough that it's not something you want just anybody to edit (and most people wouldn't want to edit it anyway). So you (find someone to) write it any way you like, in the most efficient manner you can think of, and then have it audited and included as a trusted component (and accept the blame if there are any penises hidden in it).
If you require that Java code be heavily audited, and that interpreted code only needs to be lightly audited, and if your supply of people willing and capable of doing heavy auditing is limited, then you'll end up with slower code than if you allow lightly audited Java code.
However, the supply of people capable of writing the kind of high performance code where the interpreter would really be a major disadvantage is also limited. So yes, the auditing would be a bottleneck, but it might not be _the_ bottleneck.
(Of course, anyone can write code that runs slowly. Very few people, however, can write code that not only does something slow, but really can't be made any faster except by switching to a lower level language.)
On Tue, Nov 14, 2006 at 06:03:26PM -0800, Carl Witty wrote:
Can we write our own security manager, ensure that all calls to uploaded .class files are "wrapped" by our security manager, and implement our own restrictive security policy that way?
. . . and if we do so, do we want to do it with something other than a JVM so we can avoid little issues like the nontrivial time and resources consumed on startup of the VM?
On Tue, Nov 14, 2006 at 06:31:50PM -0500, Gregory Maxwell wrote:
Our site is innovative in many ways...(nearly) instant gratification, open access, revision control (never forget), Free Content, low barriers to entry.. etc.. as we step into the realm of executable content we should not abandon all the things that have made us grand.
These issues have, of course, already been discussed: see WebGUI (which is pretty hardcore about not allowing code in through the frontend), to Zope, (which is not).
Cheers, -- jra
On 11/14/06, Simetrical Simetrical+wikitech@gmail.com wrote:
That said, there's no reason to be paranoid. Yes, there will always be vulnerabilities, but they'll be doubly limited by the approval process *and* the sandbox. We aren't distributing arbitrary machine code, we're distributing Java, which as far as I know can't do anything like take over your computer or wipe your hard drive. Running arbitrary Java is not to my knowledge a real security risk, at least no more than arbitrary JavaScript (which can spy on you to an extent), and this Java won't even be arbitrary: it will be vetted first, however imperfectly.
You are mistaken about the nature of Java code. Java code can do anything code in any other language can do (can we say java.lang.Runtime, please?); all it takes to escape the security context is one user clicking "OK" to the "give this applet permissions?" question that comes up when a signed applet is signed with an unrecognized certificate. Most people will click "OK" on that dialog. This is even true for applets; escaping the standard security context merely requires a touch of social engineering.
Kelly
Kelly Martin wrote:
On 11/14/06, Simetrical Simetrical+wikitech@gmail.com wrote:
That said, there's no reason to be paranoid. Yes, there will always be vulnerabilities, but they'll be doubly limited by the approval process *and* the sandbox. We aren't distributing arbitrary machine code, we're distributing Java, which as far as I know can't do anything like take over your computer or wipe your hard drive. Running arbitrary Java is not to my knowledge a real security risk, at least no more than arbitrary JavaScript (which can spy on you to an extent), and this Java won't even be arbitrary: it will be vetted first, however imperfectly.
You are mistaken about the nature of Java code. Java code can do anything code in any other language can do (can we say java.lang.Runtime, please?); all it takes to escape the security context is one user clicking "OK" to the "give this applet permissions?" question that comes up when a signed applet is signed with an unrecognized certificate. Most people will click "OK" on that dialog. This is even true for applets; escaping the standard security context merely requires a touch of social engineering.
A la. "this does really cool stuff, but um you need to click ok because I didn't feeling like paying evil corporations money".
wikitech-l@lists.wikimedia.org