Security/Features/Revamp Security Hooks
Please use "Edit with form" above to edit this page.
|Revamp Security Hooks|
|Directly Responsible Individual||`|
|Lead engineer||Jonas Sicking|
|Security lead||Tanvi Vyas|
|Product marketing lead||`|
|Additional members||Christoph Kerschbaumer|
Stage 1: Definition
1. Feature overview
This is a multi-step project to make security checks in Gecko more robust. Currently, security checks are done before a channel is created and before a request hits necko. This project would change this so that each individual security check would fall in the place where it is best suited. Part of this will be breaking apart the current Content Policy API and calling each content policy in the appropriate place.
- NewChannel API - Include information in the channel about who initiated the load.
- Add new network observer architecture.
- Implement security policies on top of that observer architecture, checking against each policy at the appropriate time during the life of a request.
Meta bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1006868
2. Users & use cases
- Enable new hooks to better handle redirects and response observing/filtering
- Replace necko observer-service notifications with something more high-performance
- Enable implementing CSP, local-network-CSRF-protection and https-everywhere to be implemented using standard necko hooks
- Replace nsIContentPolicy with something e10s friendly
- Replace nsIProtocolHandler with something e10s friendly
- Remove ability/need for protocol handlers to implement custom nsIURIs and nsIChannels
- Enable starting network requests directly from worker threads and other non-main-threads
- Enable off-main-thread network requests to never hit the main thread unless JS-based addons which explicitly request it are installed
- Make redirect handling simpler and more consistent
- Get rid of nsIChannel.owner
- Provide consistent observer hooks that work for all channel types, including file:, http:, chrome:, data: etc. This is useful for the devtools team.
- Provide observer hooks with fewer edge cases, even when a request is loaded from cache.
Stage 2: Design
5. Functional specification
6. User experience design
Stage 3: Planning
7. Implementation plan
Quality Assurance review
Stage 4: Development
Stage 5: Release
10. Landing criteria
|Theme / Goal||Product Hardening|
Team status notes