From caafa5ceae2152d4d6daf1565730c320b3445030 Mon Sep 17 00:00:00 2001 From: Joost de Valk Date: Sun, 13 Sep 2026 08:10:38 +0200 Subject: [PATCH 1/2] add(considered): /.well-known/hosting-provider is the host's claim, not the site's MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Records the decision not to spec Automattic's hosting-provider well-known URI. It is served by the origin, but written by the hosting platform, about the platform, and its own specification calls the value spoofable — so there is no instruction to give a site author and no outcome to audit. Co-Authored-By: Claude Opus 5 (1M context) --- .../considered/hosting-provider-well-known.md | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 src/content/considered/hosting-provider-well-known.md diff --git a/src/content/considered/hosting-provider-well-known.md b/src/content/considered/hosting-provider-well-known.md new file mode 100644 index 00000000..448245ae --- /dev/null +++ b/src/content/considered/hosting-provider-well-known.md @@ -0,0 +1,22 @@ +--- +title: "The /.well-known/hosting-provider URI" +date: "2026-09-13" +reason: out-of-scope +revisit: "If something a visitor, crawler or agent uses ever reads the file — a browser, a registrar, an abuse-reporting flow — and the specification grows past a hint its own author calls spoofable. More hosts serving it would not be enough on its own: the string would still be the platform's claim about itself rather than anything the site says." +sources: + - title: "IANA — Well-Known URIs registry (hosting-provider, provisional, registered 2020-07-21)" + url: "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" + publisher: "IANA" + - title: "hosting-provider Well-Known Resource Identifier" + url: "https://github.com/Automattic/hosting-provider" + publisher: "Automattic" + - title: "RFC 8615 — Well-Known Uniform Resource Identifiers (URIs)" + url: "https://www.rfc-editor.org/rfc/rfc8615" + publisher: "IETF" +--- + +A domain's DNS usually points at a CDN rather than at whoever actually stores the files, which makes "who hosts this site?" surprisingly hard to answer from outside. `/.well-known/hosting-provider` is Automattic's answer: a participating host serves a bare `text/plain` string at that path naming itself — a URL, a domain, or a business name — and a third party combining that with hostname and IP checks can work out, with reasonable confidence, which provider or reseller account is serving the content. IANA carries the suffix as provisional, registered in July 2020; the specification is a single README that has not changed since April 2019. + +It does not land here, and the reason is not adoption. A website does not write this file — its host does, in server configuration the site's author usually cannot reach, about the host rather than about the site. Nor is the value meant to be believed: the README's own security considerations note that anyone can spoof it and self-report as a different provider, which is why every use case it describes pairs the string with independent hostname and IP evidence. A spec page needs an instruction to give and an outcome to check, and here there is neither — a reader following it would be told to ask their hosting provider to make an unverifiable claim to nobody in particular. + +That makes it a useful counterpart to [`/.well-known/scitt-keys`](/considered/#scitt-keys-well-known), which failed a different half of the same test. Scitt-keys failed on who _serves_ the file: a transparency service, not a website. Hosting-provider is genuinely served by the website's own origin, and still fails — on who _benefits_. The beneficiary is a third party doing attribution or abuse investigation, and the origin is merely the subject of the enquiry. The test that survives both cases is the same one that admits [`security.txt`](/spec/security/security-txt/) and [`change-password`](/spec/well-known/change-password/): serving the file has to make this origin better for the people and programs that visit it. Being in the registry never settles that, and neither does serving the file yourself. From 3010477aebeeb266b3f31c6498ccca6706d616e3 Mon Sep 17 00:00:00 2001 From: Joost de Valk Date: Fri, 18 Sep 2026 11:45:49 +0200 Subject: [PATCH 2/2] Clarify hosting-provider scope and attribution use case --- src/content/considered/hosting-provider-well-known.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/content/considered/hosting-provider-well-known.md b/src/content/considered/hosting-provider-well-known.md index 448245ae..f0d99be8 100644 --- a/src/content/considered/hosting-provider-well-known.md +++ b/src/content/considered/hosting-provider-well-known.md @@ -2,7 +2,7 @@ title: "The /.well-known/hosting-provider URI" date: "2026-09-13" reason: out-of-scope -revisit: "If something a visitor, crawler or agent uses ever reads the file — a browser, a registrar, an abuse-reporting flow — and the specification grows past a hint its own author calls spoofable. More hosts serving it would not be enough on its own: the string would still be the platform's claim about itself rather than anything the site says." +revisit: "Evidence of independent consumers using the endpoint in a website-facing workflow, such as routing abuse reports or identifying a support provider, with guidance for checking the hint against other evidence. That would establish a practical reason for website operators to request or publish it." sources: - title: "IANA — Well-Known URIs registry (hosting-provider, provisional, registered 2020-07-21)" url: "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" @@ -15,8 +15,8 @@ sources: publisher: "IETF" --- -A domain's DNS usually points at a CDN rather than at whoever actually stores the files, which makes "who hosts this site?" surprisingly hard to answer from outside. `/.well-known/hosting-provider` is Automattic's answer: a participating host serves a bare `text/plain` string at that path naming itself — a URL, a domain, or a business name — and a third party combining that with hostname and IP checks can work out, with reasonable confidence, which provider or reseller account is serving the content. IANA carries the suffix as provisional, registered in July 2020; the specification is a single README that has not changed since April 2019. +A CDN can obscure which hosting provider actually serves a site's content. `/.well-known/hosting-provider` is Automattic's convention for exposing that information: a participating host returns a `text/plain` string containing its URL, domain or business name, optionally identifying a reseller. The specification describes combining that hint with hostname and IP checks to identify the provider actively serving the content, even when reseller records are stale. IANA carries the suffix as provisional, registered in July 2020. -It does not land here, and the reason is not adoption. A website does not write this file — its host does, in server configuration the site's author usually cannot reach, about the host rather than about the site. Nor is the value meant to be believed: the README's own security considerations note that anyone can spoof it and self-report as a different provider, which is why every use case it describes pairs the string with independent hostname and IP evidence. A spec page needs an instruction to give and an outcome to check, and here there is neither — a reader following it would be told to ask their hosting provider to make an unverifiable claim to nobody in particular. +That is a concrete operational use case. The endpoint has an observable response, and an operator who controls the server can publish it or ask their hosting provider to do so. Its value is self-reported and can be spoofed, so consumers must check it against other evidence; this limits the confidence they can place in it without making the hint useless. Being configured by a host is also no reason by itself to exclude a website feature. -That makes it a useful counterpart to [`/.well-known/scitt-keys`](/considered/#scitt-keys-well-known), which failed a different half of the same test. Scitt-keys failed on who _serves_ the file: a transparency service, not a website. Hosting-provider is genuinely served by the website's own origin, and still fails — on who _benefits_. The beneficiary is a third party doing attribution or abuse investigation, and the origin is merely the subject of the enquiry. The test that survives both cases is the same one that admits [`security.txt`](/spec/security/security-txt/) and [`change-password`](/spec/well-known/change-password/): serving the file has to make this origin better for the people and programs that visit it. Being in the registry never settles that, and neither does serving the file yourself. +We leave it outside this specification because its documented purpose is provider and reseller attribution, a specialised hosting-management concern. The cited sources do not establish an independently implemented visitor or agent workflow that website operators should support by publishing it. That is a scope decision about the outcome we would recommend, rather than a claim that attribution has no benefit. A demonstrated use such as routing reports to the responsible provider would justify revisiting it, including how consumers handle incorrect or missing values.