यदि आप यूज़र डेटा रखते ही नहीं, तो वह लीक नहीं हो सकता

 (seancoates.com)
2 पॉइंट द्वारा GN⁺ 2024-03-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Matter ने सकारात्मक यादों और भावनात्मक आकलनों को रिकॉर्ड कर बाद में याद करने में मदद करने वाला iPhone ऐप बनाते समय, संवेदनशील फ़ोटो और भावनात्मक डेटा को कंपनी की नज़र से दूर रखने वाले privacy-first design को आधार बनाया
  • डिज़ाइन के केंद्र में यूज़र का भरोसा, गलतियों और bugs से सुरक्षा, और भविष्य में कंपनी पर दबाव पड़ने या उसका acquisition हो जाने जैसी स्थितियों तक को ध्यान में रखने वाला threat model था
  • निजी भावनात्मक आकलन, यादों के विवरण और attached फ़ोटो Matter servers पर नहीं, बल्कि iPhone के Core Data और यूज़र के iCloud private database में stored होते हैं, और इन्हें इस तरह configure किया गया है कि कंपनी Apple tools से भी access न कर सके
  • कंपनी को केवल Matter Score जैसे कुछ ऐसे परिणाम मिलते हैं जिनसे input values वापस निकाली नहीं जा सकतीं, और private usage event metrics मिलते हैं; accounts को भी email/password के बिना numbered accounts के रूप में handle किया जाता है
  • डेटा लीक की संभावना कम होती है, लेकिन क्योंकि कंपनी यूज़र की पहचान नहीं करती और डेटा अपने पास नहीं रखती, इसलिए खोए हुए डेटा की recovery वह करके नहीं दे सकती; यूज़र को backup/restore का उपयोग करना होगा

Matter की शुरुआत और privacy का फैसला

  • 1 अक्टूबर 2024 से Sean Coates ने Matter के VP of Technology पद से कदम पीछे ले लिया, और इसके बाद वे ऐप के privacy पहलू की व्यक्तिगत रूप से गारंटी नहीं दे सकते
  • Matter की शुरुआत पहले Faculty के client के रूप में हुई थी, और बाद में agency-client संबंध से startup संबंध में बदलते हुए Coates ने VP of Technology की भूमिका संभाली
  • product idea इस दिशा से शुरू हुआ कि यूज़र सकारात्मक अनुभवों की यादें रिकॉर्ड कर सकें और बाद में उन्हें याद करके अपनी खुशी बढ़ा सकें
    • यूज़र सकारात्मक अनुभवों की फ़ोटो save कर सकते हैं और उस समय महसूस की गई भावनाओं का आकलन कर बाद में उन्हें फिर से याद कर सकते हैं
    • Coates शुरुआत में wellness-शैली के दावों को लेकर skeptical थे, लेकिन इस technology और science से आश्वस्त हुए कि सकारात्मक अनुभवों को याद करने से संबंधित neurotransmitters बनते और release होते हैं, जिससे खुशी बढ़ सकती है

“ऐसा डेटा कंपनी को भेजना ही क्यों चाहिए” वाला सवाल

  • निर्णायक सवाल यह था कि यूज़र अपनी निजी फ़ोटो और sexual desire जैसी संवेदनशील भावनात्मक ratings Matter को क्यों भेजें
  • इसी सवाल के चलते Matter ने product के शुरुआती चरण में ही निजी user content को handle करने का तरीका और threat modeling तय किया
  • privacy बाद में जोड़ी जाने वाली feature नहीं, बल्कि product design को दिशा देने वाली core value बन गई
    • यह माना गया कि user data को पहले कंपनी के अंदर expose कर देने के बाद privacy जोड़ने का तरीका error-prone या असंभव हो सकता है

