外部引用的定義與種類

外部引用指服務發出去、存放在服務以外的地方、之後會被拿來向服務送出請求、或讓別人的系統依賴服務運作的連結、端點、名稱或身分。服務關閉時，自己系統裡的資料可以刪、程式可以停，外部引用卻還在別人的文件、程式與裝置裡，持有者下一次使用時才會發現服務已經不在。

常見的外部引用有五種，每一種存放的位置不同，持有者能不能自己修改也不同：

表格裡的例子都有實際案例：Google 在 2025 年修正 goo.gl 短網址的停用計畫時寫明這些連結「embedded in countless documents, videos, posts and more」（Google, 2025）；Parse 的行動 app SDK 連線的是 api.parse.com，2016 年宣布關閉時，遷移指南把「新版 app 不再依賴 api.parse.com」列為完成條件之一（Parse 遷移指南，Wayback 2016-12）；polyfill.io 是十萬個以上網站以 <script> 嵌入的腳本網址（Sansec, 2024）。綁在網域上的身分這一種，提供者是收信網域的擁有者（例如套件維護者），持有者是把這個信箱存成帳號身分的服務（例如套件登錄服務）。

持有者的分類：直接客戶、間接使用者與第三方持有者

外部引用的持有者依「提供者聯絡得到他們嗎」分成三類，這個分類決定服務結束時通知與補救能到達誰：

• 直接客戶：在服務上有帳號、付費或註冊過的人。提供者有他們的信箱，公告與匯出工具都能送到他們手上。Parse 上開發 app 的開發者、Heroku 免費方案的帳號持有人屬於這一類；買了提供者硬體、在服務上有帳號的人（Revolv 集線器、Pebble 手錶的買主）也屬於這一類。
• 間接使用者：直接客戶的產品或內容的使用者。提供者沒有他們的聯絡方式，只能經由直接客戶轉達。Parse 開發者發布的 app 的使用者屬於這一類：他們手機上的舊版 app 仍連線 api.parse.com，要等開發者發新版、自己再更新才會切換。
• 第三方持有者：和提供者沒有任何關係、只是手上有一條引用的人。點擊 goo.gl 短網址的讀者、嵌入 polyfill.io 的網站、相依某個 npm 套件的下游專案都是。提供者手上沒有他們的名單，能觸及他們的只有引用被使用的那一刻（中間頁、回應裡的訊息、套件登錄服務的棄用警告），以及登錄服務、CDN 業者這類中介者。

三類的比例決定退場能做到什麼程度。直接客戶佔多數時，公告、匯出與遷移工具能解決大部分問題；第三方持有者佔多數時，提供者能直接用上的主要是引用被使用的那一刻：goo.gl 在 2024 年 8 月起對部分連結先顯示一頁中間頁，告知連結即將停止運作（Google, 2024）；對聯絡不到的第三方持有者來說，點擊短網址、經過中間頁的那一刻，是提供者自己唯一碰得到他們的位置。

API 的消費者還有另外兩種切法：API Consumer Shape 依「會不會回報、改不改得動」分，其中「聯絡不到的外部整合方」大致對應這裡的第三方持有者；Consumer Coordinability 問的「列得出名單、發得出通知」，就是這裡「聯絡得到的程度」。

外部引用在服務結束後的兩種結局：失效與易手

引用也可以在服務結束後繼續運作：提供者以靜態封存維持（10.7 分階段退場：停止新建、唯讀、靜態封存、關閉與公告期），或由接手者承接（10.8 移交：資料匯出、開源與交給社群或封存機構）。沒有人繼續維持時，一條外部引用會走到兩種結局之一，兩者的差別在持有者拿不拿得到失敗的訊號：

• 失效：引用指向的服務或資源不再回應，或回應錯誤（網址失效的情形，英文常稱 link rot）。短網址回 404、API 主機連不上、智慧家庭集線器無法運作。持有者至少拿得到一個失敗的訊號。Nest 在 2016 年關閉 Revolv 集線器的雲端服務時，公告寫的是「The Revolv app won’t open and the hub won’t work」（Revolv 官網，Wayback 2016-02-27）。
• 易手：引用指向的網域、名稱或帳號換了主人，引用照常運作，回應的內容卻由新主人決定。持有者拿到的是一個看起來成功的回應，沒有任何訊號。polyfill.io 的網域與 GitHub 帳號在 2024 年 2 月轉給新的經營者，同年 6 月 Sansec 公布這個網域對行動裝置注入惡意程式碼。網域易手時，沒有任何機制直接通知嵌入它的網站，警告只出現在原作者與 Cloudflare、Fastly 的公開文章裡（Sansec, 2024）。PyPI 的 ctx 套件在 2022 年 5 月被接管，成因是擁有者帳號的信箱網域過期，被別人重新註冊之後用來重設密碼（PyPI 事件報告）。

易手的危險在新主人是誰、會做什麼，持有者事先都不知道：持有者原本信任的是提供者，網域到期被陌生人註冊、或在沒有任何公告的情況下賣出之後，回應請求的是持有者沒有選擇過的新主人，而持有者從回應上看不出差別。所以在沒有接手者、也不維持靜態封存的情況下，續約網域但不回應任何內容（讓引用失效），比出售網域或放任它到期更負責任。易手的結果由新主人決定：Insteon 的伺服器在 2022 年 4 月沒有預告就停止，資產在清算中被一群使用者買下，服務因此恢復，但這個結果沒有任何安排保證。事先公告接手者、在條款裡寫明延續範圍的做法稱為公開移交，條件見 10.8 移交：資料匯出、開源與交給社群或封存機構 的〈交給接手的社群或公司〉。網域與名稱的處置見 10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS。

盤點每一種外部引用的欄位

一種外部引用在服務結束時的下場，由下列幾項性質決定；盤點就是對每一種引用記下這幾項：

• 存放位置：引用寫在哪裡（文件、別人的程式、韌體、DNS 紀錄、相依性設定檔）。
• 持有者的類別：直接客戶、間接使用者還是第三方持有者，以及各佔多少，比較的單位是請求量：請求帶的存取憑證先分出帶直接客戶憑證的請求與沒有憑證的請求（後者多半來自第三方持有者）；帶直接客戶憑證的請求，再用客戶端類型或 User-Agent 分出直接客戶自己的後端與間接使用者的裝置（識別符的分層見 11.12 API 消費者用量觀測：契約決策要的觀測維度、消費者身分的識別、欄位級用量與全量或抽樣的成本邊界）；客戶端版本的分布則顯示舊版還有多少。
• 持有者能不能自己改：能改的，退場的工作是通知與提供替代；不能改的（印刷品、韌體），只能讓引用本身繼續運作或明確失效。
• 還有沒有人在用：服務有沒有使用紀錄可以回答這個問題。goo.gl 在 2025 年修正停用計畫時，改成只停用「2024 年底沒有活動」的連結，其餘保留，依據的就是點擊紀錄（Google, 2025）；npm 判斷一個套件能不能下架時，看的是登錄服務記錄的相依關係與下載數（npm unpublish 政策）。沒有使用紀錄的服務，結束時分不出哪些引用還活著。
• 失效與易手各會造成什麼：持有者拿到錯誤時會發生什麼，引用換了主人時會發生什麼。
• 讓引用繼續運作所需的資料與格式：對照表、套件檔案、設定這類資料，有沒有一份別人讀得懂的匯出格式（見 10.5 退場能力的設計前置：端點間接層、本地運作模式與引用的命名空間 的〈使用紀錄與可交出的資料格式〉）。
• 結束時一定會失去的部分：提供者靠著自己與第三方的契約或授權才提供得了、因此無法交給別人的功能（見 10.5 退場能力的設計前置：端點間接層、本地運作模式與引用的命名空間 的〈依賴第三方契約與授權而無法移交的部分〉）。

