जब ऐप permission मांगे, तो "fake data देने" का विकल्प होना चाहिए

 (archive.md)
1 पॉइंट द्वारा GN⁺ 2023-07-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • जब कोई ऐप permission मांगे, तो OS को सिर्फ हाँ/ना जवाब की अनुमति नहीं देनी चाहिए, बल्कि "fake data देने का विकल्प" हर permission category में जोड़ना चाहिए
  • contacts मांगे जाएँ तो generate किए गए fake contacts, microphone access मांगा जाए तो random ambient sound, location data मांगा जाए तो 5×5m के छोटे द्वीप के coordinates दिए जाएँ
  • access block करने पर ऐप कह सकता है कि "तब इसका इस्तेमाल नहीं किया जा सकता", लेकिन fake data देने पर सिर्फ वही सेवाएँ दंडित होती हैं जो अनावश्यक data मांगती हैं
  • boycott उपयोगकर्ता से बड़ा व्यक्तिगत त्याग मांगता है लेकिन कंपनियों पर उसका असर बहुत मामूली रहता है, इसलिए malicious compliance boycott से अधिक प्रभावी है — यह दृष्टिकोण रखा गया
  • यह बात आगे user control के मुद्दे तक जाती है कि उपयोगकर्ता अपने स्वामित्व वाले device के administrator के रूप में apps और system software को नियंत्रित कर सके

मुख्य प्रस्ताव — permission के अनुसार fake data विकल्प

  • OS को permission request पर yes/no के अलावा "हाँ, लेकिन fake data दें" का विकल्प हर category में देना चाहिए
    • contacts request → random generated fake contacts देना
    • microphone request → random ambiance देना
    • location request → जवाब देना कि उपयोगकर्ता 5×5m के छोटे द्वीप पर है
  • यदि कोई service ऐसे data की मांग करे जिसकी उसे ज़रूरत नहीं है, तो उसके database में बेकार जानकारी भरकर उसे दंडित करने जैसा असर होगा
  • access block करने के विपरीत, fake data ऐप को "इस्तेमाल नहीं किया जा सकता" जैसी प्रतिक्रिया देने से रोक सकता है और साथ ही अनावश्यक data collection को निष्प्रभावी कर सकता है

boycott की तुलना में बेहतर होने का दावा

  • ज़रूरी apps का boycott करना काफी बड़ा व्यक्तिगत त्याग है, जबकि अरबपतियों पर उसका असर मुश्किल से महसूस होता है, इसलिए यह उपयोगकर्ता के लिए नुकसानदेह सौदा है
    • लड़ाई में वही पक्ष सबसे ज़्यादा खोता है जो विरोध करता है, इसलिए यह संरचना उपयोगकर्ता के खिलाफ जाती है
  • fake data injection का तरीका उपयोगकर्ता को ज़्यादा ताकत देता है — ऐसा तर्क दिया गया
  • यह भी कहा गया कि malicious compliance boycott से ज़्यादा मज़ेदार है

चर्चा में बताए गए मौजूदा तरीके

  • location spoofing

    • पहले location spoofing सिर्फ global setting के रूप में संभव थी, app-wise चुनना मुश्किल था
    • Android developer settings में किसी खास app को mock location app के रूप में चुनने पर यह global रूप से लागू होता है
    • Firefox में geolocation सहित कई तरह के data spoofing के लिए extensions मौजूद हैं, लेकिन फोन पर काम करने वाला तरीका ज़्यादा उपयोगी होगा
    • Pokémon GO में fake location data से cheating के मामले रहे हैं, जिससे तकनीकी रूप से इसकी संभावना सिद्ध होती है

  • XPrivacyLua

    • rooted devices पर यह उपयोगकर्ता की चाही गई क्रिया बिल्कुल सही तरीके से करता था, लेकिन इसके लिए Magisk (system modification) की ज़रूरत पड़ती थी
    • फिलहाल इसका maintenance बंद है और यह सभी devices के साथ compatible नहीं है

  • Android की built-in permission features

    • Android पहले से ही app-wise information access चुनने या हर बार पूछने की सुविधा देता है
    • लेकिन यह blocking method है, fake data उपलब्ध कराने जैसा नहीं

विस्तार के लिए विचार और उदाहरण

  • AI का उपयोग कर data pollution

    • data miners को अर्थहीन जानकारी recursive रूप से देकर निष्प्रभावी करने का सुझाव
    • AI-generated data से AI training content तक को प्रदूषित करने का विचार

  • ad tracking के खिलाफ प्रतिक्रिया

    • ads block करते हुए हर ad पर click करके targeting data को निष्प्रभावी करने वाले AdNauseam (uBlock Origin का fork) का उल्लेख
    • अतीत के प्रयासों में resource usage बहुत ज़्यादा होने की बात कही गई

  • browser tracking profile में व्यवधान

    • browser और cookies के साथ कई sites पर तेज़ी से घूमकर fingerprinting और tracking को गड़बड़ाने वाली services मौजूद हैं
    • random या profile-based pattern चुने जा सकते हैं, जैसे: "Ecuador के 70 वर्षीय hippie की तरह browse करें"
    • Mozilla के TrackThis का उदाहरण दिया गया

उठाई गई सीमाएँ और चिंताएँ

  • random date of birth डालने पर किसी मनमानी तारीख को birthday wishes मिल सकती हैं, लेकिन security questions में यह समस्या होगी कि कौन-सी तारीख दी थी, यह पता न रहे
    • इस पर यह पूरक राय दी गई कि OS उपयोगकर्ता को उसके अपने fake data values दिखा सके
  • लगभग 10 साल पहले इसे startup idea के रूप में देखा गया था, लेकिन इसे कानूनी रूप से बचाव योग्य बनाने वाला कोई वकील नहीं मिला
  • यह अनुमान जताया गया कि commercial developers इससे बहुत डरेंगे, इसलिए Google के इसे लागू करने की संभावना लगभग नहीं है
  • यह भी कहा गया कि मूल कारण यह है कि Google और Apple दोनों ही नहीं चाहते कि उपयोगकर्ता के पास control हो

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

