Jump to content

Proposal:Java applet support

From Strategic Planning
Status (see valid statuses)

The status of this proposal is:
Request for Discussion / Sign-Ups

Every proposal should be tied to one of the strategic priorities below.

Edit this page to help identify the priorities related to this proposal!


  1. Achieve continued growth in readership
  2. Focus on quality content
  3. Increase Participation
  4. Stabilize and improve the infrastructure
  5. Encourage Innovation



This is a featured proposal.
This template automatically categorizes into Category:Featured proposals. All proposals marked by this template should be on this list too.
The Wikimedia sites use Java in one capacity today — The cortado applet is used as one of the fallback methods of multimedia playback support for users with browsers which lack HTML5 <video> and <audio> tag support. Shown with top output that displays resource usage (183 Mb of RAM).
Java applet that demonstrates organism development, allowing the user to change the model parameters. The 3D object (growing organism) can be manipulated with the mouse, allowing to view it from all sides.
As applets are not supported, a screen shoot rather than applet has been uploaded to Commons in the past
3D molecular viewer applet is available under LGPL [2]. It accepts standard scientific .pdb files as input that can be enclosed in the applet archive or (if networking is allowed) downloaded from Wikipedia server. Additional 3D objects can be created through scripting, making it a generic 3D viewer as well.
This Mandelbrot set viewer, available under GPL [3] is a computation intensive visualization that benefits from faster language and scales better when running on a client side
A good way to understand the rules of the game is through playing. Chess applet under BSD [4].
Interactive comparison of the sequence alignment algorithms, GPL license [5].
NASA World Wind applet (open source) overlays NASA and USGS satellite imagery, aerial photography, topographic maps and publicly available GIS data on 3D models of the Earth and other planets. [6] [7].

.

A GPL licensed applet from the Virtual hearth[1]

Summary

Allow to place Java applets in Wikipedia pages. Contributions to applets are not expected to be from all "end-users" but only from users who have knowledge of the Java programming language. Others would handle applets same way images are handled.

Proposal

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. They are fast enough for non trivial visualizations that are computation intensive. They are more portable, secure and website-integrable than standalone applications.

Actually, in somewhat 1998's the good part of Java - related talks were talks about applets, while the main direction was general improvement of the web site appearance like enhanced animations [8]. This direction seems exhausted now: applets are overkill just for visual effects and simpler technologies tend taking over.

However a completely different group of applets started to emerge 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. Apart separate applets, there are also some big projects, for instance, the complete suite to assist the course on differential equations[2]

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.

We propose to provide possibility to put Java applets into Wikipedia space. The good, cooperative solution should also support and enforce publishing the source code together with the applet, also stored on Wikipedia server. This would also allow source code review for security and eliminate dependency on a single developer. The simplest way to enforce this is to accept applets in the form of the source code (an archive of .java rather than .class files) and compile them on a server side.

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 2 open source 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.

Java also had problems under Windows platform. The extremely outdated Internet Explorer Java virtual machine seriously limited programmers who wanted to support it as well. However it may be that in near future Microsoft will be shipping Sun's recent installation instead, as well as offering it as a recommended update[3].

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.

The major limitations of applet, imposed by security constraints, are limitations on communication: not a lot of typical tasks can be solved without network, only having user controls as an input, even if a lot of computing power is available. However this power and user input are more than enough to build a tool for illustrating some complex concept. This is why applets are popular in this concept illustration and should serve this purpose well in Wikipedia as well.

1sudo apt-get install sun-java6-plugin under Ubuntu does not look like a lot of work and there are lots of detailed instructions for inexperienced users on a web.

2 OpenJDK from Sun, GNU Classpath from FSF and Harmony for Apache.

Known Wikipedia - like sites, offering Java applets

At the time of writing the proposal, there were no any notable projects that would combine Java applets and Wiki engine. Closest to that from the applet side looked SourceForge.net that hosts huge number of various free/open source software, including many applets. However as of July 2010, Ultrastudio.org have emerged, offering something very close to that is summarized in this proposal. Ultrastudio.org has the code reviewing system, Wiki engine that supports applets very much like images in Wikipedia are supported and security-aware server side applet builder. It is currently not clear how successful this project will be.

Security

The security related criticism may sound more seriously but also should be weighted. The java sandbox is compared to other client based technologies (like flash) *very* restrictive. 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 does not look very dangerous. Applets which require elevated priveledges (signed applets) should be forbidden in Wikipedia. Java has been designed with security in mind [9], [10]. Also, after serious reading not all "malicious applets" (described in [11], for instance) look actually dangerous, most just try to crash the browser or get some tiny "victory" that seems of no much use. Some theoretical attacks assume configuration errors severe enough to be dangerous without any applets being involved (like allowing to open Telnet port for FTP [12]) Very few, if any, studies list real accidents (security breaches) rather than theoretical possibilities, and some even say there are no any so far[13]. In any case, everything is plainly visible in the applet source code.

