Jump to content

Caches involving data and executables


fizzymagic

Recommended Posts

Moderator's note: This thread was spun off from the main topic on the New Cache Listing Guidelines.

 

According to this section of 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.

 

No new caches of any kind may be published, since the act of viewing a cache page involves the downloading of data.

 

Is that really the intent?

 

If not (and I suspect that it is not the intent, but just very poor wording), then could that section please be changed to make sense?

Edited by Keystone
Link to comment

According to this section of 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.

 

No new caches of any kind may be published, since the act of viewing a cache page involves the downloading of data.

 

Is that really the intent?

 

If not (and I suspect that it is not the intent, but just very poor wording), then could that section please be changed to make sense?

 

Note red text above. I think this is pretty clear. Obviously the cache page downloads to your computer, but if you read the wording, it seems like "Caches that REQUIRE the downloading" is very clear. The cache page downloading is obviously not a requirement by the owner of the cache.

Link to comment
I think this is pretty clear. Obviously the cache page downloads to your computer, but if you read the wording, it seems like "Caches that REQUIRE the downloading" is very clear.

If that's what they meant, then that's what they should have written. For example:

 

"caches that require the downloading, installing or running of data and/or executables in addition to that visible on the cache page may not be published."

 

See? That wasn't so hard. Of course, it is still a bad guideline even as amended, but at least it makes in intent clear.

Link to comment
I think this is pretty clear. Obviously the cache page downloads to your computer, but if you read the wording, it seems like "Caches that REQUIRE the downloading" is very clear.

If that's what they meant, then that's what they should have written. For example:

 

"caches that require the downloading, installing or running of data and/or executables in addition to that visible on the cache page may not be published."

 

See? That wasn't so hard. Of course, it is still a bad guideline even as amended, but at least it makes in intent clear.

 

I'll probably hate myself for asking but, why is it a bad guideline?

Link to comment
I think this is pretty clear. Obviously the cache page downloads to your computer, but if you read the wording, it seems like "Caches that REQUIRE the downloading" is very clear.

If that's what they meant, then that's what they should have written. For example:

 

"caches that require the downloading, installing or running of data and/or executables in addition to that visible on the cache page may not be published."

 

See? That wasn't so hard. Of course, it is still a bad guideline even as amended, but at least it makes in intent clear.

Depending on the intent, it might have to go further. For instance, a Flash game may be visible on the page, but it may violate this guideline.

Link to comment
I think this is pretty clear. Obviously the cache page downloads to your computer, but if you read the wording, it seems like "Caches that REQUIRE the downloading" is very clear.

If that's what they meant, then that's what they should have written. For example:

 

"caches that require the downloading, installing or running of data and/or executables in addition to that visible on the cache page may not be published."

 

See? That wasn't so hard. Of course, it is still a bad guideline even as amended, but at least it makes in intent clear.

Depending on the intent, it might have to go further. For instance, a Flash game may be visible on the page, but it may violate this guideline.

It effectively kills all the podcaches.

Link to comment
I think this is pretty clear. Obviously the cache page downloads to your computer, but if you read the wording, it seems like "Caches that REQUIRE the downloading" is very clear.

If that's what they meant, then that's what they should have written. For example:

 

"caches that require the downloading, installing or running of data and/or executables in addition to that visible on the cache page may not be published."

 

See? That wasn't so hard. Of course, it is still a bad guideline even as amended, but at least it makes in intent clear.

Depending on the intent, it might have to go further. For instance, a Flash game may be visible on the page, but it may violate this guideline.

It effectively kills all the podcaches.

It also makes any cache that requires submitting a photo illegal.

Link to comment

I think the emphasis here is on executable files, which wouldn't include MP3 files or images that your browser can already handle.

If that were true, the guideline would not specifically mention data.

 

Under this guideline, as written, and assuming that the cache pages themselves are excluded form the prohibition:

  • Podcaches are illegal.
  • Video caches are illegal.
  • Puzzles using sound are illegal.
  • Puzzles involving processing of images (such as palette-based puzzles) are illegal.

Since several caches of each of the above types have been approved in my area since last May, I can only conclude that the guideline is not being enforced as written.

 

