Breakpad/AboutCrashes/SecurityReview: Difference between revisions

Jump to navigation Jump to search
no edit summary
(New page: = Status = ;Feature tracking bug * {{bug|xxxxx}} * ''any other high-level tracking bugs can be listed here'' '' Has a design review been completed?'' '' When do you anticipate the feature...)
 
No edit summary
Line 1: Line 1:
= Status =
= Status =
;Feature tracking bug
;Feature tracking bug
* {{bug|xxxxx}}
* {{bug|411490}}
* ''any other high-level tracking bugs can be listed here''


'' Has a design review been completed?''
'' Has a design review been completed?''
The feature is simple in nature and the bulk of the code was reviewed by Mano
'' When do you anticipate the feature landing''
'' When do you anticipate the feature landing''
''Any relevant status comments for the feature can be placed here.''


The feature has already landed and is present in beta 3


= Overview =
= Overview =
''Describe the goals and objectives of the feature here.''
''Describe the goals and objectives of the feature here.''
The goal is to provide an easy way for testers and users to get at the list of submitted breakpad crash reports. Before this feature the only way to do this involved outside extensions or finding the correct directory on disk and listing the files there.


== Use Cases ==
== Use Cases ==
''Describe the primary use cases for the feature here.''
''Describe the primary use cases for the feature here.''
* A developer that crashes will want to view the crash report, they can visit about:crashes to see the reports in date order
* A user is experiencing crashes, a supporter can direct them to copy some id's from about:crashes to try to see if there is a bug filed on the crashes and potentially provide a workaround.


== Requirements ==
== Requirements ==
''List functional and non-functional requirements for the feature here, with links back to any relevant product PRD. These requirements should be prioritized.''
* Provide simple access to a list of submitted crash reports
* Sort the crash reports in date order to simplify finding the relevant report
* Provide a means to remove old crash reports


== Schedule ==
== Schedule ==
''Describe the rough schedule here, linking back to relevant product release milestones, as well as linking to any build/release notes.''
The feature was checked in about a week before the beta 3 freeze with a couple of follow up check ins to improve the UI in case of problems and enable the feature in other applications.


== UI Design Documentation ==
== UI Design Documentation ==
'' use cases and expected user knowledge (terminology, metaphors, etc) ''
The UI is simply based on the ftp file listing display already in the browser.
'' design mockups (of whatever fidelity is easiest) ''
'' links to relevant user data, bugs, reports, examples, etc ''


= Design Impact =
= Design Impact =


== Security and Privacy ==
== Security and Privacy ==
* What security issues do you address in your project?
''What security issues do you address in your project?''
* Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
None
* Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
 
''Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?''
 
If the preference pointing to the crash report server is missing then the feature will display an error to that effect. The same is true if the preference points to anything other than a http or https url.
 
''Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.''
 
The about:crashes page runs with chrome privileges. It is not marked as safe for untrusted content to link to. This should mean that websites cannot cause the user to see the about:crashes page the only way to visit it would be through UI actions.
 
In order to add the ID's to the page DOM methods are used. This means that even if an attacker were to somehow get a file into the crash reports directory they wouldn't be able to use it to insert a script element or similar into the page since the DOM methods should escape any of that correctly.
 
The server report url is checked to ensure it is either http or https, this means that an attacker could not inject a javascript link into the page by using a javascript: url as the preference.
 
== 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.)''
* Does it interoperate with a web service? How will it do so?
 
* 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?
 
* Does it change any existing interfaces?
''Does it interoperate with a web service? How will it do so?''
 
No
 
''Explain the significant file formats, names, syntax, and semantics.''
 
The feature reads a list of files from the crash reports directory and displays the id of the reports. The ID is made by taking the file name and dropping the leading "bp-" and trailing ".txt". The contents of the files are not read.
 
''Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?''
 
N/A
 
''Does it change any existing interfaces?''
 
No
 