तीन सिद्धांत और चरम scenarios

  • Matter ने user data handling के तीन सिद्धांत तय किए
    • कंपनी के data handling तरीके पर यूज़र भरोसा कर सकें, इसके लिए trust बनाना होगा
    • किसी कर्मचारी का कमजोर password या code bug होने पर भी user data leak नहीं होना चाहिए
    • केवल मौजूदा team की सदाशयता पर निर्भर न रहकर, भविष्य में कंपनी को नियंत्रित करने वाली कोई power आ जाए या कोई अविश्वसनीय acquirer सामने आ जाए, तब भी system टिकना चाहिए
  • infrastructure level पर भी चरम सवालों पर विचार किया गया
    • अपना data center बनाना चाहिए या नहीं, इस पर चर्चा हुई, लेकिन यह माना गया कि physical layer को बड़े hosting providers बेहतर संभाल सकते हैं और वे पहाड़ खोदकर militia hire करने पर पैसा खर्च नहीं करना चाहते
    • यहां तक माना गया कि कोई दुर्भावनापूर्ण state power किसी खास user data को चाहती है और परिवार को अगवा कर लेती है; ऐसी स्थिति में भी देने के लिए कोई data न हो, यही दिशा चुनी गई
  • अंतिम विकल्प यह था कि user का private data रखा ही न जाए

Matter असल में डेटा कैसे handle करता है

  • यदि यूज़र Matter में pride जैसी भावना को high rate करता है, तो भी कंपनी को यह तथ्य पता नहीं चल सकता
    • metrics system को जानबूझकर इस तरह configure किया गया है कि वह ऐसा personal data collect न करे
    • इस data को केवल user device पर चलने वाला app access करता है
  • Matter एक iPhone app है और data फोन के Core Data और यूज़र के iCloud account के भीतर private database में stored होता है
    • कंपनी के developer credentials से चलने वाला app code device के अंदर data पढ़ और लिख सकता है
    • data Matter को transmit नहीं होता, और Apple tools के जरिए भी कंपनी इसे access नहीं कर सकती
  • कंपनी को जो data मिलता है वह कुछ inputs का output होता है, लेकिन ऐसे रूप में जिससे मूल input values वापस नहीं निकाली जा सकतीं
    • उदाहरण के लिए, केवल result value 600 जानने से यह पता नहीं चलता कि input 1 × 600, 100 × 6, 30 × 20, 12 × 50 में से क्या था
    • Matter Score पता चल सकता है, लेकिन किस input ने score बनाया, याद को कैसे describe किया गया, या फ़ोटो में क्या है—यह पता नहीं चल सकता
    • कंपनी को बस इतना पता होता है कि किसी numbered account में एक memory है और score 600 है
  • Matter फिलहाल app user accounts से email address नहीं जोड़ता और password भी नहीं रखता
    • mailing list के अलावा email address नहीं रखे जाते
    • mailing list users और app users के बीच कोई forced link भी नहीं है
    • आगे चलकर यदि यूज़र चाहें तो self-identification की अनुमति दी जा सकती है, लेकिन उस स्थिति में भी private data collect न करने की दिशा बनाए रखने की योजना है

encrypted image storage और recovery की कीमत

  • यूज़र memory में image जैसी content जोड़ें, तब भी Matter उसे ऐसे तरीके से store नहीं करता जिसे कंपनी देख सके
    • default रूप से images user device पर stored होती हैं
    • device storage limit के कारण, on-device encrypted images जैसे assets को store करने वाला system भी है
    • वास्तविक photo content और decryption keys Matter को transmit नहीं किए जाते
    • कंपनी की नज़र में stored data photo नहीं, बल्कि random noise जैसा binary ciphertext दिखता है
  • यह design recovery के मामले में स्पष्ट कीमत पैदा करता है
    • यदि यूज़र data खो दे, तो Matter उसे recover करके नहीं दे सकता
    • email से user identify कर password reset नहीं किया जा सकता, और email address व password हों तब भी कंपनी data अपने पास नहीं रखती, इसलिए restore नहीं कर सकती
  • मौजूदा app में backup/restore feature है, और data loss रोकने के लिए यूज़र को स्वयं इसका इस्तेमाल करना होगा
  • यूज़र की तरफ से backup store करते हुए भी उन्हें identify करना, और data को ऐसे तरीके से रखना कि कंपनी access न कर सके—यह समस्या अभी solve होने के लिए बाकी है
  • Matter privacy policy से बंधा है, और Coates के लिए privacy implementation की निगरानी Matter में किए गए कई technical कामों में से सबसे संतोषजनक कामों में से एक थी

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