But that doesn't keep it from being a very, very bad guideline.

Link to comment

I think the emphasis here is on executable files, which wouldn't include MP3 files or images that your browser can already handle.

I agree completely, although the way it is worded, since you're required to run an executable (iTunes, WMP, WinAmp, etc.) to play the MP3, the cache technically shouldn't be allowed.

 

It's just tricky to differentiate between that and running some .exe file or Java app that you need to solve a puzzle.

Link to comment

As with any of the guidelines, the final decision ultimately lies at the discretion of the reviewer. If the guidelines are extremely loose, people will take advantage of the loopholes. The wording that is used is strong enough that it will give the reviewers plenty of wiggle room in the decision to deny a cache that falls under this new guideline.

 

Makes perfect sense to me... Especially considering that people will test and push the boundaries on this one. If the wording wasn't strong, what would be the point?

Link to comment

Isn't a good thing that we use human volunteer reviewers instead of some AI program then? Like most of the guidelines, the operative word is "may" as in "may not be published"

 

In the case of this guideline, it's a heads-up to cache placers that putting offsite material into their cache could be cause for a reviewer refusing to publish it. If it makes someone ask their local reviewer before spending hours and hours on a clever program for their puzzle, it's done its job!

Edited by theUMP
Link to comment

It seems like the real intent of this new guideline is to stop people from downloading anything that could harm their computer (i.e. virus from .exe files). So there would be no threat from files with commonly used audio formats. Everyone already has applications on their computers that can play standard audio fomats. So I'm not sure if audio files really got trapped in the new net or not.

Edited by TrailGators
Link to comment

It seems like the real intent of this new guideline is to stop people from downloading anything that could harm their computer (i.e. virus from .exe files). So there would be no threat from files with commonly audio formats. Everyone already has applications on their computers that can play standard audio fomats. So I'm not sure if audio files really got trapped in the new net or not.

 

This is the most reasonable post so far. I know I wouldn't feel comfortable downloading a .exe file onto my computer to run some program from an "unknown publisher" just to find a cache. That's a cache that would instantly go on my ignore list.

Link to comment

So will caches that require the installation and use of http://www.Wherigo.com/ be allowed - seeing as it is a Groundspeak project!

 

I'd personally have changed this guideline to read

If your cache potentially involves downloading and installation of software, it is your responsibility to ensure caches are protected from Viruses and Malware.

 

For example, I have a puzzle which involves a reversed audiofile.

If the cacher doesn't already have a suitable tool on their computer to reverse the sound, I've recommended a freeware program which I've personally tested.

Link to comment
If your cache potentially involves downloading and installation of software, it is your responsibility to ensure caches are protected from Viruses and Malware.

 

That leaves the doors wide open for basically anything. I think (I may be wrong) that the intent was to eliminate the problem of downloading viruses/malware/adware. If Groundspeak publishes a cache that has a link to a website that contains a virus, they are leaving themselves WIDE open for a lawsuit. All it takes is a disgruntled cacher to cause some major problems. The content of the website is the responsibility of Groundspeak, not the owner of the cache.

Link to comment

Personally, I don't see any ambiguity at all.

 

Simply put:-

 

If, once the cache page has loaded, the seeker is REQUIRED to download additional files (be they data files or executables) then that, and only that, violates the guidelines.

 

Simple really - or is there a dark and sinister agenda that I've totally missed?

Link to comment

I think the problem people have is that hey can't write a program that you can download and run, that presents a unique puzzle that you have to solve to do the cache.

 

I personally wouldn't want to do a cache like this, but (other than the arguably straw man arguement that it could destroy your computer with a nasty virus) I see no reason it should be banned the way it is.

Link to comment
I think the problem people have is that hey can't write a program that you can download and run, that presents a unique puzzle that you have to solve to do the cache.

 

I.m.o. if the program runs on a server and the only thing you have to do is feeding it with your input, then it will be OK to list the cache.

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

I have two main thoughts on this:

 

