Google đánh dấu các trang Immich là trang nguy hiểm

 (immich.app)
1 điểm bởi GN⁺ 2025-10-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • Gần đây, do dịch vụ Google Safe Browsing, mọi trang liên quan đến Immich đều nhận cảnh báo nguy hiểm
  • Toàn bộ miền immich.cloud bị ảnh hưởng, khiến việc truy cập gần như bị chặn trên hầu hết trình duyệt
  • Nguyên nhân là các URL triển khai nội bộ như môi trường Preview bị tự động thu thập dữ liệu và bị xử lý thành dương tính giả
  • Nhóm đã khôi phục tạm thời bằng cách khiếu nại qua Google Search Console, nhưng vấn đề lại tái diễn mỗi khi tạo Preview mới
  • Đây là vấn đề mang tính cấu trúc do đặc thù của dịch vụ mã nguồn mở·tự lưu trữ, và trong tương lai môi trường Preview sẽ được tách sang một miền riêng

Sự cố Google đánh dấu các trang Immich là trang nguy hiểm

20 tháng 10 năm 2025
By Jason Rasmussen

Tổng quan

  • Đầu tháng này, mọi website thuộc *.immich.cloud bị phân loại là trang nguy hiểm, và người dùng nhìn thấy màn hình cảnh báo bảo mật trên trình duyệt (thường được gọi là "red-screen-of-death")
  • Không ai trong nhóm thực sự hiểu rõ cơ chế hoạt động của tính năng trình duyệt này, nhưng giờ kiến thức đó đã được thêm vào danh sách 'cursed knowledge'

Bối cảnh

  • Google cung cấp miễn phí dịch vụ Safe Browsing, nhằm xác định xem một trang có chứa mã độc, phần mềm không mong muốn hay hành vi lừa đảo xã hội hay không
  • Các trình duyệt lớn như Chrome, Firefox đều tích hợp dịch vụ này
  • Cách dịch vụ thực sự đưa ra phán định rủi ro vẫn không rõ ràng
  • Khi một trang bị phân loại là nguy hiểm, phần lớn người dùng sẽ không thể sử dụng trang đó
  • Chỉ một số rất ít người dùng có thể tiếp tục truy cập thông qua các liên kết 'Xem thêm' và 'Truy cập trang web không an toàn'

Phát hiện tình trạng bị gắn cờ

  • Đầu tháng này, nhiều trang trong miền immich.cloud bị gắn nhãn "nguy hiểm", đồng thời người dùng cũng phàn nàn rằng các instance Immich tự triển khai của họ cũng bị gắn cờ
  • Mọi trang nội bộ, bao gồm cả môi trường Preview đang dùng trong nội bộ, cũng đều hiện cảnh báo
  • Việc phải đi qua quy trình xem "trang web không an toàn" mỗi lần truy cập gây bất tiện liên tục

Ứng phó qua Google Search Console

  • Sau vài ngày mà cảnh báo vẫn không được gỡ bỏ, nhóm quyết định sử dụng Google Search Console, kênh phản hồi chính thức

  • Dịch vụ này yêu cầu tạo tài khoản Google, sử dụng Search Console và gửi yêu cầu xem xét đối với các trang bị gắn cờ

  • Search Console có cung cấp một phần giải thích về lý do bị đánh dấu nguy hiểm

    • "Google has detected harmful content on some of your site's pages"
    • "These pages may try to install unwanted software or expose personal information, among other risky behaviors"

  • Khi kiểm tra danh sách đầy đủ các URL bị nêu vấn đề, tất cả đều là URL liên quan đến môi trường Preview

  • Điều gây sốc nhất là chỉ cần một subdomain riêng lẻ bị gắn cờ thì toàn bộ miền cũng bị đánh giá là có vấn đề

Ảnh hưởng

  • Môi trường Preview và các dịch vụ nội bộ (zitadel, outline, grafana, victoria metrics, v.v.) đều nằm trong phạm vi bị ảnh hưởng
  • Máy chủ tile production (tiles.immich.cloud) cũng bị ảnh hưởng
  • Tuy nhiên, do tile server được gọi thông qua JavaScript và không có giao diện người dùng trực tiếp, nên xác nhận được rằng nó vẫn hoạt động bình thường

