Summary

  • The authority over .APP was stacked rather than consolidated. ICANN could process and evaluate the application, administer contention resolution and enforce the executed Registry Agreement. The IANA functions could verify delegation readiness and process the delegation through the root-zone change chain. Charleston Road Registry Inc. could set registration policies and contract with registrars. Registrants and their providers controlled DNS, hosting and certificates. Browser maintainers controlled whether a top-level HSTS rule became code on users’ devices.
  • The technically accurate sequence is narrower than the common claim that .app requires a certificate before DNS resolution. A participating browser can identify a .app hostname as covered by a preloaded HSTS parent and rewrite an applicable HTTP URI to HTTPS before loading it. DNS resolution ordinarily follows; only after the client has an address and begins secure connection establishment does the server present a certificate for validation. The practical requirement is therefore a certificate accepted by the relevant client before a usable browser session, not before DNS lookup.
  • Remedies stop at institutional boundaries. ICANN compliance can reach obligations in the Registry Agreement, and the registry can invoke the currently documented Registry-Registrar Agreement against a registrar that breaches an incorporated policy. A registrant can repair DNS, hosting or certificate configuration. Browser maintainers can alter preload source and ship a later release. None of those routes gives one complainant authority to change every layer at once.

Four gates and one misleading shorthand

The first revealing document in the .APP record was not a browser specification. It was an Australian governmental warning dated 20 November 2012. The GAC Early Warning criticised Charleston Road Registry Inc.’s proposal to reserve a common generic string for exclusive use, asked for transparent third-party access criteria and proposed that those criteria become part of a binding ICANN contract. Yet the form also described an Early Warning as “notice only”. It was not a formal objection, did not reject the application and did not itself rewrite the conditions under which .APP could proceed.

That distinction between influence and decision power persisted throughout the case. The government could identify a competition concern and increase the political and procedural cost of ignoring it. It could not amend Charleston Road Registry’s application, select the eventual registry operator, execute a contract for ICANN, enter .app in the DNS root or edit a browser’s source code. Even the remedy it proposed—put the access criteria into an enforceable contract—depended on later action by other parties.

Four distinct programme and implementation gates followed. The official Initial Evaluation report dated 3 July 2013 recorded a pass while the string-similarity result left the application in a contention set. The official APP auction report records that twelve applicants participated on 25 February 2015 and that Charleston Road Registry prevailed at USD 25,001,000, subject to payment and continued eligibility. On 14 May 2015, ICANN and Charleston Road Registry executed the .app Registry Agreement. The IANA root-zone record lists 25 June 2015 as .app’s registration date, followed by a delegation report dated 29 June.

None of those acts imposed HSTS on a browser. Evaluation established programme eligibility, not possession. The auction resolved contention, not contracting. The contract designated a registry operator subject to the still-separate approvals required for root entry. Delegation made the top-level domain resolvable through the DNS root; it did not dictate what an HTTP client should do with a .app URL. The client-side rule appeared later, evidenced by Google Registry’s 27 September 2017 announcement of top-level HSTS preloading, a Chromium source snapshot at version 63.0.3239.118 containing an app entry with include_subdomains and force-https, and the May 2018 retail launch. The snapshot proves that the entry was present by that code state; it does not by itself establish the first approving change or the first stable release that carried the rule.

This chronology corrects a misleading shorthand. HSTS is capable of acting before a network request because it changes an applicable http URI to https before the browser dereferences it. But that does not move certificate validation ahead of DNS. A browser normally needs to resolve the hostname and establish a connection before the server can present a TLS certificate. An NXDOMAIN response can therefore end the attempt before any certificate exists in the transaction. The supportable proposition is that an HSTS-capable browser requires successful secure transport and certificate validation before it will deliver a usable .app web session.

From an exclusive-access proposal to an amended .APP application