However while good percent of Java security publications on a web look more like a mix of groundless claims, psychological pressure, references to non existent source code files and even "malicious applets" like [4], some real problems like Calendar serialization bug[5] have been found and fixed only very recently, without anybody (hopefully crackers including) being aware for many years. Hence we agree that there is at least a theoretical risk of cracking attacks, while it still seems more probable to suffer the hard drive failure or something like that.

On the other hand, software additions to Wikipedia are quite common even today - namely in the form of bots and client-side scripts - and while security concerns exist, they do not seem to be so much of an issue in practice. Some review and approval processes exist, but they are surprisingly weak (at least surprising to me), which has so far not been an issue of concern. For the Java applets, it might be reasonable to require the source code to be open; maybe they should be compiled on the side of Wikimedia from the published source. Apart from making development independent of the individual user, this would also address most security related issues.

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

Accessing Wikipedia content by unsigned applets

An applet, downloaded from Wikipedia server can talk with this server. This is not so bad as it can download data like protein 3D files from there. However misbehaving appled could overload the server with queries that are similar to queries from ordinary users. To prevent this, applets and all they data could be hosted in a separate domain. Additionally, applets that overload server may be automatically blocked (not delivering them any longer). This may be possible by correlating applet IP with IP where the applet have just been recently downloaded.

Ways to reduce the risk

The risk can be further reduced by applying more rules. These rules must be carefully weighted because having them too strict may cause all project to fail. Some possible rules could be:

  • Introducing community driven approval process, with some people running the applet and viewing the essentially available source code before allowing applet to appear in usual Wikipedia pages. This also would eliminate applets that are simply buggy.
  • Only accepting applets from the known real people with name and maybe GPG signature (see proposal). It is also possible to verify physical address by asking to contact Wikipedia by ordinary mail.
  • Using at least rudimentary scanner (for instance, PMD based) that might appear orthogonal in capabilities to the browser security.

There are also more technical means to apply but these already have a criticism section as well. As Java runtime already has a strict security model, it might also be that these measures are not required.

  • While Java applets can always be disabled through browser configuration settings, as an additional measure they can be disabled by Wikipedia engine, serving applets only for the users that agree to receive them. However this would restrict usage in places like computer classes where may not be reasonable to demand everybody to have an account.
  • 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. This may require the use of the Java grammar parser under free license. Some parsers are listed in [14]. We could partially reuse the whitelist of reasonably harmless Java classes that has been recently prepared by Google security specialists but anyway must extend it by many classes [6]

However this approach would prevent the usage of forbidden classes for legitimate purposes like downloading from Commons data file that could be later visualized or played in particular article (reusing the same applet for many articles). From the other side, the class whitelist may be discussed as an alternative for code reviewing if the activity of community would appear not sufficient to have applets checked and approved in acceptable time.

  • The last measure would be to allow fixed set of applets only that are written and approved once. It could be interactive maps, charts, 3D structure viewers, maybe something else. Such applets can be later customized with parameters and could also download data like 3D files from Commons. However the fixed set approach would severely limit the diversity of applets and at the end may be too restrictive for the project to be successful. It also tends to shift the most of the work on the shoulders of Wikipedia dedicated programmers that is an expensive solution.

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. Not all they are under FOSS licenses, but many are, showing the willingness of some authors to share the work. Allowing applets would allow Java developers to participate in Wikipedia with they programming contribution. For the average developer, writing applet is relatively very easy task, comparable by time with the text contribution. Unlike animations that tend to grow quickly into tens and hundreds of megabytes, most of the applets are usually below one megabyte in size.

Additional Use Cases

  • JOGL enables secure hardware accelerated 3D visualizations, useful in 3D geometry or organic chemistry, for instance. There are, for instance, viewers to show 3D structure of proteins from existing structure files [15], many of them public domain [16].
  • Where Java interpreter is already written (Prolog [17], Python (Jython), Perl [18], Basic [19] and so on), an applet could allow to try immediately the programming language that the article is about.
  • Similarly some games can be made live. To demonstrate the game, an applet need not be strong player, just not overall stupid and follow rules of the game. Even chess playing applet exists [20] and is under free license.
  • Applets are useful used as falback mode to play media in browsers which don't support open source codecs [21].
  • 3D interactive map applets (such as NASAs World Wind [7]) could be used to show geographic locations.
  • Applets should also be able to run inside electronic books as long as some mouse interface (or equivalent) is provided, enhancing advantages of E-book versus ordinary paper book.

Key Questions

  • Will the people write the applets for Wikipedia?
  • Will the people allow to run applets on the browsers?
  • Which level of security is reasonable?
  • Where and how to store the applets and provide the source code?
  • How arrange code reviewing so that it would not take unacceptably long?
  • Would it make sense to keep several versions of applets (1.0+, 1.2+, OpenGL) and deliver following user preferences? Applets that require newest bells and whistles may have more narrow base of users that can view them.
  • GPG signature verification (trusted servers, etc).
  • Acceptable applet source code licenses. One approach is to allow any OSI approved licenses, other - to have the fixed list for easier code migration between applets.

Potential Costs

