# 短網址服務

### Goal
- 讓 url.gov.tw 成為符合 Public Code Standard 的 public code
- 延續上一條目，讓各單位能簡單自建

### TOC
> [TOC]

- https://url.gov.tw/ - 我們現有的短網址服務
- https://go.gov.sg/ - 新加坡 GovTech 做的短網址服務
- https://go.usa.gov/ - 美國政府的短網址服務，但已經退役
> isacl: 看了 https://blog.usa.gov/sunsetting-go.usa.gov-frequently-asked-questions 但未明確列出退役原因

### 專案 Facts
- 「短網址服務」是由兩套系統組成：
- 一套管理「短網址 <-> 長網址映射」的工具，下稱「**管理工具**」
- 一套依據「短網址 <-> 長網址映射」進行網址重導向的機制，下稱「**重導向機制**」

- 「短網址」與「長網址」在不同 domain （或不同政府單位）時的缺點為：
- Web 分析工具需要跨單位，例如追蹤 HTTP referer 會失真。因此會額外有跨單位申請對方 domain 的 log 以追蹤使用者來源的需求
- 對使用者不直覺，可能會感到不信任
- 但 `gov.tw/hel -> foo.gov.tw/hello-world` 似乎也沒有信任問題
- 資安問題
- 若有某 gov.tw 網站有上傳漏洞、被放釣魚頁面或惡意頁面，經由縮址後，使用者無法第一時間辨識。
- 可顯示待轉頁面，顯示目標連結，讓使用者點擊確認。（順暢度打折）
- 配合資安廠商產品或服務，於第一時間掃描頁面安全性，並定期巡檢。

### 方案
#### 方案 A： 集中管理 `<domain>-url-mappings.txt`，重導向行為輔導各單位自行處理

> 核心目標：產生值得信賴的 `<domain>-url-mappings.txt`
> 前提： URL 映射不怕被枚舉

- **管理工具**：用 GitHub 單一 repository 管理多組 `<domain>-url-mappings.txt`，例如 `mohw.gov.tw-url-mappings.txt` (衛福部)
- 透過 GitHub PR 修改 `<domain>-url-mappings.txt`
- 透過 GitHub Actions 進行目的地 URL 預檢，並產生 checksum

- **重導向機制**：提供一套機制讓各單位下載 `<domain>-url-mappings.txt` ，並提供文件指導設定於 Nginx 或 Cloudflare Worker，也提供自動更新的標準 script 及建議機制。
- 直接從 `https://github.com/PDIS/<project-name>/blob/HEAD/<domain>-url-mappings.txt` 下載
> isacl: 安全嗎？
- Nginx `map directive`: https://stackoverflow.com/questions/29354142/nginx-how-to-mass-permanent-redirect-from-a-given-list
> isacl: 太酷了，我之前不知道可以這樣用
> BlueT: 需確認 nginx 引用 .map 檔是否會 auto reload 、快取機制等。
> BlueT: 也可以考慮 nginx + Lua + redis 之類的方案，配合 GitHub actions 推送更新等。

- 特點：
- 「**管理工具**」 serverless
- 網址枚舉
- 不用 Design System
> isacl: 算是缺點吧 XD
- ==點擊短網址後，無公版方式提示使用者即將重導向。 => 也許是 blocker== // 2/8 新增
- 申請者要有 GitHub 帳號
> isacl: 也許能做「發信給指定 email 就自動建立 PR」
- 短網址與長網址 domain 相同
- 缺點：各單位可能只有很少量的網址需要縮，卻要自己處理重導向 (也許大家更喜歡用 url.gov.tw 呢)

- TODO
- [ ] Build PoC
- [ ] User Stories （慕安？）

### 討論/待釐清/待定義：
1. 新增短網址是於 web 介面還是 GitHub PR 操作？（目前看起來是 web 但筆記中是 PR）
1. 權限控管：任何人皆可新增，或是各單位派代表？
- 誰能新增？誰能修改？誰能刪除？
- 有哪些角色？（管理員、gov user、民眾）
3. 轉成三碼是亂數亦或自訂？
- 若為自訂，限制三碼是否易讀？有時長些反而較易讀、有意義。
- 若為亂數，要基於什麼規則？
4. 「檢測」流程是要檢測什麼、如何檢測與驗證？
5. 我們是否將 Cloudflare 定義為「國家等級」的「可信賴」服務提供商？（包含服務的安全性、穩定度等，及使用者對 Cloudflare 之間線路的安全性、穩定度等，或我們是否有能力確保、保障上述問題的發生機率夠低）
- 「若 Cloudflare 當機則政府轉址服務就會失效」、「若 Cloudflare 有資安事件可能讓轉址轉到惡意網站」是否是可接受的？
- 看起來目前的 ZTA 規劃建構於 Cloudflare 機制上，猜測上述問題的答案皆為「Yes」？
6. 同上，對象換為 GitHub 。
- 另，GitHub Actions 的執行環境是否足夠穩定安全可信（國家基礎建設角度）、誤執行和漏執行的機率多少？
- GitHub 能否提供相關資訊？
7. 預估的使用量為多大？（紀錄筆數、request per second）