Sun Microsystems will make all the Java code they own available under the GPL:
http://www.sun.com/software/opensource/java/
This is a very major step. IMHO we should now make Java core part of our own strategy, as it's one of the best ways to deliver interactive content (high quality animations, learning tools, etc.). There are large numbers of free applets that we can potentially use, esp. in Wikipedia and Wikiversity.
My main question is: Are there security considerations with enabling the upload and embedding of Java Applets? According to
one of the capabilities of applets is to open a connection to the originating host. Could this be used, e.g., to create auto-vandalism applets and if so, can we somehow protect against it?
If security is a major issue, might it be feasible to maintain a whitelist of certificates (to allow applets from trusted authority to be uploaded directly), and to flag all other applets as "non-embeddable" until a sysop flips a switch, so they can be reviewed for security? We could add a big fat warning on the file description page.
I've heard that Kelly Martin is developing a MediaWiki made of Java. In any case, Erik, it sounds great -- interactive learning applets is something Wikiversity could use. I would like to thank Sun Microsystems for this contribution to open source.
On 11/13/06, Erik Moeller erik@wikimedia.org wrote:
Sun Microsystems will make all the Java code they own available under the GPL:
http://www.sun.com/software/opensource/java/
This is a very major step. IMHO we should now make Java core part of our own strategy, as it's one of the best ways to deliver interactive content (high quality animations, learning tools, etc.). There are large numbers of free applets that we can potentially use, esp. in Wikipedia and Wikiversity.
My main question is: Are there security considerations with enabling the upload and embedding of Java Applets? According to
one of the capabilities of applets is to open a connection to the originating host. Could this be used, e.g., to create auto-vandalism applets and if so, can we somehow protect against it?
If security is a major issue, might it be feasible to maintain a whitelist of certificates (to allow applets from trusted authority to be uploaded directly), and to flag all other applets as "non-embeddable" until a sysop flips a switch, so they can be reviewed for security? We could add a big fat warning on the file description page.
-- 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. _______________________________________________ foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
On 11/13/06, Erik Moeller erik@wikimedia.org wrote:
My main question is: Are there security considerations with enabling the upload and embedding of Java Applets? According to
one of the capabilities of applets is to open a connection to the originating host. Could this be used, e.g., to create auto-vandalism applets and if so, can we somehow protect against it?
I think letting people embed java applets would be really really bad. Besides the auto-vandalism applets, one could, for instance, write an applet which reads the person's cookies and posts them on his own talk page (or even better, emails them using [[Special:Emailuser]]). See [[cross-site scripting]] for more evil ideas.
If security is a major issue, might it be feasible to maintain a whitelist of certificates (to allow applets from trusted authority to be uploaded directly), and to flag all other applets as "non-embeddable" until a sysop flips a switch, so they can be reviewed for security? We could add a big fat warning on the file description page.
Might as well give those people with certificates root access on all the servers, and let all others upload applications which won't run on the servers until a sysop glances at it and flips a switch.
Sorry if you find my sarcasm rude, but using java in this way has some major security issues. In fact, just using java applets at all has enough security and privacy issues that it isn't enabled by default on Firefox, and I personally haven't turned it on in quite a while.
Sorry again if I've been overly blunt. It's a good general idea, but I think it's way before its time. Hopefully the opening of the source code to java will speed up the addressing of these types of issues.
Alternatively, though this would be a much harder route, maybe some subset of the java language could be made available, in much the same way wiki-syntax translates into a subset of html.
Anthony
Anthony wrote:
Sorry if you find my sarcasm rude, but using java in this way has some major security issues. In fact, just using java applets at all has enough security and privacy issues that it isn't enabled by default on Firefox, and I personally haven't turned it on in quite a while.
Sorry again if I've been overly blunt. It's a good general idea, but I think it's way before its time. Hopefully the opening of the source code to java will speed up the addressing of these types of issues.
Alternatively, though this would be a much harder route, maybe some subset of the java language could be made available, in much the same way wiki-syntax translates into a subset of html.
Anthony
Adding my own $0.02 here, this is indeed a bad idea for security issues alone. I completely agree here with Anthony's sentiments as Java has some very significant security holes that would open up some incredible liability and other problems if used on Wikimedia sites. The very thought of allowing anonymous users to post Java source code that would be served up through Wikimedia servers..... I can't think of a worse possible problem. It makes all of the issues with hacking the front page of Wikimedia projects seem very tame and mild by comparison.
If there were some very heavilily restricted Java-language sub-set that was allowed (a sanitized version used with MediaWiki) that might be something worth looking at, but that is a major developer task and not somthing to simply throw Java support into MediaWiki just because you can do it. Similar issues have come up with even having Javascript enabled with Wikimedia projects, for the very same reasons.
That said, it would be incredible if we could allow Wikimedia users the option of having some custom tools that go beyond what can be served up with HTML and server-side tool. The discussion to deal with this is going to be long and involved and will take a team of very dedicated individuals who really understand the software engineering issues before it will become a reality.
On 11/14/06, Robert Scott Horning robert_horning@netzero.net wrote:
Adding my own $0.02 here, this is indeed a bad idea for security issues alone. I completely agree here with Anthony's sentiments as Java has some very significant security holes that would open up some incredible liability and other problems if used on Wikimedia sites. The very thought of allowing anonymous users to post Java source code that would be served up through Wikimedia servers..... I can't think of a worse possible problem. It makes all of the issues with hacking the front page of Wikimedia projects seem very tame and mild by comparison.
We're talking about applets, wich have a specific sandbox security model. Let's not discuss on the basis of FUD, please.
On 11/14/06, Erik Moeller erik@wikimedia.org wrote:
On 11/14/06, Robert Scott Horning robert_horning@netzero.net wrote:
Adding my own $0.02 here, this is indeed a bad idea for security issues alone. I completely agree here with Anthony's sentiments as Java has some very significant security holes that would open up some incredible liability and other problems if used on Wikimedia sites. The very thought of allowing anonymous users to post Java source code that would be served up through Wikimedia servers..... I can't think of a worse possible problem. It makes all of the issues with hacking the front page of Wikimedia projects seem very tame and mild by comparison.
We're talking about applets, wich have a specific sandbox security model. Let's not discuss on the basis of FUD, please.
I know a pretty good deal about java's basic sandbox security model. I'm pretty rusty, haven't written anything in java in a couple years, but the basic concept of the security model probably hasn't changed that much.
There are two issues here. The first is that the sandbox security model is invariably broken from time to time. The second is that, in default browser implementation, the security model relies entirely on the fact that applets which come from a server were written by an administrator of that server.
That said, I probably wasn't open-minded enough about this. Maybe there's a way to solve problem #2 (and problem #1 will get better over time). Hosting the applets on a completely separate webserver? Probably not good enough, but it might be something to look into. Providing a static wrapper applet which lowers its security privileges and then embeds the untrusted class? More likely to succeed, but harder to implement.
Just turning on the ability to upload applets would be a really really bad idea. But something a little less than that could possibly work.
Anthony
On 11/14/06, Erik Moeller erik@wikimedia.org wrote:
Sun Microsystems will make all the Java code they own available under the GPL:
and on wikitech-l Erik wrote:
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.
Check this out - I'm an English Wikiversity bureaucrat, and I haven't a clue about how any of this works or could/should be managed! In my opinion, in order to most productively conduct this conversation, we need to think of the people on the projects this will impact - by asking things like the following:
*Is an "evil" java resource going to be easily spotted by a project sysop/bureaucrat? (How do you spot an "evil" or potentially evil resource?) *How would java resources be added to a project? The same as - or similar to - a file? Or simply through adding code into a page? (and consequently) *How much patrolling will this require?
I'd of course be incredibly excited to have engaging learning materials added to Wikiversity, as well as applications for all our projects. I'm just trying here to imagine how we would deal with this "in the trenches", so to speak.
Please pardon my war-like language here - must be a hangover from the [[w:Armistice]] weekend :-)
Cormac
Alternatively, we can make the process much more bureaucratic. It'll suck, but Java is a harsh mistress. What I was thinking was that code could be submitted, then it'd have to be audited by a developer (or anyone approved by the Foundation to evaluate Java), make sure it's appropriate, then add to the site thusly.
Yes, I know, bureaucratic, but we can't afford to have our sites screwed up because of a single vandal. (At least text vandalism is revertable.)
On 11/14/06, Cormac Lawler cormaggio@gmail.com wrote:
On 11/14/06, Erik Moeller erik@wikimedia.org wrote:
Sun Microsystems will make all the Java code they own available under
the GPL:
and on wikitech-l Erik wrote:
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.
Check this out - I'm an English Wikiversity bureaucrat, and I haven't a clue about how any of this works or could/should be managed! In my opinion, in order to most productively conduct this conversation, we need to think of the people on the projects this will impact - by asking things like the following:
*Is an "evil" java resource going to be easily spotted by a project sysop/bureaucrat? (How do you spot an "evil" or potentially evil resource?) *How would java resources be added to a project? The same as - or similar to - a file? Or simply through adding code into a page? (and consequently) *How much patrolling will this require?
I'd of course be incredibly excited to have engaging learning materials added to Wikiversity, as well as applications for all our projects. I'm just trying here to imagine how we would deal with this "in the trenches", so to speak.
Please pardon my war-like language here - must be a hangover from the [[w:Armistice]] weekend :-)
Cormac _______________________________________________ foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
Cormac Lawler wrote:
On 11/14/06, Erik Moeller erik@wikimedia.org wrote:
Sun Microsystems will make all the Java code they own available under the GPL:
and on wikitech-l Erik wrote:
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.
Check this out - I'm an English Wikiversity bureaucrat, and I haven't a clue about how any of this works or could/should be managed! In my opinion, in order to most productively conduct this conversation, we need to think of the people on the projects this will impact - by asking things like the following:
*Is an "evil" java resource going to be easily spotted by a project sysop/bureaucrat? (How do you spot an "evil" or potentially evil resource?) *How would java resources be added to a project? The same as - or similar to - a file? Or simply through adding code into a page? (and consequently) *How much patrolling will this require?
Perhaps we need a good session at Wikimania on techniques for technophobic administrators. It could even coincide with hacking days, but our techies may not like being drawn away from hacking days to teach the clueless.
I'd of course be incredibly excited to have engaging learning materials added to Wikiversity, as well as applications for all our projects. I'm just trying here to imagine how we would deal with this "in the trenches", so to speak.
A course about Java might be nice.
Please pardon my war-like language here - must be a hangover from the [[w:Armistice]] weekend :-)
Not at all. Under appropriate circumstances a little loyalty to King George V is good for what ales you. :-)
Ec
On 11/16/06, Ray Saintonge saintonge@telus.net wrote:
Perhaps we need a good session at Wikimania on techniques for technophobic administrators. It could even coincide with hacking days, but our techies may not like being drawn away from hacking days to teach the clueless.
Most admins do not go to Wikimania.
wikimedia-l@lists.wikimedia.org