महिलाओं के dating safety app "Tea" में हैक, उपयोगकर्ता जानकारी 4chan पर लीक

 (404media.co)
2 पॉइंट द्वारा GN⁺ 2025-07-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • महिलाओं की safety dating app 'Tea' का database एक्सपोज़ हो गया, जिससे हजारों उपयोगकर्ताओं की चेहरे की तस्वीरें और ID जानकारी 4chan पर लीक हो गई
  • यह DB Google Firebase पर बिना authentication के सार्वजनिक था, और 4chan उपयोगकर्ताओं ने automated scripts का उपयोग करके इसे बड़े पैमाने पर डाउनलोड किया
  • Tea के 16 लाख से अधिक उपयोगकर्ता हैं, और यह user verification के लिए selfie और ID upload करने की मांग करता है
  • 404 Media ने Tea app के code को decompile करके यह पुष्टि की कि संबंधित storage URL वास्तव में मौजूद था
  • Tea ने मीडिया या Google की पूछताछ का जवाब नहीं दिया, मूल पोस्ट हटाई जा चुकी है, लेकिन archive और बाद की पोस्टों में लीक के संकेत लगातार दिखते रहे

Tea app data leak घटना का सार

एक्सपोज़ हुआ Firebase storage

  • Tea app का Google Firebase database बिना authentication के सार्वजनिक था, और कोई भी इसे access कर सकता था
  • 4chan उपयोगकर्ताओं ने इस कमजोरी का पता लगाकर व्यक्तिगत जानकारी और selfie तस्वीरों की हजारों फाइलें डाउनलोड कर लीं
  • डेटा automated scripts की मदद से एकत्र किया गया, और संबंधित scripts भी पोस्ट में साझा की गईं

लीक हुई जानकारी

  • इसमें उपयोगकर्ताओं की चेहरे की तस्वीरें, driving licence के scanned copies, जन्मतिथि, location जानकारी आदि शामिल होने की पुष्टि हुई
  • 4chan thread में इसे स्पष्ट और बिना censored images बताकर, हजारों फाइलें जुटाए जाने का उल्लेख किया गया
  • पोस्ट “अगर आपने Tea app पर अपना चेहरा और driving licence upload किया है, तो अब आपको सार्वजनिक रूप से dox कर दिया गया है” जैसे वाक्य के साथ फैलाया गया

app संरचना की पुष्टि और verification प्रक्रिया

  • Tea app signup के समय username, location, जन्मतिथि, face photo और ID photo मांगता है
  • 404 Media ने Android version app को decompile करके पुष्टि की कि Firebase storage URL वास्तव में code में शामिल था
  • verification प्रक्रिया में यह जांचने के लिए selfie upload करनी होती है कि उपयोगकर्ता महिला है या नहीं, और waiting time कभी-कभी 17 घंटे तक पहुंच जाता है

Tea app की growth पृष्ठभूमि

  • 2023 में लॉन्च होने के बाद, हाल में यह अमेरिकी App Store की ऊपरी रैंकिंग में पहुंचा, जिससे उपयोगकर्ता तेजी से बढ़े
  • app, 'Are We Dating the Same Guy?' जैसे Facebook groups की तरह, महिलाओं को पुरुषों के बारे में अपने अनुभव गुमनाम रूप से साझा करने की सुविधा देता है
  • app page पर लिखा है: “हमारे community से पूछें। हम बताएंगे कि वह आदमी सुरक्षित है या नहीं, और क्या वह cheating कर रहा है”

कमजोर प्रतिक्रिया

  • Tea app और इसके संस्थापक Sean Cook ने मीडिया और private messages का जवाब नहीं दिया
  • Google को भी एक user ने इस समस्या की रिपोर्ट दी, लेकिन कोई कार्रवाई हुई या नहीं, यह स्पष्ट नहीं है
  • लीक हुआ Firebase page अब ब्लॉक है और इस समय “Permission denied” error दिखाता है

सुरक्षा खामी को लेकर चिंता

  • उपयोगकर्ताओं की बेहद संवेदनशील जानकारी रखने वाली सेवा होने के बावजूद बुनियादी authentication settings भी लागू नहीं थीं
  • इसे ऐसे app का典型 मामला माना जा रहा है, जिसने संवेदनशील जानकारी मांगते हुए भी security लापरवाही के कारण बड़े पैमाने पर leak पैदा कर दिया
  • भरोसे पर आधारित महिलाओं के लिए सुरक्षित community के रूप में Tea app के brand को इससे बड़ा नुकसान होने की आशंका है

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

