यूज़र की location information (User Location) पर भरोसा न करें

• ऐप में location-संबंधित logic जोड़ने के उदाहरण
  • region के अनुसार ऐप की language या currency सेट करनी हो
  • किसी खास country के लोगों को discount देना हो
  • store locator में यूज़र के सबसे नज़दीकी location को दिखाना हो
  • weather app को किसी भी तरह का data देने से पहले location पर निर्भर होना पड़े
  • legal reasons से ऐप को geofence करना हो (जैसे: cookie banner)
• इसमें कुछ common themes हैं
  • display/यूज़र experience: location information का उपयोग करके यूज़र experience को बेहतर या सरल बनाना
  • function/logic: location के आधार पर application की business logic बदलती है
  • policy/compliance: ऐसे legal requirements हैं जिनके कारण कुछ features को शामिल या बाहर करना पड़ता है
• ये हमेशा साफ़-साफ़ अलग नहीं होते। कुछ मामलों में overlap भी होता है, लेकिन गलत input होने पर उसकी गंभीरता अलग-अलग होती है, इसलिए इस फ़र्क़ को ध्यान में रखना ज़रूरी है

यूज़र location प्राप्त करने के तरीके

• यूज़र से सीधे location पूछना
  • फ़ायदे: implement करना आसान, यूज़र सही जानकारी दे तो भरोसेमंद, कई तरह की locations को support कर सकता है
  • नुकसान: यूज़र typo कर सकता है या जानकारी छोड़ सकता है, यूज़र झूठी जानकारी भी दे सकता है
• device heuristics का उपयोग करना
  • modern devices GPS, Wi-Fi data, cell towers और IP address के ज़रिए location information तक पहुँच सकते हैं
  • web developers browser के Geolocation API के माध्यम से यूज़र location तक पहुँच सकते हैं
  • नुकसान: यूज़र से location sharing की permission माँगनी पड़ती है, और यूज़र मना कर सकता है
• IP address का उपयोग करना
  • IP address network में device की uniquely पहचान करने और उसकी location का अंदाज़ा लगाने के लिए उपयोग होता है
  • IP address के हर number chunk broad range से narrow range तक subnet को दर्शाते हैं
  • सिर्फ़ IP address से यूज़र की location जानना काफ़ी नहीं है, इसलिए इसे known subnet location database से मिलाना पड़ता है
• edge computing का उपयोग करना
  • इसमें यूज़र request को सबसे नज़दीकी server पर execute किया जाता है
  • यूज़र से permission माँगे बिना या IP address lookup किए बिना location information मिल सकती है
  • नुकसान: यह असली यूज़र location नहीं, बल्कि edge node की location होती है

यूज़र location पर भरोसा क्यों नहीं किया जा सकता

• यूज़र पर भरोसा नहीं किया जा सकता
  • यह गारंटी नहीं कि यूज़र हमेशा अपनी वास्तविक location ईमानदारी से दर्ज करेगा
  • वह गलती से गलत जानकारी भी डाल सकता है
• device पर भरोसा नहीं किया जा सकता
  • यूज़र Geolocation API के उपयोग को अस्वीकार कर सकता है
  • Geolocation API की जानकारी browser settings में यूज़र बदल सकता है
• IP address पर भरोसा नहीं किया जा सकता
  • यूज़र अपनी request को VPN के माध्यम से route कर सकता है
  • तब आपको सिर्फ़ VPN का IP address दिखेगा, यूज़र का वास्तविक IP नहीं
• edge computing पर भरोसा नहीं किया जा सकता
  • क्योंकि यह edge node की location information है, इसलिए यह वास्तविक यूज़र location से अलग हो सकती है
  • VPN उपयोग होने पर original IP address तक पहुँच नहीं मिलती

तो फिर हमें क्या करना चाहिए?

• location information पाने के कई तरीके हैं, लेकिन इनमें से कोई भी पूरी तरह भरोसेमंद नहीं है
• तो क्या हमें हार मान लेनी चाहिए? No! हम बेहतर जानकारी जुटा सकते हैं और पहले से तैयारी कर सकते हैं

उदाहरण: content translation

