Google ने मेरी कंपनी का Google Cloud अकाउंट तीसरी बार सस्पेंड कर दिया

• SSLMate का Google Cloud अकाउंट तीसरी बार बिना किसी पूर्व सूचना के सस्पेंड कर दिया गया, जिससे सर्विस इंटीग्रेशन फ़ीचर बार-बार ठप हो गए
• ग्राहकों के Cloud DNS और Cloud Domains इंटीग्रेशन के लिए Google के दस्तावेज़ों के अनुसार service account बनाकर delegation देने वाली संरचना इस्तेमाल की गई, लेकिन यही तरीका बार-बार सस्पेंशन का निशाना बना
• पहला सस्पेंशन (2024) रिकवरी प्रक्रिया की अक्षम्यता और अस्पष्ट कारणों की वजह से भारी भ्रम का कारण बना, और उसके बाद के दो सस्पेंशन में भी बिना पूर्व सूचना सिर्फ़ automated ईमेल ही बार-बार आते रहे
• विकल्प के तौर पर long-lived key आधारित authentication सुरक्षा के लिहाज़ से कमज़ोर है, और OIDC(OpenID Connect) की सेटअप प्रक्रिया ज़रूरत से ज़्यादा जटिल है
• नतीजतन, Google Cloud इंटीग्रेशन में security, convenience और stability में से सिर्फ़ दो ही चुन पाने की संरचनात्मक सीमा सामने आती है

---

Google Cloud अकाउंट के बार-बार सस्पेंड होने का मामला

• SSLMate का Google Cloud अकाउंट 2024 और 2025 में लगातार शुक्रवारों को बिना किसी पूर्व सूचना के सस्पेंड किया गया
  • इससे पहले 2024 में भी यही सस्पेंशन हुआ था, और तीनों बार न तो स्पष्ट कारण बताया गया और न दोबारा होने से बचने का तरीका दिया गया
• SSLMate, ग्राहकों के Google Cloud अकाउंट के साथ इंटीग्रेट करने के लिए service account delegation तरीका इस्तेमाल करता है
  • हर ग्राहक के लिए SSLMate project के तहत एक service account बनाया जाता है, और ग्राहक उस अकाउंट को Cloud DNS और Cloud Domains की access permission देते हैं
  • SSLMate ज़रूरत पड़ने पर उस service account को virtual तौर पर impersonate करके access करता है
  • यह संरचना Google के आधिकारिक दस्तावेज़ों में सुझाए गए तरीके पर आधारित है, और long-term credentials के बिना सुरक्षित तथा सेटअप में आसान तरीका है

पहला सस्पेंशन (2024)

• पहले सस्पेंशन के समय सभी customer integration फ़ीचर फ़ेल हो गए और console access बंद हो गया
  • Google support टीम ने जवाब दिया, लेकिन अकाउंट disable होने की वजह से ईमेल bounce हो रहे थे, जिससे रिकवरी प्रक्रिया अक्षम साबित हुई
  • project ID माँगा गया, लेकिन console access न होने के कारण वह दिया नहीं जा सका
  • फ़ोन नंबर verification के बाद सिर्फ़ कुछ project बहाल हुए, और अगले दिन फिर automated ईमेल से access restriction की सूचना मिली
  • उसके बाद कई automated ईमेल के बाद लगभग 19 घंटे में पूरा restoration हुआ
• Google ने सस्पेंशन का कारण नहीं बताया, और पहले से कोई ईमेल चेतावनी भी नहीं दी गई थी
  • इसके बाद SSLMate ने जल्दी पता लगाने के लिए integration error rate मॉनिटर करने वाला health check फ़ीचर जोड़ा

दूसरा सस्पेंशन (लगभग अक्टूबर 2025)

• health check फ़ेल हुआ और ज़्यादातर इंटीग्रेशन ने “Invalid grant: account not found” त्रुटि लौटाई
  • console login संभव था, लेकिन हर project के लिए सिर्फ़ “दी गई जानकारी के आधार पर बहाल किया गया” जैसा ईमेल मिला
  • सस्पेंशन की सूचना वाला ईमेल अब भी नहीं मिला
  • उसके बाद इंटीग्रेशन फ़ीचर सामान्य हो गए

तीसरा सस्पेंशन (नवंबर 2025)

