How can I use dates and random numbers for evil in Javascript?

Question

ADsafe is a subset of Javascript that prohibits the use of certain things that are unsafe for accessing guest code, such as eval , window , this , with , etc.

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

Date and Math.random

Access to these non-determinism sources is limited to simplify the definition of widget behavior.

I still don’t understand how using Date or Math.random will contribute to hostility.

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

Answer 1

According to the slideshow published by Douglas Crockford:

ADsafe does not allow access to Date or random

This allows you to confidently evaluate the content of advertising in future behavior will not change. This applies to ad quality and contract compliance, not to ensure safety.

Answer 2

I don’t think anyone considers them evil as such. However, the key part of this quote:

it’s easier to determine how widgets behave

Obviously, Math.random() introduces indeterminism, so you can never be sure how the code will behave on every run.

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

I think it is not surprising that these two methods / objects are non-functional, in other words, each run can return different results regardless of the arguments.

In general, there are several ways to combat this indeterminism. Storing the initial random seed to reproduce the exact same series of random numbers (not possible in JavaScript) and providing the client code as if it were an abstraction of TimeProvider instead of letting it create a Date everywhere.

Answer 3

According to their website, they do not include Date or Math.random to simplify the definition of third-party code behavior. The problem here is in Math.random (using Date you can also make a pseudo-random number) - they want to know how the third-party code will behave and cannot know that if the third-party code is allowed access to random numbers.

By themselves, Date and Math.random should not pose a security risk.

Answer 4

At a minimum, they allow you to write loops that cannot be shown as non-ending, but can work for a very long time.

The quote you show seems to suggest that a certain amount of static analysis is being performed (or, at least, assumed), and these functions make it a lot more complicated. Keep in mind that these restrictions are not enough to actually prevent you from writing code that is difficult to analyze.

Answer 5

I agree with you that this is a strange limitation.

Justifying that using a date or chance would make it difficult to predict the behavior of the widget is, of course, pointless. For example, run a simple counter, calculate sha-1 of the current number, and then act on the result. I don’t think it would be easier to predict what the widget will do in the long run compared to random or dated ... until it works forever.

The history of mathematics has shown that an attempt to classify functions on how they calculate their value is a path that leads nowhere ... the only reasonable solution classifies them according to actual results (black box).