分類彙整: 開放原始碼

歐盟的數位身分皮夾,為何被批評是「送給 Google 與 Apple 的大禮」?

歐盟這幾年一再對外強調要對抗科技巨頭的壟斷,從 GDPR 到數位市場法(DMA,Digital Markets Act,一套要求大型平台不得濫用守門人地位的法規)都是同一條路線。然而最近讀到荷蘭數位公共基礎建設組織 Waag一篇評論,作者 Danny Lämmerhirt 指出,歐盟各國正在推動的數位身分皮夾,實際的技術設計卻將「驗證使用者裝置」的權力交回到 Google 與 Apple 手上,與歐盟自身的反壟斷立場相互矛盾。文章標題說得相當直接,此舉無異於送給 Google 與 Apple 的一份大禮。

以下先補一點背景,再整理 Waag 這篇文章的重點。整理的部分是重點編譯、加上少許個人理解,不是逐字翻譯,原文的技術細節相當完整,建議直接閱讀完整版。

一、背景:歐盟為何要做數位皮夾

歐盟的舊 eIDAS(2014 年,歐盟的電子身分識別與信任服務規範)只解決「跨境登入政府網站」這件事,但推了幾年,只有 14 個會員國通報了電子身分方案,大約六成歐盟居民其實無法在別國使用自己國家的 eID。2020 年,執委會主席 von der Leyen 在國情咨文裡講了一句常被引用的話:每次 app 或網站要求以某個大型平台登入,使用者其實不知道自己的資料會被如何使用。隔年執委會就提出「歐洲數位身分」框架,2024 年正式修法成 eIDAS 2.0(Regulation (EU) 2024/1183,2024 年 5 月生效),要求每個會員國在 2026 年底前,至少提供公民一款數位皮夾。

官方講的目標,是讓公民用同一個皮夾在整個歐盟證明身分、自己決定要揭露哪些資料(選擇性揭露),而且不必倚賴私人的身分驗證方式。一個為了「少依賴大型平台登入」而生的計畫,真正上路後,卻在最底層「這台手機可不可信」這一關,把決定權交回給 Google 和 Apple。而 Waag 這篇文章要處理的,就是這個矛盾。

二、Waag 這篇文章在說什麼

為何需要驗證裝置

歐盟正在推動的 EUDI Wallet(European Digital Identity Wallet,歐洲數位身分皮夾),目標是讓歐盟公民以手機上的一個 app 存放身分證、駕照這類官方憑證,日後辦理政府服務、進行身分識別皆可使用。這類 app 牽涉相當敏感的官方憑證,因此會先確認目前執行這個 app 的手機,是否為一台未經竄改、可以信任的裝置。這個確認動作在技術上稱為遠端驗證(remote attestation,就像有些銀行 app 一偵測到手機被 root 或越獄就會拒絕登入,由遠端判斷這台裝置能否信任)。問題就在於,各國採用何種工具來完成這項驗證。

Play Integrity 的生態綁定

文章指出,荷蘭與義大利的皮夾採用 Google 的 Play Integrity API 進行裝置驗證。這個 API 表面上檢查的是「app 是否遭到竄改」、「是否透過官方管道安裝」,但它實際判斷的標準為兩點:這個 app 是否透過 Google Play Store 安裝、這台裝置執行的是否為 Google 授權的 Android(市售手機多半預裝通過 Google 認證的版本,GrapheneOS/e/OS 這類去 Google 化系統則不算在內)。

換言之,Play Integrity 將 Google Play Store 視為唯一的可信來源。作者原文寫道(以下為翻譯):Google 的這套安全服務,在設計上就是要排除非 Google 授權的作業系統、鼓勵使用者透過 Play Store 安裝、並要求使用者以 Google 帳號登入。結果便是,只要使用的並非 Google 版本的 Android,就可能連政府的身分皮夾都無法開啟。iOS 那一側,Apple 的 Managed Device Attestation 扮演對應的角色,文章把兩家並列點名,只是技術細節主要以 Google 這套為例展開。

開源的替代方案