First is wording. You've got to nail the wording of any guideline otherwise folks will try to take advantage of it. "May not" has been argued plenty of times as either "will not" and "might not." Two different things even though the definition of "may" includes them. The need to nail down the intent should be obvious from some of the discussions on the forums about what is and isn't allowed as per the guidelines. This is also evidenced by each clarification of said guidelines, a la ALRs.

 

Second, I'm a bit bumfuzzled over the intent of the passage. If the intent is in the interest of file security what does having the requirement of downloading potentially harmful programs have anything to do with it. It's not okay if the virus is required to be downloaded, but okay if it's just an option?

 

Personally, I think the strongest reason for avoiding use of required programs is compatibility. Mac software doesn't run so good on Windoze.

 

I liken the use of a downloaded program to a potentially dangerous adventure. It is the responsibility of the seeker to assume all risk, know what he is doing, and protect himself. If a cache placer is found to have intentionally infected another user, whether requiring the download or leaving it as simply as an option, then he should be banned.

Link to comment

I sure feel like a visonary for posting this thread Puzzle Creativity, in light of the new rules

 

My solution to the new guideline is to create really obtuse, but solvable cryptography type puzzles written on the cache page. Then, I'll post an "optional puzzle," to derive the coordinates. This optional puzzle will use the programs that I already use like Steganography software.

 

Nobody will be forced to download anything, because they have a free choice to solve the "non-threatening" puzzle.

 

Of course this gives me added incentive to continue with my "test monkey" puzzles, where cachers have to figure out some sort of contraption, in order to retrieve a cache's logbook, while in the field.

Edited by Kit Fox
Link to comment

Isn't a good thing that we use human volunteer reviewers instead of some AI program then? Like most of the guidelines, the operative word is "may" as in "may not be published"

 

In the case of this guideline, it's a heads-up to cache placers that putting offsite material into their cache could be cause for a reviewer refusing to publish it. If it makes someone ask their local reviewer before spending hours and hours on a clever program for their puzzle, it's done its job!

I think the point of the guidelines is to deflect as many of those questions from the reviewers as possible. I imagine the reviewers would rather not have to answer an email for every person who wants to hide a cache that uses mp3, Flash game, picture puzzle, etc. As it is, I think the guideline is going to create more prescreening emails to reviewers. So why not add a couple of examples of what's okay and what's not, then answer questions from there?

Edited by Dinoprophet
Link to comment

many puzzle caches have been published that require you to "crack" the password of a PDF or even just use info in a PDF to solve the puzzle. Those are data and downloaded... although not executables. As Fizzymagic has pointed out, if their intent was file security, why make a point to specifically refer to data... when the that word has a very broad meaning well beyond executable.

Link to comment

It effectively kills all the podcaches.

 

In it's current form where you download something at home, yes. But you can still make an audio guided cache: Create a multicache with a box at the first stage which contains CDs with your audio material. Cachers would have to bring a portable CD player and use one of the CDs.

 

Alternatively you can buy a few cheap MP3 players, load the audio on them and place them together with some spare batteries into a first stage box near the parking place. Cachers put them back after their hunt.

 

My guess is, that caches like these already exist and are great fun too! :rolleyes:

Link to comment

As Fizzymagic has pointed out, if their intent was file security, why make a point to specifically refer to data... when the that word has a very broad meaning well beyond executable.

 

Because of you left out the other words, people would find a way to take advantage. This gives the reviewers flexibility. The guidelines would be 200 pages worth of worthless garbage if it was required to spell out every possible combination of scenarios that are allowed and not allowed. Some people don't have any common sense and everything has to be spelled out. If everyone used common sense then there wouldn't be any problems with the approval process.

Link to comment

It effectively kills all the podcaches.

 

In it's current form where you download something at home, yes. But you can still make an audio guided cache: Create a multicache with a box at the first stage which contains CDs with your audio material. Cachers would have to bring a portable CD player and use one of the CDs.

 

Alternatively you can buy a few cheap MP3 players, load the audio on them and place them together with some spare batteries into a first stage box near the parking place. Cachers put them back after their hunt.

 

My guess is, that caches like these already exist and are great fun too! :rolleyes:

My guess is that the guidelines apply to these caches as well. If I found media in a cache that I had to install or run on my computer it shouldn't matter that I didn't download it. In fact, many people have indicated they would be more wary about installing something from a disk left in a cache than clicking a link from a cache page to an unknown website.

 

I think the guideline is a bit paternalistic. What ever happen to the disclaimer?

Cache seekers assume all risks involved in seeking a cache.

Shouldn't that apply. Puzzle caches may involve downloading, installing or running of data and/or executables. While most cachers are responsible and will not ask you to download, install, or run anything that contains virus or malware, be aware that this is a risk that exists in seeking these caches. If you have questions email the cache owner or the reviewer. You can also post questions on the Groundspeak forums. While using the forums to ask for help in solving a particular puzzle is considered poor etiquette, asking for help with downloads in order to get an idea if you want to have that software on your computer is allowed. However, Groundspeak does not take responsibility for advice given on the forums.

Link to comment

I'm sure that it's worded as "data" for a great many reasons. A properly coded malicious data file (MP3, JPEG, etc.) could exploit a buffer overrun in code that lacks sufficient bounds checks. Any program you run to open the data file could leave your system vulnerable (and that applies to all OSes, not just Windows).

Link to comment

many puzzle caches have been published that require you to "crack" the password of a PDF or even just use info in a PDF to solve the puzzle. Those are data and downloaded... although not executables. As Fizzymagic has pointed out, if their intent was file security, why make a point to specifically refer to data... when the that word has a very broad meaning well beyond executable.

 