• फिर health check फ़ेल होने के बाद console access पर नए प्रकार का error message दिखाई दिया
  • ज़्यादातर project सस्पेंड थे, जिनमें customer integration वाले project भी शामिल थे
  • शुक्रवार को appeal जमा की गई, लेकिन रविवार को पूरे अकाउंट के सस्पेंड होने की सूचना वाला ईमेल मिला
  • सोमवार को, यह पोस्ट Hacker News पर आने के तुरंत बाद ज़्यादातर project बहाल हो गए, और कुछ घंटों बाद पूरी access वापस मिल गई
  • इस बार भी सस्पेंशन के कारण या रोकथाम के तरीके नहीं बताए गए

अपवाद ग्राहक का मामला

• सभी सस्पेंशन अवधियों में भी एक ग्राहक का इंटीग्रेशन सामान्य रूप से काम करता रहा
  • उसी project के service account का उपयोग करने के बावजूद वह प्रभावित नहीं हुआ
  • कारण के बारे में कोई अतिरिक्त स्पष्टीकरण नहीं दिया गया

Google Cloud पर निर्भरता की समस्या और विकल्प

• SSLMate ने निष्कर्ष निकाला कि production environment में Google अकाउंट पर निर्भर नहीं रहा जा सकता
  • Google की प्रणाली में अकाउंट, project, या पूरा GCP मनमाने ढंग से सस्पेंड हो सकता है
• विकल्प 1: ग्राहक खुद service account बनाएँ और long-lived key के ज़रिए SSLMate को authentication दें
  • सेटअप आसान है, लेकिन key leak का जोखिम और rotation न कर पाने की वजह से सुरक्षा कमज़ोर है
• विकल्प 2: OpenID Connect(OIDC) का उपयोग
  • यह GitHub Actions और Azure इंटीग्रेशन में इस्तेमाल होने वाला मानक तरीका है, और long-term credentials के बिना सुरक्षित access देता है
  • लेकिन Google Cloud में इसका सेटअप 7-step प्रक्रिया के रूप में ज़रूरत से ज़्यादा जटिल है

OIDC सेटअप की जटिलता

• OIDC इस्तेमाल करने के लिए ये चरण आवश्यक हैं
  1. IAM Service Account Credentials API सक्षम करना
  2. service account बनाना
  3. Workload Identity Pool बनाना
  4. Pool के भीतर Workload Identity Provider बनाना
  5. SSLMate को service account impersonate करने की अनुमति देना
  6. service account को role देना
  7. बने हुए service account और Provider ID को SSLMate को देना
• हर चरण में पिछले चरण के resource ID की ज़रूरत पड़ती है, इसलिए ग्राहकों के लिए इसे फ़ॉलो करना कठिन है
• लेखक ने निम्न चरणों को अनावश्यक प्रक्रिया बताया
  • service account बनाए बिना भी सीधे role assign किया जा सकना चाहिए
  • ज़्यादातर मामलों में Pool में सिर्फ़ एक Provider होता है, इसलिए Pool बनाना अपने आप में अनावश्यक duplication है
  • Provider बनाए बिना भी OIDC issuer URL और subject को सीधे role दिया जा सकना चाहिए

संरचनात्मक समस्या और निष्कर्ष

• मौजूदा Google Cloud इंटीग्रेशन में निम्न तीन में से सिर्फ़ दो ही चुने जा सकते हैं
  1. long-term credentials न हों
  2. ग्राहक के लिए आसान सेटअप हो
  3. मनमाने सस्पेंशन से सुरक्षित हो
• SSLMate का service account आधारित तरीका security और convenience देता है, लेकिन सस्पेंशन का जोखिम बना रहता है
• service account + key तरीका आसान सेटअप और कम सस्पेंशन जोखिम देता है, लेकिन security कमज़ोर है
• OIDC तरीका security और suspension safety देता है, लेकिन सेटअप जटिल है
• निष्कर्ष यह है कि जब तक Google OIDC को first-class integration method के रूप में सरल नहीं बनाता, तब तक सुरक्षित और स्थिर इंटीग्रेशन मुश्किल रहेगा

पाठक टिप्पणियों का सार

• एक पाठक ने कहा, “कोई दूसरा cloud provider इस्तेमाल करो, GCP सबसे खराब है”
• लेखक ने जवाब दिया, “ग्राहक GCP इस्तेमाल करते हैं, इसलिए इंटीग्रेशन के लिए यह ज़रूरी है”
• एक अन्य पाठक ने कहा, “security और reliability का टकराव simplicity से होता है”, और यह भी कि simplicity को प्राथमिकता देने वाले ग्राहक शायद इसके लिए उपयुक्त नहीं हैं