The official application-status page identifies application 1-1138-33325, Charleston Road Registry Inc. and the string APP. The public application now displayed by ICANN is not a frozen copy of the original June 2012 filing. It incorporates approved changes. Treating that consolidated text as the untouched proposal would erase the very dispute that helps explain the later model.

The contemporaneous redline matters. In an April 2013 letter and attached change materials, Charleston Road Registry said it had submitted amendments for .app through ICANN’s change-request process. The materials contrasted an original closed model—in which Google was contemplated as sole registrar and registrant, with use tied to Google and selected members of its developer network—with a more inclusive model intended for application developers across different kinds of applications and platforms. The applicant characterised the revision as stronger and more inclusive. That was its case for the change, not an adjudicated finding about its competitive effect.

The Australian warning is a plausible source of pressure, but the record does not establish a legal command running directly from the warning to the amendment. The warning invited discussion, recommended contractual remediation and pointed the applicant to the change-request process. Charleston Road Registry then chose to submit changes. ICANN, not Australia, decided whether to approve and post them. The application change history records ICANN-approved changes to questions 18(a)–(c), 28 and 29 on 14 May 2013, with a thirty-day public-comment window. It also records later updates in July and December 2013.

This is the first place where participation can be mistaken for control. Governments could warn. Members of the public could comment during the posted period. The applicant could propose revised language. Those interventions could affect incentives, supply information or create reputational and procedural risk. But only the applicant could request its own amendment, and only ICANN could accept and process the change within the programme. A comment was not a veto. A warning was not a rewritten application. An approved amendment was not a promise that the applicant would receive the string.

The difference also matters for enforcement. Statements in an application can be evidence of what an applicant represented during evaluation, and the later Registry Agreement required material application information and statements to have been accurate when made. That does not make every mission statement, access plan or security aspiration a freestanding covenant after contracting. Enforceability depends on what the executed agreement incorporated. Specification 11 is unusually clear on that point: it did not import the application’s commitments, statements of intent or business plans as additional Public Interest Commitments.

The amendment process therefore accomplished something important but bounded. It replaced the expressly exclusive model described in the earlier materials with a proposal framed as open to a wider class of application developers and allowed the programme to assess the revised application. It did not settle contention, create a registry franchise, delegate the string or pre-authorise a future browser rule. The warning had leverage because later decision-makers might act on the concern, not because the warning itself possessed those later powers.

A pass was permission to continue, not possession

The official Initial Evaluation report, dated 3 July 2013, is easy to overread because its headline result is “Pass”. Its findings were segmented. Background screening was marked eligible. DNS stability, geographic-name review and registry-services review passed. The technical and operational panel found that the application met the relevant criteria, and the financial panel reached the same conclusion for its criteria. The application-status page records the same programme result and links the application’s subsequent status history.

At the same time, the report marked string similarity “Pass – Contention”. APP remained in a contention set, so passing evaluation meant only that Charleston Road Registry could proceed to the next stage; it did not mean that the company had defeated the other applicants.

The Initial Evaluation report preserves that limit. It reserved ICANN’s ability to conduct additional screening or research and to reassess eligibility until a Registry Agreement was executed. Its disclaimer stated that Initial Evaluation did not necessarily determine the application’s final result, anticipated further due diligence during contracting and made clear that the report did not waive or amend the Applicant Guidebook or a future Registry Agreement.

The institutional object at this stage was an application, not a delegated top-level domain. ICANN’s evaluation process could determine whether that application met programme criteria. It could not make competing applications disappear merely by passing one of them. Nor could it confer the operational rights that would later arise from a contract and root-zone entry. The application had moved from proposal to eligible contender. It had not become infrastructure.

The auction decided contention and nothing beyond it

The official APP auction report lists twelve participating applicants and records Charleston Road Registry’s winning price of USD 25,001,000 on 25 February 2015. The price is the most repeated fact in accounts of .app because it offers a simple story: Google paid more than anyone else and acquired the domain.

