जब सहपाठी गंभीर आपराधिक आरोपों से धमकाएँ
(miles.land)- Stanford कैंपस में लोकप्रिय हो रही अनाम social app Fizz की सद्भावना से जाँच करने वाले छात्रों ने डेटाबेस पर पूर्ण read·write access और non-anonymized user व post जानकारी पाई
- शोधकर्ताओं ने vulnerability disclosure report और fix के सुझाव भेजे, और Fizz को सुधार का समय देने के लिए disclosure embargo पर भी सहमति दी, लेकिन बाद में प्रतिक्रिया कानूनी धमकियों में बदल गई
- Fizz ने state और federal law के उल्लंघन, civil और criminal liability, तथा 20 साल की जेल की संभावना का हवाला देते हुए खोजी गई बातों को सार्वजनिक न करने की मांग की
- शोधकर्ताओं को Electronic Frontier Foundation के Kurt Opsahl और Andrew Crocker से मुफ्त कानूनी प्रतिनिधित्व मिला और उन्होंने चुप रहने की मांग के आगे झुकने से इनकार किया
- भले इरादे वाली security research में भी उद्देश्य, दायरा और गतिविधियों का रिकॉर्ड रखना, data को store या leak न करना, account manipulation से बचना, और कानूनी धमकियों का अकेले सामना न करना अधिक सुरक्षित है
Fizz में मिली सुरक्षा समस्याएँ
- Stanford student startup Fizz की अनाम social media app कैंपस में लोकप्रिय हो रही थी, और app अपने बारे में “100% secure” के करीब का दावा करती थी
- क्योंकि यह ऐसी जगह थी जहाँ users संवेदनशील बातें पोस्ट करते थे, security में रुचि रखने वाले छात्र यह जांचना चाहते थे कि यह जानकारी वास्तव में सुरक्षित है या नहीं
- कुछ ही घंटों में Fizz के डेटाबेस पर पूर्ण read·write access संभव हो गया
- डेटाबेस में user और post की जानकारी stored थी
- यह जानकारी पूरी तरह anonymous नहीं की गई थी
- शोधकर्ताओं ने निष्कर्ष निकाला कि Fizz में security safeguards लगभग न के बराबर थे
जिम्मेदार disclosure से कानूनी धमकियों तक
- शोधकर्ताओं ने अपनी खोजों को vulnerability disclosure report के रूप में संकलित किया और Fizz को email से भेजा
- रिपोर्ट में मिली समस्याएँ और fix के सुझाव शामिल थे, और Fizz को सुधार का समय देने के लिए उन्होंने पहले ही यह मान लिया था कि तय embargo date से पहले वे इस बारे में सार्वजनिक रूप से कुछ नहीं कहेंगे
- शुरुआत में Fizz ने रिपोर्ट के लिए धन्यवाद दिया और कहा कि समस्या को ठीक करना सर्वोच्च प्राथमिकता है, और कुछ हफ्तों तक कुछ updates भी भेजे
- बाद में रुख बदल गया और शोधकर्ताओं को state व federal law के उल्लंघन तथा civil और criminal liability का हवाला देते हुए धमकियाँ भेजी गईं
- इन धमकियों में 20 साल की जेल की संभावना तक शामिल थी
- मुख्य मांग यह थी कि खोजी गई बातों को सार्वजनिक न किया जाए
- ढांचा यह था कि यदि वे चुप रहने पर सहमत हों, तो कानूनी कार्रवाई आगे नहीं बढ़ाई जाएगी, और जवाब देने की समयसीमा 5 दिन थी
- शोधकर्ताओं ने इसे डराकर चुप कराने की कोशिश के रूप में देखा
EFF की कानूनी मदद और समाधान
- शोधकर्ताओं ने अपने नेटवर्क से मदद मांगी, और कुछ दिनों के भीतर उनका संपर्क Electronic Frontier Foundation के Kurt Opsahl और Andrew Crocker से हो गया
- दोनों ने शोधकर्ताओं का मुफ्त में प्रतिनिधित्व करने पर सहमति दी, और शोधकर्ताओं ने disclosure process तथा संबंधित दस्तावेज़ों के बारे में वकीलों को बताया
- कानूनी सलाह मिलने के बाद शोधकर्ताओं ने Fizz की धमकियों के आगे न झुकने का फैसला किया
- Kurt और Andrew ने Fizz को भेजे जाने वाले जवाब का मसौदा तैयार किया, और उसके बाद Fizz टीम ने मुलाकात का अनुरोध किया
- दोनों पक्षों ने स्थिति को सौहार्दपूर्ण ढंग से सुलझाया, और शोधकर्ताओं ने Fizz पर दबाव डाला कि वह समस्या को proactively users के सामने प्रकट करे
- अंततः Fizz ने users को इस समस्या की जानकारी दी
सुरक्षा शोधकर्ताओं के लिए पालन करने योग्य सिद्धांत
- research को वैध और दस्तावेज़ित स्थिति में रखना चाहिए
- research शुरू करने से पहले उद्देश्य स्पष्ट होना चाहिए और यह सुनिश्चित करना चाहिए कि नैतिक सीमाएँ पार न हों
- शोधकर्ताओं ने access किए जा सकने वाले data को store या leak नहीं किया
- उन्होंने दूसरों के accounts के साथ छेड़छाड़ नहीं की और कोई नुकसान नहीं पहुँचाया
- उन्होंने हर गतिविधि का विस्तार से documentation किया, जिससे vulnerability disclosure report लिखने और कानूनी प्रतिक्रिया में मदद मिली
- शांत और संयमित प्रतिक्रिया जरूरी है
- कानूनी धमकियाँ मिलने पर भी पेशेवर ढंग से प्रतिक्रिया देनी चाहिए
- लक्ष्य समस्या को बढ़ाना नहीं, बल्कि स्थिति को सुलझाना होना चाहिए
- भावनात्मक email जवाब सौहार्दपूर्ण समाधान की संभावना को नुकसान पहुँचा सकते हैं
-
वकील करना चाहिए
- कानूनी धमकियों को अकेले संभालने की कोशिश बड़ी गलती हो सकती है
- उनका मानना था कि Fizz को उम्मीद थी कि शोधकर्ता भोलेपन में धमकी के आगे झुक जाएंगे
- हर किसी को EFF का मुफ्त प्रतिनिधित्व नहीं मिल सकता, लेकिन भले इरादे वाले security researchers के लिए संसाधन बढ़ रहे हैं, इसलिए उनका उपयोग करना चाहिए
1 टिप्पणियां
Hacker News की राय
मैं वकील नहीं हूं, लेकिन कानून के इस अजीब क्षेत्र में पेशेवर दिलचस्पी रखता हूं, और मुझे लगता है कि EFF के staff attorney ने यहां थोड़ी हद से बढ़कर दलील दी है
Fizz एक client/server application है, शायद webapp, और researchers ने जिस चीज़ को test किया वह Fizz server पर चलने वाला software था
vulnerability मिलने के बाद researchers ने database activity का इस्तेमाल करके admin account बनाया, और उन्हें इस test की कभी अनुमति नहीं मिली थी
अगर ये तथ्य सही हैं, तो जब तक कोई ऐसा California कानून न हो जिसकी मुझे जानकारी नहीं है—और अगर हो भी, तो federal supremacy की वजह से शायद वह मायने न रखे—मेरे हिसाब से इन्होंने EFF के जवाब में किए गए दावे के उलट CFAA का काफी सीधे तौर पर उल्लंघन किया
हालांकि legal risk कम करने वाले कम से कम तीन factor हैं: disclosure और बाद की कार्रवाई से साफ है कि यह good-faith security research थी, इसलिए prosecution के लिए आकर्षक मामला नहीं; meaningful damage हुआ भी या नहीं यह स्पष्ट नहीं; और Fizz छोटा और नया है, इसलिए forensic firm या insurance settlement तक बात गई होगी, ऐसा भी कम लगता है
साथ ही, Fizz के वकीलों ने researchers से मूल्यवान रियायतें लेने के लिए criminal prosecution की धमकी दी, जो EFF ने जैसा बताया, state bar association rules का उल्लंघन है
यहां लगता है कि अच्छी side जीत गई, लेकिन बहुत सारे lesson generalize करने में सावधानी रखूंगा। अगर यह Fizz नहीं बल्कि Dunder Mifflin Infinity का social feature होता, तो नतीजा कहीं ज़्यादा खराब हो सकता था
https://www.justice.gov/opa/pr/department-justice-announces-...
“damages” की मात्रा victim के हाथ में चली जाती है, और एक बड़े bureaucracy के नजरिए से छोटे लेकिन absolute terms में बड़े resources मनमाने ढंग से खर्च करवाती है, जिससे अपने को शर्मिंदा करने वाले imperfect actor पर कठोर सजा थोपने के लिए resources waste करने का distorted incentive मिलता है
भले ही ऐसी कार्रवाई जायज दायरे में हो, जिसकी जरूरत बताने वाले व्यक्ति पर उसका खर्च डालना भी अनुचित है। अगर public service को serious vulnerability के साथ चलाया गया था, तो इस व्यक्ति ने अनुचित काम किया या नहीं, इससे अलग यह assess करना ही होगा कि कोई और इसका exploit कर सकता था
उस खर्च की वजह vulnerable service चलाने की अपनी कार्रवाई है, और अगर vulnerability खुद भी खोज ली होती, तो operation के बाद यह खर्च उठाना ही पड़ता
defendant से जो नुकसान जोड़ा जाए, वह वास्तव में किए गए harm तक सीमित होना चाहिए—जैसे access right का इस्तेमाल करके customer financial information लेना और credit card fraud करना
अगर app configuration इतनी खराब हो कि केवल Firebase protocol follow करने से database write permission मिल जाए, तो आसानी से कहा जा सकता है कि वास्तव में कोई security measure bypass नहीं किया गया। क्योंकि bypass करने के लिए कोई security measure था ही नहीं
मुझे वह मामला याद आता है जिसमें AT&T ने iPad data subscribers की जानकारी बस एक unlisted webpage पर डाल दी थी। नतीजा याद नहीं, लेकिन मुझे लगता है उस समय संबंधित व्यक्ति वह सारा data scrape करने की कोशिश कर रहा था जो मिल सकता था, और यह मामला उससे अलग है
मूल लेख में “mea culpa” नहीं दिखता, लेकिन भले ही पोस्ट का tone “यकीन होता है ये लोग क्या करने चले थे?” जैसे meme वाला हो, उम्मीद है lesson सीख लिया होगा
इरादा अच्छा लगता है, लेकिन कानून काफी साफ तौर पर तोड़ा गया लगता है
पिछले साल DOJ ने अपनी CFAA charging policy update की थी ताकि “good-faith security research” करने वालों पर prosecution न हो [1]
CFAA बदनाम तौर पर बहुत व्यापक scope वाला है, इसलिए DOJ policy सुरक्षा research की वैधता को और स्पष्ट करने के लिए कानून में amendment करने की तुलना में काफी कम है
नई administration में policy बदल भी सकती है, इसलिए risk अभी भी है, लेकिन formalize होने से पहले की तुलना में कम है
[1] https://www.justice.gov/opa/pr/department-justice-announces-...
कॉन्ट्रैक्ट्स में, और खासकर धमकी भरे कानूनी कम्युनिकेशन में, यह समझना मुश्किल है कि लिखने वाली तरफ को कंटेंट सही-सही न लिखने पर लगभग कोई नतीजा क्यों नहीं भुगतना पड़ता
मैंने कर्मचारी कॉन्ट्रैक्ट में “अगर इस कॉन्ट्रैक्ट का कोई हिस्सा अमान्य हो, तो बाकी हिस्सा अमान्य नहीं होगा” जैसी भाषा देखी है। नियोक्ता अपने नियम लागू करना चाहता है, और अपने-आप में यह वाजिब है, लेकिन मना की गई चीज़ लिख देने पर भी कोई नुकसान नहीं होता। बहुत हुआ तो अदालत उस क्लॉज को अमान्य मानेगी
बोझ पाठक पर होता है, और आम तौर पर पाठक कहीं ज्यादा कमजोर पक्ष होता है
यहां भी कंपनी “तुम इसके लिए फेडरल जेल में 20 साल जा सकते हो!” जैसा धमकी भरा पत्र क्यों भेज सकती है? जबकि यह साफ तौर पर झूठ है
क्या लिखने वाले पर यह जिम्मेदारी नहीं होनी चाहिए कि वह उचित कंटेंट सुनिश्चित करे। अगर बात बेहूदा और साबित तौर पर गलत हो, तो “अच्छा, जाने दो” से बड़ा नकारात्मक परिणाम नहीं होना चाहिए?
क्या चीज बुनियादी है, जैसा कहा गया, अदालत उसकी व्याख्या करती है
कर्मचारी कॉन्ट्रैक्ट के उदाहरण में severability असल में एक व्यक्ति के रूप में आपकी भी रक्षा करती है। क्योंकि कुछ प्रावधान अमान्य हो जाएं, तब भी आपको बचाने वाले प्रावधानों समेत बाकी समझौता लागू रहता है
अगर पूरा कॉन्ट्रैक्ट अमान्य हो जाए, तो आपको शून्य से फिर शुरू करना पड़ेगा, और शायद नौकरी भी जा सकती है। थोड़ा संरक्षण होना शून्य से बेहतर है
यह दोनों पक्षों को मामूली तकनीकी वजहों से पूरी कानूनी जिम्मेदारी से निकल भागने, या जानबूझकर ऐसे जहरीले क्लॉज डालने से रोकती है जो कानूनी समीक्षा में टिक नहीं पाएंगे
अगर कॉन्ट्रैक्ट का कोई हिस्सा अमान्य हो जाता है, तो उस हिस्से का इस्तेमाल नहीं किया जा सकता। अगर उस हिस्से की अमान्यता कॉन्ट्रैक्ट को बुनियादी रूप से बदल देती है, तो पूरा कॉन्ट्रैक्ट अमान्य हो जाता है। इससे ज्यादा आप क्या चाहते हैं, समझ नहीं आता
यह खराब कॉन्ट्रैक्ट लिखने पर दंडात्मक प्रतिक्रिया की बात जैसी लगती है, और मुझे लगता है कि यह सभी कानूनी और कारोबारी संबंध बनाने पर chilling effect डाल सकती है, इसलिए काफी खराब विचार है
जिस कमजोर पक्ष की मजबूत कानूनी ड्राफ्टर तक पहुंच मुश्किल है, उस पर शायद ज्यादा चोट पड़ेगी। अगर कॉन्ट्रैक्ट की भाषा बदलने पर बातचीत करना भी बातचीत करने वाले के लिए liability की बारूदी सुरंग बन जाए, तो पूरी लीगल टीम के सामने खड़े छोटे actor पर liability का बोझ और असमान नहीं हो जाएगा?
आप जिस दुनिया की कल्पना कर रहे हैं, वह कमजोर पक्षों के लिए अभी से ज्यादा जोखिम न पैदा करे—ऐसा तरीका साफ दिखाई नहीं देता
अच्छे इरादे वाले संदर्भ में, कानून और case law तेजी से बदलते हैं, कभी-कभी जज की सनक पर निर्भर करते हैं, और कानून के कई क्षेत्र ऐसे हैं जहां स्पष्ट precedent नहीं है या guidance धुंधली है
ऐसे मामलों में, सिर्फ इसलिए कि कोई छोटा क्लॉज अदालत में टिक नहीं पाया, पूरे कॉन्ट्रैक्ट पर फिर से बातचीत न करनी पड़े—इसके लिए severability महत्वपूर्ण है
उदाहरण के लिए non-compete clause वाले employment contract को सोचिए: कंपनी हर क्षेत्र में वही कॉन्ट्रैक्ट इस्तेमाल कर सकती है, और जिन राज्यों में non-compete अवैध है, वहां severability clause की वजह से हर jurisdiction के लिए अलग कॉन्ट्रैक्ट बनाने की जरूरत नहीं पड़ती
अगर कोई राज्य पहले non-compete की अनुमति देता था और फिर उसे प्रतिबंधित करने वाला कानून पास कर देता है, तो क्या non-compete clause वाले सभी employment contracts अचानक अमान्य हो जाने चाहिए? बिल्कुल नहीं। यही severability का काम है
मूल धमकी का संदर्भ समझना मुश्किल है, लेकिन भाषा शायद ऐसी रही हो: “हमारे computer network तक unauthorized access XYZ कानून के तहत federal crime है और इसमें अधिकतम 20 साल तक की कैद हो सकती है”
आम लोगों को यह बेहद डरावना लगेगा, लेकिन कड़ाई से देखें तो झूठ नहीं है; ज्यादातर वकील इसे बकवास मानकर आंखें घुमाएंगे, लेकिन अगर पर्याप्त qualifiers जोड़ दिए जाएं तो रेखा कहां खींची जाए, यह मुश्किल हो जाता है
आखिरकार ऐसे दस्तावेज आम लोगों के लिए design नहीं की गई legalese में वकील लिखते हैं। कॉलेज छात्रों को ऐसी धमकी देना घटिया बात थी, और कंपनी की ओर से यह पत्र लिखकर भेजने वाले वकील ने कंपनी को बेहद खराब सलाह दी
बार association के सामने मुद्दा उठाया जा सकता है, लेकिन ऐसी स्थिति में इसे convincing case बनाना बहुत मुश्किल होगा
यही एक कारण है कि collective bargaining महत्वपूर्ण है। यूनियन कंपनी के वकीलों का सामना करने के लिए कानूनी प्रतिनिधि afford कर सकती है, लेकिन व्यक्तिगत कर्मचारी के लिए ऐसा करना मुश्किल है
अमेरिकी व्यवस्था “हर कोई अपना legal cost खुद उठाए” वाली है, जिससे पीड़ित के लिए मुकदमा दायर करना आसान होता है
इसके विपरीत UK में आम तौर पर “हारने वाला दोनों पक्षों के legal costs देता है” वाला तरीका है, इसलिए काफी नुकसान होने पर भी कई plaintiffs मुकदमा करने से हिचकते हैं
ऐसी धमकी से आपको क्या नुकसान हुआ, और उचित मुआवजा कितना है? मुआवजा पाने के लिए वकील रखकर मुकदमा करने की लागत कितनी है, और जीतने की संभावना कितनी है?
धमकी भरा पत्र भेजने वाली तरफ ने भी खुद से इसी तरह के सवाल पूछे होंगे
अगर आपको लगता है कि सामने वाले के पास ज्यादा संसाधन हैं इसलिए यह अन्यायपूर्ण है, तो वह एक ज्यादा सामान्य सामाजिक समस्या है। ज्यादा पैसा होने पर हर तरह के न्याय तक पहुंच बेहतर हो जाती है
यह लेख दिखाता है कि आज vulnerability disclosure को संभालने का तरीका कुल मिलाकर सकारात्मक रूप से बदल गया है।
90 के दशक में सभी कंपनियां इसी तरह थीं। कंपनियां lawsuits की धमकी देती थीं, और disclosure खुद कानूनी रूप से संदिग्ध लगता था। फोरम या BBS पर लोग चर्चा करते थे कि disclosure करना शुरू से ही सुरक्षित है या नहीं, और anonymous email accounts जैसे सुझाव दिए जाते थे।
बेशक, आज भी इसमें से कुछ बचा है। खासकर पुरानी सोच वाली कंपनियों में, या यहां की तरह भोले-भाले कॉलेज छात्रों के मामले में, लेकिन कुल मिलाकर disclosure के पक्ष में हालात नाटकीय रूप से बदले हैं।
अब security researchers की पहचान की रक्षा करने वाले dedicated intermediaries हैं, disclosure को प्रोत्साहित और सराहने वाली बड़ी कंपनियां हैं, 6-figure bug bounties हैं, और कानून भी security researchers के प्रति अधिक friendly हो गए हैं।
लेखक के लिए यह काफी अप्रिय अनुभव रहा होगा, लेकिन यह एक अच्छा reminder है कि पहले ऐसी स्थिति standard होती थी या उससे भी बदतर, और अब यह कुछ हद तक दुर्लभ हो गई है।
कई कंपनियां bug bounty अपनाती हैं और अपने खिलाफ इस तरह की गतिविधियों को प्रोत्साहित करती हैं, जिससे दुर्भाग्य से “बच्चों” को ऐसा सीखने को मिलता है कि यह सब पूरी तरह legal, moral और ethical है।
लेकिन इस कहानी में दिखता है कि असल में यह पासा फेंकने जैसा है, और इस बार बस मामला ठीक निकल गया।
अगर किसी घोषित bug bounty program के जरिए target का cooperation नहीं मिला है, तो anonymous email जैसी विधियां अब भी बेहतर विचार हो सकती हैं। हालांकि इससे security researcher को “अपना नाम बनाने” में मदद नहीं मिलती।
यह व्यावहारिक रूप से unauthorized entry स्वीकार करने जैसा भी है। तुलना करें तो, भले ही आप सिर्फ unlocked door से अंदर जाकर यह जांचें कि फ्रिज के अंदर देख सकते हैं या नहीं, बात वही है।
जनमत की अदालत में यह ऐसा दिख सकता है कि आपने किसी कंपनी के झूठ उजागर करने में मदद की, लेकिन असली अदालत में यह तथ्य नहीं बदलता कि आप अपराध के दोषी हैं।
उस अर्थ में यह 90 के दशक वाली typical retaliation से अलग है। छात्रों के लिए यह काफी डरावना रहा होगा।
अमीर parents की involvement की संभावना को भी मैं नजरअंदाज नहीं करूंगा, हालांकि जाहिर है मुझे हालात या संबंधित लोगों के बारे में कुछ पता नहीं है।
शानदार कहानी है। Stanford Daily के article में lawyers के बीच भेजे गए letters की copies हैं, और वे काफी तीखी हैं। अगर EFF आगे नहीं आता तो हम उन्हें पढ़ नहीं पाते।
https://stanforddaily.com/2022/11/01/opinion-fizz-previously...
Stanford Daily article के मुताबिक, “उस समय Fizz यूज़र जानकारी और posts आदि store करने के लिए Google का Firestore database product इस्तेमाल कर रहा था… Fizz ने जरूरी security rules set नहीं किए थे, इसलिए कोई भी database को सीधे query कर सकता था… सभी users के phone numbers और/या email addresses तक पूरा access था, और posts व upvotes को इस identifying information से सीधे जोड़ा जा सकता था… ऊपर से पूरा database editable था। कोई भी posts, karma values, moderator status आदि edit कर सकता था।”
यह सचमुच बेतुका है।
क्योंकि client सीधे database में write करता है, आमतौर पर permission checks भूल जाते हैं, और भरोसा किया जाता है कि client सिर्फ अपने ही objects में write करेगा।
बहुत पहले मैंने Firebase user value को
isAdmin=trueमें बदलकर एक electric scooter company का admin access पा लिया था, और उसके बाद गलती से जो scooter मैं rent कर रहा था उसे Firebase से delete कर दिया। उसके बाद उस scooter का क्या हुआ, मुझे नहीं पता।app के अंदर map सिर्फ approximate location दिखाता था, और एक specific zoom level पर pins गायब हो जाते थे।
mitmproxyसे requests rewrite करने पर उन filters को भी bypass किया जा सकता था जो minors को 18+ लोगों को search करने से या adults को minors को search करने से रोकते थे, और location व gender जैसे paid-only filters भी bypass हो सकते थे। paid status को server-side verify नहीं किया जाता था।मैं एक web tool की कल्पना कर रहा हूं जिसमें app ID और public frontend app में शामिल API values डाली जाएं, optionally session ID भी support हो ताकि logged-in users को ही दिखने वाले हल्के security rules इस्तेमाल करने वाली Firestore apps को भी handle किया जा सके, और JavaScript code में मिले collection names लेकर उन्हें explore किया जा सके।
दिलचस्प बात यह है कि Fizz के Ashton Cofer और Teddy Solomon ने अपनी गलती उजागर होने पर PR damage control करने की कोशिश की https://stanforddaily.com/2022/11/01/opinion-fizz-previously...
उनका जवाब कमजोर था, और उसके बाद लगता है कि वे इस मामले पर comment करने से बचते रहे हैं।
इसमें लिखा है, “Fizz ने 7 दिसंबर 2021 को ‘Security Improvements Regarding Fizz’ नाम का statement जारी किया था, लेकिन इस article के publish होने के समय तक वह page अब Fizz website या Google search में accessible नहीं है।”
साथ ही, ऐसा अब भी काफी संभव लगता है कि app “anonymous” user activity से जुड़ी personally identifiable information store करती है।
“इसके अलावा, हमें अब भी नहीं पता कि हमारा data internally anonymized है या नहीं। founders ने पिछले साल The Daily से कहा था कि users developers को identifiable हैं, और Fizz की privacy policy अब भी यही संकेत देती है।”
यहां “developers” में वे ही founders भी शामिल हो सकते हैं जिन्होंने इस मुद्दे पर comment करने से इनकार किया, कंपनी की संबंधित communications हटा दीं, और जब शुरुआत में पूरी तरह leak होती बाल्टी को “100% secure social media app” के रूप में market करते हुए पकड़े गए, तो legal threats का इस्तेमाल किया।
मेरा अपनी जानकारी Fizz में डालने का बिल्कुल मन नहीं करता।
कानूनी धमकी देकर भी नतीजों से बचा जा सकता है, लेकिन शारीरिक हिंसा की धमकी देने पर जेल क्यों हो सकती है?
वैध काम करने की धमकी देना आम तौर पर वैध होता है। जैसे authorities को report करने की धमकी देना अवैध नहीं है
“धमकी के अंत में एक मांग थी: जो पाया है उसके बारे में कभी सार्वजनिक रूप से न बोलें। मूल रूप से, अगर वे चुप रहने पर सहमत हो जाएं तो कानूनी कार्रवाई आगे नहीं बढ़ाई जाएगी”
क्या कानूनी रूप से ऐसी मांग राज्य के अभियोजकों या पुलिस से बात करने तक को रोक सकती है?
अगर वे “100% सुरक्षित” होने का दावा करते हैं जबकि वास्तव में सुरक्षित नहीं है, और उन्हें पता है कि users को कंपनी या कम-से-कम काबिल hackers की ताक-झांक से कोई सुरक्षा नहीं मिलती, तो यह कम-से-कम fraud है और आपराधिक wiretapping के ज्यादा करीब है। क्योंकि वे जानबूझकर users को यह विश्वास दिलाकर धोखा दे रहे हैं कि यह “100% सुरक्षित” है, ताकि वे अपने राज़ service पर बता दें
यह मामला “amicably” खत्म हुआ, सच कहें तो यह न्याय की विफलता है। Fizz टीम पर fraud के आरोप लगने चाहिए
अमेरिका में नागरिकों से ज्यादा कंपनियों को महत्व दिया जाता है। अमेरिकी विज्ञापन झूठे दावों से भरे हैं
हम शब्दों का कोई अर्थ नहीं है, ऐसा दिखावा करके इसे नजरअंदाज करते हैं
दिलचस्प। हमारे स्कूल में भी SideChat नाम का बहुत मिलता-जुलता platform है, और शायद यह बहुत अलग नहीं होगा
पिछले साल “gender-affirming care” की वैधता पर सवाल उठाने की वजह से मुझे permanently ban कर दिया गया था, इसलिए सोचता हूं कि वे मेरे बारे में कितना जानते होंगे
journalism के लिहाज से देखें तो Fizz को सार्वजनिक रूप से point out करना अच्छा था। “Fizz ने user data की सुरक्षा नहीं की। उसके बाद क्या हुआ?”
यह “किसी ने hack किया” नहीं है, बल्कि Fizz अपना किया वादा निभाने में नाकाम रहा
मुझे अब भी जानना है कि vulnerability ठीक हुई या नहीं, और क्या उसका test हुआ है
हालांकि user data पहले किए गए दावे की तरह internally पूरी तरह anonymized नहीं दिखता