Privacy/Features/HSTS Preload List

Please use "Edit with form" above to edit this page.

Status

HSTS Preload List
Stage	Draft
Status	In progress
Release target	`
Health	OK
Status note	`

{{#set:Feature name=HSTS Preload List

|Feature stage=Draft |Feature status=In progress |Feature version=` |Feature health=OK |Feature status note=` }}

Team

Product manager	Sid Stamm
Directly Responsible Individual	`
Lead engineer	Stefan Arentz
Security lead	`
Privacy lead	Sid Stamm
Localization lead	`
Accessibility lead	`
QA lead	`
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	David Keeler

{{#set:Feature product manager=Sid Stamm

|Feature feature manager=` |Feature lead engineer=Stefan Arentz |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=David Keeler }}

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:

1. Hard-code the list in each shipping version of Firefox
2. 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

`

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:

1. Hard-code the list in each shipping version of Firefox
2. 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=` |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=` }}