Labs/Jetpack/Security Review

Overview

Describe the goals and objectives of the feature here.

Background links

• feature-tracking bug links
• specs or design docs

Security and Privacy

• Is this feature a security feature? If it is, what security issues is it intended to resolve?
• What potential security issues in your feature have you already considered and addressed?
• Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
• How are transitions in/out of Private Browsing mode handled?

Exported APIs

• Jetpack Unique ID
• Jetpack Core and Module Signing
• Registered Jetpack URLs
• Background Pages
• Content Frames

Module interactions

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

Data

• What data is read or parsed by this feature?
• What is the output of this feature?
• What storage formats are used?

Reliability

• What failure modes or decision points are presented to the user?
• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

Configuration

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