作者強調,這種綁定在技術上並非不得不然。Android 本身即具備另一個 Hardware Attestation API(硬體層級的裝置驗證),改用裝置內建的安全晶片來證明自己未被竄改,同樣能達成足夠的安全檢查,卻不會額外要求 Google 授權、透過 Play Store 安裝或以 Google 帳號登入。可見「確認裝置可信」這件事,存在不綁定單一廠商的做法,只是荷蘭與義大利並未採用。

各國實作不一

這不只是紙上談兵,各國的實際選擇已經分岔。

  • 荷蘭、義大利:直接採用 Play Integrity,無條件綁定 Google。
  • 瑞士官方文件明講,基於資料保護、數位主權與使用者選擇自由的考量,放棄原本要用的 Play Integrity,改用硬體層級的驗證。
  • 歐盟的架構參考框架(ARF,Architecture Reference Framework):僅「建議」採用 Google 與 Apple 的驗證,並未強制。正因僅止於建議,各國才做出寬嚴不一的選擇。

瑞士的選擇說明,不綁定 Google 在技術上同樣可行。

與歐盟法規的矛盾

  • eIDAS(也是 EUDI 皮夾的法源):將互通性(interoperability)列為關鍵目標。一旦驗證機制綁死 Google 的生態系,等同將不使用 Google 服務的人排除在外,與互通性的目標背道而馳。
  • DMA數位市場法):要求大型平台不得濫用守門人地位。將 Play Integrity 納入公共基礎建設,等同藉政府服務去強制執行 Google 的生態系政策,作者認為這明顯違反 DMA。

一邊立法反壟斷,一邊在公共服務中將守門權交予被規範的對象,這是整篇文章反覆指出的核心矛盾。

來自實測的佐證

Waag 自身執行了一項由歐盟資助的 Mobifree 專案,歷經兩年研究、招募 120 位測試者,探討何種條件會使人願意改用「去 Google 化(de-Googled)」的作業系統,例如 GrapheneOS、/e/OS 這類移除 Google 追蹤器與預載軟體的 Android 分支。研究發現,許多測試者是否願意轉換,關鍵在於這些系統能否使用支付、政府身分識別這類生活必需的 app。而 EUDI 皮夾綁定 Play Integrity 之後,想使用較能保護隱私的手機系統,反而會因此無法連上政府服務。

行動呼籲

作者最後分別點出三種人各自可著手的行動:

  • 使用替代作業系統的人:聯絡所在國家 EUDI 皮夾 app 的開發團隊,要求其擺脫對 Google 與 Apple 驗證的依賴。
  • 一般公民:聯絡所在選區的民意代表,要求將身分皮夾與 Google、Apple 脫鉤。
  • 記者:持續關注相關的政治與設計過程,使這件事受到公開監督。

不只裝置驗證這一樁

Waag 這篇並非孤例。早在 2025 年 2 月,就有人在歐盟官方皮夾 app 的開發庫提交了一則 issue(問題回報),要求移除 Play Integrity 的強制要求,理由和 Waag 幾乎一樣。歐盟另一個年齡驗證 app 專案,也因為同樣的質疑,由開發商出面澄清不會強制綁定、會支援硬體驗證等替代方案。

eIDAS 2.0 推行過程中引發的爭議,也不只裝置驗證這一項。2023 年底,超過 500 位資安專家與密碼學家連署反對其中第 45 條,擔心要求瀏覽器信任政府指定的憑證會削弱 HTTPS 的安全。EDRi 等數位權利團體則持續質疑皮夾的「不可連結性」保障不足、可能造成過度識別。推行進度也普遍落後,連荷蘭都已公開表示可能趕不上 2026 年底的期限。

三、不只歐盟:其他國家的做法

將身分證件整合進手機是全球趨勢,不只歐盟在推動。各國採取的做法並不一致,大致可分為兩種路線。

路線代表國家做法
整合進 Apple、Google、Samsung 錢包美國、日本、南韓政府把證件開放給大廠錢包收錄,證件的操作介面直接整合進平台既有的 app
政府自建、避免綁定大廠瑞士、英國、新加坡、澳洲各有獨立的官方 app,不整合進大廠錢包