1 टिप्पणियां

 
GN⁺ 2023-07-09
Hacker News की राय

  • मैं “fake data” के विचार के पक्ष में हूँ, लेकिन ऐप्स से यह भी अपेक्षा की जानी चाहिए कि अगर यूज़र असली डेटा की access न दे तो वे उसे gracefully handle करें
    पहले जब मैं iOS development करता था, तब Apple की policy थी कि permission deny होने पर यूज़र को सज़ा नहीं दे सकते थे या exit() से ऐप बंद नहीं कर सकते थे, और ऐप चलता रहना चाहिए था
    इससे भी पहले, ऐप के इस्तेमाल के लिए “account” अनिवार्य करना भी मना था. मुझे याद है 10 साल से भी पहले हमारी company ने account mandatory किया था और App Store ने उसे वाजिब तौर पर reject कर दिया था. आजकल account अनिवार्य करने वाले ऐप्स बढ़ते देख लगता है कि यह रुख अब कुछ नरम हो गया है

    • “ऐप को चलने के लिए account नहीं माँगना चाहिए” वाली बात में या तो बहुत बड़ा अपवाद छूट गया है, या फिर मैं उसका मतलब ठीक से नहीं समझ रहा
      banking apps, online games, आज का Twitter app, या Dropbox/Nextcloud जैसे ऐप्स account के बिना कैसे काम कर सकते हैं
      यह सही है कि कई ऐप्स में account की माँग marketing trick होती है, लेकिन ऐसा कोई सामान्य नियम काम करेगा, ऐसा नहीं लगता
    • WhatsApp अब भी contacts access deny करने पर यूज़र को “सज़ा” देता है. वह सारे नाम छिपा देता है और सिर्फ phone number दिखाता है, यहाँ तक कि तब भी जब सामने वाले ने अपनी profile में नाम सेट किया हो
      Facebook/Meta घटिया है
    • contacts या photos जैसे fake personal data तो ठीक हैं, लेकिन location पर मामला धुंधला हो जाता है
      अगर उपयोग सिर्फ map पर मेरी location दिखाने या आसपास के business खोजने का है, तो fake data दिया जा सकता है
      लेकिन अगर कोई internet speed test app carrier के हिसाब से speed को map कर रहा हो, या कोई ऐप यूज़र्स से local weather report लेकर forecast बेहतर बना रहा हो, तो वह यह कह सके कि “या तो accurate location दें या बिल्कुल न दें, हमें fake location नहीं चाहिए” — यह उचित लगता है
      platform को शायद यह तय करना होगा कि क्या ऐसे ऐप्स, जो दूसरे लोगों को प्रभावित करने वाला user-contributed data लेते हैं, उन्हें exception मिलना चाहिए
      Apple ने यहाँ काफ़ी अच्छा middle ground निकाला है. ऐप को “precise location” देना ज़रूरी नहीं है, और photos के मामले में भी system-provided image picker के ज़रिए यूज़र जिन तस्वीरों को चुने, सिर्फ वही ऐप को दिखाए जा सकते हैं
    • iOS पर सबसे खराब Google Photos है. अगर आप उसे सभी photos की access नहीं देते, तो ऐप खुलता तक नहीं, और selected photos की permission को भी वह स्वीकार नहीं करता
      यहाँ तक कि जब आप सिर्फ cloud में पहले से stored photos देखना चाहते हों, तब भी यही हाल है
    • अगर हम कहें कि “ऐप्स को असली डेटा की access deny होने पर भी gracefully handle करना चाहिए”, तो जो ऐसा न करें उनका क्या किया जाएगा
      यह एक technical problem का organizational solution सुझाने जैसा है, इसलिए इसका काम करना मुश्किल है, और व्यावहारिक समाधान सिर्फ fake data ही है. ऐप को ऐसा दिखना चाहिए कि permission मिल गई है, भले ही वास्तव में न मिली हो

  • rooted Android पर XPrivacy यह काम 7 साल पहले से कर सकता था, और इसके कुछ modern alternatives भी हैं. हालाँकि मैंने काफ़ी समय से phone root नहीं किया, इसलिए पक्का नहीं कह सकता: https://github.com/M66B/XPrivacy
    बेशक यह mainstream तरीका नहीं है, और मैं सहमत हूँ कि यह default built-in होना चाहिए. लेकिन Android और iOS दोनों ही region-locked apps या DRM content के screenshots block करने जैसी बकवास की अनुमति देते हैं, इसलिए यह आसान नहीं होगा

    • इस तरह लिखते हुए मुझे खुद महसूस हुआ कि एक यूज़र के तौर पर सब कुछ कितना उसके खिलाफ़ design किया गया है, और मैंने यह मानना छोड़ दिया कि phone एक computer है
      phone दरअसल vendor का content delivery device है, और यूज़र उनकी मर्ज़ी पर छोड़ दिया गया है
    • XPrivacy वाकई शानदार था, लेकिन modern phones पर root करना और Xposed install करना अब बहुत ज़्यादा जटिल हो गया है, या पूरी तरह blocked है
      GrapheneOS banking apps के साथ ठीक से नहीं चला, Google ने Android Beta में Magisk के ज़रिए rooting को कई बार तोड़ा, और किसी बिंदु पर मैंने इसकी परवाह करना ही छोड़ दिया
      GrapheneOS या ऐसे ही किसी project में शायद यह feature आ सकता है
    • XPrivacy बेहतरीन था, लेकिन कुछ permissions deny करने पर ऐप्स अक्सर crash हो जाते थे. यानी वह fake data को पर्याप्त अच्छी तरह supply नहीं कर पाता था
      हालत इतनी खराब थी कि मैं सीधे “deny” दबाने के बजाय हमेशा पहले “temporary deny” दबाता था. अगर ऐप चलता रहा तो permanent deny, और अगर crash हो गया तो यह पता लगाना पड़ता था कि काम चलाने के लिए minimum कौन-सी permissions देनी होंगी
    • यह feature factory image या Android upstream में शायद कभी नहीं आएगा, लेकिन अगर user demand काफ़ी हो तो LineageOS जैसे projects में आने की संभावना है
    • “region-locked apps” असल में वैसा नहीं है; बात यह है कि हर app store ऐप को सिर्फ उन्हीं regions में distribute करने देता है जिन्हें उसने चुना है
      यह app stores के लिए एक महत्वपूर्ण feature है, क्योंकि कोई ऐप हर देश में अच्छा experience नहीं दे सकता, हर भाषा में localized नहीं हो सकता, उस भाषा के content moderators नहीं हो सकते, हर देश के कानूनों का पालन करना पड़ सकता है, या copyrighted content की distribution license कुछ खास देशों तक सीमित हो सकती है
      DRM content पर screenshot रोकना भी app developers का माँगा हुआ feature है, क्योंकि movie जैसी content licenses में यह कानूनी requirement हो सकती है. Movie studios नहीं चाहते कि लोग फ़िल्में stream या record करें, इसलिए app platforms को ऐसा content सुरक्षित तरीके से दिखाने का तरीका चाहिए

  • “अगर कोई ऐसा सवाल पूछे जिसे पूछने का उसे हक़ नहीं है, तो आपको उसे सच बताने का कोई दायित्व नहीं है”
    — Leonard Schiffman
    स्रोत: “Blend me in: Privacy-Preserving Input Generalization for Personalized Online Services” https://drive.google.com/file/d/10OmoqMmHFcb7PsQtaU_GW4aCAJe...

  • ऐप permissions अनुरोधों में OS को सिर्फ हाँ/नहीं नहीं, बल्कि “हाँ, लेकिन app को fake data देना” जैसा विकल्प भी देना चाहिए — इस दावे में समस्या है
    काफी उपयोगकर्ताओं को यह भी नहीं पता होता कि email forward कैसे किया जाता है
    ज़रा सोचिए, अगर ऐसे लोग Google Maps navigation चलाते हुए उसका मतलब समझे बिना fake data चुन लें, तो कैसी गड़बड़ी हो सकती है
    Google Maps: “दाएँ मुड़ें”
    समुद्र किनारे की सड़क पर गाड़ी चला रहा चालक: “ठीक है”
    कार: छपाक

    • यह पूरी तरह user experience की समस्या है
      data spoofing फीचर को settings में काफ़ी अंदर छिपा दें, उसे चालू करने से पहले आसान भाषा में साफ़ समझाएँ, और screen पर स्पष्ट दिखाएँ कि उपयोगकर्ता द्वारा खुद चालू किए गए privacy फीचर की वजह से app को वैकल्पिक जानकारी दी जा रही है और इसे आसानी से बंद किया जा सकता है
      फिर भी कुछ लोग इसे गलती से चालू कर देंगे, लेकिन बहुत से अन्य उपयोगकर्ताओं के लिए यह बहुत मूल्यवान हो सकता है
    • यह सीखने का मौका लगता है। या शायद डार्विनवादी मौका
      किसी भी तरह, यह अपने आप सुलझने वाली समस्या है
    • तो फिर उस setting को advanced user option बना दें। जो उपयोगकर्ता परिचित नहीं हैं, उन्हें वह विकल्प दिखे ही नहीं
    • अगर ऐसा हो, तो उस स्थिति में चालक ने आगे का रास्ता ठीक से नहीं देखा होगा, और वह अलग समस्या है
      OS का “हाँ”, “नहीं”, “custom” देना बेहतर लगता है। “custom” चुनने पर उसके menu में ज़रूरत हो तो warning message दिखाया जा सकता है, लेकिन उपयोगकर्ता को अपनी इच्छा के अनुसार समायोजन करने से रोकना नहीं चाहिए
    • सोच रहा हूँ कि iOS पर लोग Google Maps कितना इस्तेमाल करते हैं। “fake data देने” वाला विकल्प Apple कर सकता है, ऐसा लगता है, लेकिन Google करेगा यह मानना बिल्कुल मुश्किल है
      Apple Maps में यह समस्या नहीं होगी। maps को device पर download किया जा सकता है, इसलिए यह data connection के बिना भी offline काम कर सकता है

  • हैरानी है कि iOS में permission मिली है या नहीं, यह अलग से पता चल सकता है — यह बात top-level comment में क्यों नहीं है
    उदाहरण के लिए, अगर app photo access माँगता है, तो उसे हमेशा एक array मिलता है। बस, permission मना होने पर वह array खाली होता है, इसलिए यह पता नहीं चलता कि उपयोगकर्ता की library सचमुच खाली है या access मना किया गया है। यह सरल और सुरुचिपूर्ण है
    बेशक, photos के मामले में लगभग हर किसी के पास कुछ न कुछ photos होती हैं, इसलिए heuristic इस्तेमाल की जा सकती है। लेकिन health data जैसे दूसरे प्रकारों में बात इतनी स्पष्ट नहीं होती

    • यह सही नहीं है। उदाहरण के लिए location services access के लिए CLAuthorizationStatus है: https://developer.apple.com/documentation/corelocation/claut...
      push notifications के लिए UNAuthorizationStatus है: https://developer.apple.com/documentation/usernotifications/...
      health data के लिए HKAuthorizationStatus है: https://developer.apple.com/documentation/healthkit/hkauthor...
      contacts के लिए CNAuthorizationStatus है: https://developer.apple.com/documentation/contacts/cnauthori...
      photos के लिए PHAuthorizationStatus है: https://developer.apple.com/documentation/photokit/phauthori...
      photos एक विशेष मामला है, क्योंकि उपयोगकर्ता access denied, limited access, या full access में से चुन सकता है। access denied है या नहीं, यह पता चल सकता है, लेकिन limited access और full access में अंतर नहीं किया जा सकता
    • जानना चाहता हूँ कि location कैसे काम करती है
      और अगर photo folder खाली है, तो लगभग तय है कि permission नहीं है। ऐसे लोग बहुत कम होते हैं जिन्होंने कभी photo ली ही न हो
    • उन दूसरी permissions का क्या जिनके लिए व्यवहारिक रूप से कोई खाली object भेजा ही नहीं जा सकता
      उदाहरण के लिए, अगर उपयोगकर्ता location देखने की permission देता है, तो app को मिलने वाले location object में स्वाभाविक रूप से संबंधित जानकारी होगी। अगर OS एक खाली location object दे, तो क्या permission denied होना साफ़ नहीं हो जाएगा, या इसे किसी error के पीछे छिपाया जाता है
    • यह स्पष्ट रूप से सच नहीं है, और इसे notifications access माँगने वाले लगभग हर app में देखा जा सकता है

  • मेरे हिसाब से “fake data देना” गलत तरीका है। बेहतर तरीका alternative source से data देना होना चाहिए, और वह alternative source कोई भी दूसरा program हो सके
    alternative source कुछ भी हो सकता है जो उपयोगकर्ता चाहे: खाली data, random data, fake लेकिन consistent data, वैकल्पिक file का data (जैसे अलग contacts list या camera की जगह file की photos), transformed data (जैसे camera photo को उल्टा पलटना), filtering, logging, हर अलग data item पर उपयोगकर्ता से पूछना, data की जगह error code देना और उपयोगकर्ता को error code चुनने देना, आदि। इसमें current date/time तक की access भी शामिल होनी चाहिए
    इससे user control बढ़ता है और testing तथा accessibility के लिए भी यह उपयोगी है
    OS design के लिए मेरे विचारों में से एक proxy permissions है। permission-based security में proxy permissions शामिल हों, सभी input/output इन्हीं का उपयोग करें, command shell में भी इन्हें UNIX pipe से बेहतर तरीके से इस्तेमाल किया जा सके, और दूसरे तरीकों से भी। इसमें date/time भी शामिल हो। Yield और Quit के अलावा, permission key के बिना कोई system call इस्तेमाल न की जा सके

    • मुझे लगता है यही सबसे अच्छा approach है, और वास्तव में काम करने लायक एकमात्र approach भी
      app developers के लिए उन permissions को ठीक से handle करना बहुत कठिन है जो उपलब्ध ही नहीं हैं, और अपेक्षाकृत कम उपयोगकर्ताओं के लिए testing scope बहुत बढ़ जाता है और मुश्किल हो जाता है, इसलिए ज़्यादातर छोटे commercial apps शायद इसे ठीक से handle करने की कोशिश ही नहीं करेंगे
      permission दे दी जाए लेकिन alternative data source दिया जाए — यह developers और users दोनों के लिए सबसे आसान है
      हाँ, इससे धोखाधड़ी भी आसान हो सकती है। उदाहरण के लिए, banks शायद इससे अधिक जटिल device registration प्रक्रिया अपनाएँगे

  • यूँ ही एक-दूसरे के साथ बेवजह कठोर होने की ज़रूरत नहीं है। आसान नियम यह है: “नहीं भी एक विकल्प है — सिवाय उन मामलों के जहाँ सचमुच यह विकल्प न हो।”
    अगर वह विकल्प नहीं है, तो इसका कारण बहुत स्पष्ट होना चाहिए, और शायद app review प्रक्रिया में इसे बताना भी चाहिए; नहीं तो ऐप को अस्वीकार कर देना चाहिए।
    उदाहरण के लिए, अगर TikTok/Instagram camera और microphone permission माँगते हैं, तो दोनों ही ऐप इस्तेमाल करने के लिए अनिवार्य नहीं हैं, इसलिए नहीं एक विकल्प है। अगर किसी permission के बिना भी ऐप का कुछ हिस्सा इस्तेमाल किया जा सकता है, तो उसे उसी तरह काम करने लायक डिज़ाइन करने की ज़िम्मेदारी ऐप की है। अगर camera या microphone बंद है, तो सिर्फ़ वही features शर्तों के साथ disable होने चाहिए जिन्हें उस permission की ज़रूरत है।
    और सरल शब्दों में कहें तो, ज़िम्मेदारी माँग करने वाले पर है। अगर बात स्पष्ट नहीं है या कोई चालाकी से निकलने की कोशिश कर रहा है, तो जवाब नहीं है। यह सख्त लग सकता है, लेकिन app makers permissions को optional बनाकर इस अतिरिक्त चरण से पूरी तरह बच सकते हैं।
    इसे लागू कराने पर ध्यान देने से यह छोटी-मोटी हथियारों की दौड़ जैसी स्थिति ख़त्म होगी, और लोगों के लिए भी यह बेहतर विकल्प है।

    • अच्छा लगता है, लेकिन इसे लागू कैसे किया जाएगा?
      यहाँ इसे लागू करा सकने वाली एकमात्र इकाइयाँ Google/Apple/Microsoft app stores हैं। यह भरोसा करना मुश्किल है कि इनके पास इसे लगातार और user-friendly तरीके से लागू करने की पर्याप्त प्रेरणा है। अगर होती, तो ये अब तक ऐसा कर चुके होते।

  • Samsung फ़ोन में camera access और microphone access toggle होते हैं।
    इन्हें बंद करने पर यह संदेश दिखता है:

    Turn off Camera access?  