到宣布結束時多半已經來不及改的是存放位置（取決於端點間接層與命名空間的選擇）、持有者能不能自己改、還有沒有人在用的紀錄（持有者類別的推估也靠它，要在服務運作期間累積）、讓引用繼續運作所需的資料格式，以及結束時一定會失去的部分，這些是 10.5 退場能力的設計前置：端點間接層、本地運作模式與引用的命名空間 要在上線時處理的；客戶端還收得到更新時，端點間接層與本地運作模式仍可補上，條件寫在 10.5〈客戶端讀取服務位置的端點間接層〉。持有者類別與失效、易手的後果是盤點時記下的事實；結束時還能改變的是引用的去向，見 10.7 分階段退場：停止新建、唯讀、靜態封存、關閉與公告期 與 10.8 移交：資料匯出、開源與交給社群或封存機構。

短網址服務的外部引用

本篇的分類在短網址服務裡全部出現：短網址本身是網址，持有者幾乎全是第三方持有者（0.23 短網址服務的需求定義：自建或購買、保存期限、目的地修改與濫用處理的規格 的〈連結的保存期限與保存承諾〉），服務網域是所有引用共用的命名空間，對照表是讓引用繼續運作所需的全部資料。短網址服務的價值全部在外部引用上，而那些引用的持有者幾乎都聯絡不到。誰在出資維持轉址、出資方式怎麼影響連結的存續，見 短網址的商業模型：訂閱、自架、平台內建與廣告插頁各由誰出資維持轉址。

客戶端讀取服務位置的端點間接層

端點間接層（英文常見的說法是 bootstrap config）指客戶端（行動 app、裝置韌體、SDK）不直接寫死它要連線的伺服器位置，而是先讀一份設定，再依設定連線；完整的間接層還要讓這份設定本身的來源可以由提供者以外的人（使用者或接手者）改寫，下面 Pebble 的案例說明為什麼兩件都要做。有沒有這一層，決定服務結束時能不能讓已經發出去的客戶端改連到別的伺服器。

Parse 與 Pebble 兩個案例的差別，在改寫連線位置要不要經過發布新版 app。Parse 在 2016 年 1 月宣布關閉時，同一天釋出開源的 Parse Server，並寫道「Our client SDKs now support changing the API server location to direct them to your own」（Parse, 2016）。要讓已經安裝在使用者手機上的 app 改連自架的伺服器，開發者得發布帶新設定的 app 版本，使用者得更新；遷移指南直接說發布新版、讓客戶端改連自架伺服器這一階段「is non-trivial, and will require dedicated development time」（Parse 遷移指南，Wayback 2016-12）。

Pebble 的手機 app 讀取的是一份服務設定（boot config），裡面列出各項雲端服務的位置。2017 年 4 月的更新開放使用者用一個連結改寫這份設定的來源：「The link pebble://custom-boot-config-url/CUSTOM_URL forces the Pebble mobile app to load its service configuration from the specified CUSTOM_URL」（Pebble 開發者部落格, 2017）。2018 年 Fitbit 停止 Pebble 的雲端服務時，社群專案 Rebble 接手，切換方式是讓使用者在手機上點一個連結（Rebble 的公告沒有寫出背後用的是哪個機制，推測就是這個改寫設定來源的連結），「you have nothing to download or install」（Rebble, 2018）。Pebble 2017 年的公告只寫了使用者可以改寫設定的來源；手機 app 讀取服務設定這一層是不是從 Pebble 手錶上市時就存在，公告沒有交代。這個案例也說明，改寫設定來源的能力可以晚於上線補上，條件是補上它的那一版客戶端，要在提供者的發布管道與更新伺服器還在運作時送到足夠多的裝置上；Pebble 的這次更新比雲端關閉早了一年多。沒有更新管道、或更新管道已經停止的客戶端（不支援線上更新的韌體、停止發版的 app）沒有這條路；支援線上更新（OTA）的韌體和 app 適用同一個條件。寫死在客戶端的主機名稱本身也是一層間接：網域移交出去，接手者就能把它指到新的伺服器。客戶端信任公開的憑證機構時，接手者用網域就能重新申請數位憑證；只有客戶端釘選了數位憑證或自帶信任錨點時，才需要提供者交出金鑰或換錨點的路徑。

所以設計上要預留的是兩件事（寫死的主機名稱落在可以移交的網域上，是兩件都沒有時的後備）：客戶端連線的位置來自一份可以更新的設定，而不是編譯進程式的常數；以及這份設定的來源，在提供者不再運作時有辦法被指到接手者的伺服器。只做到「設定可以更新」這一件，存放設定的伺服器本身仍是提供者的服務，它關閉時客戶端就停在最後一份設定上。另外還有客戶端信任的對象要預留：客戶端若只接受提供者數位憑證的連線、或只安裝提供者金鑰簽章的韌體與設定，接手者即使改寫了設定來源，也要拿到這些金鑰，或有一條換掉信任錨點的路徑，才連得上、推得出更新。

雲端關閉後的裝置功能：本地運作模式

本地運作模式（英文多稱 local control 或 offline mode）指裝置在連不上提供者的雲端服務時，仍能完成它被買來做的那件事，例如開關燈、感測器觸發其他裝置。對賣出去的硬體來說，有沒有這個模式決定雲端關閉時裝置是少了一些功能，還是整台失效（英文報導多稱為 bricking）。它和雲端架構裡的 Static Stability 是同一個想法：控制面失效時，資料面照最後的狀態繼續運作。

Insteon 與 Revolv 分別是有本地模式與沒有本地模式的結局。Insteon 的開關、插座與感測器之間用本地的專有無線協定連動。2022 年 4 月經營公司停止營運、伺服器關閉時，「All of those stayed operational, but users couldn’t remotely access their hub through the app or program the hub」（Stacey on IoT, 2022）：失去的是 app 遠端控制與雲端整合，家裡的燈照樣開關。Revolv 的集線器沒有本地模式，Nest 在 2016 年關閉它的雲端服務時，集線器整台無法運作，Nest 能給的補救只剩退款，而退款是公告一個多月後才加上的（見 10.7 分階段退場：停止新建、唯讀、靜態封存、關閉與公告期 的〈賣出去的裝置的補償〉）。美國聯邦貿易委員會（FTC）調查 Revolv 的關閉後寫道，擔心的是「reasonable consumers would not expect the Revolv hubs to become unusable」（FTC 結案信, 2016）。

本地模式也能在結束前補上，但要提前很久做。Fitbit 在 2016 年 12 月接手 Pebble 之後，第一步是更新手機 app，「loosening their dependency on a patchwork of cloud services」（Pebble 開發者部落格, 2016）：2017 年 4 月的版本在連不上認證與更新伺服器時仍可使用，並加入離線模式（Pebble 開發者部落格, 2017）。這次 app 更新比 2018 年 6 月雲端關閉早了一年多。Spotify 的車用控制器 Car Thing 則沒有本地模式，2024 年停止支援時，支援頁建議使用者回復原廠設定，並依電子廢棄物規定處理裝置（Spotify 支援頁，Wayback 2024-05-23）。

設計時要分清楚哪些功能本質上需要雲端（跨裝置同步、遠端存取、第三方整合），哪些只是實作時方便放在雲端（排程、裝置之間的連動、本機設定）。後一類功能在上線時就放在本地執行，雲端關閉時裝置保留它被買來做的那些事。

外部引用所屬的命名空間：提供者網域、客戶網域與共用登錄服務

命名空間在這裡指分配名稱、並決定名稱指向哪裡的那一層。外部引用的網址、主機名稱或名稱都屬於某個命名空間：提供者的網域、客戶自己的網域、或某個共用的登錄服務。服務結束時，引用能不能被保住，取決於誰還控制那個命名空間。