美國的做法比歐盟更徹底。歐盟至少還是政府自己的皮夾 app,只是採用 Google、Apple 的 API 驗證裝置。美國則是連證件的呈現介面都直接放進 Apple Wallet、Google Wallet,已有十幾個州上線,連機場的 TSA 安檢也開始接受。瑞士則做出相反的選擇,前面提過,它的官方文件為了資料保護與數位主權,刻意放棄了 Play Integrity。

大廠甚至不必等政府推出官方皮夾,就能自行把身分驗證功能整合進錢包。Google 從 2026 年 4 月起在 Google Wallet 推出「護照身分證」功能,讓使用者掃描護照晶片自己建立數位身分,已上線的地區包含新加坡、巴西和台灣,並宣布 2026 年夏天將擴及歐洲多國。

四、從歐盟看回台灣

當公共服務愈來愈以手機 app 為前提,決定「哪一台手機算可信」的權力,會在不知不覺間落入平台商手中。

平時談自架服務、開源、隱私,經常被視為少數人的偏好。一個想使用 GrapheneOS 的人,只是做了一個更能保護隱私的選擇,卻可能因此連政府身分識別都無法使用。當「保護自身隱私」與「使用基本公共服務」淪為二擇一,問題便從個人品味,轉為公共政策是否剝奪了使用者的選擇權。

回到台灣。數位發展部的數位憑證皮夾已經在 2025 年底進入試營運,設計理念上參考了歐盟的分散式身分框架,只是收錄的憑證還是以電信門號卡、駕照為主,其中門號卡自試營運起就上線,駕照要到 2026 年才陸續開放,國民身分證則尚未納入。另一條晶片身分證(New eID)的路線,則因隱私爭議停擺至今超過五年。官方當初說要先完善法制再重啟,但相關專法尚未立法,個人資料保護委員會也還停在籌備處,重啟條件並未達成。

那數位憑證皮夾會不會重演歐盟這一步?這要先分清楚兩個層次。皮夾本身有一整套身分與憑證的驗證流程,這是它能上路的前提。文章擔心的是另一層的裝置驗證。Google、Apple 那種驗證會判斷「這台手機本身可不可信」,並把去 Google 化系統排除在外。就這一層而言,台灣的情況其實比想像中好。這款皮夾的 app 是開源的,程式碼裡找不到 Play Integrity、App Attest 這類呼叫,保護金鑰靠的是手機內建的硬體金鑰庫(Android Keystore、iOS Secure Enclave),不綁定 Google 或 Apple 的生態系,也不會因為使用者改用 GrapheneOS 而拒絕服務。不過要注意,這是依 2026 年 6 月的開源版本判斷,上架的實際版本未逐一反編譯核對,也還沒有人實測它在去 Google 化手機上的相容性。

同樣的排除風險,台灣也存在。台灣人權促進會等團體在 2026 年初的聯合聲明就指出,數位憑證皮夾在缺乏專法保障的情況下便先行試營運,若日後強制使用特定驗證方式,手機不支援或不願安裝 app 的人可能被排除在公共服務之外,聲明並直接點名歐盟 eIDAS 已有的規範框架作為對照。台灣現行對數位皮夾的規範,並非完全無法可管,目前是靠幾部現行的一般性法律拼湊而成:

現行法源管什麼管不到什麼
電子簽章法給憑證「與紙本同等效力」皮夾如何使用、誰能強制要求使用
個人資料保護法皮夾裡的個資處理主管機關(個人資料保護委員會)仍是籌備處,尚未正式成立
資通安全管理法數發部與公務機關的系統資安超商、租車等實際驗證皮夾的民間業者
數位發展部組織法數發部「推動數位服務」的職權隱私邊界等實體規範

就連沙盒測試與試營運本身,也沒有專屬法規,靠的是行政措施與使用者同意的服務條款。歐盟正在爭論的「技術設計會不會把一部分人擋在門外」,台灣其實也還沒把配套規範補上。

五、小結

