Firefox3.1/SVG CSS Security Review

From MozillaWiki
< Firefox3.1
Revision as of 03:50, 27 August 2008 by Roc (talk | contribs) (New page: == 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] * [...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Overview

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?

/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 locks/files 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