[ndrgrd]

"Android developer verification का अंत भी बिल्कुल ऐसा ही होगा. बहुत से लोगों को Android के लिए डेवलपमेंट करने से बैन कर दिया जाएगा."

Hacker News की रायों में से यह सबसे ज़्यादा याद रहने वाली बात है। मुझे लगता है, वह समय दूर नहीं है.

[GN⁺]

Hacker News टिप्पणियाँ

• लोग Google को एक विश्वसनीय पार्टनर मानते हैं, लेकिन असल में यह एक बड़े रिटेल कारखाने जैसी डिज़ाइन की गई सिस्टम है
  यह लाखों लोगों को लक्ष्य करती है, और एक गलत स्वचालित सुरक्षा उपाय हज़ारों लोगों की ज़िंदगी बर्बाद कर सकता है
  customer support की कमी या automation से आने वाले बेमतलब जवाब सिर्फ cost cutting नहीं, बल्कि कानूनी ज़िम्मेदारी कम करने की रणनीति जैसे लगते हैं

  • “मैं Google पर भरोसा करता हूँ” सुनकर हँसी आती है
    ज़्यादातर लोग जानते हैं कि उनका Google account कभी भी बिना वजह suspend हो सकता है
    सच में, लगभग हर किसी के आसपास एक-दो लोग ऐसे मिल जाएंगे जिन्होंने account access खो दिया हो
    मेरा नहीं मानना कि multi-million dollar contract के बिना कोई Google को सचमुच पार्टनर मानता है

• हर platform scale को सबसे ऊपर रखता है
  individual user के साथ मानवीय रिश्ता बनाए रखते हुए drug dealer जैसी profitability बनाए रखना असंभव है
  अगर एक भला इंसान भी गलती से फँस जाए, तो उसे ‘ज़रूरी लागत’ मान लिया जाता है
  कल Wise, उससे पहले GitHub account इसी तरह block हुए
  कंपनियाँ लोकतंत्र की तरह नहीं, बल्कि सामंती जागीर की तरह चलाई जाती हैं
  अगर automated system आपको अपराधी मान ले, तो बिना किसी सुनवाई के सीधे सज़ा मिलती है

  • इसलिए मैं हमेशा छोटी कंपनियाँ चुनने की कोशिश करता हूँ
    वहाँ असली इंसानों से बात की जा सकती है, सिर्फ chatbot से नहीं
    अभी मैं Tuta Mail इस्तेमाल कर रहा हूँ, और उसकी quantum-resistant encryption व ad-free environment मुझे पसंद है
    मैं अपने domain पर जितने चाहूँ उतने alias address भी बना सकता हूँ

• कुछ साल पहले मेरा YouTube Premium account spam के नाम पर block कर दिया गया था
  मैं सिर्फ वीडियो देखता था, फिर भी account delete कर दिया गया और payment page तक की access रोक दी गई
  हर 3 हफ्ते में सिर्फ एक बार की जा सकने वाली रोबोट-जैसी appeal process से गुजरते हुए भी charges लगते रहे
  Google One का paid support भी “वह दूसरी team है, हम मदद नहीं कर सकते” कहकर बेकार साबित हुआ
  आखिरकार मैंने card cancel करके मामला सुलझाया, और कुछ महीनों बाद “यह गलती थी” वाला message मिला
  विडंबना यह कि WeChat ने एक दिन में इंसान से बात करवाकर समस्या सुलझा दी — तब लगा कि censorship state की customer support भी बेहतर है