落在提供者網域下的引用，提供者停止續約或出售網域，引用就跟著失效或易手。Firebase Dynamic Links 在 2025 年關閉時，常見問答回答使用者能不能保留或轉移 page.link 網域：「No, once the Firebase Dynamic Links service is shut down any .page.link domains will no longer be available」（Firebase 常見問答）。Firebase Dynamic Links 也讓客戶改用自己的網域；用自己網域的客戶，服務關閉後還能把網域指到別的轉址服務。短網址服務提供自訂網域的理由之一就在這裡，見 0.23 短網址服務的需求定義：自建或購買、保存期限、目的地修改與濫用處理的規格 的〈自訂網域與網域名聲的隔離〉；客戶網域讓連結能搬到別的服務，這件事的商業分析，見 短網址的商業模型：訂閱、自架、平台內建與廣告插頁各由誰出資維持轉址 的〈網域：品牌短網址的定價與切換成本〉。

落在共用命名空間的名稱，要看名稱釋出之後能不能被別人申請。Azure App Service 舊的預設主機名 <應用程式名稱>.azurewebsites.net，Microsoft 自己的文件形容為「globally predictable」；新的主機名加上一段隨機雜湊，外人無法重建同名的主機，而同一份文件寫明這種雜湊主機名「You can’t apply them to existing resources retroactively」（Microsoft Learn）。名稱可預測的風險在於：客戶網域裡指向這個主機名的 CNAME，若在資源刪除後沒有一起刪掉，別人重新申請同名的主機，就會接收客戶那個子網域的流量，稱為懸空 DNS 與子網域接管。雜湊主機名這項補救只涵蓋之後新建的資源；名稱已經以可預測的方式發出去的既有資源，要靠網域驗證或偵測懸空 DNS 紀錄這類另外的手段。名稱的保留與回收、子網域接管的細節見 10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS。

被嵌入的程式碼另有一層提供者做得到的設計：發布帶版本號、內容固定的網址，嵌入者就能加上子資源完整性（Subresource Integrity，SRI）雜湊。跨來源載入的腳本要比對雜湊，提供者的回應還要帶 CORS 標頭（Access-Control-Allow-Origin），嵌入者在 <script> 加上 crossorigin 屬性。網域易手、內容被換掉之後，瀏覽器比對雜湊不符會拒絕載入，引用的結局從易手變成失效。

使用紀錄與可交出的資料格式

服務結束時有兩個問題要靠上線時就存在的資料回答：哪些外部引用還有人在用，以及讓引用繼續運作需要哪些資料、能用什麼格式交出去。

使用紀錄回答哪些外部引用還有人在用。記錄的單位與做法（最後使用時間表、消費者身分與客戶端版本的識別）見 11.12 API 消費者用量觀測：契約決策要的觀測維度、消費者身分的識別、欄位級用量與全量或抽樣的成本邊界；客戶端版本與存取憑證是事後推估持有者類別、決定公告期的依據，所以和最後使用時間一起記。goo.gl 在 2024 年宣布所有連結將回 404，理由之一是「more than 99% of them had no activity in the last month」；2025 年修正為只停用 2024 年底沒有活動的連結（Google, 2024；Google, 2025）。兩個決定都建立在點擊紀錄上；沒有點擊紀錄，提供者只能在「全部保留」與「全部停用」之間選。紀錄要保存到什麼粒度，同時受隱私要求限制：只需要知道「這條引用最近有沒有被使用」時，保存彙總後的最後使用時間就夠了。

可交出的資料格式回答讓引用繼續運作所需的資料能不能交出去。讓外部引用繼續運作所需的資料（短網址的對照表、套件的檔案與中繼資料、專案的原始碼與 issue）要能匯出成別人讀得懂的格式。2009 年由短網址業者組成、Internet Archive 管理的封存計畫 301Works，參與條款寫明對照表的格式是以 tab 分隔的長網址、短網址與選填的點擊數（301Works 參與條款，Wayback 2009）；Microsoft 在 2017 年關閉 CodePlex 時，提供 Markdown 與 JSON 格式的專案封存檔（Microsoft, 2017）。客戶自己使用者的聯絡資料也在要能匯出的範圍裡：提供者聯絡不到間接使用者，只能靠客戶轉達，客戶手上有沒有這份名單，決定轉達做不做得到（見 10.7 分階段退場：停止新建、唯讀、靜態封存、關閉與公告期 的〈公告期的長度與通知管道〉）。格式在上線時就定下來，結束時只要執行匯出；結束時才設計格式，就要在最缺人力的時候設計並實作一套新的匯出格式。交給誰、交出去之後怎麼用，見 10.8 移交：資料匯出、開源與交給社群或封存機構。

依賴第三方契約與授權而無法移交的部分

有些功能在服務結束時無法交給別人，原因在它們依賴提供者和第三方之間的契約或授權，缺的並不是資料或程式碼。這些功能能不能移交，在提供者選用那個第三方服務、簽下契約的時候就決定了。

Rebble 接手 Pebble 的雲端服務時，有兩項功能接不走。一是時間軸的即時推送：「for technical reasons it is impossible for any entity other than Fitbit to provide that service」。二是 iOS 上回覆簡訊的功能：「Pebble had agreements in place with several carriers and service providers in order to provide the ability to reply to text messages on iOS」（Rebble, 2018）。程式碼也有同樣的限制：Google 在 2025 年釋出 PebbleOS 原始碼時，移除了部分專有程式碼，主要是晶片支援與藍牙堆疊，所以釋出的版本「will not compile or link as released」（Google Open Source Blog, 2025）。

條款不允許移交的功能，屬於 10.4 服務終止的範圍：外部引用的種類與持有者 盤點清單裡「結束時一定會失去的部分」那一項，它們在結束時的處置見 10.8 移交：資料匯出、開源與交給社群或封存機構 的〈交不出去的功能與引用：第三方契約、授權限制與提供者網域〉。

租戶的可遷出保險清單與提供者的退場設計

0.21 交付形態選型：從全託管到自建的光譜與邊界 列了一份「可遷出保險清單」，給租戶（在別人的平台上經營服務的一方）用。清單裡的自有網域、資料定期匯出、客戶聯絡管道自有三項，是租戶在採用別人的平台時替自己買的保險。這篇的設計是同一份保險從提供者這一側看：讓客戶能用自己的網域、讓資料能匯出、讓客戶能匯出自己使用者的聯絡資料，分別對應清單的三項；讓客戶端的連線位置能被改寫，則是租戶清單沒有、只有提供者做得到的一項。提供者在上線時做了這些，等於替所有持有外部引用的人買了同一份保險，包括那些不在合約裡、也不會替自己買保險的第三方持有者。清單另外三項的提供者側各不相同：金流可攜靠的是讓扣款授權綁在客戶自己名下的金流帳戶，或配合金流商之間的卡號資料轉移，授權本身不在提供者的匯出檔裡；密碼不可攜的預案是讓密碼雜湊連同演算法、參數與 pepper（如果有）一起匯出；業務邏輯文件化對應的是讓設定與規則能匯出。租戶側的處理見 10.3 託管形態遷出：資產線盤點與並行期執行 的〈身分線〉與〈整合線〉；這些都是 Vendor Lock-in 在提供者這一側的解法。

網域在服務結束後的去向：續約並回應、續約不回應、到期、出售

服務停止營運之後，它的網域有下列幾種去向，差別在引用會繼續運作、失效還是易手：

• 繼續續約、維持轉址或靜態內容：引用繼續運作。成本只剩網域續約與一個能回應請求的最小服務，做法見 10.7 分階段退場：停止新建、唯讀、靜態封存、關閉與公告期。
• 繼續續約、但不回應任何內容：引用失效，但不會易手。在不讓網域落到別人手上的做法裡，這是成本最低的一種。
• 讓網域到期：網域釋出之後任何人都能註冊，引用可能易手。
• 出售或轉讓：引用確定易手。沒有任何公告的出售，新主人可以照常提供服務，也可以不；公開移交（事先公告接手者、在條款裡寫明延續範圍，條件見 10.8 移交：資料匯出、開源與交給社群或封存機構 的〈交給接手的社群或公司〉）讓持有者事先知道新主人是誰，但條款本身沒有被執行的機制。

