# Technical Specifications

The information in this chapter may change quickly. For the most current information about the following subjects, be sure the check the Developer's Wiki at .

## Memory Management

One of the new features of &app; &appversion; is the garbage collector. The garbage collector manages complex &AS; variables, which are the only ones that are shared by references. In &app;, these are `as_object` class instances created by &AS; (i.e. not those created by playhead control: `placeobject`/`removeobject`).

Collected objects are those allocated due to &AS; explicit or implicit calls. Explicit calls are any user-defined statements that allocate new objects, such as arrays, Objects, or script-created movieclips. Implicit calls are the built-in functions that can be deleted by arbitrary user calls.

Any object that is a candidate for garbage collecting is stored in a list owned by the collector. This list is filled by an executing action context whenever a collectible object is allocated on the heap.

The garbage collector starts at the very end of an execution context, rather than using a threshold to trigger it. At this point, the virtual machine is in a "stable" state; any still-reachable object has its roots in one of the currently live character instances (stage characters).

The collector is a conservative collector. Any object on the collectibles list is marked as UNREACHABLE, an iterative scan starting from the roots marks any still-reachable object, and a final purge releases all still-UNREACHABLE resources.

## Security

Many Flash implementations contain potential security exploits that could compromise a viewer's system. With &app;, an end-user has the ability to see "what's going on" — what types of data the application accesses, where it is found, and how it is used. Many known Flash exploits are included in the &app; test suite that is used to check whether a release is ready for the public. The &app; developers are also in the process of a security review, developing a security layer that will protect an end-user, no matter what operating system they use.

One security feature found only in &app; is the blacklist/whitelist. Flash movies running in a browser can make outgoing network connections. This can be used, for example, to compromise a network device inside a company firewall via a Flash movie running on an employee's browser. &app; allows you to blacklist hosts that you know are insecure, or to whitelist hosts you know are secure, by editing a configuration file.

### Local Shared Objects

SWF movies support a form of persistent storage called Local Shared Objects. These are stored in the subdirectories of one's ~/.macromedia configuration. These files are commonly called "Flash Cookies", as they don't get deleted when the SWF movie that created or writes data to them stops executing. These files often store things like game scores, but can also store a unique identifier for tracking purposes.

Until recently, what was contained in these files wasn't widely known. There are several LSO file utilities floating around on the Web. &app; has its own soldumper program that lets one find and dump the contents of these files. We haven't discovered any nasty privacy issues yet, but as &app;'s SharedObject support is new, we may have just been lucky.

An LSO file uses a .solsuffix, and is stored in binary, big endian format. While one can look at the data in any binary editor or hex dumper, it's easier to use soldumper, which knows how to decode all the objects. The data is stored in AMF format, a simple data interchange format used in several other places in SWF.

The one SOL security setting &app; supports is the SOLReadOnly setting for your $HOME/.gnashrc file. This prevents &app; from ever writing to a .sol file, but can still read them. You can also set SOLSafeDir to a safe subdirectory, or even remove it later, although most people will want to set this path to the default one created by the other SWF player.

### Local Connections

SWF movies support a form of data interchange between running SWF movies called LocalConnection. This uses a shared memory segment to exchange AMF objects. While the specification claims an application has to register as a Listener, it turns out in reality this isn't required. Even YouTube violates this requirement. While one would think that data written to this memory segment would go away when the SWF movies are done playing, they are in fact persistent, and on some systems, the data even survives a reboot. Thank you Solaris...

The Gnash utility dumpshm can be used to do several things with these shared memory segments. This utility can find the shared memory segment left by using other SWF players to see what has been left. It can then dump the contents of the shared mempory segment either by decoding the AMF objects and printing the values, or by dumping the raw file to disk where you can analyze it with any other program you wish. If you run dumpshm repeatedly, you can even do a crude packet sniffing between two SWF movies playing.

The only current security related option for this is LocalConnection. This just disables all communication with other SWF movies. Work is in progress on adding a tracing ability to Gnash.