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.