Firefox 3.6/System Metrics Security Review

From MozillaWiki
Jump to: navigation, search

Overview

System metrics allow CSS styles to vary depending on certain characteristics of the operating system. They allow style sheets (primarily chrome ones, but use is allowed in content) to specify rules that adapt better to the user's operating environment.

Background links
  • feature-tracking bug links
    • history of nsILookAndFeel.h
    • bug 384612: Get rid of script in scrollbar XBL binding
      • introduced :-moz-system-metric()
      • added scrollbar-start-backward metric
      • added scrollbar-start-forward metric
      • added scrollbar-end-backward metric
      • added scrollbar-end-forward metric
      • added scrollbar-thumb-proportional metric
    • bug 415810: Respect the user's settings of icons in menus
      • added images-in-menus metric
    • bug 426660: Allow Firefox themes to change based on the OS theme
      • added windows-default-theme metric
    • bug 418454
      • added windows-compositor metric
    • bug 431666
      • added windows-classic metric
    • bug 448767
      • added mac-graphite-theme metric
    • bug 503042
      • added touch-enabled metric
    • bug 520341
      • added maemo-classic metric
    • bug 509671
      • added images-in-buttons metric
    • bug 522149: Add CSS media queries for all features supported in :-moz-system-metric()
      • introduced media queries versions of system metrics
  • specs or design docs

Security and Privacy

  • Is this feature a security feature? If it is, what security issues is it intended to resolve?
    • no
  • What potential security issues in your feature have you already considered and addressed?
    • none
  • Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
    • N/A
  • Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
    • primary risk is making available information about a user's system that either (1) the user wouldn't want known or (2) could be used to improve the quality of certain spoofing attacks
  • How are transitions in/out of Private Browsing mode handled?
    • not handled

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)?
    • a widget interface (nsILookAndFeel) is used to get the appropriate values from platform-specific code

Data

  • What data is read or parsed by this feature?
  • What is the output of this feature?
  • 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?
    • N/A

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?
    • N/A
  • 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?
  • 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?

Review comments