Firefox3.1/SVG CSS Security Review
Allow SVG rendering features to apply to non-SVG content (e.g., HTML)
- Background links
Security and Privacy
- What security issues do you address in your project?
- 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.
- 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?
- 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?
It extends existing interfaces, making certain situations what would have been ignored errors do something useful.
- What other modules are used (REQUIRES in the makefile, interfaces)
SVG, CSS and general frame-level rendering
- What data is read or parsed by this feature
- What is the output of this feature
- What storage formats are used
- What failure modes or decision points are presented to the user?
- Can its files be corrupted by failures? Does it clean up any locksfiles after crashes?
- 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?
- 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.
- 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.