All apps will be blocked from using the camera. Apps  
will still work, but they will only be able to access an  
empty black screen. For example, you can still make  
and receive video calls, but the other person won't be  
able to see you.
    • microphone access के लिए: 
      Turn off Microphone access?  
All apps will be blocked from using the microphone  
Apps will still work, but they won't be able to access  
any sounds from the microphone. For example, you  
can still make and receive calls, but the other person  
won't be able to hear you.

  • “हर category में ‘हाँ, लेकिन ऐप को fake data दो’ विकल्प” से बेहतर app-specific settings हैं।
    हो सकता है आप location data लगभग किसी भी ऐप को न देना चाहें, लेकिन Google Maps और emergency rescue call apps को देना चाहें। Contacts और personal data के साथ भी यही बात लागू होती है।
    हालाँकि, ऐसे apps को Google और दूसरी कंपनियों के तीखे विरोध का सामना करना पड़ेगा, क्योंकि वे user profiling से मुनाफ़ा कमाती हैं।

    • सहमत हूँ, लेकिन यह app-specific होने के साथ-साथ permission category-specific भी होना चाहिए।
      उदाहरण के लिए, एक ऐप में आप एक permission के लिए real data दें, दूसरी permission के लिए fake data या user-defined/manual input data दें, और तीसरी permission को deny कर सकें।
      हो सकता है आप testing के लिए, या किसी ऐसे app में जो current location का weather दिखाता हो, कुछ देर किसी दूसरी location का weather देखना चाहें और फिर वापस real location पर लौटना चाहें, इसलिए settings को अस्थायी रूप से बदलना चाहें।

  • अगर किसी ऐप को मेरा data मेरी experience बेहतर करने के लिए चाहिए, और वह भी सिर्फ़ मेरी experience बेहतर करने के लिए, तो fake data देने पर सिर्फ़ मेरी experience खराब होनी चाहिए। ऐप developer या owner को इससे कोई फ़र्क नहीं पड़ना चाहिए।
    लेकिन ज़्यादातर मामलों में, जहाँ मकसद मेरा data mining करना होता है, fake data उसे बाधित करने में काफ़ी प्रभावी होगा।
    बेशक, WhatsApp जैसे मामलों में इसका ज़्यादा फ़ायदा नहीं है। लोग थोड़े बेहतर messaging experience के लिए अपनी पूरी contact list को Facebook/Meta के साथ sync करने को तैयार रहते हैं।

    • मुझे भी ऐसा करना पड़ा और यह बहुत अप्रिय लगा, लेकिन वह सिर्फ़ “थोड़ा बेहतर experience” वाली बात नहीं थी।
      कम से कम mobile पर, contact sync करने से पहले ऐप और service मुश्किल से उपयोग लायक थे।