Firefox3.1/SVG CSS Security Review

Overview

Allow SVG rendering features to apply to non-SVG content (e.g., HTML)

Background links

• http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg_ef.html
• http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_serve.html
• http://weblogs.mozillazine.org/roc/archives/2008/07/the_latest_feat.html
• http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html
• https://bugzilla.mozilla.org/show_bug.cgi?id=450340

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 configuration or prefs

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

SVG masks, filters and clipping allow an element to be made invisible while still receiving input --- but there's nothing new about that. The ability to paint one element's contents in multiple places is new, but I can't see how it could be abused in any novel way.

Exported APIs

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

Existing CSS properties 'mask', 'clip-path' and 'filter' are made applicable to HTML content. CSS 'background-image:url()' is extended to allow references to elements in the current document.

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

No

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

None

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

Yes

• Does it change any existing interfaces?

It extends existing interfaces, making certain situations what would have been ignored errors do something useful.

Module interactions

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

SVG, CSS and general frame-level rendering

Data

• What data is read or parsed by this feature

None

• What is the output of this feature

Rendered graphics

• What storage formats are used

None

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 locksfiles after crashes?

No, No

Configuration

• Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

No

• Are there build options for developers? [#ifdefs, ac_add_options, etc.]

No

• What ranges for the tunable are appropriate? How are they determined?

None

• What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

None

Relationships to other projects

Are there related projects in the community?

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

Everything this depends on is on trunk already.

• 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?

This only touches areas where I am already a peer.

Review comments

• not planning the background image feature for 3.1 (though it didn't raise any additional concerns)
• not supporting external svg docs in url() references for now. When we do it needs a separate security review.