• समस्या सिर्फ Google नहीं, बल्कि पूरी algorithm-dependent बड़ी कंपनी संरचना में है
  Reddit पर भी मेरा 20 साल पुराना account बिना वजह shadowban कर दिया गया था
  appeal को नज़रअंदाज़ कर दिया गया, और मेरी posts व comments सब filter हो गए
  Fediverse एक बेहतर वैकल्पिक मॉडल दिखाता है — छोटे communities और moderator का ऊँचा अनुपात इसकी कुंजी हैं

  • लेकिन Fediverse भी परफेक्ट नहीं है
    सिर्फ #fediblock tag से सैकड़ों servers पर auto-block हो जाने वाली संरचना फिर से बिना जवाबदेही वाली censorship पैदा कर देती है
    सच में, हमारे शहर का Mastodon instance इसी तरह बर्बाद हुआ और सब Bluesky पर चले गए
  • Google के पास पर्याप्त पैसा है
    ऐसे edge cases संभालने के लिए 100 लोगों की टीम रखना उसके लिए मुश्किल नहीं है
    लेकिन margin घटेगा, इसलिए वह ऐसा नहीं करता
  • ट्रिलियन-dollar कंपनियों का यह कहना कि “algorithm के अलावा कोई रास्ता नहीं” सिर्फ बहाना है
    बात पैसे की कमी की नहीं, बल्कि खर्च न करने के चुनाव की है

• आगे चलकर Gemini API में भी ऐसी समस्या आ सकती है
  अगर कोई customer policy के खिलाफ image generate करे, तो उसी समय business Gmail या personal recovery Gmail तक permanently suspend किया जा सकता है

  • अगर external customer data input कर रहे हैं या images generate कर रहे हैं, तो built-in moderation tools ज़रूर enable करने चाहिए

• Android developer verification भी शायद इसी दिशा में जाएगा
  बहुत से developers के developer credentials suspend होने की आशंका है, वह भी बिना साफ वजह के

  • सच कहें तो यह पहले से ही गंभीर स्तर पर है
    मैंने पहले एक छोटे business में ऐसा मामला देखा था जहाँ कर्मचारियों के personal accounts भी इस वजह से block कर दिए गए कि वे “पहले से suspend किए गए developer account से जुड़े” थे
  • बुनियादी तौर पर Android development की संरचना किसी और की ज़मीन पर खेती करने वाले बटाईदार जैसी है
    platform पर इतनी निर्भरता में expertise बनाए रखना मुश्किल लगता है

• हमारी service में भी सिर्फ “Login with Google” button इस्तेमाल होता था, लेकिन अचानक account block हो गया
  कारण बस इतना बताया गया: “terms violation”
  हमने appeal डाली और users के लिए login का alternative जल्दबाज़ी में तैयार कर रहे थे, तभी अगले दिन अचानक “appeal approved” वाला mail आ गया
  आखिरकार account वापस मिल गया, लेकिन अविश्वास रह गया

  • मैं होता तो अब “Login with Google” support बंद कर देता
  • मेरा मानना है कि social login की जगह username/password, MFA, और Passkey ही बेहतर हैं

• मेरा AdSense account सिर्फ ad में एक exclamation mark डालने की वजह से तीन बार suspend हुआ
  अंत में मैंने account बंद कर दिया, लेकिन लगता है कि अब भी मुझे “potential fraud account” की तरह track किया जा रहा होगा

  • यह बेतुका है। अगर किसी system में rule-violating ads को auto-block करने की क्षमता है, तो कम से कम ad लिखते समय warning देनी चाहिए
    अगर कोई नया user एक घंटे में suspend हो जाता है, तो सवाल है कि sign-up process को शुरू से इतना आसान क्यों बनाया गया
  • मेरा account भी इसी वजह से permanently suspend हुआ था। कई साल पुरानी बात है, लेकिन आज भी हैरानी होती है
  • exclamation mark समस्या है, यह बात समझ नहीं आती; print ads में तो यह बहुत पहले से आम punctuation रही है
  • सच में exclamation mark banned था, या यह सिर्फ system error था, यह जानने की जिज्ञासा है

• ऐसी स्थिति में सोचता हूँ कि Google पर मुकदमा किया जाए या कड़े regulation की माँग की जाए

  • लेकिन सिर्फ इस आधार पर कि “कंपनी ने मुझसे कारोबार करने से इनकार किया”, मुकदमे की ज़मीन कमज़ोर होती है
  • फिर भी small claims court में कुछ संभावना हो सकती है
    सुना है कि कई बार Google पेश ही नहीं होता, या TOS का सहारा लेकर सफाई देता है और उसी से judge पर उलटा असर पड़ जाता है

• सोचता हूँ कि suspended email account से registered Passkey-only login account का क्या होता होगा
  Google Password Manager में synced Passkey account suspend होने के बाद भी काम करती है या नहीं,
  या फिर email access बंद होने से recovery असंभव हो जाती है — शायद बहुत कम लोगों ने इसे वास्तव में test किया होगा