讓網域到期與沒有公告的出售，對持有者的後果相同：持有者手上的引用照常運作，回應的內容卻由持有者不知道的新主人決定。所以網域的去向要在退場計畫裡明寫，而不是留給公司解散時的資產處分程序決定。短網址服務的需求定義也把網域的去向列進保存承諾：服務結束營運時，「網域在停止營運後由誰續約」是保存承諾的一部分（0.23 短網址服務的需求定義：自建或購買、保存期限、目的地修改與濫用處理的規格 的〈連結的保存期限與保存承諾〉）。

「續約但不回應」要在網域的每一層都做到不回應。網域沒有設定內容時，有些註冊商會預設掛上停放頁並放廣告，回應的內容就變成註冊商決定的，所以要到註冊商的網域設定裡確認停放功能是關的。網域上原本收信的 MX 紀錄也要決定去向：移除它讓寄往舊信箱的信退回，或保留一個有人看管的信箱，讓重設密碼信與客戶的支援信都有人處理。指向雲端 IP 的 A／AAAA 紀錄與萬用字元紀錄也要刪除，雲端業者把那個 IP 分給別人之後，紀錄就會懸空。網域不再寄信時，可以發布表明這個網域不寄信的 SPF 與 DMARC 紀錄，讓別人冒用網域寄出的信被收件端拒收。

續約要持續多久，要分兩種網域判斷。曾經被當成帳號信箱使用的網域，放手的條件是綁在這個網域上的帳號全部改綁到別的信箱，這要另外盤點，和流量無關：本篇〈綁在可過期網域上的帳號身分〉一節的 ctx 事件，被重新註冊的就是一個閒置的網域。其他網域看還有沒有引用在被使用：網域釋出之後，註冊它的人能接收所有仍在發出的請求，所以放手的風險隨著請求量與被嵌入的程度上升。判斷請求量需要一份紀錄。掃描器與爬蟲的請求要從請求本身（User-Agent、請求的路徑）排除，這只有 HTTP 存取紀錄做得到，所以判斷要在還保有存取紀錄的靜態封存階段做（見 10.7 分階段退場：停止新建、唯讀、靜態封存、關閉與公告期）；關閉之後只剩自己名稱伺服器的查詢紀錄，它看到的是解析器而不是發出請求的人，分不出掃描器，解析器的快取又讓數字偏低，只能當趨勢參考，不能用來判定歸零。沒有這份紀錄、或請求一直沒有歸零時，續約是一筆沒有終點的固定成本，要在退場計畫裡當成長期支出編列；多數註冊商允許一次續約多年，可以在公司還有資金時先付清，並寫明之後由誰接著付。

網域的出售：polyfill.io 的經過

polyfill.io 是一個公共 CDN 腳本，網站以 <script> 嵌入它，讓舊瀏覽器補上新的 JavaScript 功能。它的經過有完整的公開時間線：

• 2024 年 2 月，網域與 GitHub 帳號轉給新的經營者（Sansec, 2024），Cloudflare 的文章寫明新經營者是 Funnull。Cloudflare 隨即在 cdnjs 推出鏡像，理由是「any website embedding a link to the original polyfill.io domain, will now be relying on Funnull to maintain and secure the underlying project」（Cloudflare, 2024-02）；Fastly 也提供了替代網址（Fastly 社群, 2024）。
• 2024 年 6 月 25 日，Sansec 公布這個網域自易手之後就對行動裝置注入惡意程式碼、把訪客導向博弈網站，受影響的網站超過十萬個（Sansec, 2024）。
• 隔天 Cloudflare 對免費方案的網站預設把 polyfill.io 的連結改寫到自己的鏡像，並說明刻意不直接封鎖這個網域，因為「it could cause widespread web outages given how broadly polyfill.io is used with some estimates indicating usage on nearly 4% of all websites」（Cloudflare, 2024-06）。
• 2025 年 5 月，美國財政部制裁 Funnull，新聞稿寫它在 2024 年購入一個開發者使用的程式碼庫並惡意修改（未點名 polyfill）（美國財政部, 2025）。

整個過程裡，沒有任何機制直接通知嵌入這個腳本的網站：警告只出現在原作者與 Cloudflare、Fastly 的公開文章裡，看到文章的網站才會換掉；保護其餘網站的是 CDN 業者與資安研究者的介入，網域的處置本身沒有任何安排。被大量嵌入的引用，網域的處置等於在決定所有嵌入者的安全；出售這個網域，就是把所有嵌入者交給買方；這是軟體供應鏈攻擊的一條路徑，建置與發布端的供應鏈信任見 7.12 供應鏈完整性與 Artifact 信任。嵌入者這一側的防護（內容安全政策與第三方腳本的監控）見 Cloudflare Page Shield：用 CSP + SRI + script monitoring 防 client-side supply chain。

交給中立方的技術控制

讓網域繼續運作、又不由自己維運的做法，是把網域的技術控制交給一個中立的一方：由對方設定 DNS 與回應內容，所有權仍留在原處。2009 年由短網址業者組成、Internet Archive 管理的封存計畫 301Works，參與條款就是這樣設計的：參與的短網址業者關站時，「technical control of the shortening service domain will be transferred to 301Works.org in order to continue redirecting existing shortened URLs」，並註明「This does not mean that the company will transfer ownership of the domain in such a case」（Internet Archive, 2009；301Works 參與條款）。

技術控制的移交要在服務還活著時簽好，結束時才去找，通常已經來不及。tr.im 在 2009 年宣布關站、隨即撤回並改說要開源交給社群時，承諾把網域捐給一個代為持有的第三方：「donate the tr.im domain name to a 3rd party that will hold it in trust」（tr.im, 2009），但可查到的網頁快照顯示，2012 年網域只剩空白的目錄列表，2013 年起由新的經營者重新上線，沒有找到網域交給代持第三方的公告。承諾本身沒有被執行的機制。條款裡要寫明的還有續約費由誰付，以及網域所有權轉手時（例如公司解散、資產出售）技術控制是否延續。

名稱的保留與回收：套件名稱、雲端資源名稱與短碼

共用登錄服務裡的名稱（套件名稱、雲端資源名稱、使用者名稱）被刪除之後能不能被別人重新申請，決定了引用這個名稱的人會不會在不知情的情況下拿到別人發布的內容。

npm 的 left-pad 事件展示了名稱被回收時發生的事。2016 年 3 月 22 日，一位作者下架了自己的 273 個套件，其中 left-pad 被大量專案間接依賴，建置隨即失敗。有人在十分鐘內以同一個名稱重新發布了功能相同的套件，npm 說明當時的規則：「we allow anyone to use an abandoned package name as long as they don’t use the same version numbers」；被下架的其他名稱則由社群搶先發布佔位套件，「to prevent malicious publishing of modules under their names」（npm, 2016）。一週後 npm 修改政策：全部版本被移除的套件，以安全佔位套件取代，讓名稱不會被惡意搶註（npm, 2016）；現行政策延續了同一個名稱的同一個版本號不能再使用的規定，並把下架限縮在發布 72 小時內且沒有其他套件相依，或沒有其他套件相依、上週下載少於 300 次、只有單一維護者的套件，其餘只能標記為棄用；全部版本下架之後，文件只寫 24 小時內不能再發布新版本，沒有寫名稱會不會被佔位（npm unpublish 政策）。版本號不重用保護的是 lockfile：lockfile 記下確切版本與內容雜湊，在重新產生 lockfile 之前，安裝拿到的不會是別人發布的內容；重新解析版本範圍時，才可能拿到新主人發布的新版本。

