Using Applets for puzzle caches

[+ControlFreaks]

I've just had a new puzzle cache submission declined . The reason it was not published was because users must access a Java Applet to solve a puzzle. Specifically, the reason given is

 

"We have no way of ensuring that the java applet is safe."

 

I'd like some feedback on what others think about this.

 

To my knowledge Applets are a commonly used and safe way of improving web content - somewhat of an industry standard and are designed specifically so that the local machine is protected. They are about as much danger as any other form of web content. Applets exist across the internet and most people have probably browsed past many in their travels.

 

I've had a similar type of cache running for a couple of years (apparently no problem publishing it then) - Jigsaw which has had a lot of positive feedback. In fact, two other versions of the same cache have been set up in other parts of the world - see the links on the Jigsaw page.

 

So how about it - should Groundspeak be happily publishing these types of caches to add variety - or should I just get over it and go and stick another eclipse tin behind a road sign??

 

If you would like to see what I was trying to do go to

 

Breakout - GCA

 

No - this doesn't open the applet - that is one step further.

Edited November 17, 2010 by ControlFreaks

[Skippermark]

From the guidelines, "In the interest of file security, caches that require the downloading, installing or running of data and/or executables may not be published."

 

Also, "First and foremost please be advised there is no precedent for placing caches."

 

So, in an interest to protect users from unsafe websites & programs, the former guideline change was added. The Jigsaw cache was possibly published before the change.

 

Also, because something was allowed in the past doesn't mean that it will be allowed now or in the future.

Edited November 17, 2010 by Skippermark

[+Harry Dolphin]

I think that it is good that your cache submittal has been denied. From what little I've read, Java Applets are notorious for having the ability to cause major problems. This is why Geocaching frowns on them.

Go on a nice hike, and hide your eclipse tin on a mountain top.

[+skraeling]

Interesting. We have a few puzzle caches out here that use java applets. There is one where you have to put together the jigsaw puzzle. Once completed, you can then read what the coords are. Seems inconsistent that some get approved and others declined.

[+John in Valley Forge]

I think that it is good that your cache submittal has been denied. From what little I've read, Java Applets are notorious for having the ability to cause major problems. This is why Geocaching frowns on them.

Go on a nice hike, and hide your eclipse tin on a mountain top.

 

Ouch!

 

 

I've seen a lot of caches that incorporate javascript. However, they are generally hosted on another page and linked through some sort of graphic on the cache page (click on the picture and it opens a new window). That might make a difference.

[+dfx]

I've seen a lot of caches that incorporate javascript.

javascript is totally unrelated to java. except for the name, obviously.

Edited November 17, 2010 by dfx

[+ControlFreaks]

I think that it is good that your cache submittal has been denied. From what little I've read, Java Applets are notorious for having the ability to cause major problems. This is why Geocaching frowns on them.

Go on a nice hike, and hide your eclipse tin on a mountain top.

 

"From what little I've read..." says it all!

 

And I would never dream of using an eclipse tin for a good bush cache.

[+ControlFreaks]

From the guidelines, "In the interest of file security, caches that require the downloading, installing or running of data and/or executables may not be published."

 

Also, "First and foremost please be advised there is no precedent for placing caches."

 

So, in an interest to protect users from unsafe websites & programs, the former guideline change was added. The Jigsaw cache was possibly published before the change.

 

Also, because something was allowed in the past doesn't mean that it will be allowed now or in the future.

 