The auction report refuses that simplification. Its result was contingent on timely payment under the auction rules and on ICANN’s determination that the winner remained eligible to sign a Registry Agreement. It expressly stated that the outcome did not guarantee either execution of a Registry Agreement or delegation of the TLD. Nor did the auction waive or amend the Applicant Guidebook, the Registry Agreement, the bidder agreement or the auction rules.

The auction’s decision object was therefore the contention set. Its function was to choose which surviving application could advance, not to grant every downstream authority associated with running a live namespace. Competing applicants had a defined form of participation: they could bid under the auction procedure. Their bids affected the outcome. None could use a bid to execute ICANN’s contract, perform the delegation checks or require a browser vendor to preload the TLD.

The winner also remained constrained. Payment and programme eligibility were conditions. Contract negotiation and execution remained separate. Technical and procedural readiness for delegation remained separate again. The USD 25,001,000 payment resolved scarcity among applicants; it did not buy an exception from the rest of the institutional chain.

This boundary is more than formal sequencing. It identifies the forum in which a remedy could have mattered. A defect in auction administration would concern contention resolution. A dispute over a term of the later Registry Agreement would concern contracting or compliance. A failure in root-zone readiness would concern delegation. A browser’s treatment of an HTTP request would concern browser implementation. Calling the auction a purchase of .app collapses those different objects and obscures which decision could be reviewed by whom.

Contract was not delegation, and the contract did not promise HSTS

ICANN’s agreement index records Charleston Road Registry Inc. as operator, an agreement date of 14 May 2015 and a base, non-sponsored agreement type. The executed Registry Agreement created the contractual authority that evaluation and auction had not.

Section 1.1 designated Charleston Road Registry as registry operator for .app, but made that designation subject to the requirements and necessary approvals for delegation and root-zone entry. The drafting is decisive: a registry contract was a prerequisite to delegation, not delegation itself. Section 2.9 required registrations to pass through ICANN-accredited registrars and required the operator to use a uniform, non-discriminatory Registry-Registrar Agreement with authorised registrars.

Material revisions to that downstream agreement required ICANN approval, while other revisions were subject to notice and classification under the contract’s review procedure. Section 2.11 gave ICANN contractual audit rights, and section 2.17 made the operator comply with Specification 11.

Those provisions created enforceable control over registry conduct. ICANN could test compliance with the agreement, its specifications and incorporated obligations. The registry could condition registrar access on a Registry-Registrar Agreement consistent with its ICANN contract. But an enforcement claim still required an actual contractual duty.

HSTS was not one. Specification 11.2 says, in substance, that the operator did not include its application commitments, statements of intent or business plans as additional contractual commitments. Specification 11.3 contains specific Public Interest Commitments enforceable by ICANN and through the Public Interest Commitment Dispute Resolution Process. They include duties concerning registrar terms for abuse, periodic technical analysis of security threats, transparent registration policies and non-exclusive treatment of a generic string. The executed text contains no express covenant to put .app on an HSTS preload list.

That omission blocks two attractive but unsupported claims. First, the applicant’s earlier security language did not automatically become an ICANN-enforceable HSTS promise. The contract must be read on its own terms. Second, later browser source did not amend the Registry Agreement by operation of fact. A browser may enforce a rule that the registry encouraged, but that does not turn source code into an annex to ICANN’s contract.

The IANA record marks the next boundary. The root-zone database gives 25 June 2015 as the registration date and names Charleston Road Registry as sponsoring organisation. The 29 June delegation report records the application as deemed eligible, confirms that the proposed sponsoring organisation matched the contracted party and marks contact confirmation, technical conformance and other processing as completed. The report describes additional procedural checks before transmission for authorisation and implementation.

Delegation changed what the global DNS root could answer. It made .app a live top-level domain under the identified sponsoring organisation. It did not reopen the auction or alter the terms of the Registry Agreement. It did not issue certificates, configure second-level names, run registrants’ web servers or instruct browsers to replace http with https. Root authority made names under .app possible; application-layer policy determined how particular clients would try to reach web content under those names.

