ADsafe security model and limits

ADsafe’s boundary depends on restricted code, a careful runtime and a cooperating host page. A small callback or a DIV wrapper is not an isolation mechanism on its own.

Trace authority through objects

The original project limited what guest code could reach. Instead of receiving the page’s unrestricted DOM, a widget received operations on a specific subtree. A capability in this discussion is an object or function reference that permits some action. Returning a raw node would reveal relationships such as its owner document, so the documented interface uses wrappers.

This gives a practical review question: after each API call, what can the result reach? A method that appears harmless can undermine the model if its return value exposes a powerful object. The original widget documentation explicitly warns about capability leakage and treats the services provided by the host as part of the boundary.

What the host must trust

• The historical verifier must reject code outside the intended subset, including prohibited globals and language features.
• The runtime must preserve the intended restrictions when it implements queries, updates, property access and events.
• Approved libraries and any added host services must avoid leaking unrestricted references.
• The surrounding page must maintain unique IDs and avoid prototype extensions that breach containment.
• Error handling must be safe when invoked indirectly by guest code. The original homepage specifically calls out window.onerror.

The original runtime notice advises hosts to use copies they control. That is a supply-chain assumption: if an external server replaces a trusted script, language checks on a widget do not make the replacement trustworthy. The runtime’s public-domain notice also disclaims warranties.

What the layers actually enforce

Static checking works before execution. It addresses access paths that would be difficult to police by wrapping individual methods, including dynamic code evaluation and recovery of broader globals. The runtime provides a useful restricted interface during execution. Its query parser checks widget ID prefixes, its bunch objects mediate selected operations and its property helpers reject dangerous names.

Those mechanisms have different jobs. The go function does not parse a callback and prove it safe. An unrestricted callback can still refer to globals it already has. Conversely, permitting only a language subset does not repair an API that returns an unsafe object. The API reference shows the actual checks visible in this bundled runtime.

Limits that matter

The DIV identifies a subtree; it does not create a browser execution context. Styling and host extensions need their own policy. The archived widget page even demonstrates a host interceptor that rejects absolute positioning, illustrating that containment and protection against misleading presentation are separate concerns.

No CPU or memory quota mechanism is established by these documents or by the startup wrapper. Do not infer availability protection from restricted DOM access. A library that adds networking also changes the authority available to a widget; restricting raw DOM access is not evidence that every host extension is harmless.

Historical documentation and a saved runtime can disagree. For example, the archived event removal signature differs from the local implementation. That is one reason these pages explain a design rather than certify a deployable security boundary. They do not establish that this historical code withstands present-day browser behavior or attack techniques.

How to study it responsibly

Read the original rules, inspect the implementation and follow the returned objects. Keep demonstrations separate from an untrusted-code execution service. This site’s Roman, Bats and Sudoku exercises are newly written educational demonstrations; their ordinary page scripts are not validated ADsafe guests.

The enduring lesson is the relationship between language restrictions and granted authority. The sandboxing explainer compares that relationship with Caja, SES compartments and browser iframe boundaries. Those mechanisms have their own trust assumptions and are not interchangeable drop-in versions of ADsafe.