Signal, Discord जैसे प्लेटफॉर्म को निशाना बनाने वाला 0-click डी-अनॉनिमाइजेशन हमला

 (gist.github.com/hackermondev)
1 पॉइंट द्वारा GN⁺ 2025-01-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cloudflare cache और push notifications के संयोजन से, कमजोर ऐप इंस्टॉल वाले फोन या background app वाले laptop पर यूज़र की location को कुछ सौ मील के दायरे तक सीमित करने वाला 0-click डी-अनॉनिमाइजेशन हमला संभव है
  • attacker target device से Cloudflare के पीछे मौजूद resource अपने-आप load करवाता है, फिर यह जांचता है कि वह किस Cloudflare data center में cache हुआ है, ताकि target के पास का क्षेत्र अनुमानित किया जा सके
  • Signal में cdn2.signal.org attachment cache और mobile push notifications की वजह से chat room खोले बिना भी attached image download हो सकती है, और Discord में friend request notification के avatar URL से वही हमला संभव है
  • Cloudflare ने Cloudflare Teleport से जुड़े उस bug को patch किया है जो किसी खास data center को request भेजने देता था, लेकिन कहा गया कि VPN servers इस्तेमाल करके भी कुल Cloudflare data centers के लगभग 54% तक फिर से access संभव था
  • Signal और Discord ने जिम्मेदारी का दायरा Cloudflare या यूज़र की तरफ मोड़ दिया, और Cloudflare ने रुख रखा कि protected resources की caching disable करना customer की जिम्मेदारी है, जिससे app·CDN·notification design में उलझा privacy risk बना हुआ है

Cloudflare cache से location को सीमित करने का सिद्धांत

  • यह हमला Cloudflare की cache status information और भौगोलिक रूप से फैले data centers का उपयोग करके यूज़र की अनुमानित location का अंदाजा लगाता है
  • Cloudflare cacheable resource requests के लिए response headers में जानकारी देता है
    • cf-cache-status HIT या MISS दिखाता है
    • cf-ray में request process करने वाले data center के पास का airport code शामिल होता है
  • जब target device Cloudflare-आधारित site का resource load करता है, तो वह resource target के पास वाले data center में cache हो सकता है
  • इसके बाद कई Cloudflare data centers की जांच करके यह पता लगाया जाए कि resource कहां cache हुआ है, तो target के पास का क्षेत्र अनुमानित किया जा सकता है
  • Cloudflare बताता है कि वह 120 से अधिक देशों और 330 शहरों में सैकड़ों data centers चलाता है, और विकसित देशों में रहने वालों के लिए सबसे नजदीकी data center 200 miles के भीतर होने की संभावना अधिक है

Cloudflare Teleport और data center traversal

  • सामान्य तौर पर Cloudflare IP ranges anycast के रूप में काम करती हैं, इसलिए user किसी खास data center से सीधे TCP connection request नहीं कर सकता
  • community forum post के आधार पर Cloudflare Teleport बनाया गया, जिसमें बताया गया था कि Cloudflare Workers और Cloudflare WARP internal IP ranges का इस्तेमाल करके किसी खास data center को HTTP request भेजने का bypass संभव था
  • Cloudflare Teleport, Cloudflare Workers-आधारित proxy था, जो खास colo value देकर request को इच्छित data center तक भेजने का tool था
    • उदाहरण के लिए Seattle data center के लिए SEA जैसा code इस्तेमाल होता है
    • खास IP ranges और data centers की mapping colos.json रूप में व्यवस्थित की गई थी
  • Cloudflare ने बाद में इस bug को पूरी तरह patch कर दिया, और Teleport tool अब उस तरीके से काम नहीं करता

Namecheap favicon से सत्यापित proof of concept

  • पहली verification में Namecheap का favicon.ico इस्तेमाल किया गया
  • यह resource Cloudflare caching enabled वाली एक simple static image था, और bot protection बहुत सख्त नहीं था, इसलिए इसे test target के रूप में चुना गया
  • CLI tool किसी दिए गए URL के लिए यह list करता है कि किन data centers ने resource cache किया और cache age कितनी है
  • Namecheap ने cache age को 5 मिनट तक बहुत कम set किया था, लेकिन पिछले 5 मिनट में favicon cache करने वाले data centers की पहचान की जा सकी
  • browser site खोलते समय favicon को automatic download करता है, इसलिए यह result proof of concept बना कि पिछले 5 मिनट में कई क्षेत्रों के users ने Namecheap.com visit किया था