Cố gắng "giải quyết" vấn đề

  • Trong Google Search Console, cần dùng chức năng Request Review để khiếu nại và giải thích cách đã xử lý vấn đề
  • Nếu không thực sự khắc phục vấn đề mà chỉ gửi yêu cầu đánh giá lại, thời gian xem xét sẽ kéo dài

Yêu cầu khôi phục trang nguy hiểm

  • Vì nhóm đánh giá rằng thực tế không có vấn đề gì nghiêm trọng, nên đã gửi phần giải thích phản hồi như sau

    • Immich là một ứng dụng tự lưu trữ, và nhóm Immich (https://immich.app/) trực tiếp quản lý và vận hành toàn bộ miền liên quan
    • Tất cả các trang bị gắn cờ đều chỉ là môi trường tự triển khai chính thức, không mạo danh bất kỳ ai

  • Trong vòng 1–2 ngày, miền đã được đánh giá lại là an toàn và trạng thái truy cập được khôi phục

Nỗ lực giảm thiểu vấn đề

  • Khi thêm nhãn preview vào GitHub Pull Request, môi trường Immich Preview sẽ được tạo tự động, và URL Preview cũng được tạo ngay cùng với bình luận xác minh danh tính

    https://pr-<num>.preview.internal.immich.cloud/

  • Mỗi khi một môi trường Preview mới được tạo, miền immich.cloud lại tiếp tục bị đánh giá là nguy hiểm

  • Có suy đoán rằng Google thu thập dữ liệu từ GitHub, phát hiện URL mới, truy cập chúng rồi đánh dấu là nguy hiểm

  • Biện pháp hiện tại là lên kế hoạch tách môi trường Preview sang một miền riêng chuyên dụng (immich.build)

Vấn đề lớn hơn

  • Hệ thống Google Safe Browsing dường như được thiết kế mà không tính đến đặc thù của phần mềm mã nguồn mở và tự lưu trữ
  • Ngoài Immich, nhiều dự án phổ biến khác cũng gặp vấn đề tương tự
  • Google có thể chặn gần như bất kỳ miền nào một cách tùy ý, và hiện không có nhiều biện pháp ứng phó thực tế ngoài việc liên tục gửi yêu cầu đánh giá lại tới Google

Cheers,
Nhóm Immich

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-10-23
Ý kiến trên Hacker News

  • Nếu bạn định host nội dung người dùng trên subdomain, bạn nên đăng ký site vào Public Suffix List https://publicsuffix.org/list/
    Làm vậy thì một subdomain bị nhiễm sẽ không ảnh hưởng đến toàn bộ site

    • Trong giới web developer, gần như là một kiểu hiểu ngầm rằng nếu host nội dung do người dùng tạo ra thì nhất định phải có mặt trong PSL
      Nhưng vì rất khó biết được chuyện này nếu chưa từng tự mình gặp phải vấn đề như case của Immich, nên đa số chỉ biết sau khi đã đụng phải ngoài thực tế

    • Trước đây trình duyệt dùng một thuật toán chỉ chặn việc đặt cookie quá rộng khi domain không có dấu chấm nào cả (ví dụ: .com, .org)
      Nhưng với các domain cấp dưới như .co.uk thì lại phát sinh vấn đề cookie bị gửi sang mọi domain đã đăng ký bên dưới
      Vì chính sách đăng ký của từng top-level domain đều khác nhau nên không có cách nào giải quyết ở mức phát triển, cuối cùng mới xuất hiện cách quản lý thủ công bằng danh sách như Public Suffix List
      Nhìn việc trình duyệt vốn dĩ đã có giới hạn kiểu này từ đầu khiến web có cảm giác như một chiếc xe được dán bằng băng keo https://publicsuffix.org/learn/

    • Xem các link trong bài này thì thực ra có hai vấn đề

  1. Vấn đề đăng ký vào public suffix list khi đưa nội dung người dùng lên chính domain của mình như Immich
  2. Vấn đề người dùng host các dự án mã nguồn mở như immich, jellyfin trên domain của riêng họ rồi bị hiểu nhầm là phishing
    Cái đầu nếu biết về PSL thì tương đối dễ xử lý, còn cái thứ hai thì khó chịu hơn nhiều, nhất là khi tên domain có chứa tên phần mềm

  • Vấn đề không nằm ở bản thân nội dung người dùng, mà là tôi đã tự upload bản release build của Immich lên server của mình và Google chặn toàn bộ domain của tôi

  • Không phải vì Immich thực sự host nội dung người dùng, mà là issue này xảy ra trên subdomain dành cho PR preview
    Tôi nghĩ đây rõ ràng là lỗi trong code của Google

  • Tôi khuyên nên xem toàn bộ danh sách ‘Cursed Knowledge’ của đội Immich https://immich.app/cursed-knowledge

    • Một số mục trong danh sách đó thậm chí lại giống thiết kế bảo mật hiển nhiên hơn
      Ví dụ, ‘một số điện thoại sẽ tự động xóa thông tin GPS khi một ứng dụng không có quyền vị trí đọc ảnh’
      Điều này thực ra có vẻ là hành vi tự nhiên và đáng mong muốn

    • Sẽ hay nếu loại tri thức kiểu này có thể được chia sẻ giữa các dự án bằng một file chuẩn như CURSED.md
      Như vậy mọi người đều có thể học được các kiến thức thu được từ thực chiến

    • ‘Tham số truy vấn Postgres có giới hạn 65.000 cái’
      Buồn cười ở chỗ từng đó vẫn còn không đủ

  • Tôi luôn thắc mắc về những câu cảnh báo kiểu này
    Họ gần như dán nhãn trực tiếp là ‘kẻ lừa đảo’, ‘kẻ tấn công’, vậy có vướng phỉ báng không
    Cảnh báo với file thực thi chưa được xác minh của Microsoft cũng tương tự
    Ngày trước họ còn nói kiểu ‘chúng tôi không biết nó có an toàn không’, còn giờ thì hiển thị theo kiểu ‘bạn là kẻ tấn công’

    • Từ ‘kẻ lừa đảo’ không xuất hiện trong cảnh báo thực tế; câu chữ là kiểu ‘kẻ tấn công có thể ở trên site’, ‘có thể (might)’
      Nó cũng bao gồm cả trường hợp bị hacker bên thứ ba xâm nhập
      Không phải đang chỉ đích danh chủ site là kẻ tấn công
      Chắc đội pháp lý đã rà soát câu chữ này rất cẩn thận

    • Tôi không phải luật sư, nhưng hình như chưa có vụ nào vì những cảnh báo kiểu này mà ra tòa đúng không
      Có vẻ vẫn có thể cấu thành phỉ báng

  • Có thể đây không phải vấn đề quá lớn, nhưng tôi thắc mắc liệu ở chỗ như Immich, ai cũng có thể gửi PR rồi chỉ cần gắn tag preview là nội dung đó sẽ tự động được host tại https://pr-<num>.preview.internal.immich.cloud hay không
    Cuối cùng chẳng phải thành ra ai cũng có thể đăng bất cứ thứ gì sao?

    • Trên GitHub, người có thể thêm label bị giới hạn ở cộng tác viên nên không hoàn toàn mở
      Dù vậy, nếu cộng tác viên có thể gửi một PR bình thường trước, lấy được label rồi sau đó đăng gì cũng được thì vẫn có rủi ro

    • Nghe như một ý tưởng phishing đúng kiểu không tốn đồng nào

  • Thật khó tin là một công ty có thể kiểm soát cả việc bạn được truy cập site nào
    Chưa đủ với chuyện hạn chế chạy ứng dụng, giờ còn đến mức này nữa

    • Đây là hệ quả của việc Quốc hội Mỹ vận hành kém hiệu quả trong thời gian dài, dẫn tới đủ loại vấn đề

    • Tôi thấy lạ là ngay cả những người ghét quảng cáo cũng vẫn bị khiến cho nghĩ các tập đoàn lớn như vậy là ‘cool’
      Không ai muốn quảng cáo cả, nhưng với doanh nghiệp đó là cách kiếm tiền
      Tôi không hiểu Google làm cách nào để khoác cho hình ảnh doanh nghiệp phi đạo đức này vẻ ngoài ‘ngầu’ như vậy

  • Tôi có cảm giác internet mở đã kết thúc rồi
    Giờ mọi thứ đều bị các thế lực độc quyền kiểm soát
    Tôi đã để một ứng dụng iOS trên store suốt 3 năm thì đột nhiên Apple yêu cầu một loại giấy phép mới vốn còn chẳng tồn tại, rồi bảo nếu không có thì sẽ gỡ ứng dụng
    Trong 3 năm đó chẳng có gì thay đổi cả mà vẫn như vậy
    Tôi ngày càng chán với việc giờ đến cả self-hosting cũng không còn thật sự do mình quyết định nữa

    • Nếu bạn kể chi tiết hơn về vấn đề giữa ứng dụng iOS và yêu cầu của Apple thì sẽ rất hữu ích

  • Bạn tôi đồng thời cũng là khách hàng của tôi từng dùng một dịch vụ host kiểu WordPress và một redirect đơn giản
    Rồi host đó bị đưa vào blacklist ‘site nguy hiểm’ lúc nào không hay
    Ngay cả sau khi gỡ redirect, chính domain của họ vẫn bị vấy bẩn, đến mức Google không nhận bất kỳ email nào từ domain đó nữa
    Sau khi gửi yêu cầu rà soát thì họ được gỡ khỏi blacklist, nhưng hiệu ứng chặn email vẫn tồn tại vĩnh viễn
    Cuối cùng họ phải đăng ký domain mới; cách làm của Google chỉ càng tạo động lực cho người ta liên tục lập tài khoản dùng một lần

    • Nghe chuyện như vậy thấy thật đáng sợ
      Chỉ tưởng tượng domain tôi đã dùng tốt suốt 25 năm mà bị đưa nhầm vào blacklist rồi cả email cũng bị chặn là đã khủng khiếp rồi

  • Kết luận của tôi là nên tách domain theo từng mục đích sử dụng
    Dù việc này có nhược điểm là khiến nhiều TLD trên toàn cầu trông giống dịch vụ chính thức hơn, nhưng case này càng làm tôi tin như vậy
    Ví dụ
    www.contoso.com (công khai)
    www.contoso.blog (công khai, có bình luận người dùng)
    contoso.net (nội bộ)
    staging.contoso.dev (phát triển/điểm cuối zero-trust)
    raging-lemur-a012afb4.contoso.build (dùng cho snapshot)

    • Nhưng nếu tách domain như vậy thì từ góc nhìn người dùng lại càng dễ trông giống phishing hơn
      Trước đây tôi từng nhận mail từ ‘githubnext.com’, mà vì tôi biết Github = github.com nên đương nhiên nghĩ đó là phishing hoặc spam
      Hóa ra lại là dịch vụ thật

    • Cách tiếp cận hay đấy

  • Tôi cũng đang gặp đúng vấn đề này với domain của mình
    Google đánh dấu instance Immich của gia đình tôi là site nguy hiểm, khiến mọi dịch vụ khác chạy trên cùng domain đó cũng không thể truy cập bằng Chrome
    Đúng là có thể vượt qua cảnh báo, nhưng album ảnh tôi gửi cho mẹ vợ thì coi như không dùng được nữa

  • Tôi cũng từng gặp y hệt hồi đầu năm nay khi self-host Umami Analytics
    https://news.ycombinator.com/item?id=42779544#42783321
    Khi khiếu nại lên Google Search Console, tôi nhắc đến ‘biện pháp pháp lý’ thì lúc đó cờ đánh dấu mới được gỡ