Firefox3.1/SVG CSS Security Review: Difference between revisions

(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] * [...)
 
 
(3 intermediate revisions by one other user not shown)
Line 3: Line 3:


;Background links
;Background links
* [http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg_ef.html]
* 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/svg_paint_serve.html
* [http://weblogs.mozillazine.org/roc/archives/2008/07/the_latest_feat.html]
* http://weblogs.mozillazine.org/roc/archives/2008/07/the_latest_feat.html
* [http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html]
* http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html
* [https://bugzilla.mozilla.org/show_bug.cgi?id=450340]
* https://bugzilla.mozilla.org/show_bug.cgi?id=450340


== Security and Privacy ==
== Security and Privacy ==
* What security issues do you address in your project?
* What security issues do you address in your project?
/None/
''None''
* Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
* Is system or subsystem security compromised in any way if your project's configuration files '' prefs are corrupt or missing?
/No configuration or prefs/
''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.
* 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./
''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 ==
== Exported APIs ==
* Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
* 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./
''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?
* Does it interoperate with a web service? How will it do so?
/No/
''No''
* Explain the significant file formats, names, syntax, and semantics.
* Explain the significant file formats, names, syntax, and semantics.
/None/
''None''
* Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
* Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
/Yes/
''Yes''
* Does it change any existing interfaces?
* Does it change any existing interfaces?
/It extends existing interfaces, making certain situations what would have been ignored errors do something useful./
''It extends existing interfaces, making certain situations what would have been ignored errors do something useful.''


== Module interactions ==
== Module interactions ==
* What other modules are used (REQUIRES in the makefile, interfaces)
* What other modules are used (REQUIRES in the makefile, interfaces)
/SVG, CSS and general frame-level rendering/
''SVG, CSS and general frame-level rendering''


== Data ==
== Data ==
* What data is read or parsed by this feature
* What data is read or parsed by this feature
/None/
''None''
* What is the output of this feature
* What is the output of this feature
/Rendered graphics/
''Rendered graphics''
* What storage formats are used
* What storage formats are used
/None/
''None''


== Reliability ==
== Reliability ==
* What failure modes or decision points are presented to the user?
* What failure modes or decision points are presented to the user?
/None/
''None''
* Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
* Can its files be corrupted by failures? Does it clean up any locks''files after crashes?
/No, No/
''No, No''


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


== Relationships to other projects ==
== Relationships to other projects ==
Are there related projects in the community?
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?
* 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./
''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?
* 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./
''This only touches areas where I am already a peer.''


== Review comments ==
== 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.
canmove, Confirmed users
640

edits