雲端服務對資源名稱有類似的保留：Azure 的經典雲端服務（classic cloud service，*.cloudapp.net）刪除後，對應的 DNS 名稱在保留期內只允許原本租用戶的訂閱重新使用，保留期過後任何訂閱都能申請（Microsoft Learn）；App Service 刪除後同樣只讓原本的租用戶重新使用這個名稱，保留多久文件沒有寫明（Microsoft Learn）。短網址服務的短碼也是發出去之後會被引用、刪除後可能被重新申請的名稱，0.23 短網址服務的需求定義：自建或購買、保存期限、目的地修改與濫用處理的規格 寫過回收的短碼不能再發給新的連結，要留一筆紀錄佔住；這筆紀錄不設清除期限，否則名稱到期後又回到可申請的池子。

npm 2016 年的規則與短碼的佔位紀錄，共同做法是佔位：名稱不再使用時，留一筆沒有期限的紀錄讓它不能被重新申請，而不是把它放回可申請的池子。npm 的佔位名稱仍可由其他人向 npm 申請、經人工審核後轉給對方。Azure 的保留期是對照：它讓原租用戶有時間清理，期限一到名稱就回到可申請的池子。佔位的成本是一筆紀錄，放回池子的代價，是所有還持有這個名稱的引用都可能易手。佔位紀錄只需要名稱、狀態與刪除時間，不需要保留原擁有者的個人資料，所以它和刪除個人資料的要求可以並存。

懸空 DNS 與子網域接管

懸空 DNS（dangling DNS）指一筆 DNS 紀錄還指向一個已經刪除的雲端資源。客戶在自己的網域設定一筆 CNAME，指向雲端服務給的主機名稱；資源刪除之後，這筆紀錄如果沒有一起刪除，而那個主機名稱又被別人重新申請，客戶的子網域就由別人提供內容，稱為子網域接管（subdomain takeover）。Microsoft 的文件寫明接管者能做的事不只放一個假網頁：「a threat actor can use the hijacked subdomain to apply for and receive a valid SSL certificate」（Microsoft Learn）。

同一種成因也出現在 A 紀錄上：紀錄指向雲端主機的公開 IP，主機終止（有些業者是停止）時業者收回這個 IP、再分配給別的客戶，拿到它的人就收得到這個網域的流量，也能用 HTTP 驗證替它申請憑證；哪些暫停與重建的做法會把 IP 還給業者，見 服務暫停與恢復上線：只停服務、停止主機、終止主機到全部刪除各自保留的資源，暫停期間仍計費與仍被指向的資源，恢復前要查的漂移與恢復的順序〈暫停期間仍指向這台主機的外部設定〉。客戶這一側的防護是刪除雲端資源（或釋放 IP）之前先刪掉指向它的 DNS 紀錄，並定期拿自家網域裡指向雲端主機名的 CNAME 與指向雲端 IP 的 A 紀錄對照仍存在的資源；本節展開的是提供者這一側。防止子網域接管的工作橫跨客戶與提供者兩方：DNS 紀錄在客戶的網域裡，提供者無法替客戶刪除；主機名稱在提供者的命名空間裡，能不能被別人重新申請由提供者決定。提供者這一側能做的有下列幾件：

• 刪除後保留名稱一段時間，只給原本的租用戶重新使用（〈名稱的保留與回收：套件名稱、雲端資源名稱與短碼〉一節的 Azure 規則）。
• 要求驗證網域的所有權：GitHub Pages 讓帳號驗證自己的網域，驗證之後只有這個帳號能把網站發布到這個網域，並列出接管發生的情形：「when you delete your repository, when your billing plan is downgraded, or after any other change which unlinks the custom domain or disables GitHub Pages while the domain remains configured for GitHub Pages and is not verified」（GitHub Docs）。
• 讓預設主機名稱無法被預測：見 10.5 退場能力的設計前置：端點間接層、本地運作模式與引用的命名空間 的〈外部引用所屬的命名空間：提供者網域、客戶網域與共用登錄服務〉裡 Azure 的雜湊主機名稱。

服務本身結束時，保留名稱、驗證網域與不可預測的主機名稱這幾項做法要延續下去：提供者自己的網域裡，所有曾經發給客戶的子網域（例如 <app>.herokuapp.com 這一類）都不能放回可申請的池子。Heroku 在 2022 年終止免費方案時，把免費的 app 縮到零個執行個體，而不是刪除 app：程式、設定與名稱都保留，只是不再有執行中的程序（Heroku FAQ，Wayback 2022-08-25）。同一次處置從 2022 年 10 月起刪除閒置一年以上的帳號（Heroku, 2022）；刪除帳號這一條路，正是曾經發給客戶的子網域名稱可能回到可申請池子的地方。

綁在可過期網域上的帳號身分

10.4 服務終止的範圍：外部引用的種類與持有者 列的外部引用裡，綁在網域上的身分是最不顯眼的一種：套件登錄服務用維護者的信箱寄送重設密碼的信，而信箱屬於維護者自己的網域。網域過期、被別人註冊之後，新主人能收到重設密碼的信，接管維護者的帳號與帳號下的所有套件。

2022 年 5 月 14 日，PyPI 套件 ctx 擁有者帳號的信箱網域被重新註冊，事件報告記錄網域註冊後十二分鐘，密碼重設與惡意版本的上傳就開始了（PyPI 事件報告）。同一時期的研究在 npm 找到 2,818 個維護者信箱屬於已過期的網域，可以藉此接管 8,494 個套件（Zahan 等, 2022）。PyPI 自 2025 年起定期檢查信箱網域的狀態，網域進入過期階段時取消該信箱的驗證（PyPI 稱這類事件為 domain resurrection），到 2025 年 8 月已取消 1,800 個以上（PyPI, 2025）。

綁在網域上的帳號身分對服務終止有兩層意義。第一層在提供者自己：提供者的網域到期、被別人註冊之後，新主人收得到寄往這個網域的所有信，包括提供者自己在其他服務上的帳號的重設密碼信，因而能接管那些帳號，也收得到客戶寄來的支援信。行銷追蹤後台是這一層常見的例子：Meta 商家資產管理組合與 GTM、GA4 帳戶的成員是個人帳號，用公司網域信箱註冊的 Facebook 帳號、或用公司網域信箱建立的 Google 帳號（不由 Google Workspace 管理的那一種），重設密碼信都寄往這個網域，帳號沒有另外綁定兩步驟驗證或其他復原方式時，取得網域的新主人藉重設密碼就能接管這些帳號，連同它們在組合與帳戶裡的管理權（由重設密碼的機制推出）；成員的組成與移交方式見追蹤資產的歸屬。第二層在登錄服務：它在這一種引用裡是持有者，同時經營自己的帳號系統，要把「維護者信箱的網域是否仍有效」當成帳號安全的一部分持續檢查，而不是只在註冊時驗證一次。

退場階段：停止新建、唯讀、靜態封存與關閉

Google 在 2015 年 3 月宣布關閉程式碼託管服務 Google Code 時，公告列出三個日期（Google Open Source Blog, 2015）：當天停止建立新專案；2015 年 8 月 24 日起網站變成唯讀，「You can still checkout/view project source, issues, and wikis」；2016 年 1 月 25 日關閉託管服務，改提供原始碼、issue 與 wiki 的封存檔下載，承諾提供到 2016 年底。Microsoft 在 2017 年 3 月宣布關閉 CodePlex 時走了同樣的順序：當天停止建立新專案，10 月唯讀，12 月 15 日改成唯讀的輕量封存（Microsoft, 2017）。

這兩個案例共用的順序可以一般化成下列階段，每一個階段比前一個保留的少、成本也低，也讓還能自己行動的持有者在下一階段開始前先離開：

靜態封存保得住的是只需讀取、不需認證、回應不隨請求內容變化的引用：網址的轉址、被嵌入的固定版本腳本、套件的檔案都屬於這一類；需要寫入或認證的端點，以及依請求動態產生回應的服務，到這一階段就失效，要延續它們得靠 10.8 移交：資料匯出、開源與交給社群或封存機構 的接手。