• मान लीजिए एक website English में लिखी गई है, लेकिन दूसरी languages भी support करती है
• आप यूज़र की local language लोड करके उसका experience बेहतर बनाना चाहते हैं
• Belgium के उन यूज़र्स को कैसे संभालेंगे जो Dutch (Flemish), French और German बोलते हैं?

1. यूज़र website request करता है
2. edge computing से पता चलता है कि request Belgium से आई है
3. HTTP cookie में language preference खोजी जाती है
4. अगर cookie मौजूद है, तो वही preferred language इस्तेमाल करें
5. अगर cookie नहीं है, तो English या Dutch version इस्तेमाल करें
6. website पर यूज़र को supported languages की list दें
7. यूज़र language preference चुनता है, तो उसे cookie में save करें

• इस scenario में location information पाने के लिए edge computing और user reporting को मिलाकर यूज़र experience सुधारा जाता है
  • Geolocation API की ज़रूरत शायद नहीं है
  • गलत language दिखने का जोखिम है, लेकिन उसकी लागत कम है
  • location information गलत हो या missing हो, website फिर भी काम करती है
• अपडेट: client की preferred language और locale बताने वाला Accept-Language header भी उपलब्ध है

उदाहरण: weather app

• मान लीजिए एक application location के आधार पर weather information दिखाती है
  • इस मामले में app को काम करने के लिए location information चाहिए। अगर वह न हो, तो weather कैसे दिखाएँगे?
• इस scenario में first load पर यूज़र की location assume करना सुरक्षित है
  • edge computing या IP address से वह जानकारी लेकर (हमारे अनुमान के अनुसार) यूज़र के क्षेत्र का weather दिखाया जा सकता है
  • साथ ही, क्योंकि website का मुख्य focus location है, Geolocation API के ज़रिए अधिक accurate data भी माँगा जा सकता है
  • अगर यूज़र किसी दूसरी location की जानकारी चाहता हो, तो flexible user-reporting option भी देना चाहिए
  • इसके लिए एक autocomplete search input दिया जा सकता है, जो यथासंभव detailed location information दे
  • future visits को संभालने के कई तरीके हो सकते हैं। हमेशा "local" weather को default रखें या पिछली visit की location याद रखें

1. यूज़र website request करता है
2. पहली request पर edge computing या IP address से location information का अनुमान लगाकर app शुरू करें
3. पहले client load पर Geolocation API चलाकर जानकारी update करें
4. future loads के लिए location information को cookie में save किया जा सकता है
5. दूसरी location search करने के लिए autocomplete वाला flexible input दें

• यहाँ महत्वपूर्ण बात यह है कि app को वास्तव में यूज़र कहाँ है, इसकी परवाह नहीं है
  • उसे बस location चाहिए
  • यूज़र द्वारा बताई गई location (search) को cookie, edge computing या IP address से मिली location पर प्राथमिकता मिलती है
• क्योंकि weather रोज़ बदलता है, इसलिए caching strategy और app को मुख्य रूप से server-rendered रखना है या client-rendered, इस पर भी विचार करना चाहिए

उदाहरण: store locator

• मान लीजिए आप कई locations पर physical stores चलाते हैं
  • आप product catalog और inventory online दिखा सकते हैं, लेकिन in-store inventory की up-to-date जानकारी देना बेहतर होगा
  • इसके लिए यह जानना ज़रूरी है कि किस store की inventory दिखानी है, और best user experience के लिए वह यूज़र के सबसे नज़दीकी store का data होना चाहिए
• एक बार फिर, edge computing या IP address का उपयोग करके यूज़र की location का अनुमान लगाना उचित है
  • फिर यूज़र को location information दर्ज करने के लिए flexible input दें, लेकिन autocomplete को proximity के अनुसार sorted store list तक सीमित रखें
  • Geolocation API चलाना भी अच्छा विचार है
• इस उदाहरण और पिछले उदाहरण में अंतर यह है कि site का मुख्य उद्देश्य location पर निर्भर नहीं करता
  • इसलिए तब तक इंतज़ार करना चाहिए जब तक यूज़र location-dependent feature के साथ interact न करे
  • यानी, location तभी माँगें जब यूज़र store locator field पर focus करे