The problem is that the boundaries between executables and data has become blurred. MS Word files can contain a macro virus and there is even the possibility of a virus in a JPEG (http://www.internetnews.com/dev-news/article.php/1365871). Add to this MS Window's predilection for running files, coupled with the ability to disguise executables as data.

 

Yes a computer literate user won't fall for any of these but not all Geocachers are computer savey.

Link to comment

The new guidelines seem to include shareware (such as Audacity, among many others) from known and well-established developers. I can understand disallowing executables from Billy-In-His-Basement "developers," but established and popular software titles should be allowed.

 

If I intentionally download and run a program that happens to damage my data, it's nobody's fault but my own. Besides, that's what my automatic backup routine is there to defend against.

Link to comment
I can understand disallowing executables from Billy-In-His-Basement "developers," but established and popular software titles should be allowed.

Such as Microsoft Office? Exploits using macros for those programs are some of the worst things to hit the net.

 

That sort of rule sounds like too much analysis required on the part of reviewers. And I can see it opening up an argument as to what constitutes an 'established and popular' software title that's been proven 'safe' (whatever that means).

Link to comment

As Fizzymagic has pointed out, if their intent was file security, why make a point to specifically refer to data... when the that word has a very broad meaning well beyond executable.

 

Because of you left out the other words, people would find a way to take advantage. This gives the reviewers flexibility. The guidelines would be 200 pages worth of worthless garbage if it was required to spell out every possible combination of scenarios that are allowed and not allowed. Some people don't have any common sense and everything has to be spelled out. If everyone used common sense then there wouldn't be any problems with the approval process.

If everyone used common sense we wouldn't need an approval process.

 

You don't have to spell out everything, just give some examples of the most common. I'm pretty sure if you say whether audio, pictures, videos, and Flash/Java applets are allowed, almost all questions concerning this guideline would be answered. It's not clear to me at this point whether those are allowed. If I had to guess I'd say "no" to all, except possibly Flash, but clearly others in this thread come to a different conclusion. Any file type can be made malicious.

Link to comment

Such as Microsoft Office? Exploits using macros for those programs are some of the worst things to hit the net.

 

I think the last one of these to appear was around 2002. Since Office 2000 turned off autorun macro execution by default, nobody has bothered. They were an issue for Office 95 and 97, unless of course you used my little bit of code to patch them (see http://target0.be/madchat/vxdevl/vxmags/crptlt54/Crypt54.txt, article about "ATLAS-T" halfway down).

 

And nobody has caught a genuine virus (as in, self-reproducing code which attaches itself to other programs) by downloading an EXE file since about 1991 (back in the days of Fidonet). :rolleyes:

 

These days, you are far, far more likely to "catch" some form of malware by surfing Web pages - not even "dubious" ones, either - which have been hacked to contain little bits of Javascript which install a Trojan on your PC - probably based around rootkit (enjoy cleaning that up). Of course, this malware's main job is to take over your PC for the purposes of sending out spam, so it will do almost no damage to your PC. That's why there are so many "zombie" PCs out there - they appear to be running quite normally.

 

In any case, there would be no need to go to all the trouble of putting a virus in there. Viruses are hard to write, and the user's brain has already done the "replicating" part of job by doing the download. All that's needed is the payload. If you're running Windows, OS X, or Linux with administrator privileges, no anti-malware program in the world can protect you from a 4Kbyte executable that repartitions your hard disk. So from a paranoia point of view, anything could be a "virus" (in the popular sense of "nasty program that did stuff to your computer").

 

That said, some other good reasons not to allow executables include:

- Elementary politeness towards people who don't have your (or any) version of Windows (or Linux, etc; although, on a separate issue, I suspect that a cache with a Linux-only executable would probably fail the "agenda" guideline, not intrinsically but because of what the cache owner would want to add to the description. I say this as a fan of Linux, although not always all of its advocates).

- Not having to answer lame questions from people who can't run the executable for whatever reason.

- Not having to defend lawsuits from people whose hard disk crashed an hour after running your executable and want you to prove that it wasn't your program that caused it (we have users who blame the PC techs when the printer jams the day after we change their PC).

 

Jaz666's suggestion to say that it's your job to protect yourself from malware and viruses presumes that such a solution exists. The Sony rootkit saga (4 millions machines running what was essentially an undetectable stealth virus platform for months, which no anti-virus program on the market found) showed that to be an unrealistic assumption.

 

The guideline seems to want to err on the side of caution. Maybe that will have another benefit: to get people to make caches that get us all out from behind our computers. :lol:

Edited by sTeamTraen
Link to comment

I think the emphasis here is on executable files, which wouldn't include MP3 files or images that your browser can already handle.

If that were true, the guideline would not specifically mention data.

 

Under this guideline, as written, and assuming that the cache pages themselves are excluded form the prohibition:

  • Podcaches are illegal.
  • Video caches are illegal.
  • Puzzles using sound are illegal.
  • Puzzles involving processing of images (such as palette-based puzzles) are illegal.

Since several caches of each of the above types have been approved in my area since last May, I can only conclude that the guideline is not being enforced as written.

 

But that doesn't keep it from being a very, very bad guideline.

"Data" is mentioned because there may be cases where it's applicable. For example, owner provides source code (data) that you are required to compile into an executable, and then run in order to get coordinates.

Link to comment

I think the emphasis here is on executable files, which wouldn't include MP3 files or images that your browser can already handle.

I agree completely, although the way it is worded, since you're required to run an executable (iTunes, WMP, WinAmp, etc.) to play the MP3, the cache technically shouldn't be allowed.

No, because you're not downloading/running an executable provided by the cache owner. You're free to use whatever MP3 player you wish.

Link to comment
"Data" is mentioned because there may be cases where it's applicable. For example, owner provides source code (data) that you are required to compile into an executable, and then run in order to get coordinates.

It may be that the intent of the guideline is what you say. But my concern is with what the guideline actually says. And it quite clearly states that puzzles that require data to be downloaded are now illegal.

 

The history of such guidelines is unambiguous: they are interpreted more and more literally as time goes by. This one will be no exception. If the intent of the guideline is not to prohibit all puzzles that require downloading data (such as MP3 files), then the wording of the guideline must be changed.

 

The intent of the guideline has never been clarified by TPTB. So all we have to go on is the exact wording. And the wording, as it stands, is both extreme and somewhat ambiguous.

Link to comment

Makes clear sense to me too. I curious why this so important to some? It is clear, unless one just wants to argue the analytical details, and avoid the escape clauses like "may".

The intent can kill a cache I'm working on. I don't write programs. I can handle Word, or figure out how to create a password protected PDF so that people who find a clue can unlock details needed to further figure out the cache.

 

Since most people have access to the internet in some way or they could not cache and since anyone who is on the net knows about 'protetion' or has already assumed the risk I don't think the rule does anything more than eliminate a catagory of cache. If that's the case they should just eliminate it. "No caches that involve data that isn't on the cache page" Then actually allow data and files to be posted to the cache page.

Link to comment

Personally, I don't see any ambiguity at all.

 

Simply put:-

 

If, once the cache page has loaded, the seeker is REQUIRED to download additional files (be they data files or executables) then that, and only that, violates the guidelines.

 

Simple really - or is there a dark and sinister agenda that I've totally missed?

What about data that is loaded along with the cache page? If I want to start an mp3 when the cache page is loaded, should I go ahead with the work, or should I bother my reviewer about it first?

 

As to a dark and sinister agenda, that's the reason this guideline was added in the first place. But it's not the reason people are asking for clarification. People want to know if certain cache ideas are still doable.

Link to comment

Basically it is left to the (mis)interpretation of a reviewer ?

 

To a degree, yes... as are many other reviewer decisions.

 

It seems that some people have the following paradigm:

 

Groundspeak = The Government
Reviewers = Law Enforcement
appeals@geocaching.com = The Supreme Court

 

This is not an entirely correct analogy. :rolleyes:

Edited by sTeamTraen
Link to comment
"Data" is mentioned because there may be cases where it's applicable. For example, owner provides source code (data) that you are required to compile into an executable, and then run in order to get coordinates.

It may be that the intent of the guideline is what you say. But my concern is with what the guideline actually says. And it quite clearly states that puzzles that require data to be downloaded are now illegal.

 

No, it doesn't. It says they may not be published. It doesn't say they won't be published. If the "data" clause was left out, someone would use that as a loophole, like my compile-the-code example. Likewise, if they tried to list every type of file that is or is not excluded, the paragraph would be as long as the entire guidelines are now, and someone would still use it to find a loophole.

 

You have to look at the intent of the guideline, which is clearly spelled out, "In the interest of file security...". MP3 files probably don't fall into that category, while others may. If you're looking for a specific, exhaustive list of exactly what files are and are not allowed, well, I have a feeling you're in for a long wait.

Link to comment

Use of the word "data" does seem to be a bit "all encompassing" in this context. While I agree that the intent of the guideline remains clear - I too worry that it will be very unequally applied. Though I consider many file types to be perfectly safe and I take reasonable percautions to protect my PC, a reviewer may simply disallow a file because it "is" data.

Link to comment
It says they may not be published. It doesn't say they won't be published. If the "data" clause was left out, someone would use that as a loophole, like my compile-the-code example.

You may be correct about the intent; however, when I tell the kids "you may not go to the movie," I don't mean that it is possible that they won't go; I mean that they will not be allowed to go. That is the meaning of the phrase "may not" in this context.

 

If the intent was as you say, then the correct word would be "might." But just replacing "may" with "might" doesn't fix things, as it introduces new ambiguities. How about this:

 

"In the interest of file security, approval for caches that require the downloading, installing or running of data and/or executables may be denied."

That phrasing makes the intent clear and avoids the implication that all such caches will be denied.

 

And if that is indeed the intent of the new guideline, then I will withdraw my objection to it once the wording is changed on the website.

Link to comment

And it quite clearly states that puzzles that require data to be downloaded are now illegal.

 

No it doesn't Fizzy. It says it MAY be. The reviewers reserve the right to deny a cache for the stated reasons. If you require the download of some program, it will probably hold up the approval process and you will probably need to justify why you think its appropriate. The guideline is not as black and white as you are making it out to be.

Link to comment

And it quite clearly states that puzzles that require data to be downloaded are now illegal.

No it doesn't Fizzy. It says it MAY be. ...The guideline is not as black and white as you are making it out to be.

No, it says "may not be." Try as I might, I could not find the phrase "may be" in the guideline.

 

While your interpretation may be what was intended, it is not what the guideline says. The meaning of the phrase "may not" is quite well-established, thank you. It does not mean the same thing as "might not." It means a prohibition.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...