The separation also explains why corporate proximity cannot substitute for legal analysis. Charleston Road Registry described itself as a wholly owned Google subsidiary, while the later rule is evidenced in a Chromium source tree used for Chrome. That proximity could reduce coordination costs and align incentives. It did not merge ICANN, the IANA functions, the registry company, registrars, certificate authorities and browser projects into one decision-maker. Each acted on a different institutional object under a different source of authority. The Registry Agreement could bind its parties and incorporated actors; it could not, by itself, patch an installed browser. Chromium-derived code could change client behaviour once accepted and shipped; it could not rewrite the contract or the root-zone record.

The three-year gap between root authority and retail launch

The dates expose a gap that a single-act account cannot explain. Charleston Road Registry signed the Registry Agreement in May 2015. .app entered the root in June 2015. Google Registry publicly described a strategy of preloading HSTS at the top-level in September 2017. General availability followed in May 2018.

A delegated TLD can exist before it is broadly available for retail registration. Delegation identifies the TLD’s sponsoring organisation and allows its name servers to be reached through the root. Registry launch planning, rights-protection periods, registrar onboarding, pricing and general availability are later operational choices and obligations. Nothing about the root-zone act itself required a public buyer to be able to register a second-level name on 25 June 2015.

The later security policy was similarly distinct. Google Registry’s 27 September 2017 security announcement described the ability to place whole top-level domains on the HSTS preload list. The Chromium transport-security source snapshot at version 63.0.3239.118 proves that app appeared as a static entry with subdomain inheritance and forced HTTPS in that code state. Standing alone, it does not establish the first change list that added the entry, the author and reviewers of that change, the exact landing date or the first stable release containing it. Those adoption details are not established by the cited snapshot.

On 1 May 2018, Google announced that .app names would be available through an Early Access Program from 1 to 7 May and through general availability from 8 May. The launch notice presented HTTPS as a defining feature. That statement described the operator’s product and security position; it did not prove universal behaviour across every browser, client or protocol.

The present .app Domain Registration Policy translates the consequence into a retail notice duty. Registrars must alert prospective registrants, before purchase and distinctly from general terms, that .app names require HTTPS to work in web browsers. The notice must cover HTTPS configuration and resources for obtaining a certificate. This is governance through the registrar interface: the registry uses contractual access to require information to reach the buyer before the sale.

The available public documents are not complete enough to backdate the current instruments to May 2018. The November 2022 Registry-Registrar Agreement form expressly incorporates the Domain Registration Policy, gives the registry a mechanism for changing registry policies, requires registrar compliance and treats breach of those policies as a material default subject to notice, cure and possible termination. A publicly accessible ICANN-hosted registry-policy packet contains substantially the same HTTPS-notice language, but the packet as retrieved has no cover sheet or visible filing date, effective date, approval record or other provenance sufficient to establish when it became operative. It is therefore an undated packet of uncertain operative status, not proof of the contractual position at the May 2018 launch. The current chain is documented; its exact launch-era wording remains unresolved.

How a registry policy became executable on a user’s device

The registry’s notice policy and the browser’s preload rule did different work. The policy told registrars what they had to disclose. The code changed what a browser did. The difference becomes clear by following one navigation rather than speaking generally about “HTTPS by default”.

Assume a user enters or follows http://service.app/path in a browser that ships the relevant top-level preload entry. Under RFC 6797, a browser preparing to load an HTTP URI first extracts the host and checks whether it matches a known HSTS host. Domain matching proceeds from the rightmost labels. Because the preloaded parent app carries subdomain inheritance, service.app falls under the rule.

Before proceeding with the load, the browser replaces the http scheme with https. An explicit port 80 is mapped to 443; a different explicit port is preserved. This rewrite is local client behaviour. The registry does not receive a request asking permission to upgrade the URI, and the authoritative DNS server does not insert the HTTPS scheme. The browser acts because its shipped security state says that the parent domain is a known HSTS host.

