Firefox3.1/SMIL Security Review

Overview

Describe the goals and objectives of the feature here.

Background links

• Bug 216462: Main SMIL bug
• SVG 1.1 Spec's Animation Section
• SMIL Animation Spec
• Brian Birtles' writeup

Security and Privacy

• What security issues do you address in your project?

None.

• Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?

No. (Only one pref, to enable/disable SMIL support.)

• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

Exported APIs

• Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)

• Does it interoperate with a web service? How will it do so?

No.

• Explain the significant file formats, names, syntax, and semantics.

• Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?

• Does it change any existing interfaces?

Module interactions

• What other modules are used (REQUIRES in the makefile, interfaces)

gfx, layout, content

Data

• What data is read or parsed by this feature

The values of the SVG <animate>, <set>, and <animateTransform> elements' attributes. These consist of semicolon-separated lists of values, time values, ...

The SMIL patch adds the class "nsSMILParserUtils," which takes care of its parsing needs.

• What is the output of this feature

Animations (animated attributes) in SVG documents that would otherwise be static.

• What storage formats are used

Reliability

• What failure modes or decision points are presented to the user?

None.

• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

N/A -- no files or locks used.

Configuration

• Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
• Are there build options for developers? [#ifdefs, ac_add_options, etc.]
• What ranges for the tunable are appropriate? How are they determined?
• What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

Relationships to other projects

• Are there related projects in the community?

Opera and WebKit both support subsets of SMIL. FakeSMIL is a Greasemonkey script that uses Javascript to add partial SMIL support to Firefox.

• If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?

This proposal is parallel to their work, adding built-in SMIL support to Firefox.

• Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?

No & N/A -- I'm not updating, copying or changing functional areas maintained by other groups.