How can dates and random numbers be used for evil in Javascript?

The ADsafe subset of Javascript开发者_Go百科 prohibits the use of certain things that are not safe for guest code to have access to, such as eval, window, this, with, and so on.

For some reason, it also prohibits the Date object and Math.random:

Date and Math.random

Access to these sources of non-determinism is restricted in order to make it easier to determine how widgets behave.

I still don't understand how using Date or Math.random will accomodate malevolence.

Can you come up with a code example where using either Date or Math.random is necessary to do something evil?

---

According to a slideshow posted by Douglas Crockford:

ADsafe does not allow access to Date or random

This is to allow human evaluation of ad content with confidence that behavior will not change in the future. This is for ad quality and contractual compliance, not for security.

---

I don't think anyone would consider them evil per se. However the crucial part of that quote is:

easier to determine how widgets behave

Obviously Math.random() introduces indeterminism so you can never be sure how the code would behave upon each run.

What is not obvious is that Date brings similar indeterminism. If your code is somehow dependant on current date it will (again obviously) work differently in some conditions.

I guess it's not surprising that these two methods/objects are non-functional, in other words each run may return different result irrespective to arguments.

In general there are some ways to fight with this indeterminism. Storing initial random seed to reproduce the exact same series of random numbers (not possible in JavaScript) and supplying client code with sort of TimeProvider abstraction rather than letting it create Dates everywhere.

---

According to their website, they don't include Date or Math.random to make it easier to determine how third party code will behave. The problem here is Math.random (using Date you can make a psuedo-random number as well)- they want to know how third party code will behave and can't know that if the third party code is allowed access to random numbers.

By themselves, Date and Math.random shouldn't pose security threats.

---

At a minimum they allow you to write loops that can not be shown to be non-terminating, but may run for a very long time.

The quote you exhibit seem to suggest that a certain amount of static analysis is being done (or is at least contemplated), and these features make it much harder. Mind you these restrictions aren't enough to actually prevent you from writing difficult-to-statically-analyze code.

---

I agree with you that it's a strange limitation.

The justification that using date or random would make difficult to predict widget behavior is of course nonsense. For example implement a simple counter, compute the sha-1 of the current number and then act depending on the result. I don't think it's any easier to predict what the widget will do in the long term compared to a random or date... short of running it forever.

The history of math has shown that trying to classify functions on how they compute their value is a path that leads nowhere... the only sensible solution is classifying them depending on the actual results (black box approach).