Security/ReviewTemplate: Difference between revisions

no edit summary
(Split out "Privacy")
No edit summary
Line 23: Line 23:


= Topics To Discuss During The Review =
= Topics To Discuss During The Review =
Please be prepared to discuss the following topics as they relate to your feature / project.  To the degree you can answer some of these questions prior to the review it will speed up the process, but its not a requirement.
'''Please be prepared to discuss the topics listed at [[Security/ReviewTopics|ReviewTopics]] as they relate to your feature / project.  Optionally, you may copy the most relevant questions here and answer them before the review, which could speed up the review meeting.'''
 
== Security ==
Provide a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
 
* Is this feature a security feature? 
** If it is, what security issues is it intended to resolve?
* Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
* If any content or UI is displayed to the user, in what context is that content presented?  Does it have chrome privileges, for example?
* Does the feature include any new cryptographic functions or other security-critical code? 
** Has this code been reviewed and verified by someone familiar with the theory or principles behind it?
 
== Privacy ==
 
* Does the feature expose information that could strengthen fingerprinting?
* Does the feature cache or store data that could strengthen super-cookies?
* How are transitions in/out of Private Browsing mode handled?
* How is "Clear Recent History" handled?
 
== Exported APIs ==
Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc).
Explain the significant file formats, names, syntax, and semantics.
 
* Does it interoperate with a web service?
** How will it do so (by which protocols or techniques)?
* Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
* Does it change any existing interfaces?
 
== Module/Library interactions ==
* What other modules are used (REQUIRES in the makefile, interfaces)?
* What third-party libraries are used (.so, .dll, source code libraries/modules, etc)? 
** Have these third-party sources been reviewed for security?
** How will we keep up-to-date with upstream?
 
== Data ==
* What data is read or parsed by this feature?
** What types of validation are done on data inputs (e.g., type checking, string decoding/encoding, etc.)?
* What is the output of this feature?
** What types of normalization or sanitization are performed on data outputs (e.g., data aggregation, string encoding, path canonicalization, etc)?
* What storage formats are used?
** Who can access the data in storage (for example: is it encrypted with a master password, obfuscated, packed, protected by a filesystem ACL, etc)?
 
== 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 UI, about:config, or environment variables)?
* Are there build options for developers (e.g. #ifdefs, ac_add_options)
* 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 =
= Review comments =
''Notes made during the review will be recorded here.''
''Notes made during the review will be recorded here.''
Confirmed users
729

edits