Signal में उपयोग

  • Signal content delivery के लिए दो CDN इस्तेमाल करता है
    • cdn.signal.org: CloudFront-आधारित, profile avatar के लिए
    • cdn2.signal.org: Cloudflare-आधारित, message attachments के लिए
  • https://cdn2.signal.org/attachments/* path पर Cloudflare cache configured है, इसलिए attachment पाने वाला device इसे download करे तो यह पास के data center में cache हो सकता है

  • 1-click तरीका

    • जब user Signal में attachment भेजता है, file cdn2.signal.org पर upload होती है
    • recipient बातचीत खोलता है, तो device attachment को automatic download करता है, और Cloudflare cache geo-estimation method से recipient की location सीमित की जा सकती है
    • test में Signal desktop app की SSL pinning हटाई गई और Burp से requests और responses देखे गए
    • अगर attacker-side device पहले attachment download कर ले, तो attacker के पास वाले data center में cache बनकर result contaminate हो सकता है, इसलिए attacker-side Signal app में cdn2.signal.org/attachments/* GET requests block की गईं
    • New York से खुद को target बनाकर किए गए test में Newark, NJ का EWR data center मिला, जो actual coordinates से लगभग 150 miles दूर था

  • 0-click तरीका

    • Signal mobile app default रूप से push notifications में sender और message शामिल करता है
    • attachment image वाले message में notification के right side में दिखाने के लिए device Signal CDN से image download करता है
    • target Signal बातचीत न भी खोले, फिर भी push notification आने पर attachment image download हो सकती है, और इस process में target के पास वाले Cloudflare data center में cache बन जाता है
    • यह तरीका user interaction के बिना current location का अनुमान लगाने वाले 0-click attack में बदल जाता है
    • Signal journalists, activists और whistleblowers द्वारा इस्तेमाल की जाने वाली service है, इसलिए account tracking, identity correlation, और किसी journalist से मिलने वाले employee की location estimate करने जैसे misuse risks हैं

Discord में उपयोग

  • Discord भी Cloudflare cache configured CDN resources के कारण इसी प्रकार के attack के लिए vulnerable app पाया गया
  • 1-click तरीके में Nitro subscribers द्वारा इस्तेमाल किए जा सकने वाले custom emoji का उपयोग होता है
    • custom emoji Discord CDN से load होता है
    • यह message, user status, channel आदि कई जगहों पर दिख सकता है
    • attacker user status में custom emoji दिखाकर target के profile खोलने का इंतजार कर सकता है
  • Discord को submit की गई पूरी HackerOne report अलग Gist पर public है

  • friend request notification से 0-click

    • Discord mobile push notifications messages के अलावा कई तरह के events पर भी भेजे जाते हैं
    • friend request भेजने पर target mobile device पर push notification बनता है
    • target Discord इस्तेमाल कर रहा हो तब भी friend request notification हमेशा mobile device पर भेजा जाता है
    • friend request notification में request भेजने वाले user का avatar URL शामिल होता है, और phone इस avatar को user interaction के बिना download करके notification में दिखाता है
    • Discord के avatar URL formats situation के अनुसार अलग होते हैं
    • push notification: https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash}
    • website display: https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash}.png
    • दोनों URL एक ही image की ओर इशारा करते हैं, लेकिन path अलग होने से वे अलग-अलग cache होते हैं, इसलिए push notification से load हुए cache और app profile display से बने cache को अलग किया जा सकता है

  • GeoGuesser automation

    • Discord 0-click attack process को private Discord bot GeoGuesser से automate किया गया
    • bot एक single command में username लेकर ये काम करता है
      • Discord User API के लिए account credentials इस्तेमाल करता है
      • user avatar को random image में बदलकर नया avatar hash बनाता है
      • specified user को friend request भेजता है
      • Cloudflare Teleport CLI-आधारित private API से cache enumeration attack चलाता है
      • results को Discord के अंदर 30 seconds से कम में दिखाता है
    • Discord CTO Stanislav Vishnevskiy पर किए गए demo में दो Cloudflare data centers द्वारा avatar cache किया जाना दिखा
    • दो data centers दिखने की वजह कई devices पर notification मिलना, या एक ही device request का अलग-अलग data centers में load balancing होना हो सकता है
    • GeoGuesser Google Maps API से दोनों data centers का midpoint calculate करता है और radius circle दिखाता है
    • demo map में Discord headquarters San Francisco, CA में था और outer circle के भीतर शामिल था, जबकि actual location लगभग 300-mile range वाले inner circle के edge के पास estimate की गई
    • पूरा process 1 मिनट से कम में खत्म हुआ, और attack लगभग detect करना मुश्किल स्तर का है

bug bounty और प्रत्येक संगठन की प्रतिक्रिया

  • Signal ने report को तुरंत reject करते हुए कहा कि उसने WireGuard, Tor, open source VPN software जैसे network-layer anonymity features को पूरी तरह replicate करने की कोशिश कभी नहीं की
  • Signal पर counterargument इस बात पर आधारित है कि Signal खुद को privacy-first communication platform के रूप में market करता है, और users end-to-end encryption से आगे के privacy risks को minimize किए जाने की उम्मीद करते हैं
  • Telegram को ऐसे example के रूप में mention किया गया जो इस attack के लिए vulnerable नहीं है
    • यह HTTP पर निर्भर न रहने वाला अपना protocol इस्तेमाल करता है
    • यह Cloudflare जैसे cloud providers की caching पर निर्भर नहीं करता
  • Discord security team ने शुरू में कहा कि वह users की सुरक्षा के लिए changes पर विचार करेगी, लेकिन बाद में रुख बदलकर कहा कि यह Cloudflare issue है जिससे अन्य Cloudflare customers भी vulnerable हैं
  • Cloudflare ने वह bug patch किया जिसका इस्तेमाल Cloudflare Teleport data centers traverse करने के लिए करता था
    • यह bug एक साल पहले किसी दूसरे reporter ने HackerOne पर report किया था, लेकिन उस समय इसे impact-less माना गया था
    • इस research के share होने के बाद Cloudflare ने पुराने report को फिर से खोला और resolve किया, और पुराने reporter तथा इस report, दोनों को $200 bounty दिया

patch के बाद भी बची समस्या

  • Cloudflare ने जो patch किया वह internal network से data center traversal को संभव बनाने वाला bug था, लेकिन cache-based location estimation की core conditions खुद खत्म नहीं हुईं
  • बताया गया कि patch के बाद भी पिछले 24 घंटों में article में बताए गए attacks execute किए गए
  • Cloudflare Teleport को patch के 24 घंटे बाद VPN-based तरीके से फिर से implement किया गया
  • चुने गए VPN provider के पास 31 देशों में 3,000 से अधिक servers हैं
  • इस तरीके से कुल Cloudflare data centers के लगभग 54% तक फिर से access किया जा सका, और बताया गया कि यह अधिक आबादी वाले अधिकांश क्षेत्रों को cover करता है
  • Cloudflare का final stance यह है कि वह इस de-anonymization attack को अपने systems की vulnerability नहीं मानता, और जिन resources को protection चाहिए उनकी caching disable करना customer की जिम्मेदारी है
  • Discord जैसे customers इसे Cloudflare की जिम्मेदारी मानते हैं, जबकि Cloudflare कहता है कि customers को caching adjust करनी चाहिए, जिससे responsibility boundary बंट जाती है

protection और practical implications

  • यह attack दिखाता है कि caching और push notifications जैसे performance·usability features साथ आने पर tracking mechanism के रूप में misuse हो सकते हैं
  • Cloudflare Teleport bug patch हो चुका है और Signal·Discord जैसे कुछ apps ने disclosure के बाद mitigation steps लिए हो सकते हैं, लेकिन basic risk बना हुआ है
  • जो apps CDN से content serve करते हैं और caching इस्तेमाल करते हैं, वे उचित सावधानी न होने पर इसी तरह के attack के लिए vulnerable हो सकते हैं
  • जिन resources को protection चाहिए, उनके लिए CDN caching policy, push notifications में automatic load होने वाली images, और per-user unique URLs के cache behavior को साथ में consider करना चाहिए
  • journalists, activists, hackers और privacy-sensitive users को यह aware रहने की जरूरत है कि app notifications और external resources की automatic loading location exposure में बदल सकती है

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

1 टिप्पणियां

 
GN⁺ 2025-01-22
Hacker News की रायें

  • Signal यूज़र को कोई फोटो भेजने पर वह Cloudflare के ज़रिए fetch होती है और उस यूज़र के पास वाले data center में cache हो जाती है। इसके बाद cache status query करके पता लगाया जा सकता है कि कौन-सा data center इस्तेमाल हुआ
    जब तक यूज़र किसी बहुत दूर-दराज़ इलाके में न हो, इसे de-anonymization कहना थोड़ा बढ़ा-चढ़ाकर कहना लगता है, लेकिन फिर भी यह दिलचस्प लेख है

    • “यूज़र के पास” भी एक बड़ा अनुमान है। मेरे मामले में ORD लगभग 200 मील दूर और IAD लगभग 500 मील दूर है, लेकिन ISP की peering और upstream network configuration की वजह से Cloudflare मेरा traffic 700 मील दूर DFW से handle करता है
      फिर भी Cloudflare, Seattle, Manchester, Tokyo के cache तो नहीं चुनेगा, इसलिए किसी अज्ञात Signal यूज़र को मोटे तौर पर किसी भौगोलिक लोकेशन तक सीमित करना भी अहम metadata बन जाता है, जिसे व्यक्ति की पहचान उजागर करने के लिए अन्य चीज़ों के साथ जोड़ा जा सकता है। शानदार attack है
    • group पर इसके असर के बारे में सोचें तो यह और भी दिलचस्प हो जाता है। group में सिर्फ एक image भेजने भर से उस group के सभी devices Cloudflare की तरफ से पहचाने जा सकने योग्य हो जाते हैं, और उसी client address से दूसरी websites पर जाने वाला ढेर सारा unencrypted traffic भी साथ में दिखता है
      Cloudflare private और group chats से बहुत बड़ी मात्रा में metadata देख सकता है, और file size के आधार पर original media भेजने वाला, पढ़ने वाले, पढ़ने का समय, forward करने वाला और recipients तक track कर सकता है। भले ही images या videos सीधे न दिखें, अगर size पहले से पता हो या बाद में law enforcement request जैसी किसी चीज़ से पता चल जाए, तो उतना काफी है
    • यह correlation analysis के लिए उपयोगी हो सकता है। उदाहरण के लिए, मान लें कोई investigator किसी व्यक्ति से नियमित रूप से संपर्क करता है; एक अकेला data point मायने नहीं रखता, लेकिन रोज़ाना के image download records यह hint दे सकते हैं कि वह व्यक्ति 90% समय WA में और 10% समय कहीं और बिताता है
      सिर्फ यह जानकारी अभी भी पर्याप्त न हो, लेकिन अगर कोई खास suspect हो तो पुष्टि में मदद मिलती है। अगर आप संदिग्ध व्यक्ति तक सीधे पहुंच सकते हैं और उसके “clean” profile से भी friend बन सकते हैं, तो इसी technique से दो location profiles को match भी कर सकते हैं। de-anonymization कोई single piece of information नहीं, बल्कि ऐसी प्रक्रिया है जिसमें सारी जानकारी suspect को narrow down करने या suspicion confirm करने वाले profile में जुड़ती जाती है
      यहां “investigator” से मतलब AI agent या law enforcement agency नहीं, बल्कि सामान्य व्यक्ति है। law enforcement agency हो तो वह शायद Cloudflare से ज्यादा सीधे तौर पर जानकारी हासिल कर सकती है
    • यह अतिशयोक्ति नहीं है। Signal में message receive करते समय उम्मीद होती है कि IP address या location के observable aspects उजागर नहीं होने चाहिए
      de-anonymization का यह खास स्तर और प्रकार आपके use case में समस्या है या नहीं, यह अलग सवाल है। निजी तौर पर मुझे इस बात से खास फर्क नहीं पड़ता कि mutual contacts मेरा IP address सीधे देख लें, लेकिन सभी users ऐसे नहीं होते
    • “de-anonymization” का मतलब हमेशा सटीक घर का पता होना ज़रूरी नहीं है। कुछ लोग अपना देश या क्षेत्र छिपाना चाहते हैं, और यह attack उसे कमजोर करता है
      Silk Road investigation में भी इस स्तर की जानकारी वास्तव में महत्वपूर्ण थी। Ulbricht ने शुरू में गलती से अपना time zone reveal कर दिया था, जिससे अमेरिकी authorities उसे अमेरिका में मौजूद व्यक्ति तक narrow down कर सकीं। वह जानकारी न होती तो वह दुनिया में कहीं भी हो सकता था

  • दिलचस्प technique और approach वाला अच्छा लेख है
    हालांकि “de-anonymization” या “यूज़र की location हासिल करना” जैसे शब्द थोड़े बढ़ा-चढ़ाकर लगते हैं। यह precise location से काफी दूर है, और 150 मील Atlanta, GA से Augusta, GA तक highway से लगभग 2 घंटे की दूरी है। उस radius के भीतर शायद 7 लाख से अधिक लोग होंगे
    Signal का attachments auto-fetch feature थोड़ा चिंता पैदा करता है। एक private messenger में मुझे उम्मीद थी कि Tor में JavaScript बंद करने की तरह इसे disable करने का option होगा; हो सकता है मैंने गहराई से न खोजा हो, लेकिन ऐसा feature दिखा नहीं
    लगता है Signal ने mass adoption के लिए privacy और usability के बीच balance बनाते हुए “default रूप से useful” approach चुनी है। जो users सच में चिंतित हैं वे https://www.privacyguides.org/articles/2022/07/07/signal-con... जैसी guides के अनुसार Signal को harden कर रहे होंगे। high-risk scenarios में VPN/proxy और settings changes की हमेशा सलाह दी जाती रही है
    caching भी खत्म नहीं होगी और CloudFlare भी नहीं। पुराने P2P multiplayer lobbies में IP expose होने से DDoS का खतरा इससे बड़ा लगता था, और third parties में CloudFlare की response सबसे बेहतर लगती है। sensitive information को cache न करना मूल सिद्धांत है, और CDN या intermediate service को यह बताने की जिम्मेदारी communicating application की है कि कौन-सी specific item cache नहीं करनी है

    • ऐसा सोचना आसान है, लेकिन यह लोगों द्वारा share की गई छोटी-छोटी जानकारियों के साथ जल्दी जुड़ जाता है। “Starbucks तक 15 मिनट drive किया” जैसी मामूली जानकारी समय के साथ जमा होकर सटीक location तक पहुंचा सकती है
    • auto-download बंद किया जा सकता है। Settings > Data and storage > Media auto-download में mobile data, Wi‑Fi, और roaming के हिसाब से auto-download targets चुन सकते हैं
    • एक अलग, छोटा-सा point: Atlanta और Augusta के बीच 100km radius वाले circle में लगभग 20 लाख लोग हैं। यह https://www.tomforth.co.uk/circlepopulations/ से calculate किया गया

  • शानदार। कुछ अन्य मामलों के उलट, इसे निश्चित रूप से de-anonymization कहा जा सकता है, या कम से कम यह उसके काफी करीब है। अगर Satoshi की लोकेशन 250 मील के अंदर पता चल जाती, तो वह आज कितना anonymous रह पाता?
    इस हमले को बार-बार लागू करके, किसी न किसी तरह छिपाकर, समय के साथ movement track किया जा सकता है। आम तौर पर ZIP code के आकार की 4–5 लोकेशन ही किसी व्यक्ति को uniquely identify करने के लिए काफी होती हैं

    • जवाबी तर्क यह है कि जिसे anonymity की चिंता होगी, वह अपनी पहचान ऐसे तरीके से छिपा रहा होगा जो इस हमले से नहीं टूटता, जैसे VPN। ऊपर से, खुद के control वाले endpoint का link भेजने जैसे कहीं ज्यादा प्रभावी हमले भी हैं। अगर रिश्ता इतना भरोसेमंद है कि notifications भेजी जा सकती हैं, तो link click करवाना मुश्किल नहीं है। कम technical तरीका यह भी है कि user कब online/offline रहता है, उसे दुनिया के time zones से match किया जाए
      Apple और Cloudflare अपने privacy software में जो तरीका इस्तेमाल करते हैं, वह भी इस विचार पर आधारित है कि region पहचान उजागर करने वाली जानकारी नहीं है। जैसे Apple का iCloud Private Relay या Cloudflare का WARP; Apple Private Relay on करने पर original IP छिप जाता है, लेकिन traffic जिस IP से route होता है वह उसी देश में होता है
      https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overv...
      यह हमला academic तौर पर दिलचस्प और नया है, लेकिन “de-anonymization” नहीं है
    • Satoshi का माना जाने वाला home IP address Bitcoin release के तुरंत बाद वास्तव में leak हुआ था, लेकिन कई साल बाद जाकर पहचाना गया
      बेशक वह उसका न भी हो सकता है, कोई random शुरुआती user भी हो सकता है। फिर भी मुझे लगता है कि उसके होने की कुछ संभावना है
      ज्यादा जानकारी: https://news.ycombinator.com/item?id=29728339
      मैं उसका नाम और पता ढूंढकर public करने की कोशिशों का समर्थन नहीं करता, क्योंकि इससे उसकी जिंदगी मुश्किल हो सकती है। बस abstract तौर पर यह बहुत दिलचस्प है कि इतने सालों तक इतने लोगों की नजर होने के बावजूद यह mystery solve नहीं हुई
    • New York के आसपास 250 मील के circle में कितने लोग रहते होंगे?
    • लगभग सभी ऐसी applications में advertising ID से पहले ही यही काम किया जा सकता है
    • वह फिर भी काफी anonymous है। उसने लगभग निश्चित रूप से VPN इस्तेमाल किया होगा, और अगर नहीं भी किया तो संभव है कि वह किसी बड़े शहर में रहता हो जहां हजारों से लेकर लाखों तक काबिल engineers हों। अगर किसी message के समय वह SF में था भी दिखे, तो उससे सचमुच कुछ भी पता नहीं चलता

  • समझ नहीं आता कि इतने सारे top comments इसकी गंभीरता को कम क्यों आंक रहे हैं। यह ठीक उसी तरह का attack है जो law enforcement या malicious actors को location evidence बनाने में मदद देता है

    • कुछ लोग शायद उसकी उम्र से जलते हैं, और कुछ को लगता है कि de-anonymization कहना overstatement है, क्योंकि बहुत specific cases को छोड़कर यह किसी व्यक्ति को ढूंढने लायक जानकारी नहीं देता। यह “attack” VPN इस्तेमाल करने या बड़े शहर में रहने से आसानी से neutralize हो जाता है
    • मुझे लगता है कई लोग इसे कम इसलिए आंक रहे हैं क्योंकि original write-up में severity कुछ ज्यादा बेच दी गई लगती है। “शानदार discovery है, लेकिन दावे जितनी catastrophic नहीं” जैसी balanced reactions ज्यादा दिखती हैं, और problem की severity classification accurate होनी चाहिए
      location proof de-anonymization नहीं है, खासकर जब वह “location” इतनी व्यापक हो
    • सिर्फ देश जान लेना भी बड़ा पहला कदम है
    • लोग इसे उसी वजह से ignore कर रहे हैं जिस वजह से disruptive new technology को ignore करते हैं: क्योंकि यह uncomfortable है। यह संकेत है कि threat बहुत real है
      पहले ignore करके देखते हैं कि सुबह भी problem बची रहती है या नहीं। तब तक उम्मीद रहती है कि कोई वजह ढूंढ दे कि यह problem क्यों नहीं है

  • Signal ने उन URLs पर caching क्यों enable रखी है? सबसे आम case तो यही होगा कि attachment एक बार download हुआ और बात खत्म
    बल्कि मैं उम्मीद करता कि वे एक बार से ज्यादा download ही न होने दें, और पहली successful download के तुरंत बाद delete कर दें। हां, client बीच में fail हो सकता है, इसलिए re-download के लिए grace period रखा जा सकता है। फिर भी वह common case नहीं लगता, और CDN caching बंद करने से यह issue fix हो सकता है और उम्मीद है cost भी बहुत नहीं बढ़ेगी
    वैसे यहां “de-anonymization” थोड़ा clickbait जैसा शब्द है। किसी की location को लगभग 250 मील के अंदर narrow करना अच्छा नहीं है, लेकिन उससे उस व्यक्ति की anonymity खत्म नहीं होती
    edit: मैंने यह नहीं सोचा था कि attachment group chat में भेजा जा सकता है और कई लोग उसे download करेंगे। लेकिन उस case में भी क्या attachment group के हर व्यक्ति के लिए अलग-अलग encrypt नहीं होता? बेशक असल में यह कैसे काम करता है, मुझे ठीक-ठीक नहीं पता

    • Signal की default settings end-to-end encryption support करते हुए usability पर ज्यादा focus करती हैं, और ऐसे extreme threat model पर कम जिसमें यह भी छिपाना हो कि आप जिस continent में हैं वहां आपके citizenship rights हैं
      आपने जिन चीजों का जिक्र किया, उन्हें इतना crazy level की privacy/security चाहने वाला व्यक्ति practically configure कर सकता है। Messages को देखे जाने के 30 seconds बाद auto-delete कराया जा सकता है, proxy के जरिए सारा traffic route कराने के लिए set किया जा सकता है, और user की पसंद के हिसाब से काफी कुछ tune किया जा सकता है
      caching की वजह शायद egress cost होगी। File attachments, voice messages, video वगैरह सब मिलकर बड़ा खर्च बन जाते हैं
    • वजह group chats और multi-device users भी हो सकते हैं

  • यह वही 15-year-old है जिसने कुछ महीने पहले Zendesk Slack takeover vulnerability ढूंढी थी [1]
    [1]: https://news.ycombinator.com/item?id=41818459

    • अगर Twitter account 2017 में बना था तो वह तब 8 साल का रहा होगा: https://x.com/hackermondev
      Adobe को submit की गई वह bug report उसने पांच साल की उम्र में लिखी होगी: https://hackerone.com/daniel?type=user

  • यह निश्चित रूप से “हमला” तो है, लेकिन वह प्रकार नहीं है जिसे आम तौर पर zero-click सुनकर सोचा जाता है। कोई code execution नहीं है; यह कुछ tricks के जरिए पता लगाता है कि किस Cloudflare data center ने image cache की, और उससे user का बहुत मोटा-मोटा region निकालता है
    फिर भी प्रभावशाली और insightful है

    • हालात के हिसाब से सिर्फ मोटा-मोटा region भी छिपे हुए व्यक्ति के विरोधियों के लिए उपयोगी हो सकता है। अपराधियों जैसे लोगों को इससे बहुत बड़ा नुकसान होगा, ऐसा नहीं लगता, और 300 miles एक बड़ा radius है। लेकिन अगर “क्या वह व्यक्ति अभी भी देश के अंदर है” जैसी बात जाननी हो, तो उदाहरण के लिए law enforcement के लिए यह उपयोगी है
      ऐसे लोग local resources के साथ मिलकर आगे जांच कर सकते हैं। सिर्फ यह जानना कि किस region में कौन-से resources लगाने हैं, बहुत खर्च बचा सकता है
      जैसा कहा, प्रभावशाली और insightful है। दस्तावेज़ में थोड़ा ChatGPT की मदद ली गई जैसी feeling भी आती है, लेकिन बहुत सारे वाक्य बेहद स्पष्ट और specific हैं। ऐसे use के लिए यह बढ़िया use case है, इसलिए यह criticism नहीं है। अच्छा लेख था

  • अगर मैं कुछ miss नहीं कर रहा हूं, तो यह user की IP location जांचने का बेहद लंबा-चौड़ा तरीका लगता है
    उदाहरण के लिए VPN से connect करने के बाद https://cloudflare.com/cdn-cgi/trace देखने पर colo:CPH(Copenhagen) आता है, जो geographically मेरे सबसे नजदीकी CF data center से दूर है और VPN provider की IP location Oslo के ज्यादा करीब है, लेकिन फिर भी खास करीब नहीं है
    VPN इस्तेमाल न करूं तो भी अभी जिस देश में हूं उसकी राजधानी नहीं आती, बल्कि करीब 250 miles उत्तर का data center आता है। इसलिए मैं इस बात से भी सहमत नहीं हो पाता कि Cloudflare हमेशा “सबसे नजदीकी available data center” लौटाता है
    लेख अपने-आप में शानदार और निश्चित रूप से रोचक है, लेकिन इसकी practical usefulness को लेकर मुझे भरोसा नहीं है

    • यह user की IP location जांचने से कम accurate है। IP geocoding कई मामलों में city level तक जा सकती है। यह तो ज्यादा से ज्यादा सबसे नजदीकी Cloudflare data center ही है
    • सिर्फ एक data point से result शायद ज्यादा meaningful नहीं होगा
      असली usefulness और संभावित जोखिम तब पैदा होते हैं जब यह data दूसरे data के साथ combine होता है। sparse datasets का इस्तेमाल करके de-anonymization techniques कम से कम 15 साल से active research area रही हैं, और लोग अक्सर हैरान होते हैं कि आपस में असंबंधित दिखने वाले data के कुछ टुकड़ों से कितना कुछ पता लगाया जा सकता है
    • क्या आप यह नहीं मानते कि user की IP location protection जरूरी है?
      Applications image जैसे resource requests को proxy करने के लिए बहुत मेहनत करती हैं, इसकी वजह है। यह free नहीं है
    • Signal पर जो लोग message भेज सकते हैं, उनसे अपना IP address उजागर न होना privacy की काफी reasonable expectation है
    • भाग रहे राजनीतिक dissidents, terrorists वगैरह को track करने में यह उपयोगी हो सकता है। अगर location को 250 miles तक narrow down किया जा सके, तो यह पहले से ही बहुत उपयोगी जानकारी है, और शक भी पैदा नहीं करती

  • Signal में images को CDN पर cache करने का फायदा क्या है?
    अगर local client caching मौजूद मानें, तो उस resource के लिए total request count बहुत कम होना चाहिए, और ज्यादातर cases में शायद एक ही बार
    अलग से, CloudFront अगर cf-ray header return न करे या customers को उसे हटाने का option दे, तो यह problem बहुत आसानी से ठीक कर सकता है। हालांकि timing information से फिर भी पता लगाया जा सकता है

    • यह caching से ज्यादा CDN use है। CDN का origin content के cache की तरह काम करना CDN का side effect है; distribution response time बेहतर करने के लिए वह response के हिसाब से सबसे नजदीकी server पर cache करता है
      यहां “नजदीक” approximate heuristic है, और request जिन BGP routers से गुजरती है उनके anycast routing table की property है। असल में यह “optimal path” के ज्यादा करीब है
    • cf-ray header हटाने पर भी बस response time देखना काफी है। अगर resource दूसरे continent से लाना पड़े, तो शायद इसे reliably measure किया जा सकता है
      किसी user के मौजूद होने को छिपाने की कोशिश करने वाली websites में भी ऐसा ही होता है। मौजूद username से login request करने पर password hashing चलती है, जिससे आम तौर पर response time कम से कम 50ms बढ़ जाता है, और non-existent username जल्दी exit कर जाता है। solution है हमेशा same code चलाना और hashing भी हमेशा करना, लेकिन बहुत कम sites ऐसा करती हैं। या फिर threat model के हिसाब से username न होने की बात तुरंत बता देना भी ठीक हो सकता है
      Cloudflare case पर लौटें तो, response delay किए बिना यह मदद नहीं करेगा। लेकिन response delay करना Cloudflare के काम के उलट है
    • मुझे नहीं लगता कि Signal app या network images को CDN पर cache करने का choice करता है
      क्या यहां “attack” यह नहीं है कि कोई भी user दूसरे user को CDN पर cached resource link वाला message भेज सकता है? हो सकता है मैंने गलत समझा हो
    • Cloudflare को customers को वह header disable करने देना चाहिए, और Signal को किसी एक व्यक्ति को भेजी गई images या सौ से कम लोगों वाले groups में भेजी गई images cache नहीं करनी चाहिए
    • उस resource के लिए total request count कम होने वाली बात में, एक और number “उस server के लिए request count” है

  • थोड़ा समझ नहीं आया। क्या कभी किसी ने Signal को anonymous माना है? Discord के लिए भी यही बात है। अगर ऐसा है, तो बुरी खबर है। दोनों anonymous नहीं हैं, बिल्कुल नहीं हैं, ज़रा भी नहीं हैं
    उन्होंने ऐसा दावा भी कभी नहीं किया। Signal सिर्फ़ यह दावा करता है कि वह messages नहीं पढ़ सकता। Discord के बारे में ठीक से नहीं पता और शक है। उस दावे में भी कमियां हैं। Cryptography मजबूत हो तब भी, क्या आपने अभी इस्तेमाल हो रहे version की अच्छी तरह review की है और खुद compile किया है?
    ज्यादा से ज्यादा यह कमजोर pseudonymity भर है। यूज़र की सुविधा के लिए कुछ security त्यागने वाली applications का default रूप से media load करना हमेशा आम रहा है, और सामान्य threat model में यह ठीक विकल्प है। Messages में media डालना भी हमेशा deanonymization attacks का पुराना तरीका रहा है
    आखिरकार, बस इतना दिखा कि tracking pixel आज भी एक असरदार technique है; यह अच्छी बात है, लेकिन चौंकाने वाली नहीं
    अगर anonymous बने रहना चाहते हैं, तो Discord या Signal इस्तेमाल नहीं करना चाहिए, और HN पर लिखने की भी सलाह नहीं दूंगा। शायद Whonix के ज़रिए disposable account से, JavaScript के बिना, local LLM से फिर से लिखे गए messages को random समय पर automatically paste किया जाए तो कुछ संभावना हो सकती है। फिर भी इसकी गारंटी नहीं माननी चाहिए
    anonymity अब मौजूद नहीं है

    • मैंने यह बताने पर कि Signal metadata collect नहीं करता — यह बस Signal की बात पर भरोसा करना है — अब Signal subreddit में ban हो चुका हूं। इसलिए लोग सच में Signal को anonymous मानते हैं
    • लोग ऐसे माहौल में जहां anonymity महत्वपूर्ण होती है, Signal और Telegram* इस्तेमाल करते हैं। बेशक वे इस उद्देश्य के tools नहीं हैं, लेकिन कोई दूसरी widely understood solution नहीं है और ज्यादातर मामलों में उनके लिए यह काफी होता है
      • मज़ेदार बात यह है कि इस बार अपना protocol इस्तेमाल करने की वजह से यह vulnerable नहीं है, लेकिन शायद यह और भी खराब हो सकता है
    • लोग लगातार भूल जाते हैं कि anonymity और privacy अलग-अलग चीजें हैं