驗證裝置本身合理,敏感的官方憑證確實需要確認裝置可信。真正的關鍵在於採用何種驗證,因為這決定了公共服務將誰排除在外。採用 Google 的 Play Integrity,等同預設把不使用 Google 的人拒於門外。改採開源的硬體驗證,同樣能確保安全,又不致替 Google 鞏固壟斷。歐盟的反壟斷立法,與它在數位皮夾上的實際技術設計是否一致,端看它將「數位主權」視為口號,還是視為真正的設計原則。這道題不只屬於歐盟。台灣的數位憑證皮夾也已經上路,配套規範卻還沒跟上,把誰隔絕在外、由誰把關,同樣是我們無法迴避的問題。


本文為 Waag〈European Digital ID Wallets Are a Gift to Google and Apple〉(作者 Danny Lämmerhirt,2026-06-22)的重點整理與編譯,非逐字翻譯,僅為評論性引用。原文:https://waag.org/en/article/european-digital-id-wallets-are-gift-google-and-apple/

我們是不是把「辦研討會」誤當成「經營社群」?

我們是不是常常把「辦了一場成功的研討會、一場盛大的年會」當成「我們有一個健康的社群」?

最近讀到一篇文章,讓我把這個問題又翻出來想了一遍。作者 Jr Conlin 在 Mozilla 待了超過 15 年,離開前寫了一封很長的告別文〈Leaving Mozilla〉。表面上他在談一家瀏覽器公司的內部問題,但讀到後面我發現,他真正在寫的是另一面。一個組織如何把真正撐起它的「社群」,誤當成「顧客」、誤當成「一場可以反覆操辦的大活動」,然後一步步離棄那些持續投入的人。

說明:以下前半段是我自己讀完後的重點整理與編譯,加上一點個人的理解,不是逐字翻譯。內容很豐富,強烈建議直接點原文讀完整版,我這裡只整理摘要與觀點。

Jr Conlin 如何看 Mozilla

離職信留給同事的三句話

他離開時留給同事一封信:

  • 你比你想的還重要:他講的就是「正在讀這封信的那個你」,不是什麼「企業體」或「組織」。他長年在公司裡推動 mentoring(師徒制、指導),本質就是「找到另一個可以對話的人」。無論你的資歷深淺,你都同時能學、也能教。
  • 你是更大整體的一部分:在 Mozilla 領薪水的人,是幸運的少數。真正的 peers(同儕)是外面那一大群「沒有 badge、沒有 @mozilla.com 信箱」、卻一起想打造一個「把使用者利益擺第一」的瀏覽器的人。對這群人,公司有「傾聽」的義務,因為如果不為他們做事,他們會去找別人。
  • 我們其實很小:Firefox 是一個 niche(小眾)瀏覽器,只是運氣好,取得了足夠的資金。他用了一個很傳神的比喻:想像你住在一個只有麥當勞、漢堡王、溫蒂漢堡的地方,而 Mozilla 是那間溫暖的「夫妻經營的小餐館」:客人會彼此打招呼、互相倒咖啡、幫忙收桌子。人們是特地繞過手邊現成的大廠瀏覽器、忍受各種「你的瀏覽器過期了」的警告,才來找 Firefox 的。

最後他把這封信收束成三句 TL;DR:尊重你自己、互相幫助、記得你到底是為誰工作。

離職之後的真心話