The project can be implemented in several ways, having more for more costs. Likely at least the following choices are possible:

  1. Implement server side compilation from uploaded archives, containing source code only and set up some web environment for people to run test versions and view/approve the code. This also does not look like a lot of work, likely one developer month at most with all testing but would ensure independence from the first applet contributor.
  2. It would be great for somebody to work full time for a couple of months or about to collect existing applets under FOSS license from the web and do some code inspection. We may get an interesting contribution without programming at all.
  3. If something really cheap and fast is required, we could simply implement possibility to upload applet .jar same way images are uploaded and extend Wiki language to embed applet, specify parameters and specify the alternative content in the applet place if the applet is not available. This way would be reasonable if we assume that security risks are not so huge and we do not need to enforce publishing of the source code. This is path is not preferred by the author of the proposal but it still would be better than nothing (who wants, can host applet code in SourceForge).

Additionally, it may take some work to set up Java applet developer community and to verify first applets. If it would not be enough truly FOSS demos, projects like OSCAR [8] can provide some applets for beginning under fair use, we can later phase them out or maybe authors will relicense. Later this community maybe can exist on itself, using the new "Java specialist" role that could substitute administrators in approving the new applets,

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 seems notably faster than JavaScript [22] and can be used in computation intensive visualizations like Mandelbrot set in the figure. JavaScript also offers features like GChart for creating graphics that can replace simple applets like interactive charts. However it seems not equally well suited for tasks that are computation intensive or have complex algorithm. While it may be useful for Wikipedia to provide JavaScript support as well, this would not eliminate the need of Java applets for the most interesting cases.

Silverlight may cause compatibility problems as not all operating systems have implementation from the same vendor. While in the less scale, this may also be the issue for ActionScript because part of the users (in particular Linux distributions) may press on using Gnash.

From these possible candidates Java seems more popular between developers, 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. In addition, applets scale better than servlets as they pass load to the client machine.

Better visualization may also be possible by providing a self-dependent Wikipedia access program that would be a replacement for the browser. However this approach requires to support legacy versions of such "Wikibrowser", as it cannot be easily updated. Differently, applet is updated by the browser if it changes.

It is important to note that all security issues are fundamentally the same for any kind of the client side scripting, so they should be equally taken into consideration when discussing alternatives as well, even if some newer technology is better marketed and had less time to collect scarying texts on a web. For instance, a platform with public bug database is actually more secure as it allows to report and fix bugs well before anybody have used them. However platform that does not even allow to report a bug ("we do not have bugs at all") easily may appear more secure as in this case the bug becomes known only after the real accident that in addition needs to be disclosed. Also, allowing to run user script on Wikipedia server may have even bigger security risks.

While it is possible to generalize this proposal as "some kind of server side interactivity is needed", the number of technologies to support is a topic of the separate discussion. In the case of limited resources it may be more reasonable to select one visualization technology, allowing to invest more work into infrastructure that would support it. Alternatively maybe at most two technologies with clearly separable roles and very different strongest sides may be selected, the second technology being a subject of separate proposal.

Probable infrastructure

The supporting infrastructure can vary be complexity. The simplest way seems to derive it from the structure, used to upload images. It needs to support multiple versions of the source code archives (can be done by adding suffix to archive name) and have a discussion page for approval process and bug reports. All web layout, while complex, may be possible to set a wiki level.

The applet could be uploaded in the source archive form, compiled on a server side and presented for download in both source and .jar form. At this stage the server would apply automatic code checks, if any. If it would happen that it is too slow to compile applet at the upload time, the server may have internal compilation queue, automatically updating wiki contents and status page as it proceeds.

The approved applets then could be embedded into Wikipedia page same way as images are, with extensions that would allow to pass parameters to the applet and deliver either specified or latest approved version. The new would be approval flag that is set after approval process in the discussion page is positively resolved. The flag should be altered either by administrators or by the new user group, "scripting specialists". Unlike other Wikipedia projects, the "Applet Commons" project space could allow to embed unapproved applets, allowing volunteers to test and approve them.

This relatively simple infrastructure would fit reasonably well into general Wikipedia style and layout. We likely cannot expect same number of applets as we have images, but even several tens of successful and heavily used applets in popular pages may have a serious impact.

Applet examples

Community Discussion

Do you have a thought about this proposal? A suggestion? Discuss this proposal by going to Proposal Talk:Java applet support.

See also

Notes and references

  1. ↑ The virtual hearth
  2. ↑ The d'Arbeloff Interactive Math Project
  3. ↑ Sun - Microsoft 2002 lawsuit
  4. ↑ A reference to "proof of concept malicious applet" leads to the page without the functional applet tag [1]
  5. ↑ Java Calendar serialization bug
  6. ↑ Google whitelist is quite restricted even for server oriented applications, as it does not cover any visualization (like BufferedImage or Graphics2D that would be useful even on a server side). Also, neither awt nor swing packages are included so any user interface is very problematic, if possible at all.
  7. ↑ http://java.sun.com/developer/technicalArticles/javase/newapplets/
  8. ↑ project OSCAR - educational Java applets under Creative Commons non commercial license

Want to work on this proposal?

  1. .. Sign your name here!
Retrieved from "https://strategy.wikimedia.org/w/index.php?title=Proposal:Java_applet_support&oldid=72516"