The navigation then proceeds through ordinary resolution and connection steps, using cached or newly obtained DNS information. If service.app does not exist, DNS returns NXDOMAIN and no TLS handshake follows. If the name exists but lacks usable address records, the attempt can still end before TLS. If an address is available, the client tries to connect to the selected endpoint. The server must be listening for secure transport on the resulting port. During TLS, the server presents certificate material, and the client applies its normal trust, validity and identity checks.

That order is why “certificate before DNS resolution” is wrong. HSTS can precede dereferencing by rewriting the URI, but a certificate is exchanged as part of secure connection establishment, not as a prerequisite to asking DNS for an address. The operational requirement is certificate-accepted-before-usable-session. A registrant may register a name without immediately placing it in the zone. A delegated name may resolve without a web server. A web server may accept TCP but not TLS. A TLS server may present an expired, self-signed, mismatched or otherwise untrusted certificate. Each failure occurs at a different layer.

HSTS changes the consequence of the last group. RFC 6797 directs a conforming browser to terminate connection attempts to a known HSTS host on secure-transport errors, including certificate-validity and server-identity failures. Its implementation advice calls for “no user recourse”: the ordinary path that sometimes lets a user click through a certificate warning should not be available. For a .app site covered by the preload entry, an invalid certificate is therefore not merely a caution screen on the way to content. It is intended to be a hard stop.

Preloading closes a bootstrap gap. Dynamic HSTS normally begins only after a browser has successfully reached a site over HTTPS and received a valid Strict-Transport-Security header. A first visit that begins over HTTP can be intercepted before the browser learns that policy. A built-in list allows the browser to know the rule before any visit. The Chromium HSTS documentation describes Chrome’s preload list and notes that other browsers maintain related lists, while the preload project describes special handling for whole public suffixes and the automatic upgrade of HTTP requests to listed domains.

The preload list is not a registry database. Browser maintainers decide what source to accept, review and ship. Downstream browser projects may base their lists on Chromium’s, but each retains its own code, release schedule and implementation choices. Google Registry could request or coordinate a top-level entry and could design a registration policy around the expected effect. It could not independently update every browser already installed on a user’s device or grant one second-level registrant an exception inside another vendor’s binary.

The certificate authority is another separate control point. Under the current CA/Browser Forum Baseline Requirements, a publicly trusted certificate authority is responsible for certificate creation, issuance, revocation and lifecycle management, and it must validate domain authorisation or control by an approved method before issuing a certificate for a fully qualified domain name. The authority can issue, decline to issue or revoke under those rules; a replacement certificate requires another issuance process. The registry’s delegation of a name is not certificate issuance, and a certificate is not proof that a registrant or its content is trustworthy. Successful validation establishes only that the certificate and key satisfy the applicable identity, validity and trust checks for that connection within the client’s trust model. A malicious site can possess a valid certificate. HSTS enforces a strict-transport rule for the covered hostname in a participating client; it does not certify the site’s honesty.

Nor does HSTS encrypt DNS. The mechanism governs how the browser handles HTTP transport to a domain name. DNS confidentiality depends on separate resolver and transport arrangements. The .app root delegation, DNSSEC requirements in the Registry Agreement and browser HSTS behaviour are distinct technical controls. Treating them as one “encrypted namespace” may be useful marketing, but it is inaccurate as an institutional or protocol description.

Who owed what to whom

The .APP chain can be stated as a duty matrix. The point is not merely to name actors, but to identify the object each controlled and the remedy its authority could supply.