關閉之後若不再續約或出售網域，引用會從失效變成易手（網域換了主人，引用回應的是新主人的內容），各種去向的比較見 10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS 的〈網域在服務結束後的去向：續約並回應、續約不回應、到期、出售〉。

停止新建這一階段本身省不下成本，但它是後面每一階段的前提：外部引用還在增加時，任何保留範圍的估算都會過時。API 版本淘汰也是先停止新的使用、再處理既有使用者，見 11.5 版本策略與 deprecation 的〈Deprecation 的執行工具箱〉。

靜態封存是讓第三方持有者的引用繼續運作的最低成本做法。短網址服務把對照表匯出成靜態的轉址規則，放在物件儲存或 CDN 上（做法見 0.24 短網址服務的實作：短碼生成、對照表儲存、轉址快取與點擊紀錄 的〈服務結束時的轉址延續〉）；程式碼託管服務把每個專案頁面輸出成靜態 HTML。CodePlex 的公告另外寫了兩件為持有舊網址的人做的事：「Where possible, we’ll put in place redirects so that existing URLs work, or at least redirect you to the project’s new homepage on the archive」，以及封存會沿用專案擁有者設定的「I’ve moved」指向，把訪客帶到專案的新家（Microsoft, 2017）。轉址與沿用「I’ve moved」指向，是 CodePlex 為第三方持有者做的安排：他們手上只有舊網址，轉址讓那些網址繼續有用。靜態封存期間仍要保留下架單一引用的管道：已經轉址到惡意目的地的連結，以及目的地網域到期後被別人註冊的連結，在封存之後照樣把人送過去，要能單筆改寫成說明頁或回 404。

退到靜態檔之後，應用程式的紀錄跟著消失，還量得到的是 CDN 或物件儲存的存取紀錄；關閉之後只剩自己名稱伺服器的查詢紀錄。封存後還要判斷保留範圍的話，這些紀錄要在封存前先開啟。單筆下架能不能到達已經點過連結的瀏覽器，取決於轉址回應帶的快取標頭，見 12.8 快取設定的應用：轉址、需登入的 API 回應與個人化頁面。

靜態封存的成本低，但不是零：網域要續約、有人要決定它保留多久。到 2026 年 10 月，Google Code 的封存頁面仍可存取，遠超過承諾的 2016 年底；CodePlex 的公告寫過「There isn’t currently any plan to have an end date for the archive」，封存網址現在卻已經轉到 Microsoft 的首頁，Microsoft 何時撤掉封存網站，沒有公告。到了靜態封存與關閉階段，團隊多半已經解散，而網域、TLS 憑證、雲端帳單與註冊商帳號都還有到期日；每一項都要在解散前寫明保管人與付款來源，否則它們會像 10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS 裡那些過期的信箱網域一樣，在沒人注意時到期。

依使用紀錄決定保留範圍

不是每一條外部引用都要保留到同一個階段（例如全部保留到靜態封存）。有使用紀錄的服務，可以依「最近還有沒有人用」把引用分開處理。

goo.gl 的三次公告是這個做法的完整過程。2018 年 3 月 Google 宣布分階段停止建立新的短網址：2018 年 4 月起新使用者不能建立，2019 年 3 月起全面停止，並承諾既有連結繼續轉址（Google, 2018）；2024 年 7 月宣布 2025 年 8 月 25 日起所有連結回 404，理由是超過 99% 的連結在宣布前一個月沒有活動，並從 2024 年 8 月起對部分連結先顯示中間頁（點擊短網址時先出現、告知連結即將停止運作的一頁；Google 也寫明它會打斷後續的轉址與社群平台的連結預覽，並提供一個參數讓人跳過；由程式送出的請求收到的是這一頁的 HTML 而不是轉址，告知因此到不了任何人）（Google, 2024）；2025 年 8 月 Google 修改了 2024 年的計畫，改為只停用「2024 年底沒有活動」的連結，其餘保留，這一批沒有活動的連結在九個月前已經改導到告知即將停用的訊息頁；修改的理由是「these links are embedded in countless documents, videos, posts and more」（Google, 2025）。

這個過程裡有兩個做法可以直接沿用。一是用中間頁把通知送到第三方持有者面前：他們不在任何聯絡名單上，但只要還在用這條引用，就一定會經過它被使用的那一刻。二是依使用紀錄切出要保留的部分，讓保留的成本隨著還在用的引用數量走，而不是隨著曾經發出去的總數走。

推動直接客戶遷移的手段

直接客戶有能力自己遷移，而遷移的時程由他們自己排。提供者推動時程的手段有下列幾種，代價分別落在客戶的使用者、提供者自己與晚到的客戶身上：

• 分段截止日加上降級：Parse 的遷移指南把遷移拆成三個建議日期（先搬資料、再架自己的伺服器、最後發布指向新伺服器的 app 版本），並說明資料還沒在 2016 年 4 月 28 日前搬走的 app，「a small number of database requests may fail with a 428 error code」；Parse 會優先處理已經搬完的 app 的請求（Parse 遷移指南，Wayback 2016-12）。用真實的錯誤讓還沒動的客戶在自己的監控上看到問題，而不只是收到一封可能沒人讀的信（API 淘汰常用的 brownout 是同一種做法，見 11.5 版本策略與 deprecation 的〈Deprecation 的執行工具箱〉），代價是這些客戶的使用者先承受錯誤。
• 縮減而不刪除：Heroku 在 2022 年終止免費方案時，免費的 app 被縮到零個執行個體，也就是不再有執行中的程序，app 的程式、設定與名稱保留（Heroku FAQ，Wayback 2022-08-25）；現行的常見問答寫明，訂閱付費方案之後可以再擴回來（Heroku FAQ）。客戶的設定與名稱都還在，回來的成本低。
• 直接刪除：Heroku 同一次處置刪除了免費方案的資料庫；Parse 在 2017 年 1 月 30 日逐一停用 app 之後，「you will not be able to access the data browser or export any data」（Parse, 2017）。兩者都沒有唯讀期，沒趕上截止日的客戶連匯出都做不到。

刪除之前留一段唯讀期，是成本最低的保險：寫入已經停了，只多付儲存與一個讀取介面的成本，換來晚到的客戶還能取回資料。

公告期的長度與通知管道

公告期是從宣布到關閉的時間，它要長到讓持有者完成他們要做的工作。下列案例的公告期從零到一年都有：Parse 約一年、Google Code 約十個月、CodePlex 約八個半月、Spotify Car Thing 約六個半月、Heroku 約三個月、Revolv 約十一週，Insteon 則是 2022 年 4 月伺服器停止之後才在官網貼出說明。

決定長度的是持有者要做的工作裡最慢的那一項，而不是提供者想多快結束：

• 直接客戶要搬資料、架設替代服務，時間以月計：Parse 的遷移指南從宣布起算，給搬資料約三個月、架好自己的伺服器約六個月。
• 間接使用者要等客戶發新版 app、自己更新，時間以月計。Parse 的遷移指南把「發布指向新伺服器的 app 版本」排在最後一步，建議日期是 2016 年 9 月 28 日，離 2017 年 1 月 30 日 Parse 停用 app 還有四個月，留給使用者更新。提供者看得到請求裡的 SDK 或 app 版本，舊版客戶端的流量比例降到多少，是決定公告期與降級時點的直接依據；請求要帶哪些識別才量得到，見 11.12 API 消費者用量觀測：契約決策要的觀測維度、消費者身分的識別、欄位級用量與全量或抽樣的成本邊界。
• 第三方持有者收不到公告信與公告文章；送得到他們面前的是引用被使用那一刻的訊息，依引用種類不同：網址用中間頁，套件用登錄服務的棄用警告（npm 的 deprecate 會在每次下載時顯示作者寫的訊息，見 npm unpublish 政策），API 用回應標頭。這些訊息顯示多久，就是他們實際得到的公告期；這段期間沒有使用引用的人，得到的公告期是零。除此之外，保護他們的是靜態封存、依使用紀錄保留，以及 CDN 業者這類中介者的介入（10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS 的〈網域的出售：polyfill.io 的經過〉）。

