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 Share This

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.


Upload code, not applets, posted 23 Aug 2009 at 18:25 UTC by cdfrey » (Journeyer)

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.

Makes a lot of sense. , posted 23 Aug 2009 at 18:39 UTC by audriusa » (Journeyer)

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.

Separate app frmo article, posted 29 Aug 2009 at 18:57 UTC by Mysidia » (Journeyer)

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.

Source code is needed, posted 30 Aug 2009 at 02:38 UTC by cdfrey » (Journeyer)

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.

Java on "esoteric platforms", posted 10 Sep 2009 at 09:08 UTC by audriusa » (Journeyer)

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.

absolutely no way in hell., posted 24 Sep 2009 at 12:51 UTC by lkcl » (Master)

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.

.. so numerous that i am really ..., posted 25 Sep 2009 at 09:39 UTC by audriusa » (Journeyer)

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.

JDK inside the browser?, posted 25 Sep 2009 at 15:10 UTC by audriusa » (Journeyer)

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.

And now the history continues at Ultrastudio.org, posted 10 Jul 2010 at 09:08 UTC by audriusa » (Journeyer)

And now see the continuation of the history at Ultrastudio.org.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page