Google ने Immich साइटों को खतरनाक साइट के रूप में चिह्नित किया

 (immich.app)
1 पॉइंट द्वारा GN⁺ 2025-10-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • हाल ही में Google Safe Browsing सेवा के कारण Immich से जुड़ी सभी साइटों पर खतरनाक होने की चेतावनी दिखने लगी
  • पूरे immich.cloud डोमेन पर असर पड़ा, जिससे अधिकांश ब्राउज़र में पहुंच व्यावहारिक रूप से अवरुद्ध हो गई
  • कारण यह था कि Preview environment जैसे आंतरिक deployment URL अपने-आप crawl होकर false positive के रूप में चिह्नित हो गए
  • Google Search Console में आपत्ति दर्ज कर अल्पकालिक रूप से बहाली की गई, लेकिन हर नए Preview के बनने पर समस्या फिर दोहराई गई
  • open source·self-hosting सेवा की प्रकृति के कारण यह एक संरचनात्मक समस्या है, और आगे Preview environment को अलग डोमेन में विभाजित करने की योजना है

Google ने Immich साइटों को खतरनाक साइट के रूप में चिह्नित करने की घटना

20 अक्तूबर 2025
By Jason Rasmussen

अवलोकन

  • इस महीने की शुरुआत में *.immich.cloud की सभी वेबसाइटों को खतरनाक साइट के रूप में वर्गीकृत कर दिया गया, और उपयोगकर्ताओं को ब्राउज़र में सुरक्षा चेतावनी (जिसे "red-screen-of-death" भी कहा जाता है) दिखाई देने लगी
  • टीम में किसी को भी इस ब्राउज़र सुविधा के काम करने के तरीके की स्पष्ट जानकारी नहीं थी, लेकिन अब यह संबंधित ज्ञान 'cursed knowledge' की सूची में जुड़ गया है

पृष्ठभूमि

  • Google Safe Browsing सेवा मुफ्त में उपलब्ध कराता है, जिसका उद्देश्य malware, unwanted software और social engineering जैसे जोखिमों का पता लगाना है
  • Chrome, Firefox जैसे प्रमुख ब्राउज़र इस सेवा को एकीकृत करते हैं
  • सेवा वास्तव में जोखिम का फैसला कैसे करती है, यह स्पष्ट नहीं है
  • किसी साइट को खतरनाक के रूप में वर्गीकृत कर दिए जाने पर, अधिकांश उपयोगकर्ता उस साइट का उपयोग नहीं कर पाते
  • केवल बहुत कम उपयोगकर्ता 'ज्यादा जानकारी' और 'सुरक्षित साइट पर जाएं' लिंक के जरिए ही आगे बढ़ सकते हैं

Flagged स्थिति का पता चलना

  • इस महीने की शुरुआत में immich.cloud डोमेन की कई साइटों पर "खतरनाक" संकेत दिखाई दिया, और उपयोगकर्ताओं ने शिकायत की कि उनके self-hosted Immich instance भी flagged हो गए हैं
  • आंतरिक रूप से इस्तेमाल हो रहे Preview environment सहित सभी internal साइटों पर भी यही चेतावनी दिखाई दी
  • हर बार "सुरक्षित साइट" देखने की प्रक्रिया से गुजरना एक लगातार परेशानी बन गया

Google Search Console के जरिए जवाबी कार्रवाई

  • कई दिन बीत जाने के बाद भी चेतावनी नहीं हटी, इसलिए आधिकारिक जवाबी कार्रवाई मार्ग Google Search Console का उपयोग करने का निर्णय लिया गया

  • इस सेवा के लिए Google account बनाना, Search Console का उपयोग करना, और flagged साइटों के लिए review request भेजना अनिवार्य है

  • Search Console ने जोखिम वर्गीकरण के कारणों पर कुछ जानकारी दी

    • "Google ने आपकी साइट के कुछ पेजों पर हानिकारक सामग्री का पता लगाया है"
    • "इन पेजों में unwanted software install करवाने या व्यक्तिगत जानकारी उजागर होने जैसे जोखिम हो सकते हैं"

  • समस्या वाले पूरे URL की सूची देखने पर पता चला कि वे सभी Preview environment से जुड़े URL थे

  • सबसे चौंकाने वाली बात यह थी कि केवल एक individual subdomain के flagged होने पर भी पूरे डोमेन को खराब माना जा रहा था

