Java applets in Wikipedia - that do you think?
Posted 23 Aug 2009 at 17:54 UTC (updated 23 Aug 2009 at 18:32 UTC) by audriusa
Wikipedia recently posted a call for strategic proposals, and one subset
of them looks quite interesting for me - it is a bunch of proposals to
support some kind of the client side scripting. They have a choice
between JavaScript, Flash, Java and Silverlight. After all that at the
end happened with FOSS Java implementation, Java applets seem an
interesting option so let's propose.
To be heard by needed people, this proposal have been uploaded
to Wikipedia
Strategic
Projects space so it
can also be viewed there. It is up to you where to make the comments.
Proposal:Java applet support
Summary
Allow to place Java applets in Wikipedia pages.
Introduction
Java applet is a powerful feature to illustrate mathematical,
technical,
electric and some other subjects, from interactive function graphs till
mathematical models with advanced visualization. Unlike animations, they
may have controls to interact with the user, allowing active
experiments. During the years, lots of applets were created for
educational and similar purposes; it is even possible to suspect that
this is one of the most successful areas of they use.
There are quite many such applets on the web but they must be
stored at
the cost of they authors and frequently disappear when the funding
ceases. Many are available with the full source code but without any
clear license, so it is not obvious if even screen shoot can be uploaded
to Wikipedia.
Popularity
It is a normal security practice to disable all unneeded browser
features for untrusted sites, and it may happen that Java is disabled by
default as well on a majority of browsers. This, however, does not look
like a major problem as it is not complex to install1 and enable Java
for selected sites. Administrators are also not just devils: after
several years of nothing horrible happening around they would enable
features that people need for they direct work.
Java on a browsers has been available for a long time but was
criticized
by some parts as too proprietary. In particular, it was common not to
have Java applets under Linux but with more than three 1 FOSS
implementations recently available this is likely to change. After all,
if something is not yet done, putting applets to Wikipedia may
contribute a desired kick, motivating people to complete the work.
Regardless of all said it may be that certain percent of
browsers will
not be able to run applets. For such cases, it is possible to specify
the replacement of the content, using applet area to show the replacing
static figure.
1 OpenJDK from Sun, GNU Classpath from FSF, Harmony from
Apache and worth to mention IceTea from Sun/Red Hat.
Security
The security related criticism may sound more seriously but also
should
be weighted. Java applet in a properly designed browser cannot access
the user file system, clipboard and is only allowed to communicate with
the web site from where it was downloaded, so it is not more dangerous
than any .jpeg image. Java has been designed with security in mind [1]
and lots of work was done late to increase security even further [2].
A Google search gives a long list of scaring warnings that
accumulated
through years but it seems not many cases when malicious java applet
have actually done a real damage. After all, Java applets can always be
disabled through browser configuration settings and can additionally be
disabled by Wikipedia engine, serving them only if user has enabled this
feature. From the other side, the currently widespread JavaScript,
ActionScript and Microsoft Silverlight technically are also just client
side scripting languages, same as Java is, so they have no obvious
reason to be more secure. Differently, a language with longer history
seems much more likely to have possible security bugs discovered and
closed, so if once to allow the client side scripting, choosing
something that "it is new and it is secure" may not look like an optimal
decision.
Ways to reduce the risk
The risk can be further reduced by
- Only accepting applets from the known real people with name and
GPG signature, and listing the authors after clicking under "info" link.
It is also possible to verify physical address by asking to contact
Wikipedia by ordinary mail.
- Introducing community driven approval process, with some people
running the applet and viewing the source code before making it public.
Updates in existing code are easy to check if they are given in the form
of patches.
- Restricting the set of Java classes that are allowed to use. The
standard Java security uses security manager to block potentially
malicious operations but in general applets have access to the same
library as standalone executables do. It is possible to increase
security by disallowing the usage of potentially dangerous classes on a
server side. Wikipedia server can easily refuse to accept upload or
deliver download of an applet that violates agreed security rules. Java
code needs to declare the packages it uses in the beginning of every file.
- Implementing the server side scanning of applets. That way it is
possible to put further restrictions on the language subset that is
allowed to use. For instance, network access, class loading by name or
reflection can be disabled by rejecting uploads of applets that
reference these features.
Fixed sets of applets for ultimate security
Java applet that visualizes complex mathematical function, with controls
to alter parameters.
JFreeChart (LGPL) applet already has the most of functionality, needed
to visualize X/Y dependencies
For the ultimate safety, it may be possible to have a limited set of
standard applets rather than allowing to users to upload they own ones.
Such applets become part of the Wikipedia side software that is just
executed on a client side. To be useful in multiple articles, such
applets could be configurable via they parameters.
- One obvious candidates to such applet could be function drawing
applet that could draw function graphs with interactive controls to
change some parameters. This application can be relatively easily made
by combining available FOSS charting library (like JFreeChart) with some
FOSS expression evaluator (to pass the expression to chart).
- An applet for digital electronics may also look realistic,
however about this one I am less informed. There are several FOSS
libraries that maybe would work.
However the fixed set approach would severely limit the diversity of
applets and at the end may be too restrictive. In particular,
demonstration of physical laws and other similar applets seem difficult
to put in some simple generic framework unless adding one more layer of
scripting language. The author of proposal just wants to discuss this
ultimate compromise as the last topic if anything else would be found
unacceptable.
Motivation
Wikipedia pages are now mostly static. Some animations are
available but
they cannot interact with the reader. The only true and obvious
interactivity is by navigating between pages themselves. This problem is
also understood by the authors of other proposals, like Visualization
methods or Interactive articles.
Java is a highly popular language with long history; many issues
that
were possible in the past should be resolved. Educational and
demonstrational Java applets are abundant on a web, showing that this
technology may be efficient and attractive. Allowing applets would allow
Java developers to participate in Wikipedia with they programming
contribution. For the average developer, writing applet is not much more
difficult than adding text. Unlike animations that tend to grow quickly
into tens and hundreds of megabytes, most of the applets are usually
below one megabyte in size.
Alternatives
JavaScript and ActionScript are two other languages that may also be
discussed. For the author of this proposal, Java seems more suitable for
generating user-driven visualizations and also similarity to C allows to
port code from research projects more easily. While Java may be not as
fast as C (that is not possible to embed into browser), it is much
faster than JavaScript and can be used in demonstrations that are
computation intensive.
Silverlight may cause compatibility problems as not all operating
systems have implementation from the same vendor. From these possible
candidates Java seems more popular, so likely more people will know it
and more contributions are expected. Sever side scripting, present in
other proposals, seems not a good replacement for these as it adds the
server side call making everything much slower than it could be. Also,
allowing to run user script on Wikipedia server may have even bigger
security risks.
Deciding on some scripting for Wikipedia automatically means
that the
chosen language will get a boost for popularity. Hence it would be an
important decision. Worth to think.
In Wikipedia, where editing of articles is core to its operation and
philosophy, the editing of Java applets must be as well.
To achieve that aim, it would make sense that new java applets are
uploaded only in the form of source code, and that source code is
viewable in the same historical manner as regular articles. Java
applets would then be compiled by the wikipedia servers before being
made part of the page.
Which version of the source code that is compiled should be a matter of
approval. Editing code has more security implications than editing the
text of a wiki article, so such code should be peer reviewed, and
require approval before the server compiles the latest code to form the
applet.
It should be clear in the historical source code view which version is
currently being used for the downloaded applet, and which changes have
not yet been reviewed and approved.
All java applet source code must be licensed under a CC style
license, similar to the rest of the media on Wikipedia.
Yes, of course. Updated on Wikipedia project space. Reviewing of the source code would add a lot of security. Maybe the best is simply to accept submissions in source code only, compiling on a server side.
The applet should be separated from article text, much like images are;
Java source code in articles would hurt WP.
I would imagine they would want to create a new article namespace, e.g.
so CoolApplet would be linked by [[Java:CoolApplet]]
These are similar in principle to images. Wikipedia does not require
artists to upload source code or original PSD files for layered diagrams
and figures they create, or photographers to upload high-res images,
when they reduced the resolution for display on WP, essentially, this
means only the author can update without degrading quality.
And I think it should be the developer's choice whether to provide
source code or not for applets, provided the class files they upload
meet Wikipedia's security policies.
However, Wikipedia should definitely allow them to provide source code,
and IMO, prefer open source content over equivalent closed source content.
Some developers will object to Creative Commons licensing of source
code. The problem is it allows a commercial developer to make changes
to the code, distribute only binaries, and sell those binaries.
There should be some compromise, like letting them use GPL for the code,
and license the visual elements of the application under CC-BY-SA.
And I think it should be the developer's choice whether to provide
source code or not for applets, provided the class files they upload
meet Wikipedia's security policies.
How will you openly check for security without the source code?
Disassember?
I disagree that source code should be optional. The text of articles is
open and the media such as photos and sound is open. Programs should be
open too.
The comparison to photos being uploaded at high res is mistaken in my
opinion. The author of a Java applet has the option to remove features
before uploading his app, just as a photographer has the option to
upload a smaller image. But what people do with the java applet or
the photograph after it has been uploaded is governed by the open
licenses that Wikipedia is well
known for.
There should be some compromise, like letting them use GPL for the code,
and license the visual elements of the application under CC-BY-SA.
I have no problem with the GPL being used for the code, but as the GFDL
change has shown, the Wikipedia community might. I wouldn't want to see
a similar exception added to the GPL due to an unpopular decision made now.
What do I think? , posted 8 Sep 2009 at 20:34 UTC by uriel »
(Journeyer)
I'm too busy checking what is wrong with advogato's post dates, it claims this story was not posted on the first of April, and I'm certain it can't have been posted any other date.
In other words: try to keep your hallucinogenic experimentation away from wikipedia, and you will have my eternal gratitude. The 90's are dead, and the death of Applets with it were one of the few good things the new millennium brought us.
I would never be suggesting this without knowing that even Sun's Java is
FOSS now so theoretically can be ported to the new platforms, including
experimental ones. If this seems too problematic to start with,
"esoteric systems" maybe could try gcjappletviewer from GNU Classpath, that maybe could be easier to
port.
the number of reasons why java should not be included as a language in which authoritative wikipedia articles can be written are so numerous that i am really taken aback that it was even suggested.
the entry barrier to java, both in terms of deployement and in terms of actually being able to contribute, is just way too high and is completely at odds with the aims of the wikipedia project.
if wikipedia was a tiny project, with a specialist reach into one particular area (scientific research for example) then fine - it would probably be fantastic (and i wouldn't go near it in a million years).
but for "general purpose" unrestricted deployment? absolutely no way in hell. the potentials for abuse and elitism are just too great.
It would be good if you find time to list at least top five. Would be a valuable contribution to Wikipedia Applets project.
done., posted 25 Sep 2009 at 11:17 UTC by lkcl »
(Master)
if you look in the responses so far, i've made at least three, which focus on the massive burden placed on contributors and the "elitism" which would come with contributions written solely and exclusively in java. other commenters cover at least another three (mostly involving security, sandboxing etc.)
you _really_ need to think this through from the simple perspective of: "how can anyone literally anyone now contribute to wikipedia? answer: simply through the use of any web browser dating back 20 years (or even by actually telnetting into the HTTP port of wikipedia.org if they are desperate enough), and submitting.... words".
if java could be executed _in_ the web browser (and not as a plugin)
if the java development environment could be executed _in_ the web browser (and not as a plugin)
if the java compilation could be executed _in_ the web browser (and not as a plugin)
if the resultant application could be executed _in_ the web browser (and not as a plugin)
THEN you stand a chance of java being half-way acceptable. i say HALF way because you then also still have the barrier to entry of contributions requiring that the contributors be "java programmers". which is still wholly and completely unacceptable for something as large and lowest-common-denominator-contributable as wikipedia.
the bottom line is absolute and straightforward: the lowest common denominator takes absolute unassailable priority. in every way shape and form, java doesn't _remotely_ come close to being a lowest common denominator.
I agree that Java or any other IDE inside the browser does not look reasonable and in any case would be far more limited than a good standalone IDE.
well... it depends, posted 25 Sep 2009 at 20:35 UTC by lkcl »
(Master)
pyjamas and
skulpt demonstrate that it's perfectly well possible to do self-hosting language translation, complete with interpreter and GUI widgets, from another language into javascript. there's even x86 assembler and 6502 assembler interpreters, written in javascript; ruby in javascript (rubyjs); hotruby; scheme and many more.
google maps and many other rich media apps written purely in javascript show that wow, dang, it most definitely _is_ possible to do useable and useful complex javascript applications.
so it's perfectly possible... the question is: do you _really_ want to bother? eclipse is a whopping 150 mb download, for goodness sake. why anyone would _choose_ to inflict themselves with that kind of millstone even as a desktop app i honestly cannot understand, and to even remotely contemplate even auto-conversion to javascript, for execution in-browser, is just unthinkable.
Much needed, posted 13 Nov 2009 at 23:19 UTC by aminorex »
(Journeyer)
It's the only portable way to do animations and process logic.