1 टिप्पणियां

 
GN⁺ 2024-03-29
Hacker News की राय

  • मुख्य विचार से सहमत हूं। अगर आप स्टोर नहीं करते, तो लीक भी नहीं कर सकते वाला approach सही है, और मुझे लगता है कि कानूनी ढांचा भी ऐसा होना चाहिए जो इस सोच को ज्यादा प्रोत्साहित करे और परिणाम-केंद्रित हो
    हैक होने पर “हमने industry standards के हिसाब से सब किया” यह खास मायने नहीं रखता; मायने यह रखता है कि मेरी जानकारी चोरी हुई। भले ही आपने वही तरीका अपनाया हो जिसे industry सही मानती थी, फिर भी जिम्मेदारी लेनी चाहिए

    • “जानकारी को ऐसा स्टोर ही मत करो कि वह लीक हो सके” अच्छा विचार है। यह least privilege principle जैसा है: दी जा रही service के लिए जितना जरूरी हो, सिर्फ उतना ही रखना चाहिए। इससे provider और consumer दोनों का जोखिम घटता है
      हालांकि अमेरिका में लगता है कि ज्यादा कंपनियां यह मानने लगी हैं कि personal data में पैसा है। ज्यादातर stores reward program चलाते हैं और आपने क्या, कब खरीदा, यह इकट्ठा करते हैं—कारण भी यही है
      अगर मकसद सिर्फ customers को दोबारा बुलाना होता, तो 10 साल पहले की तरह stamp card ही काफी होते। वे data का इस्तेमाल कैसे करते हैं, यह नहीं पता, लेकिन अगर उससे मिलने वाली value reward की लागत से ज्यादा न हो, तो वे मुफ्त खाना या discounts जैसे incentives क्यों देंगे
    • डेटा लीक liability insurance रखा जाए, और अगर लीक करने लायक कुछ है ही नहीं तो premium कम कर दिया जाए
      बेशक, यह ऐसी अलग दुनिया मानकर चलता है जहां कंपनियां अपनी गलतियों की सचमुच कीमत चुकाती हैं
    • मंशा से सहमत हूं, लेकिन यह practically कैसे implement होगा, साफ नहीं है
      कानून को ईमानदारी से best effort करने वालों को punish नहीं करना चाहिए, खासकर जब “industry standard था तब भी फर्क नहीं पड़ता” जैसी शर्त जुड़ जाए तो यह और खतरनाक हो जाता है। इससे भ्रम पैदा होगा, गलत लोगों को सजा मिलने की संभावना बढ़ेगी, और competitors को hack करवाकर उन्हें कानूनी जिम्मेदारी में धकेलने का incentive भी बन सकता है
    • मैं वकील नहीं हूं, लेकिन दूसरे अपराधों में इस तरह के degree differences पहले से हैं
      गलती से किसी की मौत हो जाए तो manslaughter हो सकता है, और दुर्भावना व planning के साथ मारें तो aggravated/premeditated murder बनता है
      आखिरकार अगर जान गई है, तो किसी न किसी स्तर की judicial review होनी चाहिए। लेकिन hacking incidents में ऐसी प्रक्रिया ज्यादा दिखाई नहीं देती
    • privacy breaches बढ़ने की मूल वजह यह है कि surveillance और hacking रोकने वाले legal framework में एक बहुत बड़ी vulnerability है
      बिना permission personal data collect करने वाला spyware develop और distribute करना illegal है, और collect किया गया data leak न भी हो तो भी illegal है। लेकिन उसे चमकदार marketing, समझ में न आने वाली दर्जनों पन्नों की terms और “privacy” policy में लपेट दें, तो अचानक legal हो जाता है; यहां तक कि data leak या बेच देने पर भी लगभग कोई सजा नहीं मिलती
      यह सिर्फ अमेरिका में नहीं, यूरोप में भी ऐसा ही है। GDPR से पहले भी ज्यादातर देशों में personal data processing, use और storage से जुड़े कानून थे, लेकिन उन्हें enforce नहीं किया जाता था। GDPR भी enforcement के मामले में बहुत बेहतर नहीं है; अनगिनत non-compliant “consent” flows दिखते हैं और बिना consent data processing पर आधारित businesses अब भी आराम से चल रहे हैं

  • यह मेरे नजरिए से भी काफी मेल खाता है
    हालांकि इस विचार की वजह से मैं colleagues के बीच ज्यादा popular नहीं हुआ। पूरी industry personally identifiable information collection में डूबी हुई है, और उस information को बहुत हल्के में लेती है। यहां तक कि solitaire app भी leaderboard और challenges में signup के लिए लगातार push करता है
    एक नए app में हम लगभग 30% signups को pig butchering scam जैसे दिखने के कारण reject कर रहे हैं, और यह काफी चौंकाने वाला है। सभी signups manually review होते हैं, और हमें मात्रा से खास मतलब नहीं है। हम सिर्फ अमेरिका, कनाडा और भारत को target कर रहे हैं और promotion भी लगभग नहीं किया, फिर भी scammers तुरंत आ पहुंचे
    अभी यह सब crude है, लेकिन सिर्फ इसलिए कि हम एक specific demographic को target करते हैं, जिसे fake करना मुश्किल है; मुझे लगता है यह जल्द बदलेगा। आखिरकार हमने मान लिया है कि बुरे लोग अंदर आएंगे ही, इसलिए जरूरी है कि जब वे liquor cabinet लूटने आएं तो अंदर कुछ हो ही नहीं

  • शीर्षक के दावे से काफी सहमत हूं। विशाल data silos के इर्द-गिर्द data residency, integrity, confidentiality measures, उन्हें manage और scale करने वाली infrastructure teams, और आखिर में web पर आने वाले “gospel” जैसे technical posts देखकर हैरानी होती है—क्योंकि company बस वह data collect न करे तो भी काम चल सकता है
    “Data device पर रहता है, हम उसे नहीं देखते। ज्यादा से ज्यादा हमें न्यूनतम location statistics मिलते हैं” वाला model मुझे पसंद है। हालांकि उनके metrics system का दुरुपयोग नहीं होगा, इस दावे पर मुझे संदेह है। जो चीज program की गई है, उसे reprogram या update भी किया जा सकता है, खासकर आज के update-centric दौर में। “हमने ध्यान रखा है कि users पर कभी surveillance न हो” जैसी सामान्य explanation के अलावा यह हिस्सा पर्याप्त रूप से address नहीं किया गया लगता; अगर कोई technical post हो तो देखना चाहूंगा
    साथ ही Sentinel Devices में भी हम industrial machinery के लिए ठीक यही “हम data अपने पास नहीं रखते” approach अपनाते हैं। इसे air-gapped automation AI pipeline जैसा समझें। हम hiring कर रहे हैं, रुचि हो तो hello@sentineldevices.com पर संपर्क करें

  • इसलिए B2B SaaS को SSO पर enterprise pricing लगाना बंद करना चाहिए, और IdP या OAuth/OIDC जैसे flows को बस mandatory बना देना चाहिए
    https://vaultvision.com/blog/what-is-oidc
    user experience इस तरह के “continue with” buttons जैसा होता है
    https://id.atlassian.com/login
    https://www.xsplit.com/user/auth
    तब आपके पास खोने के लिए account credentials ही नहीं होंगे। personal data, personally identifiable information वगैरह risk liability हैं

    • फिर metadata से personalized ads के जरिए अरबों dollars कैसे कमाएंगे

  • इससे जुड़ा concept Datensparsamkeit है: https://martinfowler.com/bliki/Datensparsamkeit.html

    • थोड़ा संबंधित लेख भी है: https://www.w3.org/2001/tag/doc/leastPower.html
    • बेहतर expression Datenenthaltsamkeit है, यानी data abstinence। यह सिर्फ कम store करने की बात नहीं, बल्कि सचमुच तभी store करना है जब कोई दूसरा विकल्प न हो

  • Maciej Cegłowski के Notes From An Emergency [1] में भी मिलती-जुलती बात है
    “यह साफ़ नहीं है कि कोई भी समय के साथ बड़े पैमाने के डेटा संग्रहों को सुरक्षित रख सकता है या नहीं। हमले और बचाव की असमानता बहुत बड़ी हो सकती है। अगर बड़े पैमाने पर बचाव संभव है, तो उसका एकमात्र तरीका है कि सबसे अच्छे सुरक्षा लोगों को नियुक्त करने पर लाखों डॉलर खर्च किए जाएँ। शीर्ष-स्तर के डेटा breaches ने दिखाया है कि खतरा वास्तविक और लगातार है। और जिस एक breach के बारे में हमें पता होता है, उसके बदले कई शांत breaches ऐसे होते हैं जिनके बारे में हमें वर्षों तक पता नहीं चलेगा
    लेकिन बचाव में जितनी सफलता मिलती है, जोखिम उतना ही बढ़ता है। अगर आप किले की दीवारों के पीछे पर्याप्त खज़ाना जमा कर दें, तो अंततः आप किसी ऐसे व्यक्ति को आकर्षित कर ही लेंगे जो उन दीवारों को लांघ सकता है। सामंतवाद इंटरनेट को और कमजोर बनाता है, और यह सुनिश्चित करता है कि जब अंततः breach हो तो वह आपदा बन जाए”
    [1] https://idlewords.com/talks/notes_from_an_emergency.htm

  • क्या वे user data न रखने का वादा contractual penalty के साथ करने को तैयार हैं? अगर नहीं, तो वे गंभीर नहीं हैं
    “Facebook - मुफ़्त है और हमेशा रहेगा” को याद रखना चाहिए

  • उद्धृत विवरण को देखें तो क्या इसका मतलब है कि user द्वारा input की गई हर तस्वीर का encrypted version server पर store होता है, लेकिन keys store नहीं होतीं?
    अगर ऐसा है, तो encrypted user data store करना ज़रूरी नहीं कि दुनिया का अंत हो, लेकिन समझ नहीं आता कि इसे ऐसे क्यों promote किया जा रहा है जैसे user data बिल्कुल भी store नहीं किया जाता। असल में तो यह वही है जो कई कंपनियाँ करती हैं—encrypted user data store करना—और Backblaze भी यही तरीका इस्तेमाल करता है। हो सकता है मैंने गलत समझा हो

    • मैंने इसे ऐसे पढ़ा कि encrypted data server पर नहीं, बल्कि user device पर है

  • privacy policy देखें: https://matter.xyz/privacy
    “अगर हम इस privacy policy को बदलते हैं, तो हम इसे यहाँ update करेंगे और ऊपर effective date को अपडेट करेंगे। क्योंकि हम सभी के email addresses collect नहीं करते, इसलिए हम बदलावों के बारे में email नहीं भेज सकते। इस policy में बदलाव retroactively लागू नहीं होंगे।”
    व्यवहार में वे इसे कभी भी बदल सकते हैं, और users को शायद पता भी नहीं चलेगा
    अगर इसका उल्लंघन हो तो क्या user के पास enforce कराने की ताकत है? क्या उसे lawyer को छह अंकों की रकम देनी पड़ेगी? किस कानून के तहत, किस तरह के damages के लिए?
    और यहाँ retroactively लागू नहीं होंगे का कानूनी मतलब क्या है, यह भी मुझे ठीक से समझ नहीं आता। अगर company के पास मेरा data है और वह policy बदलती है, तो क्या वह कल से नई policy के तहत मेरा data इस्तेमाल कर सकती है? वैसे भी बदलाव का पता नहीं चलेगा, इसलिए इसका खास मतलब नहीं है

    • इसका मतलब यह हो सकता है कि policy में बदलाव का इस्तेमाल उन पुराने कामों को सही ठहराने के लिए नहीं किया जा सकता जो पिछले version में violation थे लेकिन नए version में violation नहीं हैं
      बेशक, मैं पूरी तरह नहीं समझता कि किसी company की privacy policy legally कितनी enforceable होती है
    • privacy को बेहद गंभीरता से देखने वाले दृष्टिकोण से, यह व्यावहारिक रूप से सबसे अच्छे विकल्प के काफ़ी करीब है। अगर उनके पास email नहीं है तो वे भेज नहीं सकते, और policy बदलने पर भी वह बदलाव मौजूदा users पर लागू नहीं होता
      “retroactively लागू नहीं होगा” का मतलब है कि updated version मौजूदा data use पर लागू नहीं होता, इसलिए नई policy के तहत user का data इस्तेमाल करने की संभावना को स्पष्ट रूप से बाहर कर दिया गया है

  • सही
    मैं cybersecurity में काम करता हूँ, और दिन-ब-दिन मेरा भरोसा बढ़ता जा रहा है कि हर संभव threat को mitigate करने की कोशिश करने के बजाय जवाब है चोरी किए जाने लायक data अपने पास रखना ही नहीं
    इसे zero trust और 2-factor authentication/passkeys के साथ जोड़ दें, तो यह industry को पसंद आने वाले ढेरों snake-oil security solutions की तुलना में कहीं ज़्यादा असरदार हो सकता है