這條判斷標準假設提供者撐得到那一天。資金用完、公司解散或合約終止時，提供者能給的時間可能短於最慢的那一項工作，Insteon 的公告期就是零；有些工作根本沒有完成的一天，例如沒有更新管道的裝置、印在紙上的網址。這段差距只能由不靠提供者存續的做法承接：靜態封存、預先付清的網域續約、交給中立方的技術控制，以及 10.8 移交：資料匯出、開源與交給社群或封存機構 的移交。這些安排的費用與負責人，要在資金還夠的時候先定下來。

通知管道要依持有者的類別分開設計：直接客戶用信件與管理介面；間接使用者要靠直接客戶轉達，提供者能做的是給直接客戶可以轉達的材料；第三方持有者只能在引用被使用的那一刻通知，也就是中間頁或回應裡的訊息。API 的使用者還可以從回應標頭機器可讀地得知退場時點，做法見 11.5 版本策略與 deprecation 的 Sunset header；各類通知工具怎麼組合覆蓋不同類型的消費者，見 Deprecation Lifecycle 卡；那張卡依「消費者會看到哪一種通知」分類，和這裡依「提供者聯絡得到誰」分的持有者類別是兩種切法。

賣出去的裝置的補償

服務結束讓已經賣出去的硬體失效時，公告期之外還有補償的問題。兩個案例的時序相似：Revolv 的關閉公告最早出現在 2016 年 2 月下旬的網頁快照裡，客服說明只寫「Please contact Revolv customer support」，全額退款的文字到 4 月上旬的快照才出現（Revolv 官網，Wayback 2016-04-05；Wayback 2016-04-11）。Spotify 在 2024 年 5 月 23 日公布 Car Thing 停止支援時，支援頁沒有退款條目，「憑購買證明聯絡客服討論退款」的文字出現在 5 月 28 日到 30 日之間的快照，5 月 30 日 TechCrunch 報導了一件針對 Car Thing 的集體訴訟（Spotify 支援頁，Wayback 2024-05-28；Wayback 2024-05-30；TechCrunch, 2024）。兩案的退款都是公告之後才加上的；快照只能界定退款文字出現在哪兩個日期之間，退款與抗議或訴訟之間的因果，一手來源沒有寫明。

FTC 對 Revolv 的調查結論說明了補償在監理上的份量。FTC 決定不採取執法行動，考量的因素包括「the limited number of units sold; Nest’s practice of providing full refunds after the Revolv system shutdown was announced」，以及透過網站、app 內通知與信件公告退款（FTC 結案信, 2016）。Revolv 的關閉日期在各份文件裡不一致，所以上面的公告期只能寫成約十一週：結案信第一頁寫 2016 年 6 月 19 日，第二頁引用官網當時寫的 5 月 15 日，官網之後又改成 5 月 22 日。

所以補償要和公告一起規劃，而不是等反應出現才加：退款的條件、截止日與申請管道寫在第一份公告裡。至於能不能讓裝置在沒有雲端時繼續運作，要在上線時決定，見 10.5 退場能力的設計前置：端點間接層、本地運作模式與引用的命名空間 的〈雲端關閉後的裝置功能：本地運作模式〉。

移交的對象與各自需要的資料、程式碼與權限

移交的對象有四種，每一種需要的不同：

四種對象對應到持有者的類別（10.4 服務終止的範圍：外部引用的種類與持有者）：資料匯出與開源照顧直接客戶；社群接手照顧直接客戶（包括買了提供者硬體的人）與間接使用者；在四種對象裡，不需要拿到網域就以第三方持有者為目的的只有封存機構（拿到網域的接手者也照顧第三方持有者；表外還有 CDN 業者提供的鏡像，例子見 10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS 的〈網域的出售：polyfill.io 的經過〉），因為第三方持有者（和提供者沒有關係、聯絡不到的引用持有者）不會自己採取任何動作。提供者自己能為他們做的靜態封存見 10.7 分階段退場：停止新建、唯讀、靜態封存、關閉與公告期。表中「網域的技術控制」指代管網域的 DNS 與回應內容、所有權不移轉，見 10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS 的〈交給中立方的技術控制〉。

交給直接客戶的資料匯出

匯出是最基本的移交，前提有兩個：客戶在公告期內有時間執行匯出，以及匯出的格式在另一個服務或自架環境裡讀得進去。

Parse 在 2016 年宣布關閉時提供的資料庫遷移工具，把匯出做成不停機的線上搬遷：先建立快照，再持續同步寫入，讓開發者驗證之後才確認切換，「this can happen without downtime」（Parse, 2016；搬遷步驟見 Parse 遷移指南，Wayback 2016-12）。它也把搬遷拆成兩件可以分開做的事：資料先搬到開發者自己的 MongoDB，客戶端照舊連線 api.parse.com，由 Parse 託管的 API 伺服器改去讀寫開發者自己的資料庫；客戶端改連自己的伺服器是下一步。拆開之後，資料留在 Parse 手上這件最急的事可以先解決，等使用者更新 app 這件最慢的事可以晚一點。

匯出的範圍要涵蓋讓外部引用繼續運作的全部資料，而不只是客戶在介面上看得到的部分。Parse 的託管檔案放在 Parse 自己的 S3 儲存，「our S3 bucket will also be turned down, which means those files will need to be migrated before that date」（Parse, 2016），所以檔案要另外用一個工具搬。goo.gl 在 2018 年讓帳號持有人從管理介面匯出自己的連結資料（Google, 2018），匯出的是對照表，但網域留在 Google 手上：客戶拿到對照表之後，能做的是在自己的網域上重建連結，原本 goo.gl 開頭的引用仍然依賴 Google。匯出期結束之後，讓引用繼續運作所需的資料（例如靜態封存保留的短網址對照表）依服務條款保留，其餘客戶資料依合約與適用的個人資料規定刪除，備份也在範圍內；刪除的時點寫進公告，客戶才知道匯出的最後期限；刪除的證據怎麼留，見 7.11 資料駐留、刪除與證據鏈。匯出範圍也包括帳號憑證：密碼雜湊連同演算法、參數與 pepper（如果有）一起交出，客戶的使用者才不必全部重設密碼。

開源程式碼獨立運作所需的元件與授權

開源服務端程式碼讓客戶與社群能自己架一份相容的服務。它的價值取決於釋出的程式碼是不是完整到能跑起來，而這一點常常受限於上線時採用的第三方元件。

Parse 開源的 Parse Server 是可以跑的例子：它以 Node.js 實作了大部分的 Parse API，宣布同一天就釋出，之後 Parse Dashboard 也開源，至今由社群在 parse-community 組織下維護（Parse, 2016；GitHub parse-community/parse-server）。它也有沒涵蓋的部分：同一篇公告列出分析與遠端設定（Parse Config）這兩項功能不在 Parse Server 的支援範圍裡。

Google 在 2025 年釋出 PebbleOS 原始碼則是另一種結果：移除了部分專有程式碼，主要是晶片支援與藍牙堆疊，所以釋出的版本「will not compile or link as released」（Google Open Source Blog, 2025）。釋出仍然有用，社群拿到了建置系統與大部分程式；但要讓它跑起來，缺的那幾塊得有人重寫。

開源能不能當作移交手段，取決於讓這份程式碼跑起來的全部元件裡，有多少的授權允許一起釋出。授權不允許的元件只有兩種去處：在釋出前換成可以釋出的替代品，或在公告裡寫明缺了什麼，讓接手的人知道要補哪裡。

交給接手的社群或公司