1 टिप्पणियां

 
GN⁺ 2025-07-26
Hacker News की राय

  • archive.today का लिंक पर देखा जा सकता है

    • जिन साइटों के लिए user verification चाहिए उन्हें freewalled कहना, अपने आप में काफ़ी मज़ेदार है

  • यह ऐप मूल रूप से Peeple जैसा ही ढांचा है, बस इसमें केवल महिलाओं को साइन अप करने की अनुमति है। Peeple के फेल होने की वजह यह थी कि bias और चुगली को 100% रोकना संभव नहीं था। कोई व्यक्ति जलन में किसी दूसरे को बदनाम कर दे और उसे सच की तरह पोस्ट कर दे, तो पीड़ित को नौकरी या रिश्तों में नुकसान हो सकता है। इसलिए VC और पूरे इंटरनेट ने उसका मज़ाक उड़ाया और अंततः वह बंद हो गया। Tea आखिर कानूनी कैसे है, यह सवाल है, और कानूनी रूप से मानो time bomb लगी defamation जैसा लगता है

    • defamation (बदनामी या अपमान) तभी बनता है जब बात झूठी हो या उसे सीधे तथ्य के रूप में गलत समझा जा सके। यह तभी लागू होता है जब वास्तविक जोखिम के कारण नुकसान हुआ हो या कानून पहले से उसे नुकसान मानता हो। "यह आदमी creepy है और अपने पार्टनर के साथ बुरा बर्ताव करता है" जैसी बात सिर्फ राय है। राय defamation तभी बन सकती है जब उसमें ऐसे ठोस और झूठे तथ्य शामिल हों जैसे "मैं इस व्यक्ति के बारे में ऐसा सोचता/सोचती हूँ क्योंकि मैंने ये-ये तथ्य देखे हैं"। "मुझे लगता है यह व्यक्ति शायद शिकार करना पसंद करता है" defamation नहीं है। अमेरिकी कानून के तहत, ऐप सेवा प्रदाता आम तौर पर users द्वारा पोस्ट की गई defamation वाली सामग्री के लिए कानूनी रूप से लगभग जिम्मेदार नहीं होते। यह साबित करना पड़ता है कि सेवा ने खास तौर पर उस content को उकसाया था, और व्यवहार में ऐप डेवलपर्स के लिए इस मानक को पार करना मुश्किल है
    • असल में ऐसे ऐप अपराधी प्रवृत्ति वाले या दुर्भावनापूर्ण users के लिए दूसरों को ट्रैक और manipulate करने का उपयुक्त साधन लगते हैं। यह 'सुरक्षा' का दावा करता है, लेकिन वास्तव में यह बिना आधार की बात है
    • अगर Tea अवैध है, तो फिर glassdoor, yelp, Google reviews आदि भी सब अवैध होने चाहिए — यही सवाल उठता है। hiring process में identity verification पर भी वही तर्क लागू होगा
    • यह कहा जाता है कि Peeple bias और चुगली को नहीं रोक पाया इसलिए डूब गया, लेकिन एक निंदक राय यह भी है कि अगर bias और चुगली न हो, तो कोई ऐसे ऐप का इस्तेमाल ही क्यों करेगा
    • मेरा मानना है कि Tea पर भी दूसरे social media की तरह Section 230 कानूनी immunity लागू होती है

  • मेरा मानना है कि जो कंपनियाँ सीधे financial services से जुड़ी नहीं हैं, उन्हें सरकार द्वारा जारी ID माँगने की अनुमति नहीं होनी चाहिए। Facebook पर भी यही बात लागू होती है। आखिर ऐसे ऐप्स की वजह से हज़ारों लोग identity theft के जोखिम में आ जाते हैं। इसे growth hacking की योजना कहना भी बहुत अनैतिक होगा

    • अच्छा होगा अगर Apple या Google डेवलपर्स के लिए कोई मज़बूत Know Your Customer API दें। ऐसा हो कि ऐप केवल वही जानकारी निकाल सके जिसकी user ने अनुमति दी हो, तब इसे कई ऐप्स में इस्तेमाल किया जा सकेगा। पता नहीं ऐसा पहले से है या नहीं, लेकिन कम से कम Tea ने तो उसका इस्तेमाल नहीं किया लगता

  • अब समय आ गया है कि ऐसी गंभीर security breach से निपटने वाली नीतियों पर सोचा जाए (लगता है Tea का data store भी पूरी तरह असुरक्षित था)

    • App Store registration review के समय server security checklist की जाँच अनिवार्य होनी चाहिए
    • App Store के लिए blocking kill switch होना चाहिए, ताकि publisher एक private token Apple को जमा करे, और वह token लीक होते ही ऐप को तुरंत हटाया जा सके
    • ऐप publishers को बाध्य किया जाना चाहिए कि वे अपनी ही कीमती personal information (जैसे मुख्य bank account access) भी consumer data के साथ backend में स्टोर करें
      • security breach होने पर कंपनी पर वास्तविक damages की कानूनी जिम्मेदारी होनी चाहिए। कंपनियों को security की परवाह करवाने का एकमात्र तरीका financial penalty है। इस मामले में किसी elite hacker का कारनामा नहीं था, बल्कि सब कुछ सार्वजनिक रूप से खुला पड़ा था
      • user के नज़रिये से देखें तो सीधी सामान्य समझ यही कहती है कि gossip app में अपना face photo और driving license अपलोड नहीं करना चाहिए। बचपन से यह सामान्य समझ थी कि पेशेवर उपयोग के अलावा असली नाम सार्वजनिक नहीं करना चाहिए। सिस्टम कुछ भी कहे, अंतिम जिम्मेदारी user की ही है। OS चाहे जितनी सुरक्षा दे, वह आपके अपने व्यवहार को नहीं रोक सकता
      • इस घटना में सिर्फ एक public Firebase bucket का इस्तेमाल हुआ था, और ऐप को block कर देने से समस्या हल नहीं होती। backend ने अलग से relay किया हो सकता था, लेकिन Apple उस security का आकलन नहीं कर सकता
      • publisher से उसकी अपनी personal information backend में शामिल करवाने का सुझाव काफ़ी अनोखा है। मतलब हर admin DB में MY_PERSONAL_INFO table अनिवार्य करने का विचार
      • मैं app reviewers को अधिक अधिकार देने के पक्ष में नहीं हूँ। पहले ही अक्सर बिना कारण ऐप reject कर दिए जाते हैं, और यह पता लगाना बहुत कष्टदायक होता है कि reject क्यों किया गया

  • यह सवाल है कि user की driving license image को verification पूरा होने के बाद भी एक पल के लिए अतिरिक्त क्यों रखा गया

    • ऐसे व्यवहार पर बहुत भारी जुर्माना लगना चाहिए। सही सज़ा न होने से यह सब बार-बार होता है। revenue का 10% या उससे अधिक fine होना चाहिए, और बहुत गंभीर मामलों में केवल corporation नहीं बल्कि वास्तविक equity holders की व्यक्तिगत संपत्ति तक से damages वसूले जाने चाहिए, तभी consumer protection सच में होगा
    • जो ऐप privacy को इस तरह संभालता है, वही वास्तव में दूसरे लोगों की तस्वीरें (चाहे सहमति हो या नहीं) और चुगली भी अपलोड करने के लिए डिज़ाइन किया गया है। यह privacy की सचमुच परवाह नहीं करने वाली सेवा है
    • मेरे पास कोई सबूत नहीं है, लेकिन मैं इस ऐप के revenue model को लेकर उत्सुक हूँ। कहीं यह driving license और phone number की जानकारी बेचकर पैसा कमाने की कोशिश तो नहीं कर रहा था
    • यही है vibe coding की वास्तविकता
    • दूसरी रिपोर्टों के अनुसार, नए account verification की queue 17 घंटे से अधिक थी। संभव है कि 4chan users जो लेकर गए, वह verification queue की images रही हों

  • अगर कोई LLM का इस्तेमाल करके fake profiles बना सके और activity को automate कर सके, तो ऐसे user data की विश्वसनीयता या उपयोगिता बिल्कुल नहीं बचेगी। driving license भी जाली बनाया जा सकता है, और असली license लेकर कोई दूसरे व्यक्ति का नाटक भी कर सकता है। Tea की सेवा, उसका implementation, और उसकी process — सब design flaws हैं और डेवलपर्स के लिए कानूनी जोखिम हैं

    • उम्मीद है इससे यह सीख मिले कि sensitive information जमा करते समय थोड़ा ज़्यादा सावधान रहना चाहिए। सिर्फ इसलिए कि ऐप सुंदर है, या यह पता नहीं कि सेवा कौन चला रहा है, ID आसानी से जमा नहीं कर देनी चाहिए। मैंने पहले कनाडा की एक सरकारी संस्था के साथ काम किया था, जहाँ उन्होंने ID ईमेल से भेजने को कहा। मैंने encrypted link से भेजा, तो उन्होंने मना कर दिया और मुझे खुद जाकर देना पड़ा। यह पागलपन है कि इंटरनेट 10 साल में 'YouTube पर असली नाम मत लिखो' से 'किसी भी ऐप को ID दे दो' तक पहुँच गया
    • अगर मेरा driving license लीक हो जाए और कोई stalker मेरे घर पहुँच जाए, तो मैं उसे यह कहकर लौटा दूँगा/दूँगी कि वह license तो साफ़ तौर पर नकली होगा
    • मेरा मानना है कि driving license forge करना या किसी और के नाम से register करना व्यवहार में काफ़ी कठिन है। कम से कम मेरे आसपास तो कोई ऐसा नहीं है जो अपना license किसी और को उधार दे

  • मुझे पूरा यक़ीन है कि IT startup शुरू करने वालों में कम से कम एक व्यक्ति का technical background होना चाहिए। चाहे outsourcing पूरी कर दी जाए, फिर भी security से जुड़े सवाल सीधे पूछना आना चाहिए। समस्या सिर्फ यह नहीं थी कि database इंटरनेट पर खुला था, बल्कि वह वास्तव में पूरी तरह public था। लोगों की ID को public DB में रखा गया था — यह सचमुच चौंकाने वाली बात है

    • अब vibe coding tools आ गए हैं, तो माहौल यह है कि technical वगैरह कुछ ज़रूरी नहीं, बस result निकालो। LinkedIn influencers और founders deployment कैसे हुआ इसमें रुचि नहीं रखते, वे सिर्फ result देखते हैं। अब जब समझ आ गया है कि IT और security को न्यूनतम लागत मानना सबसे अच्छा security outcome नहीं देता, फिर भी लगता है सब कुछ छोड़कर वही बेफिक्री जारी रहेगी
    • वास्तव में authentication के बिना public firebase databases की संख्या लाखों में है। Fortune 500 कंपनियों तक में यह असुरक्षित exposure गंभीर है [bleepingcomputer लेख]
    • सिर्फ technical capability काफ़ी नहीं है। security background ज़रूरी है। security के मामले में मैंने सबसे खराब लोगों में कई ऐसे देखे हैं जिन्हें अपने technical skills पर बहुत भरोसा था, लेकिन security की समझ नहीं थी
    • डॉक्टर, वकील, और architects 5~8 साल या उससे भी ज़्यादा पढ़ते हैं और परीक्षा देते हैं। मेरा मानना है कि IT भी कुछ दशकों बाद कानूनी रूप से regulated होगा। अब तक यह खुला और मज़ेदार रहा है, लेकिन आगे सब कुछ IT पर निर्भर होगा, इसलिए यह बहुत सख़्त होने वाला है

  • मीडिया में इसे “data breach” कहा गया, लेकिन वास्तव में यह exposed DB था। ऐसे मामलों में ज़्यादा सटीक शीर्षक चाहिए। खबर की headline में hacker को दोष देने से पहले service operator की गलती पर ज़ोर होना चाहिए

    • “breach” शब्द गलत चुनाव है। इससे ऐसा लगता है जैसे अभी हाल में hack हुआ हो, जबकि असल में ऐप शुरू होने के समय से ही यह सबके लिए खुला था और आज बस इसका खुलासा हुआ है। यह तो और भी गंभीर स्थिति है
    • मेरे अनुभव में 404media की खबरें अक्सर उस गुणवत्ता की नहीं होतीं जो HN पर आने लायक हो

  • जब देश या स्थानीय सरकारें ID verification को और मजबूत करने की दिशा में बढ़ रही हैं, यह घटना अच्छी तरह दिखाती है कि ऐसे हादसे क्यों बुरे परिणाम ला सकते हैं

    • पूरी तरह सहमत

  • “'सुरक्षा' शब्द शीर्षक में बहुत बड़ी भूमिका निभा रहा है, लेकिन वास्तव में यह बस एक gossip app है”