離職信寫得客套,那些「困擾他很久」的事,他在文章後續另外寫下來(原文內容很豐富,有時間建議閱讀):

  • 領導層不是功臣:業界常說「Mozilla 是『靠著』它的領導層存活下來的,而不是『因為』領導層」,他說這句話「最近聽起來特別真實」。
  • 使用者「極度不正常」:Firefox 的使用者是「deeply abnormal(極度不正常)」的一群人,你得主動去找、去下載、無視所有要你改用 Chrome 的廣告。而問題在於,領導層不知道該如何面對這種「不正常」。Mozilla 本來就是不正常的,幾乎每一行程式碼都是開源公開的、關鍵漏洞常常 24 小時內修掉。
  • 把開源透明當火星人:從傳統科技業挖來的領導者,多半來自「黑色高領毛衣之神」(暗指賈伯斯那套)信奉的世界,奉行「什麼都別告訴任何人」。對他們來說,「把東西免費送出去、而且透明到不可思議」這件事,簡直像火星人在做的事。
  • DAU 焦慮:日活躍使用者數(DAU)掉了好幾年,新的領導者每次進來都帶著大想法,而那些大想法幾乎都是「我們應該抄大廠在做的東西」。但這註定沒用。如果使用者真的想要那個功能,他們手邊的大廠瀏覽器早就有了,何必特地來用你?
  • 假裝成新創:每個新領導者都覺得「我們要像新創一樣思考!」可是 Mozilla 是一家 30 年的老公司,是新創的反面。結果他們「假裝成新創」假裝了 15 年,換來史上最低的 DAU。他的建議是,回頭看看 30 年歷史裡 DAU 最高的時候在做什麼。而那答案,從來都跟潮流無關:做自己擅長的事、保持那份「不正常」、幫人們做出他們真正想要的東西
  • 追企業合約的諷刺:Mozilla 一度想去賺「企業財」,得通過一堆 ISO 標準與資安認證、證明自己的程式與基礎設施夠安全。諷刺的是,企業客戶用的 curl、Linux 和一大堆開源工具,全是「網路上隨便一些人」寫的。而那些資安認證體系所要求的「金鑰妥善保管、建置環境安全、有可稽核的軌跡」,其實正是 Mozilla 這種「全部開源、公開修漏洞」的做法在示範給大家看的。
  • 倖存者偏差:推出爭議功能(DRM、AI、推播通知……)後,「聽使用者的意見」其實很難,因為會留下來告訴你想法的人是少數,多數人不爽就直接走了。於是你的資訊來源永遠是「留下來的那群人」,得到的滿意度自然虛高。他用了二戰那張著名的轟炸機彈孔圖當比喻。原文只一句帶過,這裡補充一下典故:你以為該補強中彈多的地方,但真正該補的是「沒中彈」的部位,因為中那裡的飛機根本沒飛回來。一個功能如果熱度過了新鮮期就掉下去,那大概就是你猜錯了,Reddit 上抱怨的人可能才是對的。
  • 最痛的一點,離棄社群:過去五年,Mozilla 由上而下地背離了它最大的後盾:社群。領導層認定「Mozilla 是靠自己走到今天的」。但它不是。他們說服自己「社群只是顧客、頂多是粉絲」,這激怒了非常多無償貢獻者。這些人付出了好幾年的時間,因為相信自己屬於一件更大的事,結果換來一句「你們只是顧客」,覺得被背叛了。

「如果讓我當 CEO,我會做什麼?」

他說,這是他面試時最愛問別人的問題,現在反過來問自己,答案有四個:

  1. 無聊一點:Mozilla 什麼都想做,做過購物樞紐、做過手機作業系統,然後一再發現自己不擅長。他們真正擅長的就是做瀏覽器。那就專心把核心功能顧好,讓那台「高速亂噴的義大利麵砲」先冷卻一下。
  2. 少一點登月計畫:Firefox 都存在這麼多年了,會用它的那群「怪人」要的很樸實,把累積已久的舊 bug 和技術債修一修、把東西做得更好用、更不煩人,而不是再來一個一年後就棄坑的花俏新功能。而且重大改動要預設 opt-in。他提醒、你的使用者不是你的粉絲,他們只是「勉強忍受你」,你得每天努力才留得住他們。這話聽起來消極,卻很務實。謙虛才會逼你進步。
  3. 重建你的社群:鼓勵外部貢獻,鼓勵到他們能「參與決定下一步要做什麼」的程度。他要的是真的會去修正 bug、做翻譯、回答海量問題的那些人,而不是用 Amazon 禮券把人圈進來坐一小時的焦點團體。(Firefox 曾經幾乎支援所有語言,靠的就是這群志工。)
  4. 別丟掉好東西:Mozilla 有個很糟的習慣、把成功的東西丟掉。Thunderbird 被晾在一邊、Rust 被丟出去(明明可能是金雞母)、Servo 說不定哪天會反過來打敗你、Bugzilla 才是原版好東西(Jira 不過是從它腐化出來的那場惡夢)。這些其實都可以重新邀請回來、一起把事情做得更好。