社群或另一家公司接手，是讓直接客戶（包括買了提供者硬體的人）與間接使用者（客戶的 app 或裝置的使用者）繼續使用服務的做法，前提是接手者能讓既有的客戶端改連到新伺服器。

Pebble 的雲端服務由社群專案 Rebble 接手，接手需要的條件在這個案例裡大多是提供者事先留下的。Pebble 在 2016 年 12 月宣布團隊轉入 Fitbit 時就寫明，之後要「phase out cloud services, providing the ability for the community to take over, where possible」（Pebble 開發者部落格, 2016）；2017 年的手機 app 更新讓使用者能用一個連結改寫服務設定的來源（10.5 退場能力的設計前置：端點間接層、本地運作模式與引用的命名空間 的〈客戶端讀取服務位置的端點間接層〉）；2018 年 1 月把停止日延後半年到 2018 年 6 月 30 日（Fitbit, 2018）。Rebble 公布接手計畫時感謝 Fitbit 在轉換規劃上的協作，並說明使用者只要在手機上點一個連結就會切換到 Rebble 的服務（Rebble, 2018；Rebble, 2018-06）。Pebble 原創辦人 Eric Migicovsky 在 2025 年回顧時寫道，Rebble 在 2017 年、伺服器關閉之前就封存並開始託管一份應用程式商店的副本（Eric Migicovsky, 2025）。

Insteon 是沒有任何移交安排的對照案例。2022 年 4 月經營公司停止營運、伺服器關閉，官網隨後貼出的說明只談公司的財務狀況與資產處分。兩個月後，一群 Insteon 使用者買下這個品牌與服務，新公司寫道「Our first priority was getting the hubs online immediately before we had access to this site, the email service provider, social accounts, etc.」（Insteon, 2022）：接手者要先自己摸清楚怎麼讓集線器（連接家中開關與感測器、再連上雲端的裝置）重新上線，官網、信件服務與社群帳號都是之後才拿到的。服務恢復之後改成了付費訂閱（Insteon, 2022-06，現行頁面）。

兩案的差別說明接手者需要提供者事先留下的條件：客戶端改連新伺服器的方法與它信任的金鑰或數位憑證、服務端的程式碼與資料，以及網域、信件服務、帳號這些營運資產的交接清單。這些都準備好時，交接可以在停止日之前完成；什麼都沒準備時，接手者得在服務已經中斷的情況下從頭重建。

營運資產清單要列進行銷追蹤後台。網站頁面裡嵌著的 Google Tag Manager（GTM）容器 ID、Google Analytics 4（GA4）評估 ID 與 Meta Pixel ID 都屬於原公司的帳戶，接手者拿到網站與網域、卻沒拿到這些帳戶的管理權時，頁面上的追蹤碼會繼續把訪客的事件送進原公司的帳戶，而接手者看不到這些資料、也改不了容器裡的設定；持有原 GTM 帳戶發布權限的人，還能透過頁面上的容器片段在接手者的網站上執行程式碼，原 GTM 帳戶日後再轉手給別人時，這個權限也跟著落到新的持有者手上。所以接手當下就把頁面上的容器片段換成接手者自己帳戶的容器，不等帳戶移交談完。

這三個後台的最上層帳戶（Meta 的商家資產管理組合、GTM 帳戶、GA4 帳戶）都能用加入接手者、再移除原公司成員的方式移交（依三家的權限規則推出），而這個方式成立的前提是帳戶裡只放這項服務的資產；帳戶裡還放著原公司其他事業的資產時，原公司不會把整個帳戶交出去，就要逐項看每個資產能不能搬到接手者的帳戶。三家的資產各有不能搬的情形，例如 Meta Pixel 在 Meta 後台對應的資料集不能轉移，搬不出來的由接手者另建、再換掉頁面上的 ID。綁在法人身上的資料也不隨成員移交（由權限設計推出）：Meta 組合的商家驗證是以原公司的身分做的，付款方式仍留在組合裡而它屬於原公司，GA4 帳戶已接受的資料處理條款也是原公司簽的，接手者要以自己的公司重做驗證、換上自己的付款方式並重新確認條款。移交的順序與前置條件見追蹤資產的歸屬的〈資產與權限的移交方式〉中事業轉手那一段，各家能不能搬見同篇〈追蹤資產換擁有者的條件〉。

接手者拿到網域時，持有者手上的引用就換了主人，對持有者來說同樣是易手。公開移交指三件都做到的移交：提供者事先公告接手者的名稱；在移交條款裡寫明延續服務的範圍與期限；寫明網域或它的技術控制再次轉手時，條款是否跟著延續。公開移交讓持有者事先知道新主人是誰，但條款本身沒有被執行的機制（tr.im 的例子見 10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS 的〈交給中立方的技術控制〉），所以它降低的是新主人看不見的風險，不保證接手者做到。Pebble 交給 Rebble 是事先安排的接手，那一案沒有移交網域，使用者是點一個連結把手機 app 改指到 Rebble 的伺服器。

交給封存機構

封存機構照顧的是第三方持有者：讓服務結束前發出去的外部引用繼續解析，或至少讓人查得到它原本指向哪裡。取得對照資料有兩種方式，差別在業者有沒有參與，這決定了能保住的範圍。

業者合作交出：2009 年由短網址業者組成、Internet Archive 管理的 301Works，參與的業者「will provide regular backups of their URL mappings」，關站時把網域的技術控制交給 301Works 繼續轉址（Internet Archive, 2009）。條款同時考慮了隱私：查詢時要拿著短網址，一次只回一筆（301Works 參與條款）。這個方式的效果取決於業者是否真的上傳；Internet Archive 上的 301Works 收藏至今標示為不公開取用（Internet Archive 中繼資料），公開資料裡也沒有找到任何參與業者關站時交出網域技術控制的例子。

外部爬取：ArchiveTeam 的 URLTeam 不等業者合作，用分散式爬蟲對短碼空間逐一送出請求、記下轉址的目的地，結果公開發布。它的說明頁寫道「Even 301Works founding member bit.ly does not actually share their databases and most other big shorteners don’t share theirs either」（ArchiveTeam URLTeam）。爬取不需要業者同意，但只能拿到爬得到的部分：短碼是不是循序產生、業者有沒有限制請求速率，決定了能保住多少對照資料。短碼的可猜測性和 0.24 短網址服務的實作：短碼生成、對照表儲存、轉址快取與點擊紀錄 的〈短碼生成：可猜測性與協調成本的取捨〉是同一件事的兩面：短碼越難猜，承載私密連結越安全，關站時外部也越難把對照表保住。

所以想讓封存機構接手的服務，要在上線期間就定期交出對照資料，並在條款裡寫好關站時網域技術控制的去向；等到關站時才聯絡，封存機構拿到的只會是爬得到的那一部分。

交不出去的功能與引用：第三方契約、授權限制與提供者網域

有些功能與引用無論提供者多配合都交不出去，退場公告要明寫它們會消失：

• 依賴提供者與第三方契約的功能：Pebble 在 iOS 上回覆簡訊的功能依賴與電信商的協議，時間軸的即時推送只有 Fitbit 能提供，Rebble 都接不走（Rebble, 2018）。
• 授權不允許釋出的程式碼：PebbleOS 的晶片與藍牙程式碼。
• 提供者網域下的引用：除非網域本身或它的技術控制也交出去（以本篇〈交給接手的社群或公司〉的公開移交交出；各種去向的比較見 10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS 的〈網域在服務結束後的去向：續約並回應、續約不回應、到期、出售〉），否則接手者只能在新網域上重建服務，舊的引用仍指向原本的網域。提供者網域的處置見 10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS。

短網址服務在這幾項裡只碰到提供者網域下的引用，但它正好是短網址的全部價值所在：對照表可以交出去，引用卻寫在提供者的網域上。短網址服務的退場實作見 0.24 短網址服務的實作：短碼生成、對照表儲存、轉址快取與點擊紀錄 的〈服務結束時的轉址延續〉。