ชุมชนโอเพนซอร์สกำลังเผชิญกับวิกฤตที่ทวีความรุนแรงขึ้น เนื่องจากระบบความปลอดภัยอัตโนมัติของ Google บ่งชี้ว่าแอปพลิเคชันที่โฮสต์เองอย่างถูกกฎหมายมากขึ้นเรื่อยๆ ว่าเป็นเว็บไซต์อันตราย ประเด็นนี้ถูกเปิดเผยเมื่อ Immich โซลูชันจัดการภาพถ่ายแบบโฮสต์เองยอดนิยม พบว่าเซอร์วิส Google Safe Browsing ได้ทำเครื่องหมายโดเมนทั้งหมดของพวกเขาว่าเป็นอันตราย ส่งผลให้ผู้ใช้ส่วนใหญ่ไม่สามารถเข้าถึงบริการของพวกเขาได้ เหตุการณ์นี้ได้จุดประกายความกังวลอย่างกว้างขวางในหมู่ผู้พัฒนาและผู้ใช้ซอฟต์แวร์แบบโฮสต์เอง โดยเผยให้เห็นข้อบกพร่องพื้นฐานในวิธีที่บริษัทเทคโนโลยีรายใหญ่จัดการกับโปรเจกต์โอเพนซอร์สและแบบโฮสต์เอง
เอฟเฟกต์โดมิโนของการระบุว่าโดเมนเป็นอันตราย
เมื่อเซอร์วิส Google Safe Browsing ระบุว่าซับโดเมนหนึ่งมีศักยภาพเป็นอันตราย ผลที่ตามมาสามารถลุกลามไปทั่วทั้งโดเมนได้ สิ่งนี้เกิดขึ้นกับ Immich เมื่อสภาพแวดล้อมพรีวิวของพวกเขาถูกระบุว่าเป็นอันตรายโดยอัตโนมัติ ทำให้ทุกบริการบนโดเมน immich.cloud ไม่สามารถเข้าถึงได้ผ่านเบราว์เซอร์ที่ใช้ฐานข้อมูลของ Google Safe Browsing ปัญหานี้ไม่ได้จำกัดอยู่แค่ Immich เท่านั้น — โปรเจกต์โอเพนซอร์สอื่นๆ อีกมากมาย รวมถึง Jellyfin, NextCloud และ n8n ได้รายงานประสบการณ์ที่คล้ายกัน สิ่งที่ทำให้เรื่องนี้น่ากังวลเป็นพิเศษคือสิ่งเหล่านี้เป็นการติดตั้งซอฟต์แวร์โอเพนซอร์สที่ถูกกฎหมาย ไม่ใช่ความพยายามเลียนแบบที่มุ่งร้าย
หากคุณจะโฮสต์เนื้อหาของผู้ใช้บนซับโดเมน คุณควรจะมีไซต์ของคุณอยู่ใน Public Suffix List
Public Suffix List คือรายการคำต่อท้ายโดเมนที่ดูแลโดยชุมชน ซึ่งช่วยให้เบราว์เซอร์และบริการอินเทอร์เน็ตอื่นๆ เข้าใจลำดับชั้นของโดเมน การอยู่ในรายการนี้สามารถป้องกันไม่ให้ซับโดเมนเดียวที่ถูกบุกรุกส่งผลกระทบต่อทั้งโดเมน
โปรเจกต์ที่ได้รับผลกระทบจากการถูกตั้งค่าสถานะเดียวกันใน Safe Browsing:
- Jellyfin
- YunoHost
- n8n
- NextCloud
- การติดตั้ง Immich หลายรายการ
ต้นทุนที่ซ่อนอยู่ของความปลอดภัยแบบอัตโนมัติ
สำหรับผู้ใช้รายบุคคลที่ใช้งานเซอร์วิสแบบโฮสต์เอง ผลกระทบสามารถสร้างความเสียหายอย่างใหญ่หลวงได้ ผู้ใช้หนึ่งรายรายงานว่าโดเมนส่วนตัวของพวกเขา ซึ่งใช้มา 25 ปีโดยไม่มีปัญหาด้านความปลอดภัยใดๆ ถูกระบุว่าเป็นอันตรายอย่างกะทันหันหลังจากแชร์ลิงก์อัลบั้มรูป Immich ผ่านอีเมล โดเมนดังกล่าวไม่สามารถเข้าถึงได้ผ่าน Chrome และเบราว์เซอร์อื่นๆ ที่ใช้ Safe Browsing ส่งผลกระทบไม่เพียงแต่เซอร์วิสรูปภาพเท่านั้น แต่รวมถึงบริการอื่นๆ ทั้งหมดบนโดเมนนั้นด้วย ลักษณะอัตโนมัติของการระบุเหล่านี้หมายความว่ามีทางเลือกน้อยนอกจากจะส่งคำขอดูผ่าน Google Search Console และหวังว่าจะมีการตรวจสอบด้วยตนเอง
สถานการณ์ยิ่งมีปัญหามากขึ้นสำหรับเครือข่ายภายในและผู้ที่ชื่นชอบ homelab ผู้ใช้รายงานว่าแม้แต่โดเมนภายในที่ไม่ได้เปิดเผยสู่สาธารณะบนอินเทอร์เน็ตเลยก็สามารถถูกระบุว่าเป็นอันตรายได้ ซึ่งชี้ให้เห็นว่าวิธีการตรวจจับของ Google อาจขยายไปไกลกว่าการรวบรวมข้อมูลเว็บสาธารณะ เพื่อรวมแหล่งข้อมูลอื่นๆ เช่น บันทึกความโปร่งใสของใบรับรอง (certificate transparency logs) หรือแม้แต่เนื้อหาอีเมลที่ถูกสแกน
วิธีแก้ไขชั่วคราวทางเทคนิคและโซลูชันของชุมชน
ชุมชนนักพัฒนาได้ระบุโซลูชันที่มีศักยภาพหลายประการ แม้ว่าหลายคนรู้สึกว่าสิ่งเหล่านี้เป็นเพียงการแก้ไขปัญหาเฉพาะหน้าสำหรับระบบที่มีข้อบกพร่องพื้นฐาน การย้ายสภาพแวดล้อมพรีวิวและเนื้อหาที่เผชิญกับผู้ใช้ไปยังโดเมนแยกต่างหากเป็นแนวทางหนึ่ง ดังที่ Immich วางแผนจะทำกับโดเมนใหม่ immich.build ของพวกเขา อีกวิธีหนึ่งคือการใช้ชื่อซับโดเมนที่ไม่ชัดเจนซึ่งไม่ไปกระตุ้นตัวตรวจจับการเลียนแบบของ Google แม้ว่าจะสร้างความท้าทายด้านการใช้งานในตัวของมันเอง
นักพัฒนาบางส่วนสนับสนุนให้ใช้ Public Suffix List อย่างกว้างขวางมากขึ้น ในขณะที่บางคนตั้งคำถามว่าความปลอดภัยบนอินเทอร์เน็ตควรพึ่งพารายการพิเศษที่ดูแลโดยบริษัทเอกชนหรือไม่ ความซับซ้อนทางเทคนิคของโซลูชันเหล่านี้เน้นย้ำให้เห็นว่ามันยากแค่ไหนสำหรับโปรเจกต์ขนาดเล็กและผู้ใช้รายบุคคลที่จะเดินทางผ่านภูมิทัศน์ความปลอดภัยของอินเทอร์เน็ตที่พัฒนาอย่างต่อเนื่อง
แนวทางแก้ไขที่มีการพูดถึงกันทั่วไป:
- ใช้โดเมนแยกกันสำหรับวัตถุประสงค์ที่แตกต่างกัน (production, staging, previews)
- เพิ่มโดเมนเข้าไปใน Public Suffix List
- ใช้ชื่อ subdomain ที่ไม่มีลักษณะเฉพาะเจาะจงเพื่อหลีกเลี่ยงการถูกตรวจจับว่าเป็นการปลอมแปลงตัวตน
- ใช้ robots.txt เพื่อบล็อกไม่ให้ search engine รวบรวมข้อมูลจากบริการภายใน
ผลกระทบในวงกว้างต่อการโฮสต์เอง
รูปแบบการระบุอันตรายแบบอัตโนมัตินี้แสดงถึงภัยคุกคามที่สำคัญต่อระบบนิเวศการโฮสต์เอง ดังที่ผู้แสดงความคิดเห็นหนึ่งระบุไว้ พฤติกรรมของ Google ในที่นี้ บังเอิญแต่ส่งเสริมให้มีการลงทะเบียนโดเมนแบบใช้แล้วทิ้งจำนวนมาก ซึ่งไม่ได้ทำให้อะไรดีขึ้นเลย มาตรการความปลอดภัยที่ออกแบบมาเพื่อปกป้องผู้ใช้อาจกำลังผลักดันกิจกรรมที่ถูกกฎหมายให้ไปสู่แนวทางที่ ใช้แล้วทิ้ง และมีความรับผิดชอบน้อยลงในการจัดการโดเมน
เหตุการณ์นี้ทำให้เกิดคำถามสำคัญเกี่ยวกับความเข้มข้นของอำนาจในมือของยักษ์ใหญ่ด้านเทคโนโลยีไม่กี่ราย เมื่อระบบอัตโนมัติของบริษัทเดียวสามารถลบการเข้าถึงบริการที่ถูกกฎหมายได้อย่างมีประสิทธิภาพโดยมีทางแก้ไขน้อยนิด มันจึงสร้างระบบนิเวศที่เปราะบาง ซึ่งโปรเจกต์โอเพนซอร์สและผู้ใช้รายบุคคลต้องปรับตัวอย่างต่อเนื่องให้เข้ากับกฎเกณฑ์ที่เปลี่ยนแปลงและไม่โปร่งใส
ชุมชนการโฮสต์เองยังคงนวัตกรรมต่อไปแม้จะมีความท้าทายเหล่านี้ แต่เหตุการณ์ Immich ทำหน้าที่เป็นเครื่องเตือนใจที่ชัดเจนถึงตำแหน่งที่ precarious ที่โปรเจกต์โอเพนซอร์สครอบครองในอินเทอร์เน็ตแบบรวมศูนย์ในปัจจุบัน ในขณะที่ระบบความปลอดภัยอัตโนมัติก้าวร้าวมากขึ้น ความต้องการกระบวนการที่โปร่งใสและเป็นธรรมในการจัดการกับผลบวกปลอม (false positives) ก็มีความเร่งด่วนมากขึ้นเรื่อยๆ