प्रभाव

  • Preview environment और internal services (zitadel, outline, grafana, victoria metrics आदि) सभी प्रभावित हुए
  • Production tile server (tiles.immich.cloud) भी इसकी चपेट में आया
  • हालांकि tile server JavaScript के जरिए request किया जाता है और उसका सीधा user interface नहीं है, इसलिए यह सामान्य रूप से काम करता हुआ पाया गया

समस्या को "हल" करने की कोशिश

  • Google Search Console में Request Review फीचर के जरिए आपत्ति दर्ज करनी होती है और यह बताना होता है कि समस्या कैसे हल की गई
  • यदि वास्तव में समस्या हल किए बिना केवल review मांगा जाए, तो जांच की अवधि लंबी हो जाती है

खतरनाक साइट बहाली अनुरोध

  • चूंकि वास्तविक रूप से कोई समस्या नहीं पाई गई, इसलिए नीचे दिए अनुसार स्पष्टीकरण भेजा गया

    • Immich self-hosting के लिए एक application है, और Immich टीम(https://immich.app/) पूरे संबंधित डोमेन का सीधे प्रबंधन और संचालन करती है
    • flagged की गई सभी साइटें आधिकारिक self-deployed environment हैं और किसी अन्य का प्रतिरूपण नहीं करतीं

  • 1–2 दिनों के भीतर डोमेन को फिर सामान्य माना गया और पहुंच बहाल हो गई

समस्या को कम करने के प्रयास

  • GitHub Pull Request पर preview label जोड़ने से Immich Preview environment अपने-आप बनता है, और बनते ही verification comment के साथ Preview URL तैयार हो जाता है

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

  • हर बार नया Preview environment बनने पर immich.cloud डोमेन फिर से खतरनाक घोषित कर दिया जाता है

  • अनुमान है कि Google GitHub को crawl करते हुए नए URL खोजता है, उन्हें एक्सप्लोर करता है, और फिर खतरनाक के रूप में चिह्नित कर देता है

  • वर्तमान उपाय के रूप में Preview environment को अलग समर्पित डोमेन (immich.build) में विभाजित करने की योजना बनाई जा रही है

इससे भी बड़ी समस्या

  • Google Safe Browsing system ऐसा लगता है कि open source और self-hosting software की प्रकृति को ध्यान में रखकर डिज़ाइन नहीं किया गया
  • Immich के अलावा कई लोकप्रिय प्रोजेक्ट्स ने भी ऐसी ही समस्या का अनुभव किया है
  • Google मनमाने ढंग से किसी भी डोमेन को ब्लॉक कर सकता है, और इसके खिलाफ व्यावहारिक रूप से Google से लगातार review मांगने के अलावा कोई खास उपाय नहीं है

Cheers,
The Immich Team

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-23
Hacker News टिप्पणियाँ

  • अगर आप user content को subdomain पर host करने वाले हैं, तो साइट को Public Suffix List में register करना चाहिए https://publicsuffix.org/list/
    इससे किसी संक्रमित subdomain का असर पूरी साइट पर नहीं पड़ेगा

    • अगर आप user-generated content host करते हैं, तो PSL में होना web developers के बीच एक तरह की implicit common knowledge मानी जाती है
      Immich के issue जैसी चीज़ें पहले से झेली न हों तो यह जानना मुश्किल है, इसलिए ज़्यादातर लोगों को यह तब तक पता नहीं चलता जब तक वे खुद इसका सामना न करें

    • पहले browsers एक ऐसा algorithm इस्तेमाल करते थे जो सिर्फ उन domains पर broadly cookie set होने से रोकता था जिनमें dot नहीं होता था, जैसे .com, .org
      लेकिन .co.uk जैसे sublevel domains में cookies सभी नीचे registered domains तक leak हो जाती थीं
      हर top-level domain की registration policy अलग होने की वजह से इसे development के स्तर पर हल करने का तरीका नहीं था, इसलिए अंत में Public Suffix List जैसी manually maintained list का तरीका आया
      यह देखकर कि browser में यह सीमा मूल रूप से मौजूद है, web कुछ-कुछ duct tape से बनी कार जैसा लगता है https://publicsuffix.org/learn/

    • इस पोस्ट से जुड़े कई links देखने पर लगता है कि वास्तव में दो समस्याएँ हैं

  1. Immich की तरह अपने domain पर user content डालने पर public suffix list में register करने की समस्या
  2. जब users immich, jellyfin जैसे open source projects को अपने domain पर host करते हैं, तो उसे phishing समझ लिए जाने की समस्या
    पहली समस्या PSL के बारे में पता हो तो अपेक्षाकृत आसान है, लेकिन दूसरी समस्या ज़्यादा पेचीदा है, खासकर जब domain name में software का नाम शामिल हो

  • समस्या user content नहीं है, बल्कि यह है कि मैंने Immich का release build सीधे अपने server पर host किया और Google ने मेरा पूरा domain block कर दिया

  • ऐसा इसलिए नहीं हुआ कि Immich वास्तव में user content host कर रहा था, बल्कि यह issue PR preview subdomain पर हुआ
    मेरे हिसाब से यह साफ़ तौर पर Google के code की समस्या है

  • मैं Immich टीम की पूरी ‘Cursed Knowledge’ सूची एक बार देखने की सलाह दूँगा https://immich.app/cursed-knowledge

    • सूची की कुछ बातें तो उल्टा बिल्कुल obvious security design जैसी लगती हैं
      उदाहरण के लिए, ‘कुछ phones location permission न रखने वाले app द्वारा image पढ़े जाने पर GPS information अपने-आप हटा देते हैं’
      यह तो बल्कि स्वाभाविक और desirable behavior लगता है

    • अच्छा होगा अगर इस तरह की जानकारी हर project में CURSED.md जैसी किसी standard file में साझा की जा सके
      इससे सब लोग field में सीखी गई तरह-तरह की practical knowledge सीख पाएँगे

    • ‘Postgres query parameters की limit 65,000 है’
      दिलचस्प यह है कि वह भी कम पड़ सकती है

  • ऐसी warning language में मुझे हमेशा एक बात पर हैरानी होती है
    वे सीधे किसी को ‘scammer’ या ‘attacker’ जैसा label दे देते हैं, तो क्या यह defamation नहीं बनता
    Microsoft की unverified executable warning में भी यही बात है
    पहले वे कहते थे, ‘हमें नहीं पता कि यह safe है या नहीं’, लेकिन आजकल यह ज़्यादा ‘आप attacker हैं’ जैसी निर्णायक भाषा लगती है

    • actual warning message में ‘scammer’ शब्द इस्तेमाल नहीं होता, बल्कि ‘site पर attacker हो सकता है’, ‘might’ जैसी wording होती है
      इसमें third-party hacker intrusion के मामले भी शामिल होते हैं
      यह site owner को attacker नहीं कहता
      कानूनी टीम ने शायद wording को काफ़ी सावधानी से review किया होगा

    • मैं वकील नहीं हूँ, लेकिन मुझे नहीं लगता कि ऐसी warning wording को लेकर मामला कभी अदालत तक गया है
      फिर भी यह defamation हो सकता है

  • यह शायद बहुत बड़ी समस्या न हो, लेकिन मैं सोच रहा हूँ कि Immich जैसी जगहों पर क्या कोई भी PR submit करके सिर्फ preview tag लगते ही उस content को https://pr-<num>.preview.internal.immich.cloud पर host करा सकता है
    आख़िर इसका मतलब तो यह हुआ कि कोई भी कुछ भी freely upload कर सकता है, है न?

    • GitHub में label जोड़ने की अनुमति collaborators तक सीमित होती है, इसलिए यह पूरी तरह खुला नहीं है
      फिर भी अगर कोई collaborator पहले एक वैध PR भेजकर label हासिल कर ले और उसके बाद कुछ भी upload कर सके, तो उसमें risk है

    • यह तो बिना पैसे वाला phishing idea लगता है

  • यह मानना मुश्किल है कि एक company यह तक नियंत्रित कर सकती है कि आप किन sites तक पहुँच सकते हैं
    app execution restrict करना ही काफ़ी नहीं था, अब बात यहाँ तक पहुँच गई है

    • यह अमेरिका की Congress के लंबे समय तक अक्षम ढंग से चलने के असर का एक और परिणाम है

    • मुझे हैरानी है कि ads को नापसंद करने वाले users तक को भी कैसे इन बड़ी कंपनियों को ‘cool’ मानने पर राज़ी कर लिया गया
      ads कोई नहीं चाहता, लेकिन company के लिए वही कमाई का ज़रिया हैं
      समझ नहीं आता कि Google जैसी अनैतिक company को कैसे ‘cool’ image में पैकेज कर दिया गया

  • ऐसा लगता है कि open internet खत्म हो चुका है
    अब सब कुछ monopolies के नियंत्रण में है
    मेरी iOS app 3 साल से store में थी, फिर अचानक Apple ने एक नया license माँगना शुरू कर दिया जो असल में मौजूद ही नहीं था, और कहा कि उसके बिना app हटा दी जाएगी
    तीन साल में कुछ बदला भी नहीं था, फिर भी यही हुआ
    अब self-hosting तक भी अपनी मर्ज़ी से न कर पाने की स्थिति से मैं धीरे-धीरे थक गया हूँ

    • अगर आप iOS app और Apple की requirement वाली समस्या के बारे में विस्तार से बताएँ, तो वह सच में मददगार होगा

  • मेरे एक दोस्त और client ने WordPress-आधारित hosting और एक simple redirect इस्तेमाल किया था
    किसी बिंदु पर host ‘dangerous site’ blacklist में चला गया
    redirect हटाने के बाद भी उसका अपना domain दूषित बना रहा, और इसके कारण Google उस domain से email भी बिल्कुल स्वीकार नहीं कर रहा था
    review request के ज़रिए blacklist से निकल तो गया, लेकिन email blocking का असर स्थायी रहा
    आख़िरकार उसने नया domain register किया, और Google का ऐसा behavior तो उल्टा सिर्फ one-off accounts बनाते रहने की प्रेरणा देता है

    • यह सुनकर डर लगता है
      मैंने भी 25 साल से अपना domain ठीक-ठाक चलाया है, और अगर वह गलती से blacklist हो जाए और email तक रुक जाए, तो यह कल्पना ही डरावनी है

  • मेरा निष्कर्ष यह है कि अलग-अलग उपयोगों के लिए अलग domains इस्तेमाल करना बेहतर है
    वैश्विक स्तर पर कई TLDs होने से यह कमी रहती है कि वे official service जैसे न लगें, लेकिन इस मामले ने मुझे और आश्वस्त किया है
    उदाहरण के लिए
    www.contoso.com (public)
    www.contoso.blog (public, user comments सहित)
    contoso.net (internal)
    staging.contoso.dev (development/zero-trust endpoint)
    raging-lemur-a012afb4.contoso.build (snapshot) की तरह इस्तेमाल किया जा सकता है

    • लेकिन domains इस तरह अलग करने से users को phishing जैसा लगने का ख़तरा कहीं ज़्यादा हो जाता है
      मुझे पहले ‘githubnext.com’ से mail मिला था, और मैं Github = github.com मानता था, इसलिए मैंने स्वाभाविक रूप से उसे phishing या spam समझा
      बाद में पता चला कि वह असली service थी

    • अच्छा तरीका है

  • मैं भी अभी अपने domain पर यही समस्या झेल रहा हूँ
    Google ने हमारे family Immich instance को dangerous site मान लिया, और उसी domain पर चल रही बाकी सभी services भी Chrome में inaccessible हो गईं
    तकनीकी रूप से warning bypass की जा सकती है, लेकिन अपनी सास को भेजा गया photo album ही बेकार हो जाता है

  • इसी साल की शुरुआत में self-hosted Umami Analytics के साथ मेरा भी बिल्कुल यही अनुभव रहा था
    https://news.ycombinator.com/item?id=42779544#42783321
    जब मैंने Google Search Console में आपत्ति दर्ज करते हुए ‘legal action’ का ज़िक्र किया, तभी जाकर flag हटा

    • क्या आप बता सकते हैं कि आपने आपत्ति में क्या लिखा था
      मैं भी कई सालों से यही समस्या झेल रहा हूँ
      https://news.ycombinator.com/item?id=45678095