Google Sync और Less Secure Apps समर्थन को चरणबद्ध रूप से बंद करना
Google Workspace खातों के लिए Google Sync और “Less Secure Apps” पासवर्ड एक्सेस को चरणबद्ध रूप से बंद कर रहा है, और संगठनों को IMAP, POP और SMTP के लिए OAuth-आधारित प्रमाणीकरण या app-specific passwords की ओर धकेल रहा है। टिप्पणीकार credential stuffing और phishing के खिलाफ मजबूत सुरक्षा का स्वागत करते हैं, लेकिन legacy clients, printers, और scripts के टूटने, छोटे प्रोजेक्ट्स के लिए OAuth की जटिलता और लागत, और Google के अपने apps तथा ecosystem lock-in की ओर एक कथित धक्का को लेकर चिंतित हैं। कई लोग app passwords और third-party mail providers को व्यावहारिक workaround के रूप में इंगित करते हैं, जबकि यह सवाल उठाते हैं कि Google उन विकल्पों को कितने समय तक उपलब्ध रखेगा।
परिवर्तन का दायरा
- कई लोगों ने नोट किया कि HN शीर्षक भ्रामक है: Google “Less Secure Apps” (username + मुख्य पासवर्ड) और Workspace के लिए Google Sync (ActiveSync) को बंद कर रहा है, न कि IMAP/SMTP/POP को स्वयं।
- App-specific passwords और OAuth अभी भी समर्थित हैं; कई उपयोगकर्ता पुष्टि करते हैं कि Workspace support ने स्पष्ट रूप से कहा है कि IMAP, POP, और SMTP के लिए app passwords काम करेंगे।
- Personal Gmail ने LSA पहले ही खो दिए थे; यह Workspace के लिए संक्रमण को पूरा करता है।
App passwords और legacy devices
- प्रिंटरों, scanners, और पुराने clients (जैसे, Outlook 2007, iOS Mail via Exchange) को लेकर भारी चिंता है।
- थ्रेड की सहमति: ये app passwords के जरिए, या कुछ मामलों में SMTP relays के जरिए, काम करते रह सकते हैं।
- कुछ admins रिपोर्ट करते हैं कि app passwords भरोसेमंद रूप से काम कर रहे हैं; अन्य लोगों को वे भ्रमित करने वाले या अविश्वसनीय लगते हैं और चिंता करते हैं कि सामान्य users/IT को परेशानी होगी।
OAuth की जटिलता और घर्षण
- कई लोग शिकायत करते हैं कि OAuth2 भ्रमित करने वाला, अपारदर्शी, और त्रुटिपूर्ण है, खासकर headless servers और scripts के लिए।
- जिन समस्याओं का उल्लेख किया गया: अस्पष्ट error messages, token behavior में बदलाव, refresh-token की quirks, और verified production client रखने के लिए Google की ऊँची बाधा (और लागत)।
- कई tools और workarounds का उल्लेख है (OAuth proxies, CLI helpers, rclone, आदि), लेकिन उनके लिए अक्सर manual OAuth client setup चाहिए।
सुरक्षा तर्क और पासवर्ड की मजबूती
- परिवर्तन के पक्ष में: LSAs credential stuffing को सक्षम करते हैं और 2FA की कमी रखते हैं; OAuth और app passwords blast radius और phishing risk को कम करते हैं।
- अन्य लोग तर्क देते हैं कि मजबूत, unique passwords + TLS और वैकल्पिक 2FA पहले से ही पर्याप्त हैं, और इसे “security theater” तथा users के प्रति hostile बताते हैं।
- app-password entropy (16 random lowercase chars) पर बहस। अधिकांश लोग निष्कर्ष निकालते हैं कि 65–75 bits पर्याप्त हैं, खासकर online-rate limits के साथ।
Lock-in, UX, और प्रतिस्पर्धा संबंधी चिंताएँ
- कई लोग इसे users को third‑party clients से हटाकर Gmail apps की ओर धकेलने के तरीके के रूप में देखते हैं, खासकर iOS Mail में Exchange push खोने और JMAP जैसे protocols के प्रति Google के प्रतिरोध को देखते हुए।
- कुछ संस्थाएँ पहले ही Exchange/O365 के साथ IMAP को प्रतिबंधित करती हैं, जिससे proprietary ecosystems की व्यापक प्रवृत्ति का डर और मजबूत होता है।
- कई उपयोगकर्ता विकल्पों पर चर्चा करते हैं या उनका समर्थन करते हैं (self-hosting, Fastmail, Proton, Tuta), बेहतर interoperability या spam handling का हवाला देते हुए।
अनिश्चितताएँ
- app passwords का भविष्य अस्थिर माना जा रहा है: Google docs उन्हें हतोत्साहित करते हैं, और कुछ organizations पहले deprecation warnings की रिपोर्ट करती हैं।
- app passwords के माध्यम से non‑OAuth IMAP/SMTP के लिए दीर्घकालिक समर्थन का सटीक स्तर “फिलहाल” जैसा माना जाता है, गारंटीशुदा नहीं।