他真正的願望,是 Mozilla 能重新和社群連結,靠「有用」而不是靠「製造聲量」來成長,當生態系裡有活力的一分子,而不是吞掉一切的黑洞。

文章最後,他把自己這一年反覆問自己的問題攤開來:「我到底是為誰在做這些?」他得到的答案讓人很難過:「我做這一切,是為了讓某個人在下一份履歷上,多得一顆星星。」

反觀台灣:社群,不是研討會

讀完上面那段,我一直在想一件事。Mozilla 真正的問題,是忘了自己一直靠社群撐著,把那群無償投入的人慢慢當成顧客、當成一場可以反覆操辦的大活動。

那我們呢?台灣的開源圈、技術圈,犯的是一個方向相反、結果卻一樣的錯。Mozilla 是忘了社群還在,我們是把「辦了一場研討會」直接當成「我們有一個社群」。一個是遺忘,一個是替換,最後那群真正持續投入的人,同樣沒有被關注!

什麼才叫「社群」

社群,是「除了辦大型活動之外,平常還持續在一起做事」的那群人。一場一年一度的研討會,本身不是社群。

研討會頂多是社群的「年度高峰」,而且前提是,它背後真的有一個平常就在運作的社群。如果一年就那一場、辦完就散、隔年再重來,那它是個「活動」,不是個「社群」。

這跟 Jr Conlin 講的是同一件事,只是換了詞,對他來說,社群是那些「沒有 badge、沒有薪水,卻一直回來」的人。研討會是一個「事件」,社群是一段「持續的關係」。事件結束後,關係才開始累積。

正面的樣子:把社群做對的例子

台灣其實有把「社群」做對的例子,特徵都一樣,大會落幕後,它們仍在運作

  • g0v 零時政府:嚴格說,g0v 比較像一場運動、一個協作平台,不是單一個社群。真正在一起做事的,是各專案頻道裡平常持續協作、持續推進的那群人。每兩個月一次、由「揪松團」籌辦的「大松」(g0v 的大型黑客松)持續在辦,雙年會 Summit 只是其中一個節點而已,g0v 不是「靠 Summit 才存在」的。
  • 各語言、技術的 meetup 與讀書會(Python、Ruby、前端、資安……):定期小聚、定期分享、定期動手做。這些聚會通常不大,但它們是「持續的」。這才是讓新人能一直走進來、讓關係能一直長出來的入口。
  • COSCUP:嚴格說,COSCUP 是一場研討會、一個交會點,不是社群本身。它辦得好,是因為背後有眾多平常各自持續運作的社群,而不是大會那幾天本身。
  • 我自己在 Devconnect ARG 2025 也看過這種「對的設計」:大會給社群一塊空間(Community Hub),讓社群在活動週裡自己持續長出小議程、自己佈置、自己招呼人,而不是「一桌兩椅、講完就收」。給空間讓社群自己長,跟「把社群當成一個攤位節目」,是兩種完全不同的思路。

反面的樣子:辦完一場大會,就說自己有社群

對照之下,台灣也有不少這樣的型態:

  • 「我們辦了一場 XX 高峰會、XX 論壇、XX 年會,所以我們有社群」,但大會結束後,沒有持續的聚會、沒有持續的協作、也沒有讓新人持續加入的入口。明年再用同一套模板辦一次,中間 11 個月一片安靜。
  • 由上而下、由主辦方、政府、企業掛名的「社群」:名義上是社群,實際上缺了 grassroots(草根)那一層持續性。沒有人在「不辦大活動的日子」也願意一起做事。
  • 把參加者當「人次、KPI、觀眾」,而不是「會回來一起做事的夥伴」:這其實就是 Mozilla 把社群當顧客的台灣版,你關心的是「今年來了幾個人」,可惜不是「這些人會不會再回來」。

為什麼說台灣「面臨一樣的處境」