== Web Compatibility ==
== Web Compatibility ==
* Does the feature had any impact on Web compatibility?
''Does the feature had any impact on Web compatibility?''
 
No
 
== Performance ==
== Performance ==
* How will the project contribute (positively or negatively) to "perceived performance"?
''How will the project contribute (positively or negatively) to "perceived performance"?''
* What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results?
 
* Will it require large files/databases (for example, browsing history)?
The feature makes life easier for users seeking support when they are already experiencing problems. Anything we can do to help these users out makes things easier for them.
 
''What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results?''
 
The feature is not on any startup or other critical path so the only real performance goal was for the reports list to display in a reasonable time.
 
''Will it require large files/databases (for example, browsing history)?''
 
No
 
== Reliability ==
== Reliability ==
* What failure modes or decision points are presented to the user?
''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?
 
If the report server preference is not set or invalid then this is displayed.
 
''Can its files be corrupted by failures? Does it clean up any locks/files after crashes?''
 
There are no files written to by the feature.
 
== l10n and a11y ==
== l10n and a11y ==
* are any strings being changed or added?
''are any strings being changed or added?''
* are all UI elements available through accessibility technologies?
 
Yes some strings were added, all in http://mxr.mozilla.org/seamonkey/source/toolkit/locales/en-US/crashreporter/
 
''are all UI elements available through accessibility technologies?''
 
This is untested however the UI is a standards compliant webpage and so should be accessible.


== Installation, Upgrade/Downgrade/Sidegrade, and platform requirements ==
== Installation, Upgrade/Downgrade/Sidegrade, and platform requirements ==
* Does it equally support all Tier-1 platforms?
''Does it equally support all Tier-1 platforms?''
* Does is have a hardware requirement (or increase minimum requirements)?
 
* Does it require changes to the installer?
Yes the feature was tested on all tier 1 platforms
* Does it impact updates?
 
*list the expected behavior of this feature/function when Firefox is upgraded to a newer minor release, downgraded by installation of an earlier revision, or re-installed (same version)
''Does is have a hardware requirement (or increase minimum requirements)?''
 
No
 
''Does it require changes to the installer?''
 
No
 
''Does it impact updates?''
 
No
 
''list the expected behavior of this feature/function when Firefox is upgraded to a newer minor release, downgraded by installation of an earlier revision, or re-installed (same version)''
 
No behaviour is needed on upgrade/downgrade since the feature holds no local state.


== 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?''
* Are there build options for developers? [#ifdefs, ac_add_options, etc.]
 
* What ranges for the tunable are appropriate? How are they determined?
There is one preference used to point to the crash reporter for the application. This is generally set as a default in the application preferences and should never be changes.
* What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
If a user chose to change this in about:config then they would end up with links in about:crashes that no longer point to the crash report server.
 
''Are there build options for developers? [#ifdefs, ac_add_options, etc.]''
 
No, the feature is enabled/disabled by the already present MOZ_CRASHREPORTER define
 
''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)?''
 
The crash report server preference may need changing if the crash reports server moves.
 
== Relationships to other projects - are there related projects in the community? ==
== 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?
''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?  
 
The feature is applicable to any Mozilla based project that uses the breakpad crash reporter. The feature can be enabled on any Mozilla based project by simply setting the crash report server preference and providing a means to load about:crashes in a browser.
 
''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?''
 
No


== Documentation ==
== Documentation ==
* Do built-in Help pages need modified?
''Do built-in Help pages need modified?''
* Documentation for developer.mozilla.org?
 
== Other ==
''any other implementation or design related documentation''


= Discussion & Implications =
The support page http://kb.mozillazine.org/Breakpad has already been updated explaining how to use the feature.


== Caveats / What We've Tried Before ==
''Documentation for developer.mozilla.org?''
''links to previous design documents, discussions, etc.''


== References ==
N/A
''links to external documents that could inform the design of the feature''
canmove, Confirmed users
1,570

edits

Navigation menu