Thanks - I know the Groundspeak policy. I agree entirely with the concept that downloading people's applications which have access to the local hard drive should not be allowed. This is, I think, the spirit of the rule. What I question is broadly applying this to other accepted technologies such as Applets, Flash or even pdf's (yes, I've heard of issues there). These are all accepted in the internet community. If it bothers Groundspeak then require some sort of warning - but you don't get this surfing the web at the moment. Taking your rule to extremes, html is data that must be downloaded - oops, better block that too!

[+Lil Devil]

You shouldn't hide a cache in a bush, either, but that's a whole 'nuther thread

[+GeePa]

From the guidelines, "In the interest of file security, caches that require the downloading, installing or running of data and/or executables may not be published."

 

I never have understood when this rule is applied. I can't count how many caches I have seen where you have to solve a puzzle to open a password protected Word, Excel, or PDF document containing the coordinates. All these require running/installing an executable.

[+fizzymagic]

There have been several new caches published (and therefore approved) in our area requiring Flash in the past month. And Flash is a MUCH bigger security problem than Java applets.

 

In addition to being grammatically ambiguous (and therefore poorly written), the guideline is also inconsistently applied. This problem has been around for a couple of years now; my conclusion is that TPTB actually want the ambiguity and inconsistency.

 

My opinion:

• If it uses something that is nearly universally available (e.g. Flash, Java applet, MP3 or video player, etc.) then it should be approved.
  
• If it requires installation of general-purpose software available from multiple sources for multiple platforms (e.g. image or sound editors, waypoint projection, etc.) then it should likewise be approved.
  
• If it requires a specific piece of software (e.g. steganography applications) it should NOT be approved.
  

[+Xaa]

I guess this seems to be a very arbitrary guideline. I've even seen caches here where you have to download specific software created by the CO from his website to solve a puzzle. Doesn't seem like there was a problem getting it published. And don't get me started on all the steganography caches, which normally result in "install every stego software you can find on- and offline and see which one works".

 

It's a very reasonable guideline, but I don't think all reviewers can be assumed to have the knowledge to judge on this. Java is probably one of the safer 'applications' here.

[Motorcycle_Mama]

Also, please remember that cache owners can (and often do) change the contents of their cache pages AFTER the cache is published.

 

It is quite possible that some or all of the caches where users now must "download" something were altered after they were published.

[+NYPaddleCacher]

I've seen a lot of caches that incorporate javascript.

javascript is totally unrelated to java. except for the name, obviously.

 

Specifically, a java applet can't run unless you've downloaded a java runtime environment (which is probably more ubiquitous than a flash plugin) then the code for the actual applet is downloaded and executed when the browser encounters the tag which specifies the applet. Javascript is embedded in the html markup of the requested page itself and is executed by the browser.

 

Technically, every web page consists of data which is downloaded (initiated by requesting a url) and executed in the browser and some pretty nefarious things can be done without the use of a java applet or javascript. I was recently bit by a malicious script embedded in an image. I was using a site that I've used many times in the past that allows to do online ordering/delivery of food from local restaurants. Somehow somebody injected an image on the site that contained malicious code and it hosed my system pretty good until I found a fix and malware detection application to check for future occurrences. There isn't really inherently malicious about the use of java applets but they have the potential to do harm. Personally, I think that they should be allowed and let the user decide if they want to run the applet or not. If I recognize the cache owners name I might run it. A cache owner that wants to maintain an account on the geocaching site isn't going to intentionally include malicious code in their cache listing. All it would take would be for one geocacher to report it to Groundspeak and I would suspect they'd take action. Unfortunately, because java applets can be downloaded from other sources as binary class files, a CO could include something like a jigsaw puzzle creator (I had one awhile back like that but compiled it from source code myself) that had malicious code in it and a CO might not even know it.

[+sbell111]

As I see it, there are two issues here. First, some people who want to use this code are upset that the guidelines forbid it. Second, some believe that the guidelines regarding this issue are being applied inconsistently. I suspect that the only change that will result from this drama is that TPTB will give the reviewers some guidance that will stop some of these caches from being listed in error.

[+Brooklyn51]

I've just had a new puzzle cache submission declined . The reason it was not published was because users must access a Java Applet to solve a puzzle.

 

Keep in mind that you can appeal your reviewers decision to Groundspeak. The reviewer is only following the rules they have to work with too. State your case and let Groundspeak arbitrate the final decision.

 

We also have several puzzles that use applets in our area. One thing that seems to help is posting a disclaimer to the effect that Groundspeak is not liable in any way for the content and that the user is accessing the applet at their own risk. Also, we've seen in a few cases that the CO provided an alternative way to solve the puzzle that may not be as much fun but didn't use Java or applets.

[+ControlFreaks]

I've just had a new puzzle cache submission declined . The reason it was not published was because users must access a Java Applet to solve a puzzle.

 

Keep in mind that you can appeal your reviewers decision to Groundspeak. The reviewer is only following the rules they have to work with too. State your case and let Groundspeak arbitrate the final decision.

 

We also have several puzzles that use applets in our area. One thing that seems to help is posting a disclaimer to the effect that Groundspeak is not liable in any way for the content and that the user is accessing the applet at their own risk. Also, we've seen in a few cases that the CO provided an alternative way to solve the puzzle that may not be as much fun but didn't use Java or applets.

 

The reviewer consulted with Groundspeak and that's when the decision was made.

 

And I write all my own code.

 

I'd be interested in seeing other caching applets so if you know of any then please post the GC code. Haven't found any other way to search for them.

[+sbell111]

I've just had a new puzzle cache submission declined . The reason it was not published was because users must access a Java Applet to solve a puzzle.

 

Keep in mind that you can appeal your reviewers decision to Groundspeak. The reviewer is only following the rules they have to work with too. State your case and let Groundspeak arbitrate the final decision.

 

We also have several puzzles that use applets in our area. One thing that seems to help is posting a disclaimer to the effect that Groundspeak is not liable in any way for the content and that the user is accessing the applet at their own risk. Also, we've seen in a few cases that the CO provided an alternative way to solve the puzzle that may not be as much fun but didn't use Java or applets.

 

The reviewer consulted with Groundspeak and that's when the decision was made.

 

And I write all my own code.

 

I'd be interested in seeing other caching applets so if you know of any then please post the GC code. Haven't found any other way to search for them.

Before you get all excited, you should know that exposing other similar caches may have the result of getting those caches archived, but it won't get your cache listed.

[+ControlFreaks]

Archive existing?

 

My understanding is that Groundspeak won't archive existing caches - they didn't archive the one I have - Jigsaw.

 

And I'm not attempting to use others to get mine published - I've accepted the ruling and archived the cache (although I have published it on Geocaching Australia which has a much more relaxed attitude to different cache types).

 

I'm genuinely interested in what other people do with applets - I write them for my work purposes as well (education).

Edited November 17, 2010 by ControlFreaks

[+fizzymagic]

As I see it, there are two issues here. First, some people who want to use this code are upset that the guidelines forbid it. Second, some believe that the guidelines regarding this issue are being applied inconsistently. I suspect that the only change that will result from this drama is that TPTB will give the reviewers some guidance that will stop some of these caches from being listed in error.

I think a third (and very important) issue is that the guideline, as written, is ambiguous.

The guideline, to quote, is:

In the interest of file security, caches that require the downloading, installing or running of data and/or executables may not be published.

The ambiguity comes from the use of the phrase "may not." Some people feel that it means "might not," so that the reviewers have the discretion to not publish any cache that they have a question about. Others believe it means "will not," so that the reviewers are explicitly instructed to not publish any such cache.

 

Given that clarification of this guideline would involve changing exactly one word, and that this issue has been repeatedly raised in the past, I believe that the ambiguity is intentional.

[+niraD]

One technique that I've heard puzzle cache owners using is to provide two solutions. The intended solution is the Flash/Java program, but to avoid requiring the use of the Flash/Java program, another (perhaps more difficult) puzzle is provided which produces the same final location.

[+sbell111]

As I see it, there are two issues here. First, some people who want to use this code are upset that the guidelines forbid it. Second, some believe that the guidelines regarding this issue are being applied inconsistently. I suspect that the only change that will result from this drama is that TPTB will give the reviewers some guidance that will stop some of these caches from being listed in error.

I think a third (and very important) issue is that the guideline, as written, is ambiguous.

The guideline, to quote, is:

In the interest of file security, caches that require the downloading, installing or running of data and/or executables may not be published.

The ambiguity comes from the use of the phrase "may not." Some people feel that it means "might not," so that the reviewers have the discretion to not publish any cache that they have a question about. Others believe it means "will not," so that the reviewers are explicitly instructed to not publish any such cache.

 

Given that clarification of this guideline would involve changing exactly one word, and that this issue has been repeatedly raised in the past, I believe that the ambiguity is intentional.

Given that 'will not' is a subset of 'might not', I don't see it as a big deal. In fact, given other's assertions that recent ones have been published, it's pretty clear that 'might not' is correct.