Disable client-side Scripting (like Greasemonkey) on a web site?

Question

I would like to know if there is a way to prevent the use of userscripts on my browser game site?

Many use Greasemonkey to have advantages over other players, and I would like a way to disable these scripts.

I found this old article, "How To Disable Greasemonkey On Your Web Site", but it's from 2005 and doesn't seem to work.

Answer 1

Combating a smart scripter is tough. They have the upper hand since their script can touch the page before your server does, and can block or replace just about anything. See this answer to a very similar question.

Your smartest, and most cost-effective countermeasure is to sanction the users who are "gaming" the game. Attack the burglar, not the lock-pick.

If you insist in a tech war with your users, nothing you do will block everybody, but you can make them work for it.
Here are some things you can do make life harder for scripters:

1. Frequently change the structure of the page, especially element ID's and CSS class names. If you can, periodically insert or remove elements, so that the key <div> is not always the 3rd one in the second <table>, for example.

   Every time you make a change, monitor your logs for users who get a sudden decrease in performance or usage -- for however many hours or days it takes them to adapt their scripts.

2. Likewise, frequently change your javascript filenames, and change the names of any variables or functions that the scripter may use.

3. Write your click and keyboard event-handlers to only work for trusted events, for browsers that support it.

4. You can put key text, including countdown timers, in images with unpredictable names. Making it hard for the script to detect key events. Needing to do OCR ramps up the skill-level required by a Greasemonkey scriptwriter, considerably. (At least for now.)

5. If you move the key game action into Flash, it becomes an order of magnitude harder to script for. They may even have to reverse engineer your flash and replace it with one that has scriptable hooks. Switching to Flash will annoy and drive off users (like me), though.

See that answer for more but, again, the best and most cost-effective approach is to sanction the offending user(s). Be sure that your Terms of Service specifically forbids what they are doing, though.

Answer 2

As addition to Brock Adams' own answer, here's couple methods for finding a possible scripter.

• Timed function that checks DOM tree and search for added elements that are not your code's creation, or look for missing elements.
  • Primarily finds scripter who alters UI, yet haven't read/understood the game's js-source.
  • Client-side.
  • "Missing element"-search may get false positives from people who use something like AdBlock Plus. Not really false positive, if aim is to rank them out, too.
• Inspect cookie content and look for hints of user added content.
  • If scripter has to transfer information from page/session to another, and has/knows no other method, he may attempt to use cookies for this.
• Inspect query/hash in URL for content not added by your code.
  • It's possible to try to transfer information to other pages by altering links.
  • Hash-content (# in URL) is accessible only client-side.
• Inspect session/localStorage.
  • Client-side.
• Disable access thru anonymizing services, like anonym.to.
  • Circumventable, but makes life harder for people using unwanted online-tools.
• Allow access to game-page only if referer is correct, otherwise redirect to login-page.
  • Another method to limit access to game-pages from outside sources.
  • If you want to be a pain, kill active session when redirecting.

NOTE: All client-side functions can be circumvented by scripter who understands the code.
NOTE: Usage of these requires some wisdom and good planning. If doing things wrong, then with client-side stuff you risk of kicking users' browsers on knees or DDoSing your own server. Or you may end up banning least half of the userbase after an update on your own code, if you use too much automation.

Answer 3

Here's one of my scripts. It could definitely still use some work, but the framework is there (though you may need to wrap everything in a big function to make variables private)

var secureElements,secureTags,secureTagLoop,secureLoop,var secureReporter = secureAnalyzationFunction = 0;
function analyze(secureAnalyzation){
 if(secureAnalyzation.indexOf("function ")!=-1){
  secureAnalyzationFunction = secureAnalyzation.substring(secureAnalyzation.indexOf("function ")+9,secureAnalyzation.indexOf("()"));
  secureAnalyzationFunction = secureAnalyzationFunction+"=undefined;";
  eval(secureAnalyzationFunction);
 }
}
function secure(){
 var secureTags = ["script","link","meta","canvas"];
 for(secureTagLoop=0;secureTagLoop!=secureTags.length;secureTagLoop++){
  secureElements = document.getElementsByTagName(secureTags[secureTagLoop]);
  for(secureLoop=0;secureLoop!=secureElements.length;secureLoop++){
   if(secureElements[secureLoop].outerHTML.indexOf("verified")==-1){
    analyze(secureElements[secureLoop].outerHTML);
    secureElements[secureLoop].parentElement.removeChild(secureElements[secureLoop]);
    secureLoop--;
    secureReporter++;
    console.log("Deleted "+secureReporter+" foreign elements.")
   }
  }
 }
}
window.onload = function() {
 secure();
 setInterval(secure,1500);
};