SecurityEngineering/Roadmap: Difference between revisions
mNo edit summary |
|||
| Line 62: | Line 62: | ||
{|class=wikitable | {|class=wikitable | ||
|- | |- | ||
! Item | ! Item | ||
! Status | ! Status | ||
| Line 68: | Line 67: | ||
! Owner | ! Owner | ||
|- | |- | ||
| [https://wiki.mozilla.org/NPAPI:Pepper2 Plugin sandboxing]<br> | | [https://wiki.mozilla.org/NPAPI:Pepper2 Plugin sandboxing]<br> | ||
| not started | | not started | ||
| Line 74: | Line 72: | ||
| ? | | ? | ||
|- | |- | ||
| [https://groups.google.com/group/mozilla.dev.security/browse_thread/thread/f8afac1eef7cb4cd/b570280627c3dca8 Effective certificate revocation and management]<br> | | [https://groups.google.com/group/mozilla.dev.security/browse_thread/thread/f8afac1eef7cb4cd/b570280627c3dca8 Effective certificate revocation and management]<br> | ||
| not started | | not started | ||
| Line 80: | Line 77: | ||
| ? | | ? | ||
|- | |- | ||
| [https://wiki.mozilla.org/Opt-in_activation_for_plugins Plugin runtime mitigations such as whitelist and/or click to ]<br> | | [https://wiki.mozilla.org/Opt-in_activation_for_plugins Plugin runtime mitigations such as whitelist and/or click to ]<br> | ||
| not started | | not started | ||
| Line 86: | Line 82: | ||
| Justin Dolske | | Justin Dolske | ||
|- | |- | ||
| javascript: and data: handling in URL bar and chrome | | javascript: and data: handling in URL bar and chrome | ||
| <br> | | <br> | ||
| Line 92: | Line 87: | ||
| <br> | | <br> | ||
|- | |- | ||
| DLL whitelisting by name or signature<br> | | DLL whitelisting by name or signature<br> | ||
| not started<br> | | not started<br> | ||
| Line 98: | Line 92: | ||
| ?<br> | | ?<br> | ||
|- | |- | ||
| Track "Application Reputation"<br> | | Track "Application Reputation"<br> | ||
| <br> | | <br> | ||
| Line 104: | Line 97: | ||
| <br> | | <br> | ||
|- | |- | ||
| Prune dead and dying code<br> | | Prune dead and dying code<br> | ||
| <br> | | <br> | ||
| Line 110: | Line 102: | ||
| <br> | | <br> | ||
|- | |- | ||
| Malloc should be infallible<br> | | Malloc should be infallible<br> | ||
| <br> | | <br> | ||
| Line 116: | Line 107: | ||
| <br> | | <br> | ||
|- | |- | ||
| TLS 1.2 support<br> | | TLS 1.2 support<br> | ||
| <br> | | <br> | ||
| Line 122: | Line 112: | ||
| <br> | | <br> | ||
|- | |- | ||
| Eviltraps meta-bug (prevents users from leaving a page)<br> | | Eviltraps meta-bug (prevents users from leaving a page)<br> | ||
| <br> | | <br> | ||
| Line 128: | Line 117: | ||
| <br> | | <br> | ||
|- | |- | ||
| Notify user of malware in their crash signatures<br> | | Notify user of malware in their crash signatures<br> | ||
| <br> | | <br> | ||
| Line 134: | Line 122: | ||
| <br> | | <br> | ||
|- | |- | ||
| Expose HSTS and other security browser state to plugins (NPAPI)<br> | | Expose HSTS and other security browser state to plugins (NPAPI)<br> | ||
| <br> | | <br> | ||
| Line 140: | Line 127: | ||
| <br> | | <br> | ||
|- | |- | ||
| Ignore autocomplete="off" for password fields | | Ignore autocomplete="off" for password fields | ||
| <br> | | <br> | ||
| Line 146: | Line 132: | ||
| <br> | | <br> | ||
|- | |- | ||
| UX security experiment | | UX security experiment | ||
| not started | | not started | ||
| Line 152: | Line 137: | ||
| ? | | ? | ||
|- | |- | ||
| [https://bugzilla.mozilla.org/show_bug.cgi?id=663566 Content Security Policy revisions] | | [https://bugzilla.mozilla.org/show_bug.cgi?id=663566 Content Security Policy revisions] | ||
| In progress | | In progress | ||
| Line 158: | Line 142: | ||
| Brandon Sterne | | Brandon Sterne | ||
|- | |- | ||
| CSRF mitigations | | CSRF mitigations | ||
| <br> | | <br> | ||
| Line 164: | Line 147: | ||
| <br> | | <br> | ||
|- | |- | ||
| Clickjacking mitigations | | Clickjacking mitigations | ||
| | | | ||
| Line 170: | Line 152: | ||
| | | | ||
|- | |- | ||
| X-Content-Type-Options | | X-Content-Type-Options | ||
| | | | ||
| Line 176: | Line 157: | ||
| | | | ||
|- | |- | ||
| toStaticHTML | | toStaticHTML | ||
| | | | ||
Revision as of 03:38, 3 February 2012
![]() |
Product Security Feature Roadmap | |
| Owner: Lucas Adamski | Updated: 2012-02-3 | |
| Security at Mozilla can be thought of a set of principles that are reflected in the products we ship, but also in the impact Mozilla has on the entire web. As such our security roadmap should reflect the real security improvements we need to make to our products to reflect the evolving security landscape, but also the ambitious impact we'd like to have on all web users. | ||
Vision
Security at Mozilla can be thought of a set of principles that are reflected in the products we ship, but also in the impact Mozilla has on the entire web.
Themes and Goals
Web users are under constant attack from a wide variety of opponents, many of whom are merely opportunistic, but also by a minority of very clever and determined attackers. To protect users, we need to improve our current products to keep pace with these evolving threats, but we are ultimately limited in what we can do unilaterally within our products. We must also drive innovative solutions that require the participation of other vital players in the web ecosystem, including standards bodies, internet technology vendors, web developers, web admins and web frameworks.
As such, security at Mozilla has two complementary but distinct focuses.
- Protect our users directly from an ever-increasing volume & sophistication of online attacks, by improving the products and services we deliver from a feature and architecture standpoint.
- Drive innovative security solutions to enable the wider web ecosystem of web developers, web admins and users to adapt to evolving web technologies and their corresponding security threats.
Here the concrete goals are segmented into themes. Some goals may potentially fit into multiple themes, but are only identified here under the most relevant one.
Survey taken in early 2011 to identify and prioritize potential features for our security roadmap. The results of this survey are available as a Google doc or as PDF: File:Security roadmap survey.pdf.
NOTE: these goals are tentative and more may be added or some may be dropped.
Roadmap
Items with Feature Pages
{{#ask: Feature stage::!LandedFeature roadmap::Security OR Feature secondary roadmap::Security | ?# | ?Feature name# | ?Feature priority# | ?Feature engineering team# | ?Feature stage# | ?Feature status# | ?Feature product manager# | mainlabel=- | sort=Feature priority,Feature stage | format=template | limit=500 | template=FeatureListTable }}| Pr | Feature | Team | Stage | Status | Product manager |
Ideas Not Yet Awesome Enough
| Item | Status | ETA | Owner |
|---|---|---|---|
| Plugin sandboxing |
not started | ? | ? |
| Effective certificate revocation and management |
not started | ? | ? |
| Plugin runtime mitigations such as whitelist and/or click to |
not started | ? | Justin Dolske |
| javascript: and data: handling in URL bar and chrome | |||
| DLL whitelisting by name or signature |
not started |
? |
? |
| Track "Application Reputation" |
|||
| Prune dead and dying code |
|||
| Malloc should be infallible |
|||
| TLS 1.2 support |
|||
| Eviltraps meta-bug (prevents users from leaving a page) |
|||
| Notify user of malware in their crash signatures |
|||
| Expose HSTS and other security browser state to plugins (NPAPI) |
|||
| Ignore autocomplete="off" for password fields | |||
| UX security experiment | not started | ? | ? |
| Content Security Policy revisions | In progress | ? | Brandon Sterne |
| CSRF mitigations | |||
| Clickjacking mitigations | |||
| X-Content-Type-Options | |||
| toStaticHTML |
Related Info
Links to implementation plan and progress:
