On 11/14/06, Gregory Maxwell <gmaxwell(a)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/repositoryApple…
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.
--
Peace & Love,
Erik
Member, Wikimedia Foundation Board of Trustees
DISCLAIMER: Unless otherwise stated, all views or opinions expressed
in this message are solely my own and do not represent an official
position of the Wikimedia Foundation or its Board of Trustees.