Why does gmail use eval?

Question

This question suggests that using eval is a bad practice and many other questions suggest that it is 'evil'.

An answer to the question suggests that using eval() could be helpful in one of these cases:

• Evaluate code received from a remote server. (Say you want to make a site that can be remotely controlled by sending JavaScript code to it?)
• Evaluate user-written code. Without eval, you can't program, for example, an online editor/REPL.
• Creating functions of arbitrary length dynamically (function.length is readonly, so the only way is using eval).
• Loading a script and returning it's value. If your script is, for example, a self-calling function, and you want to evaluate it and get it's result (eg: my_result = get_script_result("foo.js")), the only way of programming the function get_script_result is by using eval inside it.
• Re-creating a function in a different closure.

While looking at the Google Accounts page Source code I've found this:

(function(){eval('var f,g=this,k=void 0,p=Date.now||function(){return+new Date},q=function(a,b,c,d,e){c=a.split("."),d=g,c[0]in d||!d.execScript||d.execScript("var "+c[0]);for(;c.length&&(e=c.shift());) [a lot of code...] q("botguard.bg.prototype.invoke",K.prototype.ha);')})()</script>

I just can't get how is this helpful as it does not match any of the above cases. A comment there says:

 /* Anti-spam. Want to say hello? Contact (base64)Ym90Z3VhcmQtY29udGFjdEBnb29nbGUuY29tCg== */

I can't see how eval would be used as anti-spam . Can somebody tell me why is it used in this specific case?

Answer 1

Mike Hearn from plan99.net created anti-bot JS system, and you see parts of its anti-reverse engineering methods (random encryption). There is his letter with mention about it: https://moderncrypto.org/mail-archive/messaging/2014/000780.html

[messaging] Modern anti-spam and E2E crypto Mike Hearn Fri Sep 5 08:07:30 PDT 2014

There's a significant amount of magic involved in preventing bulk signups. As an example, I created a system that randomly generates encrypted JavaScripts that are designed to resist reverse engineering attempts. These programs know how to detect automated signup scripts and entirely wiped them out http://webcache.googleusercontent.com/search?q=cache:v6Iza2JzJCwJ:www.hackforums.net/archive/index.php/thread-2198360.html+&cd=8&hl=en&ct=clnk&gl=ch

You can google the info about system by its "Ym90Z3VhcmQtY29udGFjdEBnb29nbGUuY29tCg" base64 contact code or by "botguard-contact".

The post http://webcache.googleusercontent.com/search?q=cache:v6Iza2JzJCwJ:www.hackforums.net/archive/index.php/thread-2198360.html+&cd=8&hl=en&ct=clnk&gl=ch says:

The reason for this is being the new protection google introduced a couple of weeks/months ago. Let me show you a part of the new Botguard ( as google calls it ) Code:

/* Anti-spam. Want to say hello? Contact (base64) Ym90Z3VhcmQtY29udGFjdEBnb29nbGUuY29tCg== */

You will have to crack the algorithm of this javascript, to be able to create VALID tokens that allow you to register a new account. Google still allows you to create accounts without these tokens, and you wanna know why?

Its because they wait a couple of weeks, follow up the trace you and your stupid bot leave behind and than make a banwave.

ALL accounts you've sold, all accounts your customers created will be banned. Your software might be able to be able to still create accounts after the banwave, but whats the use?

So, botguard is the optional security measure. It can be correctly computed in browser, but not in some/most javascript engines, used by bots. You can bypass it by not entering correct code, but the created account will be marked as bot-account and it will be disabled soon (and linked accounts will be terminated too).

There are also several epic threads on the GitHub:

https://github.com/assaf/zombie/issues/336

Why does Zombie produce an improper output compared to the more basic contextify version in the following example?

Output varies depending on when document.bg is initialized to new botguard.bg(), because the botguard script mixes in a timestamp salt when encoding.

mikehearn commented on May 21, 2012 Hi there,

I work for Google on signup and login security.

Please do not attempt to automate the Google signup form. This is not a good idea and you are analyzing a system that is specifically designed to stop you.

There are no legitimate use cases for automating this form. If you do so and we detect you, the accounts you create with it will be immediately terminated. Accounts associated with the IPs you use (ie, your personal accounts) may also be terminated.

If you believe you have a legitimate use case, you may be best off exploring other alternatives.

In the https://github.com/jonatkins/ingress-intel-total-conversion/issues/864 thread there are some details:

a contains heavily obfuscated code that starts with this comment:

The code contains a lot of generic stuff: useragent sniffing (yay, Internet Explorer), object type detection, code for listening to mouse/kb events... So it's looks like some generic library. After that there's a lot of cryptic stuff that makes absolutely no sense. The interesting bit is that it calls something labeled as "botguard.bg.prototype.invoke". Evidently this must be google's botguard. From what I know, It collects data about user behavior on the page and its browser and avaluates it against other know data, this way it can detect anomaly usage and detect bots (kinda like clienBlob in ingress client). My guess would be it's detecting what kind of actions it takes the user to send requests (clicks, map events would be the most sensible)

So, google uses evil eval to fight evil users, which are unable to emulate the evaluated code fast/correctly enough.