skip to content

Should a district submit its parent domain to the HSTS Pre-Loaded List with includeSubDomains, and what does that commit?

level: principalimportance: nice to knowfreq 33%

answer

  1. closes the bootstrap gap only
  2. shipped inside the browser
  3. vendor-operated, not the RFC
  4. removal paced by browser releases
  5. commits names not yet created

basics

~20 s

Only after every name under the domain is enumerated and confirmed to serve TLS. A pre-loaded entry closes the unprotected first request, but it commits present and future subdomains, is operated by browser vendors, and is slow to leave.

solid answer

~50 s

The pre-loaded list is the one facility that closes the bootstrap gap: names shipped inside the browser are known before any request is made, so a parent typing a bare host name on a hostile network never emits a plaintext request. That benefit is real and lands exactly on the people the portal exists for. The price is asymmetry. Entry is a request to an operator you do not control and it reaches users only as browsers ship. Removal is the same, and slower, whereas a policy you sent yourself can be shortened and then zeroed on your own schedule. With `includeSubDomains` the commitment covers every present and future name under the domain — including old plaintext-only school sites nobody currently employed maintains, and names not yet created. The decision is therefore an inventory and ownership question before it is a security one.

go deeper

for a junior

Know what the list is for: some names are already known to a browser before it has ever reached them, which is the only way the first request can be protected.

for a middle

Explain that the list is operated by browser vendors rather than defined by the specification, and that entries are therefore added and removed on their release cadence.

for a senior

Show the operational asymmetry: a header-delivered policy has a withdrawal path you control, while a pre-loaded entry does not, and both make covered names fail closed.

for a principal

Own the tradeoff explicitly — a benefit for first-time visitors bought with an irreversible, tree-wide commitment binding name owners who were never consulted, including future ones.

## What the list buys A policy delivered by a header field can only be learned by first reaching the host, so the very first request from a device that has never held an entry goes out as written — the Bootstrap MITM Vulnerability. The **HSTS Pre-Loaded List** closes that specific hole by shipping a set of names inside the browser itself, so the rewrite applies before any request has ever been made to the name. For a district portal this is not academic. The population is parents typing a bare host name into an address bar from a phone on whatever network a school car park offers, often on a device that has never visited before. For that visitor, the header alone does nothing on the trip that matters; a pre-loaded entry does. ## What the list costs The list is a **vendor-run facility**, not part of RFC 6797. That single fact generates every cost: - **Entry is a request, not a deployment.** You ask; operators decide; the entry reaches users as browsers ship new releases. The timeline is not yours. - **Removal is the same, and slower.** A policy you sent yourself has a defined withdrawal path — shorten `max-age`, then send `max-age=0`, both over TLS. A pre-loaded entry does not answer to your responses at all. You submit a removal request and wait for releases to carry it. - **The commitment is to names, not to a project.** With `includeSubDomains` it covers every present and future name under the domain. The names that have not been created yet are included by construction, which means future colleagues inherit a constraint they never agreed to. - **Failure is closed, everywhere.** On a covered name any secure transport error terminates the connection and browsers offer no way past it. The list makes that true for names nobody has visited, on devices that have never reached your infrastructure. ## The judgment, framed honestly The distribution of costs and benefits is the reason this is a lead's decision: | | benefit | cost | |---|---|---| | who it lands on | first-time visitors on untrusted networks | owners of every other name under the domain | | when it lands | immediately, on the visit that matters most | whenever any covered name's secure transport breaks | | who decided | the team submitting | people not in the room, including future ones | | how reversible | n/a | slow, and outside your control | A district's parent domain typically carries a name per school. Some are old, plaintext-only, and maintained by nobody currently employed. Submitting the parent with `includeSubDomains` makes every one of those names fail closed in browsers that have never touched them, and the recovery path runs through an external operator. ## A defensible sequence 1. **Inventory every name under the domain.** Not the ones you know about — every one that resolves. If that list cannot be produced, the answer is no, and the reason is that the commitment cannot be scoped. 2. **Make each one serve TLS correctly, with owned and monitored renewal.** A name with no owner is a name that will fail closed at some point. 3. **Run the header alone, widening deliberately**: a short lifetime on the portal, then a long one, then `includeSubDomains` across the tree. Live with the wide policy long enough to learn what it breaks — this stage is still reversible. 4. **Only then consider submission**, and consider submitting the narrower name. Pre-loading the portal's own host gets the bootstrap protection for the visitors who need it while leaving the rest of the tree governed by a header you can still withdraw. 5. **If the tree cannot be made TLS-only**, the honest answer is not to pre-load the parent at all — and to say so in those terms, because "we will fix the school sites later" is a plan that ships an irreversible commitment ahead of the work. ## What a strong answer sounds like It names the benefit precisely (the first request from an unknown device, and nothing else), names the mechanism of the cost (vendor-operated, release-paced, tree-wide, fail-closed), and then refuses to answer in the abstract: the decision turns on whether the organisation can enumerate and own every name under the domain. A candidate who answers "yes, preloading is best practice" has treated a one-way door as a checklist item.

  • What does a pre-loaded entry protect that a long max-age does not?
    Only the first request from a browser that has never held an entry for the name — a new device, a fresh profile, cleared state, or an expired entry. Once a browser has processed the header field, its behaviour is the same either way. That one request is the entire difference, and for a portal reached by first-time visitors on untrusted networks it is the request that matters.
  • Why is a narrower submission often the better call?
    Because the benefit concentrates on the name people actually type, while the cost spreads across every name under the domain. Submitting the portal's own host buys the bootstrap protection for those visitors and leaves the rest of the tree under a header-delivered policy you can still shorten and withdraw on your own schedule.
  • What would make you refuse the submission outright?
    An inability to enumerate the names under the domain, or any covered name without an owner for its secure transport. Both mean the commitment cannot be scoped or maintained, and the failure mode is names going dark in browsers that never reached them, with recovery paced by an external operator's release cycle.

saying these in an interview costs you the question

  • Calls pre-loading a best practice with no inventory step.
  • Thinks a removal request takes effect as quickly as a header change.
  • Believes the list is defined by the HSTS specification itself.
  • Assumes future subdomains are outside an includeSubDomains commitment.
  • Says pre-loading protects requests a stored policy already covers.