Mullvad exit IP आश्चर्यजनक रूप से आसानी से पहचाने जा सकते हैं

 (tmctmt.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Mullvad एक सर्वर पर कई exit IP रखता है, लेकिन WireGuard key के आधार पर उन्हें निर्धारक रूप से असाइन करता है, इसलिए हर कनेक्शन पर वे रैंडम तरीके से नहीं बदलते
  • 9 सर्वरों पर pubkey को बार-बार बदलकर जुटाए गए 3,650 data points को संभावित 8.2 ट्रिलियन संयोजनों में से सिर्फ 284 संयोजनों पर ही असाइन किया गया
  • हर सर्वर का exit IP अपने pool के भीतर लगभग समान percentile position पर होता है, और एक संयोजन कई सर्वरों में मोटे तौर पर 81वें percentile पर मैप होता है
  • वजह संभवतः ऐसी संरचना है जिसमें pubkey या tunnel address को seed बनाकर और pool size को upper bound बनाकर seed-based RNG से exit IP index चुना जाता है
  • अगर IP logs के float ranges आपस में overlap करें, तो अलग-अलग Mullvad सर्वर इस्तेमाल करने पर भी अकाउंट्स के बीच correlation संभव हो जाता है, जिससे anonymity risk बढ़ता है

Mullvad exit IP कैसे fingerprinting vector बन जाते हैं

  • Mullvad एक सर्वर पर कई exit IP देता है, और एक ही सर्वर से जुड़े दो उपयोगकर्ताओं को आमतौर पर अलग-अलग public IP मिलते हैं
  • सर्वरों की संख्या 578 है, जो Proton VPN के 20,000 सर्वरों से कम है; इसलिए एक IP पर बहुत अधिक उपयोगकर्ता न बिठाने वाला vertical scaling, अत्यधिक IP blocking और rate limiting से बचने में फायदेमंद है
  • लेकिन हर बार सर्वर से जुड़ते समय exit IP रैंडम तरीके से नहीं बदलता, बल्कि WireGuard key के आधार पर निर्धारक रूप से चुना जाता है
  • WireGuard key 1~30 दिनों में rotate होती है, लेकिन third-party clients में rotation नहीं होती
  • अगर हर सर्वर पर स्वतंत्र रूप से fixed exit IP असाइन होता है, तो कुछ सर्वरों के IP combination भर से किसी उपयोगकर्ता को दूसरे Mullvad उपयोगकर्ताओं से अलग पहचाना जा सकता है

9 सर्वरों पर देखे गए exit IP combinations

  • pubkey को बार-बार बदलते हुए 9 सर्वरों के exit IP इकट्ठा करने वाली script को रात भर चलाकर 3,650 pubkey data points जुटाए गए
  • हर सर्वर की exit IP range इस प्रकार देखी गई
Hostname Start IP End IP # IPs
au-syd-wg-101 103.136.147.5 103.136.147.64 60
cl-scl-wg-001 149.88.104.4 149.88.104.14 11
de-ber-wg-007 193.32.248.245 193.32.248.252 8
dk-cph-wg-002 45.129.56.196 45.129.56.226 31
fi-hel-wg-201 185.65.133.10 185.65.133.75 66
us-lax-wg-001 23.234.72.36 23.234.72.126 91
us-nyc-wg-602 146.70.168.132 146.70.168.190 59
us-sjc-wg-302 142.147.89.212 142.147.89.224 13
za-jnb-wg-002 154.47.30.145 154.47.30.155 11
  • इन सर्वरों के pool sizes को गुणा करने पर 8.2 ट्रिलियन से अधिक exit IP combinations संभव लगते हैं
  • लेकिन वास्तव में टेस्ट किए गए सभी pubkey को उनमें से सिर्फ 284 combinations में से किसी एक पर ही असाइन किया गया
  • संभावित combinations की तुलना में observed combinations की संख्या बहुत कम है, जो संकेत देती है कि सर्वर-वार IP selection स्वतंत्र नहीं है

अलग-अलग IP का एक ही percentile पर आने का pattern

  • exit IP की numeric position इस आधार पर निकाली जा सकती है कि वह pool के start IP से कितनी दूर है
  • उदाहरण के लिए au-syd-wg-101 पर 103.136.147.53, 103.136.147.5 से गिनने पर 1-based index 49 है
  • observed combinations के IP positions को हर सर्वर के pool size से विभाजित करने पर अलग-अलग सर्वरों में भी लगभग एक जैसा ratio दिखता है
Server IP Position Pool size Ratio
au-syd-wg-101 103.136.147.53 49 60 0.816
cl-scl-wg-001 149.88.104.12 9 11 0.818
de-ber-wg-007 193.32.248.251 7 8 0.875
dk-cph-wg-002 45.129.56.220 25 31 0.806
fi-hel-wg-201 185.65.133.63 54 66 0.818
us-lax-wg-001 23.234.72.109 74 91 0.813
us-nyc-wg-602 146.70.168.179 48 59 0.813
us-sjc-wg-302 142.147.89.222 11 13 0.846
za-jnb-wg-002 154.47.30.153 9 11 0.818
  • हर IP अपने pool के लगभग समान percentile पर आता है, और ऊपर दिया गया उदाहरण मोटे तौर पर 81वें percentile से मेल खाता है
  • इस pattern के कारण ऐसा लगता है कि Mullvad सभी सर्वरों पर एक-दूसरे के पड़ोसी स्थानों वाले exit IP ही असाइन करता है

seed-based random selection जैसी दिखने वाली वजह

  • cl-scl-wg-001 और za-jnb-wg-002 ने observed 284 IP combinations में हमेशा एक ही IP index साझा किया
  • इन दोनों सर्वरों में समानता यह है कि pool size 11 है, जो ऐसी संरचना से मेल खाती है जहाँ समान seed और समान bounds के साथ random call हमेशा वही परिणाम देती है
  • अगर static seed से RNG initialize किया जाए और उसी range में random number चुना जाए, तो वही परिणाम बार-बार दोहराया जाएगा
  • ऐसा लगता है कि Mullvad pubkey या tunnel address को seed की तरह इस्तेमाल करके, और pool size को upper bound बनाकर seed-based RNG से exit IP index चुनता है
  • bounds बदलने पर भी RNG के entropy pool पर असर नहीं पड़ता, और Rust में यह उस व्यवहार से मेल खाता है जहाँ पहली call में वही float बनता है और bounds से multiply होता है
  • इस व्यवहार को min + round((max - min) * float) की तरह सरल करके समझा जा सकता है, हालांकि यह काफी सरलीकृत अभिव्यक्ति हो सकती है
  • इसी गुण के कारण pool size अलग होने पर भी एक ही seed से निकला float, हर सर्वर pool के लगभग समान ratio वाले बिंदु पर map हो जाता है
  • Mullvad client Rust में लिखा गया है, इसलिए backend language भी Rust हो सकती है, हालांकि यह निष्कर्ष केवल client implementation पर आधारित है
  • random_range bounds बदलने पर ठीक कैसे व्यवहार करेगा, इसका सटीक अनुमान लगाना कठिन है; आम तौर पर लग सकता है कि bounds बढ़ने से entropy के साथ mix होकर दूसरा number बनेगा, लेकिन observed परिणाम ऐसा नहीं दिखाते

IP log correlation से पैदा होने वाला anonymity risk

  • किसी विशेष IP combination के लिए संभावित float values के minimum और maximum का अनुमान लगाने वाला टूल mullvad-seed-estimator के रूप में उपलब्ध है
  • screenshot में दिखाए गए एक विशेष IP set को 0.2909~0.2943 के बीच की float value के रूप में समझा गया, और अंतर 0.0034 है
  • इसका मतलब है कि Mullvad उपयोगकर्ताओं में 0.34% लोग यही IP साझा करेंगे, जो 100,000 active users के मोटे अनुमान में 340 लोगों के बराबर है
  • यह शुरुआत में सोचे गए स्तर जितना unique नहीं है, लेकिन 99% से अधिक accuracy भी कम नहीं है
  • उदाहरण के लिए, अगर किसी forum admin को पिछली रात ban किए गए उपयोगकर्ता के sockpuppet होने का शक किसी नए अकाउंट पर हो, तो दोनों अकाउंट अलग-अलग Mullvad सर्वर इस्तेमाल कर रहे हों तब भी यदि उनके IP logs 0.4334 - 0.4428 और 0.4358 - 0.4423 जैसे overlap करने वाले float ranges दिखाएँ, तो उनके एक ही व्यक्ति होने की संभावना 99% से अधिक हो जाती है
  • data breach या legal process से प्राप्त IP logs पर भी यही correlation लागू किया जाए, तो VPN के पीछे छिपे उपयोगकर्ता अपनी anonymity खो सकते हैं

सुरक्षा के तरीके

  • एक pubkey के लिए सर्वर को एक से अधिक बार न बदलना सुझाया गया है
  • Mullvad app में logout करके pubkey को force rotate किया जा सकता है

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

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • मैं Mullvad में काम करने वाला co-CEO और co-founder हूँ। पोस्ट में बताए गए कुछ व्यवहार जानबूझकर हैं और कुछ नहीं, और कारण भी ब्लॉग पोस्ट में दी गई व्याख्या से बिल्कुल मेल नहीं खाते
    mitigation के तौर पर, अनचाहे व्यवहार के लिए patch का कुछ इंफ्रास्ट्रक्चर पर पहले से परीक्षण चल रहा है, इसलिए अगर आज इसे reproduce करने की कोशिश करें तो नतीजे उलझाऊ हो सकते हैं
    जो व्यवहार जानबूझकर हैं, वे स्वीकार्य हैं या नहीं, इसका भी फिर से मूल्यांकन करेंगे; इसमें कई privacy पहलुओं और user experience के बीच trade-off है
    यह समझ मुझे एक घंटे पहले ही हुई है, उसके बाद ops टीम के साथ तुरंत प्रतिक्रिया पर चर्चा की और यह लिखते हुए अपनी मौजूदा राय व्यवस्थित की है, इसलिए यह बदल भी सकती है
    सुरक्षा शोध करने वालों से अनुरोध है कि सुरक्षा·प्राइवेसी समस्या मिले तो, भले उसे तुरंत सार्वजनिक करने का इरादा हो, पहले admin या vendor को सूचित करें

    • Mullvad client में डिफ़ॉल्ट key rotation interval शायद 72 घंटे है, और CLI client को भी थोड़ा बदलकर native WireGuard इस्तेमाल करने वाली ज़्यादातर स्थितियों में चलाया जा सकता है
      mullvad tunnel get से इसे देखा जा सकता है और mullvad tunnel set rotation-interval से बदला जा सकता है; पोस्ट में पसंद किया गया mitigation तरीका भी यही है
      व्यक्तिगत रूप से मुझे semi-static IP बहुत बड़ी समस्या नहीं लगती। मकसद ISP और सरकार की network-level निगरानी को रोकना है, और कुछ प्रदाता तो static IPv4 को feature के रूप में बेचते भी हैं
      privacy VPN में IP space जितनी छोटी हो, बाहर से दिखने वाले एक IP के पीछे उतने ज़्यादा users मिल सकते हैं, इसलिए इसमें एक फ़ायदा भी है। DAITA जैसी तकनीक, जो tunnel में dummy traffic डालती है, और multihop entry points को मिलाकर, मुझे लगता है कि पूरे दिन netflow देखने वाले निगरानीकर्ता के लिए यह वास्तव में और कठिन बना सकता है
    • मैं Obscura का CEO Carl हूँ, और Mullvad के partners में से एक भी। यह दिलचस्प खोज है, लेकिन जैसा kfreds ने कहा, सार्वजनिक करने से पहले vendor को बताना बेहतर होता
      मुख्य खोज, यानी सर्वरों के बीच IP pool में स्थिति का correlation, वास्तव में अनचाहे व्यवहार को शामिल करती लगती है। Mullvad टीम के साथ काम करने के मेरे अनुभव के आधार पर, यह जल्दी ठीक हो जाएगा
      अगर अलग-अलग “identities” चाहिए, तो WireGuard keys rotate करनी होंगी या अलग keys इस्तेमाल करनी होंगी
      लेख में कहा गया है कि “हर बार server से connect करने पर exit IP random नहीं चुना जाता, बल्कि WireGuard key के आधार पर deterministically चुना जाता है, और वह key हर 1~30 दिनों में rotate होती है। third-party clients इस्तेमाल करने पर यह rotate नहीं होती।” लेकिन WireGuard डिज़ाइन के अनुसारhttps://www.wireguard.com/protocol/ connectionless protocol है, इसलिए इसमें connection की धारणा ही नहीं है; सिर्फ़ traffic बहने पर हर 2~3 मिनट में rekeying handshake होता है
      अगर उसी WireGuard key पर हर “connection” के समय, जैसे हर rekeying handshake पर या हर 15 मिनट में, exit IP बदल जाए, तो transport layer पर QUIC को छोड़कर tunnel के अंदर की लगभग सारी connections टूटकर फिर से बनानी पड़ेंगी, और application layer पर “same cookie, new IP” पर शक करने वाली services logout, CAPTCHA, और risk score ट्रिगर करेंगी
      दोनों ही खराब user experience हैं, और इससे भी बुरा यह कि इससे user का fingerprint और अधिक अनोखा बन सकता है, जैसे “यह व्यक्ति बार-बार अलग IP से reconnect कर रहा है, इसलिए यह Mullvad user है”

  • “फ़ोरम admin ने जिस user को एक दिन पहले ban किया था, उसके alt account पर शक करके IP logs देखे, तो अलग-अलग Mullvad servers इस्तेमाल होने के बावजूद दोनों accounts overlapping floating-point ranges 0.4334~0.4428 और 0.4358~0.4423 पर map हुए, इसलिए 99% से ज़्यादा संभावना है कि यह वही व्यक्ति है” — यह उदाहरण ऐसा एहसास देता है जैसे कोई intelligence agency VPN डिज़ाइन करे तो शायद ऐसा बनाए

    • समझ नहीं आता क्यों। अगर कोई intelligence agency VPN डिज़ाइन करे, तो वह exit node statistics पर निर्भर नहीं करेगी; वह बस VPN से जुड़ने वाले सभी IPs को log करेगी
      ऊपर से, यह तरीका इस बात पर निर्भर करता है कि user अलग-अलग servers चुने, इसलिए और भी कम वजह बनती है
    • कभी न कभी यह भी सामने आएगा कि Cloudflare का intelligence agencies से संबंध है। अगर “अचानक DDoS” का समाधान यह है कि website को Cloudflare के पीछे रख दो, तो यह भी सोचने का मन होता है कि ऐसे अचानक हमले कौन कर सकता है
    • फिर भी logs स्टोर न करने वाली छोटी-सी detail अभी भी बची हुई है
      मेरे हिसाब से यह बड़ी समस्या है, और यह कई VPN exit nodes के बीच correlation analysis को संभव बनाती है, लेकिन बस इतना ही। यह अपने-आप users की पहचान संभव नहीं बनाती
      हालांकि यह पहचान की कठिनाई को काफ़ी कम कर देती है, और शर्तें अब भी ऊँची हैं। उम्मीद है जल्द ठीक होगा
      “इसे hash जैसी sensitive value से बना देते हैं” वाली गलती आज भी, वह भी Mullvad में, हो रही है — यह यक़ीन करना मुश्किल है। सीधा randomize क्यों नहीं किया गया?
    • Mullvad Snowden खुलासों से कई साल पहले से मौजूद था, और उन दस्तावेज़ों में उसका कहीं ज़िक्र नहीं था
      बेशक दूसरी intelligence agencies भी हैं, लेकिन चिंता सबसे ज़्यादा उसी पक्ष की होती है। या तो वह खुद इसे चलाते, या ऐसा विचार जानते और कॉपी करते, या partner agencies के चलाए service तक उनकी पहुँच होती। वरना वह मेरे लिए threat नहीं होते
      और Mullvad users के VPN के ज़रिए deanonymize होने का कोई सार्वजनिक मामला नहीं है; जो मामले ज्ञात हैं वे दूसरी opsec विफलताओं से सामने आए। अगर intelligence agencies के पास यह क्षमता होती, तो यह मानना कठिन है कि लगभग 20 साल के डेटा के बावजूद उन्होंने इसका इस्तेमाल नहीं किया होता
    • अगर intelligence agency VPN को नियंत्रित कर रही हो, तो वह सीधे traffic की निगरानी कर सकती है। बाहरी observer के लिए यह अनुमान लगाना आसान बनाने की कोई प्रेरणा नहीं होती कि कौन-सा user किस exit IP से निकल रहा है

  • सिर्फ़ पोस्ट में दिए गए numbers से “99% से ज़्यादा संभावना” कैसे निकलती है, यह समझ नहीं आता। भले ही मज़बूती से मान लें कि पहले banned IP का seed और दूसरे का seed दोनों 0.4423~0.4358 रेंज में हैं, इसका मतलब सिर्फ़ इतना है कि यह रेंज पूरे Mullvad user base का 0.65% शामिल करती है
    अगर users 100,000 हों तो यह 650 लोग हुए; यानी आपने “suspects” को 99% से ज़्यादा घटाया है, लेकिन कई exit IPs के पार किसी एक व्यक्ति की 99% से ज़्यादा accuracy से पहचान नहीं की है
    Bayesian नज़रिए से देखें तो संभावित seeds का overlap मज़बूत सबूत है कि दोनों IPs एक ही व्यक्ति के, या कम-से-कम एक ही Mullvad account के हैं; लेकिन पोस्ट लेखक जो कह रहा है, वह शायद यह नहीं है

    • मान लें फ़ोरम थोड़ा बड़ा है, 1000 active users हैं और रोज़ 1 नया user जुड़ता है। तब यह देखना होगा कि किसी के ban होने के अगले दिन इस VPN का इस्तेमाल करने वाला और मिलती-जुलती range वाला कोई व्यक्ति join करे, इसकी कितनी संभावना है
      ज़्यादातर छोटी websites पर यह काफ़ी मज़बूत सबूत बन जाता है

  • VPN का उद्देश्य visit की गई sites के सामने user को anonymous बनाना नहीं है, इसलिए Mullvad unique exit IP enforce नहीं करता, यह चौंकाने वाली बात नहीं होनी चाहिए। जिन्हें anonymity चाहिए, उन्हें Tor जैसे network का इस्तेमाल करना चाहिए

    • क्यों नहीं हो सकता, यह समझ नहीं आता। किसी खास VPN service का उद्देश्य ऐसा होना असंभव क्यों होगा?
    • क्या Tor अमेरिकी सरकार की project नहीं है, और क्या यह नहीं दिखाया गया कि इसे deanonymize किया जा सकता है?
    • यही तो public VPN का मकसद है
      अगर आप public VPN इस्तेमाल करते हैं, तो ideally किसी को यह नहीं पता होना चाहिए कि request किसने भेजी, end IP सहित
      उस तर्क से तो VPN का इस्तेमाल torrenting के लिए नहीं होना चाहिए। क्योंकि उसका मतलब होगा कि उसे end IP के संदर्भ में anonymity नहीं देनी चाहिए। लेकिन व्यवहार में यह torrenting में बहुत अच्छी तरह काम करता है
      अगर आप private VPN की बात कर रहे हैं, तो Mullvad वैसा नहीं है

  • मैं लंबे समय से Mullvad इस्तेमाल कर रहा हूँ, और जब तक मेरे देश में यह कानूनी है, मैं अपने नाम वाले credit card से Mullvad VPN service खरीदना और इस्तेमाल करना जारी रखूँगा
    VPN 100% anonymous नहीं है, और न ही इसे इस तरह डिज़ाइन किया गया था। बल्कि यह कानून का पालन करने वाले वयस्कों को कुछ हद तक privacy देने के लिए है
    ज़्यादातर लोगों को शर्मिंदगी होगी अगर उनके सहकर्मी और पड़ोसी उनकी निजी ज़िंदगी, पसंद, ख़रीदारी और कामों के बारे में जान जाएँ। इसी वजह से अधिकांश लोगों को privacy की सुरक्षा के लिए VPN इस्तेमाल करना चाहिए
    परिभाषा के अनुसार “ज़्यादातर लोग” online 100% anonymity न चाहते हैं, न उसकी उम्मीद करते हैं; वे बस अपनी निजी ज़िंदगी और रिश्तों में थोड़ी privacy चाहते हैं
    VPN का उद्देश्य online crime करने वालों को सरकार से 100% anonymity देना नहीं है, और न ही उसका ऐसा इरादा है। यह फ़र्क महत्वपूर्ण है। “ज़्यादातर लोग” अपराधी नहीं होते, और Mullvad या किसी दूसरे VPN provider से ऐसी अवास्तविक अपेक्षा नहीं रखते

    • VPN anonymous नहीं होते; लोग बस ऐसा जताते हैं। फिर भी इस रिपोर्ट की खोज यह दिखाती है कि इसमें ऐसी चीज़ें हैं जो user identification को अपेक्षा से आसान बनाती हैं
      सिर्फ़ ऊपर वाले तर्क से रिपोर्ट को ख़ारिज नहीं किया जा सकता। खोज अपने-आप में अब भी वैध है

  • इसमें एक चीज़ छूटी हुई है। जानना चाहूँगा कि क्या Mullvad से संपर्क किया गया था। security team ने कैसे प्रतिक्रिया दी, यह देखना भी दिलचस्प होता

    • मेरी जानकारी के अनुसार संपर्क नहीं किया गया था; मैंने ops टीम और support टीम दोनों से पुष्टि की है। अगर मैं ग़लत हूँ, तो मैं यह पोस्ट update करूँगा
      बाद में लगा कि यह टिप्पणी लिखकर पछतावा हुआ। यह अनावश्यक था, लेकिन अब इसे मिटाऊँ तो अजीब लगेगा
    • नहीं, लेकिन इस पोस्ट की सबसे ऊपर वाली top-voted comment Mullvad co-founder का जवाब है

  • यह बात मुझे चौंकाती है कि लोग VPN से Tor जैसी अपेक्षा रखते हैं
    इस तरह खोलकर कहें तो यह बेतुकी लगती है, और यह भी ध्यान रखना चाहिए कि exit node को नियंत्रित किया जाए तो Tor users को भी deanonymize किया जा सकता है

    • इसमें हैरानी की बात नहीं, क्योंकि ज़्यादातर बड़े consumer VPN अपनी marketing में “privacy” को anonymity जैसा imply करते हैं
    • क्या Tor के डिज़ाइन का हिस्सा यही नहीं था कि traffic कई relay nodes से गुज़रे, ताकि exit node भी original IP न देख सके?
    • ज़रूरी नहीं कि यह अपेक्षित हो, लेकिन अगर संभव हो तो कोई privacy देने के लिए जो किया जा सकता है, वह करने की कोशिश करेगा — ऐसा सोचना स्वाभाविक है

  • “exit IP हर connect पर randomize नहीं होता, बल्कि WireGuard key के आधार पर deterministically चुना जाता है, और यह key हर 1~30 दिनों में rotate होती है। third-party clients इस्तेमाल करने पर यह कभी rotate नहीं होती” — यह हिस्सा थोड़ा confusing है
    अगर repository में तरीका विस्तार से दिया गया है, तो समझ नहीं आता कि third-party को default app client की तरह key rotation करने से रोक क्या रहा है

    • third-party clients में, उदाहरण के लिए, Linux kernel का WireGuard driver भी शामिल है। network driver पर किसी एक खास commercial service के लिए attack mitigation की ज़िम्मेदारी नहीं डाली जा सकती
    • मुख्य बात यह है कि लोगों को पता ही नहीं होता कि ऐसा करना चाहिए

  • पोस्ट लेखक ने यह अच्छी तरह पकड़ा, और यह भी काफ़ी विश्वसनीय है कि यह Mullvad की गलती थी। इतनी साधारण चीज़ का निकल जाना काफ़ी चौंकाने वाला है, हालांकि मैं भी शायद इसे मिस कर देता
    कई servers के बीच IP correlation को छोड़ दें, तो शुरुआत में मुझे यह भी जिज्ञासा हुई कि एक server पर user IP स्थिर क्यों रखा जाता है। लेकिन लेखक का यह स्पष्टीकरण समझ में आता है कि दूसरे VPN अक्सर प्रति server एक ही IP रखते हैं, तो यह उसी की नकल है
    इसका फ़ायदा यह है कि अगर user को कोई ऐसा server मिल जाए जिससे कोई service accessible हो, तो दोबारा उसी server से जुड़ने पर वही IP मिलने से फिर वही चीज़ काम करने की संभावना रहती है
    हालाँकि servers के बीच IP correlation को rand.seed(user_pub_key + server_id) जैसे तरीके से ठीक करना चाहिए

    • उल्टा देखें तो अगर उसी IP के noisy neighbor की वजह से किसी service पर block हो जाए, तो user के पास उससे निकलने का कोई रास्ता नहीं बचेगा, है न?

  • मैं IPinfo में काम करता हूँ। हम VPN detection business में हैं, लेकिन ईमानदारी से कहूँ तो Mullvad के बारे में मैं good faith मानना चाहूँगा
    हमारे जैसे IP geolocation providers को गलत geolocation जानकारी submit करने की कोशिश न करने वाले VPN providers में Mullvad उन तीन में से एक था। मुझे भरोसा है कि यह issue भी ठीक कर दिया जाएगा

    • बाकी कौन थे?