Actor Controlled object or duty What it could enforce or change Where its authority stopped
ICANN Application processing, programme evaluation, contracting and Registry Agreement compliance Approve application changes, determine programme status, execute and audit the Registry Agreement, enforce stated Public Interest Commitments It did not itself resolve DNS queries, issue certificates or dictate independent browser releases
Auction mechanism APP contention set Select the prevailing application under the auction rules, subject to payment and eligibility A win did not guarantee contracting or delegation
IANA functions Delegation-readiness checks and root-zone change processing Verify the contracted sponsoring organisation, contacts, technical conformance and procedural readiness; process the delegation through the root-zone change chain Delegation did not decide HTTP, TLS or HSTS behaviour
Charleston Road Registry Inc. Registry operation, registry policies and registrar access under the Registry Agreement Publish registration policies, require a Registry-Registrar Agreement, notify and pursue registrar defaults within contractual limits It could not patch third-party browsers, issue every certificate or configure registrants’ services
Registrar Retail registration flow and customer relationship Present the required pre-purchase notice, register names, provide support and contract with registrants It could not remove a top-level preload entry or make an unconfigured host serve HTTPS
Registrant and service providers Second-level DNS, hosting and TLS deployment Delegate or configure hostnames, run services, obtain and renew certificates, repair outages They could not alter the parent TLD’s rule in another vendor’s installed browser through an ICANN complaint
Certificate authority Domain-control validation and certificate lifecycle under the CA/Browser Forum Baseline Requirements and the authority’s policies Issue, decline to issue or revoke certificates; process replacement through a new issuance decision Issuance did not confer registry rights or guarantee benign content
Browser maintainer Preload source, implementation and release channel Add, modify or remove entries and ship behaviour to users Browser code did not amend the Registry Agreement or root-zone record
End user Choice of client and whether to attempt access Report the failure, correct a controlled local problem or await repaired service or software In a conforming HSTS flow, the user cannot bypass a certificate failure for the known host

The duty running from the current registry policy to the registrar is disclosure, not remote configuration. The registrar must present the HTTPS consequence before purchase. It may supply its own guidance or link to other resources. The registrant remains responsible for making the hostname resolve and for arranging hosting and certificate service. A registrar that gives perfect notice cannot make a neglected certificate renew itself. A registrant that configures perfect TLS cannot retrospectively cure a registrar’s failure to disclose.

The November 2022 RRA form shows the present contractual transmission mechanism. It defines the Domain Registration Policy by reference, makes registered names available in accordance with that policy, requires compliance with registry policies after notice and treats breach of those policies as a material breach that can trigger a thirty-day cure period and termination. It also says that registered names can exist in the registry database without appearing in the TLD zone, which helps distinguish registration from DNS activation.

That form should not be used as a time machine. It is strong evidence of the current registry–registrar chain, not conclusive evidence of the precise agreement signed by every launch registrar in May 2018. The evidence establishes that a notice duty exists now and that an ICANN-hosted packet carries matching language. Without the operative 2018 instruments, however, it does not establish that every clause, cure period and incorporation mechanism was identical at launch.

Many review routes, no cross-layer appeal

The most consequential governance feature of .APP is not the number of institutions but the mismatch between the harm a person experiences and the forum that can repair it. A user sees one failed page. The reasons may sit in DNS, hosting, certificate issuance, registrar disclosure or browser code. Each layer has its own review route, standing rules and remedy.

An ICANN contractual-compliance complaint can test conduct governed by the Registry Agreement. ICANN can audit the registry operator and enforce specifications and actual Public Interest Commitments. The PICDRP can reach the Public Interest Commitments identified in Specification 11.3. It cannot sensibly be used to demand enforcement of an HSTS covenant that the agreement does not contain. Nor can any ICANN accountability or contractual process identified here order an independent browser vendor to ship a changed preload list merely because the registry operator is affiliated with a browser developer.

A registrar dispute belongs lower in the contract stack. Under the current RRA form, the Domain Registration Policy is incorporated into the registrar’s obligations. A failure to provide the required notice can therefore be treated as a policy breach, followed by notice, an opportunity to cure and possible termination under the RRA. That remedy can compel or sanction registrar conduct. It does not make an HTTP-only site reachable in an HSTS browser. Technical enforcement continues even while contractual notice is disputed.