把 Mozilla 的狀況拿來對照,會發現問題幾乎一模一樣:

  • 一樣的倖存者偏差:我們只看得到「來參加大會的人數」,看不到那些默默離開、不再回來的貢獻者。活動報告裡只會寫「今年破紀錄、來了多少人」,不會有人記下「去年那批熱情參與的人,今年一個都沒回來」。
  • 一樣的「製造聲量」勝過「真的有用」:把資源和注意力都壓在一年一度的曝光與人次上(很像 Mozilla 追 DAU、追潮流),而不是去經營那種「能持續產出、能持續投入的夥伴」的關係。
  • 於是社群空心化:因為所有力氣都花在「大型活動」這個事件上,平常該持續運作的小聚、協作、新人招募反而無人承接。久了,大會還在,但大會背後那個「社群」已經被掏空了。

所以呢?

辦一場研討會、辦一場盛大的年會,當然是好事。但我想提醒自己,研討會是社群的「果」,不是「因」。沒有平常持續的活動撐著,一場大會就只是一次性的展演,熱鬧兩天,然後呢?

Jr Conlin 為 Mozilla 提出的那幾條建議,其實放到台灣的社群也成立。他說要「無聊一點」、別一直追新花樣,換成社群的話,就是別每年都想辦一場更大、更炫的活動,把心力放回每個月的小聚、每次的協作上。他說「別丟掉好東西」,就是別讓那些長期默默運作的老專案、老聚會自生自滅,它們往往才是社群真正的命脈。他說要「重建社群」、讓貢獻者能參與決定下一步,換成我們,就是讓平常一起做事的人有真正的位置,而不只是在大會那幾天被當成觀眾。

借用他那句話:社群,是那些「沒有 badge、沒有薪水,卻一直回來」的人。今年的大會來了多少人,其實沒那麼要緊。比較能說明一個社群還活著的,是大會結束三個月後,你還叫得出名字、還願意約出來一起做事的人,到底剩下幾個。

大會結束之後,還有多少人,願意持續一起做事?

這個問題我沒有標準答案,丟給你,也丟給我自己。如果你也在經營或參與某個社群,歡迎從一件小事開始:在下個月不辦大活動的那些日子,找幾個人一起動手做點什麼 🙂


本文前半為 Jr Conlin〈Leaving Mozilla〉的重點整理與編譯(非逐字翻譯,僅為評論性引用),原文連結:https://blog.unitedheroes.net/5751。後半的台灣社群觀察為個人觀點。

Roc Camera 透過零知識證明(Zero Knowledge Proofs)驗證資訊

在網路上看到一台很酷的相機 Roc Camera,用 Raspberry Pi 4 再加上 3D 列印出來的外殼組裝起來就可以拍照,如果僅止於此,那和一般相機沒什麼差別。這台相機在拍照完後建立零知識證明(Zero Knowledge Proofs)的資訊,未來可以透過他們的 SDK 來驗證相片是否真實、是否被串改過。

作者覺得以前照片可以擔任事實呈現(證據)的重要角色,但是現在越來越多 AI 產出的虛假影像,已經讓拍照真實呈現失去其功能,需要一個驗證的方式來加強。目前這台相機還在 Beta 測試階段,看起來之後也會與 IPFS 整合,拍攝完成的作品直接上到 IPFS 鏈紀錄。

這台相機我覺得可以有其他用途,如果只是用在一般生活拍照,稍微有點可惜。例如這相機是用在特定現場的取證,需要關注在影像的正確性的場景下,這台相機才能發揮他的重要性。

撇除以上軟體的部分,透過 Raspberry Pi 4 建立起來的相機模組,這台看起來不錯,前陣子有考慮要不要來添購一台 3D 列印機,滿想建立一些模組板塊來自建一個機房!

持續關注這個小產品,一台 $399,運送預計 2 ~ 3 週的時間。

Stalwart 開源郵件伺服器即將發佈 1.0 版本,成為第一個實作 JMAP 協議的郵件伺服器

雖然現在已經很少人自架郵件伺服器了,但是一款開源的郵件伺服器軟體 Stalwart 完成了 JMAP 的實作!這篇文章介紹了 Stalwart Labs 一個重大里程碑:完成 JMAP 用於行事曆、聯絡人、地址簿、檔案儲存及分享的完整實作,使 Stalwart 成為首個支援完整 JMAP 協作協議的郵件伺服器。

