Privacy/Features/HSTS Preload List
Status
| HSTS Preload List | |
| Stage | Development |
| Status | In progress |
| Release target | Firefox 17 |
| Health | OK |
| Status note | ` |
{{#set:Feature name=HSTS Preload List
|Feature stage=Development |Feature status=In progress |Feature version=Firefox 17 |Feature health=OK |Feature status note=` }}
Team
| Product manager | Sid Stamm |
| Directly Responsible Individual | ` |
| Lead engineer | David Keeler |
| Security lead | ` |
| Privacy lead | Sid Stamm |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=Sid Stamm
|Feature feature manager=` |Feature lead engineer=David Keeler |Feature security lead=` |Feature privacy lead=Sid Stamm |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
HTTP Strict-Transport-Security (HSTS) allows sites to specify that they would like to be accessed via HTTPS only. The problem is, a user's first request to a site employing HSTS may not be over HTTPS. A preload list will allow us to ship Firefox with some pre-set HSTS sites that, from the first time they're accessed in the browser, will require HTTPS.
2. Users & use cases
- Sensitive sites that want HTTPS always and never HTTP
3. Dependencies
This depends on HSTS, which landed and shipped with Firefox 4.
4. Requirements
- It must be easy for sites to get on the list
- It must be hard for someone to put a site that doesn't want HSTS onto the list
- We must be able to change the list quickly without shipping a new version of the product
Non-goals
- This does not change the underlying transport or feature (HSTS, HTTPS or SSL)
- This won't have anything to do with certificate pinning.
Stage 2: Design
5. Functional specification
There are two ways to accomplish this:
- Hard-code the list in each shipping version of Firefox
- Stand up a service (like blocklist ping) that serves the list upon request.
If we hard-code the list, we must be able to change it with hot fixes (without shipping new versions of the software).
If we stand up a service, it should be polled pretty regularly.
Google maintains a list in their chrome source (https://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state_static.json -- look for mode=force-https). We can use this list, since Google has invested in maintaining and sharing it.
6. User experience design
`
Stage 3: Planning
7. Implementation plan
- Create a mechanism to import a list of sites using HSTS into the permissions manager
- This mechanism must also be able to remove HSTS sites from the permissions manager if necessary (details TBD)
- Create a mechanism to suck down chrome's list and scrub/reformat it
- Initially this will be done by manually running a script and obtaining a file that we will check in to mozilla-central along with the above import mechanism code
- Periodically the script will be re-run, and any changes will be checked in to mozilla-central. Presumably this would be at least once per release.
- Eventually we (with IT) will set up a server that polls, scrubs and checks in updates to the preload file.
- TBD: Do we land updates to the preload list on branches?
- Currently ssh://hg.mozilla.org/users/dkeeler_mozilla.com/sts-preload has an early version of this script and its output
- In the future, create a mechanism by which URLs can be used as subscription endpoints
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
` {{#set:Feature open issues and risks=` |Feature overview=HTTP Strict-Transport-Security (HSTS) allows sites to specify that they would like to be accessed via HTTPS only. The problem is, a user's first request to a site employing HSTS may not be over HTTPS. A preload list will allow us to ship Firefox with some pre-set HSTS sites that, from the first time they're accessed in the browser, will require HTTPS. |Feature users and use cases=* Sensitive sites that want HTTPS always and never HTTP |Feature dependencies=This depends on HSTS, which landed and shipped with Firefox 4. |Feature requirements=* It must be easy for sites to get on the list
- It must be hard for someone to put a site that doesn't want HSTS onto the list
- We must be able to change the list quickly without shipping a new version of the product
|Feature non-goals=* This does not change the underlying transport or feature (HSTS, HTTPS or SSL)
- This won't have anything to do with certificate pinning.
|Feature functional spec=There are two ways to accomplish this:
- Hard-code the list in each shipping version of Firefox
- Stand up a service (like blocklist ping) that serves the list upon request.
If we hard-code the list, we must be able to change it with hot fixes (without shipping new versions of the software).
If we stand up a service, it should be polled pretty regularly.
Google maintains a list in their chrome source (https://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state_static.json -- look for mode=force-https). We can use this list, since Google has invested in maintaining and sharing it. |Feature ux design=` |Feature implementation plan=* Create a mechanism to import a list of sites using HSTS into the permissions manager
- This mechanism must also be able to remove HSTS sites from the permissions manager if necessary (details TBD)
- Create a mechanism to suck down chrome's list and scrub/reformat it
- Initially this will be done by manually running a script and obtaining a file that we will check in to mozilla-central along with the above import mechanism code
- Periodically the script will be re-run, and any changes will be checked in to mozilla-central. Presumably this would be at least once per release.
- Eventually we (with IT) will set up a server that polls, scrubs and checks in updates to the preload file.
- TBD: Do we land updates to the preload list on branches?
- Currently ssh://hg.mozilla.org/users/dkeeler_mozilla.com/sts-preload has an early version of this script and its output
- In the future, create a mechanism by which URLs can be used as subscription endpoints
|Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}
Feature details
| Priority | P1 |
| Rank | 999 |
| Theme / Goal | HTTPS By Default |
| Roadmap | Security |
| Secondary roadmap | Platform |
| Feature list | ` |
| Project | ` |
| Engineering team | ` |
{{#set:Feature priority=P1
|Feature rank=999 |Feature theme=HTTPS By Default |Feature roadmap=Security |Feature secondary roadmap=Platform |Feature list=` |Feature project=` |Feature engineering team=` }}
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}