A registrant with a broken site usually needs an operational remedy. If DNS returns NXDOMAIN for a name that is meant to resolve, the registry or registrant DNS state must be corrected. If no secure service listens, hosting must be configured. If the certificate has expired, is self-signed where the client does not trust that issuer, or does not match the hostname, the certificate or trust configuration must be repaired. The relevant registrar, host or certificate authority may assist, but the cure remains attached to the failing component.

A browser-list problem belongs to the preload-maintenance process. The HSTS preload project warns that inclusion is difficult to undo: a removal can take months to reach Chrome users through updates, and the project cannot guarantee propagation to other browsers. TLD owners are invited to coordinate top-level preloading with the project, but the public documentation does not establish an individual second-level .app waiver capable of overriding an inherited parent entry in all clients. Even a successful source change would not instantly alter old browser installations.

The end user has the least formal control at the moment of failure. RFC 6797’s security model deliberately removes the ordinary warning bypass for known HSTS hosts. The user can report the problem, contact the site, correct an erroneous local clock or a legitimate trust configuration under the user’s control, or wait for service or software repair. Choosing another client does not remove the inherited rule from the client that enforces it and should not be confused with a certificate-error exception. The protocol’s intended response to the error is not an ICANN-style appeal and not a one-time bypass.

The denial of access is the enforcement mechanism.

Review access must therefore be separated from an enforceable remedy. A registrant may complain to ICANN, but ICANN can act only on duties within its authority. A registrar may contest a registry notice or termination under the RRA, but that dispute does not bind browser maintainers. A browser project may review a removal request, but its decision does not cancel the registrant’s name or amend the registry contract. The public materials identified for this case contain no reconsideration request, Independent Review Process decision or PICDRP determination directed at .app’s HSTS preload choice.

That is a bounded statement about the located record, not proof that no complaint was ever made in any channel.

The located ICANN, registry-contract and browser-maintenance processes provide no forum with authority to issue one restorative order across every layer. That is why the same incident can produce partial remedies. A registrar can improve disclosure while the site remains broken. A registrant can fix TLS while the historical disclosure breach remains. A browser vendor can remove an entry in a later release while the registry policy continues to require notice. Institutional fragmentation does not mean there is no accountability; it means accountability is object-specific.

Exceptions and the narrow security holding

The claim that every .app name “requires a certificate” becomes precise only when different states are separated.

An unregistered or non-existent name. A browser may rewrite an http navigation to https, but DNS can still return NXDOMAIN. No certificate is presented because no endpoint is reached. HSTS has affected the intended scheme, not created a DNS record.

A registered name not published in the zone. The current RRA recognises that a registered name may remain outside the TLD zone. Registration establishes a registry record and sponsorship relationship; it does not ensure DNS publication. Again, the failed navigation may end before any TLS certificate is presented.

A resolving name with no HTTPS service. DNS succeeds, but connection establishment fails because the endpoint is absent, closed or serving only plaintext HTTP. The preload rule prevents the browser from falling back to an insecure web session. The cure is to deploy secure service, not to change the root delegation.

A resolving name with valid TLS. The client connects, validates the certificate and can continue. HSTS supplies the automatic upgrade and strict treatment of errors; the certificate and server configuration supply the secure endpoint.

A resolving name with an expired, self-signed, mismatched or otherwise untrusted certificate. A conforming HSTS-capable browser terminates the attempt without the ordinary click-through route. The registrant or its provider must repair the certificate or trust configuration. A certificate authority’s issuance decision, not ICANN’s delegation, is central here.

Nested subdomains. Because the source snapshot’s app entry includes subdomains, a hostname such as api.service.app inherits from the preloaded parent in a client that ships that rule. That inheritance is powerful: the TLD-level browser rule reaches names that did not exist when the code was written and hostnames created by later registrants.