完整的文章內容: https://stalw.art/blog/jmap-collaboration

  • 新一代協議:JMAP 包括用於行事曆、聯絡人、檔案儲存及分享的新協議,目標取代傳統的 WebDAV 技術如 CalDAV 和 CardDAV,並引入 JSCalendar 和 JSContact 作為 iCalendar 和 vCard 的繼承者。這些新標準提供一致且優雅的生態系統。
  • 舊技術的限制:傳統的 WebDAV 及其延伸技術因 XML 設計的複雜性,導致實施困難且互通性差。iCalendar 和 vCard 的技術負擔也使這些格式難以維護。
  • JMAP 的現代解決方案:JMAP 協議以 JSON 為基礎,透過 HTTPS 提供高效且清晰的 API,用於郵件、行事曆、聯絡人及檔案分享,簡化協作技術實作,提升可讀性與解析效率。這次發佈不僅帶來新功能,更改變了群件協議的設計和實作方式,對開發者和組織而言意味著更簡單、更少的互通性問題,並加速創新。
  • 客戶端支援與生態系統:目前已有幾個專案(如 Mailtemi、Parula 和 OpenCloud)在開發 JMAP 的客戶端實作,預期 JMAP 會快速被採用。
  • 感謝及未來展望:感謝 NLNet 對 JMAP 開發的支持。Stalwart 開發團隊將致力於性能優化和增強功能,目標在未來幾個月內推出正式的 1.0.0 版本,樹立開放且現代化的郵件通信伺服器新標準。

前幾個月有把 Stalwart 架起來,很難想像在此刻架一台郵件伺服器能有多難,但再往前跨一步出去後發現,很多雲端服務如 AWSDigitalOcean 將 25, 465, 587 連線埠給關閉或不提供 IP 反向解析1(PTR/RDNS),即使架好了也無法與其他郵件伺服器溝通,或許當越來越多人使用 Stalwart 後這個問題有可能會被克服,我很期待可以自己架設郵件伺服器!


  1. 設定 IP 反向解析(PTR/RDNS)有助於驗證發信伺服器的真實身份,提高郵件的可信度並減少被標記為垃圾郵件的風險,確保郵件順利地送達收件者的主要信箱,提升整體郵件的可交付性。 ↩︎

開源自架服務 immich 被 Google 安全瀏覽誤判為「危險」網站

Google 提供一項名為「安全瀏覽(Google Safe Browsing)」的服務,用來檢測網站是否存在惡意軟體、不受歡迎的軟體或從事某種社交工程行為。不過,對於如何判斷網站是否「危險」的細節仍然不太清楚。這導致使用 Google 安全瀏覽服務的瀏覽器(如 Chrome 和 Firefox)會自動警告使用者,除非少數人忽視這樣的警告,否則這些網站幾乎無法被訪問。

而近期一款開源自架的照片、影片管理軟體 immich,因為自家的 Demo 網站被標記為危險,影響到整個網域的使用。immich 解釋如何透過 Google 的申訴管道提出恢復,但恢復之後所產生的頁面也再次被標記危險。結論提到目前像是可自架服務的 NextCloud、n8n、Jellyfin …… 等,都會有這樣發生的可能,對於開源、自架環境是一個潛在的阻礙

有興趣可以閱讀完整內容:https://immich.app/blog/google-flags-immich-as-dangerous


查了一下 Google Safe Browsing 沒有公開名單讓人查閱哪些網站被放入,只有一個查詢的網站可以使用,雖然我自己不是用 Chrome,但其他使用者以目前 Chrome 的市占率,其影響不容小覷。

這樣的審查模式與臺灣之前討論 RPZ 類似,一樣也是不公佈名單,但 Google 比較麻煩的部分是評判標準不明,然後又常常誤判,申訴後也不知道何時可以恢復,如果真的遇到誤判,還真的不知道該如何面對。

之前作過一個內部系統,也是遇到這樣的問題,想說臨時換一個網域應該可以解決,但又馬上被判定「危險」,最後只能請使用者關閉「安全瀏覽」檢查的功能,還好不是面對外部的使用者,可以這樣一一通知暫時解法使用。