उदाहरण: region-based price differences

• यह थोड़ा tricky विषय है: अगर यूज़र की location के आधार पर अलग-अलग कीमत लेनी हो, तो कैसे करेंगे?
• उदाहरण के लिए, कुछ airlines और hotels के बारे में जाना जाता है कि वे एक region से booking करने वाले यूज़र्स को दूसरे region की तुलना में ज़्यादा कीमत दिखाते हैं
• ethical issues को अलग रखें, तो यह profitability का सवाल है, इसलिए इसका असर बहुत बड़ा हो सकता है
• इसलिए आप शायद नहीं चाहेंगे कि यूज़र self-reported location information के ज़रिए आसानी से price बदल सके
• इस स्थिति में संभवतः आप सिर्फ़ edge computing या IP address का उपयोग करेंगे
  • यूज़र VPN का उपयोग करके इसे bypass कर सकता है, लेकिन शायद यही सबसे अच्छा संभव तरीका होगा
  • अगर आप fraudsters से बचने को लेकर बहुत चिंतित हैं, तो Akamai की enhanced proxy detection capability का उपयोग करके VPN users की requests block करने की कोशिश कर सकते हैं
  • लेकिन ऐसा करने से discounted sale के बजाय पूरी sale ही न हो, ऐसा भी हो सकता है। फ़ैसला आपका है

उदाहरण: cookie banner

• यह आख़िरी उदाहरण legal compliance पर ज़्यादा केंद्रित है, इसलिए एक छोटा disclaimer: मैं वकील नहीं हूँ!!!
  • यह सिर्फ़ एक hypothetical example है और इसे legal advice नहीं माना जाना चाहिए
• 2016 में European Union ने General Data Protection Regulation (GDPR) पारित किया
  • यह EU के internet users की privacy की रक्षा करने वाला क़ानून है, और यह उन companies पर भी लागू होता है जो EU के बाहर हों लेकिन EU के भीतर व्यक्तियों को goods या services देती हों
• website owners के लिए इसमें कई requirements हैं, लेकिन मैं जिस चीज़ पर ध्यान दे रहा हूँ वह है cookie banners का संकट, जो आज हमें online लगभग हर जगह दिखता है
  • मैं privacy concerns, cookie banners सही हैं या गलत, उनकी effectiveness या ineffectiveness, या क्या कोई बेहतर approach है—इन पर चर्चा नहीं करूँगा
  • इसके बजाय, मैं कहूँगा कि cookie banner केवल तब दिखाना बेहतर है जब वह कानूनी रूप से आवश्यक हो, और अन्यथा उससे बचना चाहिए
• एक बार फिर, यूज़र की location जानना बहुत महत्वपूर्ण है
  • यह पिछले case से बहुत मिलता-जुलता है और implementation भी समान है। मुख्य अंतर गलती होने पर उसकी गंभीरता और उसे सही ढंग से करने में लगने वाले प्रयास का स्तर है
• cookie banner शायद सबसे व्यापक उदाहरण है कि क़ानून और यूज़र location website को कैसे प्रभावित कर सकते हैं, लेकिन अगर आप सबसे शक्तिशाली उदाहरण ढूँढ रहे हैं, तो शायद वह चीन की firewall होगी

निष्कर्ष

• यूज़र location निर्धारित करने का कोई एक सही जवाब नहीं है
  • scenario के अनुसार user reporting, device heuristics, edge computing और IP address को मिलाकर approach करनी चाहिए
• महत्वपूर्ण बातें
  • क्या आपको यूज़र की location चाहिए, या बस कोई भी location काफ़ी है?
  • data कितना accurate होना चाहिए?
  • अगर यूज़र location spoof की गई हो, तो क्या वह स्वीकार्य है?
• साथ ही legal compliance, regulations, functionality, और क्या 95% reliability काफ़ी है—इन पर भी विचार करना चाहिए
• अगर आप legal reasons से location logic उपयोग कर रहे हैं, तो खुद की सुरक्षा के लिए कदम उठाना अच्छा है
• CCPA, GDPR जैसी data privacy laws का पालन करें