An IP literal. RFC 6797 excludes IP literals from known-HSTS-host matching. Navigating directly to an address is not the same as navigating to the .app hostname, even if the address happens to host the same service. Certificate identity and virtual-host behaviour may create separate failures.

An explicit alternate port. HSTS changes port 80 to 443 but preserves another explicit port while changing the scheme. If that port offers only plaintext HTTP, the resulting secure attempt can fail. Preloading does not discover or repair the service topology.

A non-browser protocol or a client without the entry. HSTS is an HTTP client policy. Mail, DNS, arbitrary application protocols and clients that do not implement or ship the same preload state are not governed identically. The existence of Chrome source cannot establish universal coverage across Firefox, Safari, Edge, embedded web views, command-line tools and non-browser applications. Their adoption dates, inherited lists, exception handling and release propagation require vendor-specific evidence.

The security holding should therefore remain narrow. For a browser that includes the top-level entry and applies RFC 6797-style behaviour, a .app hostname is treated as a known HSTS host through parent matching. An applicable HTTP navigation is upgraded before loading. If secure transport or certificate validation fails, the connection is terminated without the usual warning bypass. This protects the covered client and hostname against the first-load HTTP downgrade gap and against ordinary click-through treatment of certificate errors.

It does not encrypt DNS. It does not prove the registrant is honest. It does not ensure that every service under the name is available. It does not govern all protocols. It does not stop a phishing site on a different domain from obtaining its own valid certificate. RFC 6797 expressly says HSTS is not a defence against phishing as such and that malware on the user’s system can compromise a session regardless of HSTS.

The counterfactuals confirm the institutional boundaries. Without top-level preloading, a .app site could still redirect HTTP to HTTPS and establish dynamic HSTS after a successful secure visit, but the first-visit bootstrap gap would remain. If browser vendors removed the top-level entry while the registry kept its notice policy, registrars could remain contractually obliged to disclose an HTTPS expectation even as automatic enforcement disappeared or varied by client.

If browsers retained the entry while a registrar failed to warn buyers, users would still encounter hard technical enforcement, but the registrar could face a contractual notice claim.

Even an express HSTS term in the ICANN Registry Agreement would not have compelled every independent browser vendor to ship identical code, release dates or exceptions. ICANN could have enforced the registry’s contractual conduct; it could not turn that contract into a universal software update. Conversely, browser source can make HTTPS mandatory in practice for participating users without making HSTS an ICANN covenant. If .app had been delegated and never preloaded, the root would still make names resolvable while browsers remained free to use ordinary HTTP behaviour.

.APP is therefore not a case in which a registry simply ordered the web to become secure. It is a case in which separate powers aligned. The GAC Early Warning put the proposed access model under formal scrutiny. ICANN processed an amended application, evaluated it, administered the programme’s contention resolution and contracted with the prevailing applicant. The IANA functions verified readiness and processed the delegation into the root-zone change chain. The registry used its registrar relationship to transmit a warning and configuration expectation. Registrants and providers supplied the operational pieces.

Chromium maintainers, and downstream browser vendors where they adopted and shipped the entry, made the hard client-side rule executable. The result was powerful precisely because no single instrument contained the whole command.

The remaining evidential limits are material but bounded. The version 63.0.3239.118 source snapshot does not identify the first Chromium change list adding app, its author, reviewers, landing date or first stable milestone. The public documents located for this case do not include the signed or operative 2018 RRA and then-effective Domain Registration Policy, and the undated ICANN-hosted packet does not close that gap. Vendor-specific adoption and exception records for Firefox, Safari and Edge are also incomplete. Without dated vendor records and a preserved cross-browser test matrix covering NXDOMAIN, inactive names, HTTP-only service, valid and invalid certificates, nested subdomains, alternate ports, IP literals and non-browser clients, present behaviour cannot be inferred from one source tree alone. Those limits do not alter the documented separation between application, auction, contract, delegation, registry policy and browser code. They limit how precisely the later implementation history can be assigned.