OVH मिसाल के आधार पर फ्रांस में CrowdStrike की हर्जाना देयता
(thehftguy.com)- 19 जुलाई 2024 के CrowdStrike अपडेट आउटेज से 85 लाख कंप्यूटर निष्क्रिय होने और 5.4 अरब डॉलर से अधिक नुकसान का अनुमान है, और यह फ्रांस के OVH मामले जैसी हर्जाना-देयता की तर्क-श्रृंखला तक जा सकता है
- OVH मामले में अदालत ने माना कि बैकअप प्रदाता को उचित स्तर और सर्वोत्तम प्रथाओं का पालन करना चाहिए, और उसी स्थान या पास के डेटा सेंटर में रखे गए बैकअप को उचित संचालन नहीं माना गया
- CrowdStrike कर्नेल-स्तर पर सबसे पहले चलने वाला सुरक्षा सॉफ़्टवेयर है, इसलिए बैंक, ट्रैवल, सुपरमार्केट जैसे उद्यमों और महत्वपूर्ण उद्योग उपकरणों में जितना अधिक तैनात होगा, टेस्टिंग और चरणबद्ध डिप्लॉयमेंट का बोझ उतना बढ़ेगा
- समस्याग्रस्त अपडेट दुनिया भर में एक साथ लाखों डिवाइस पर डिप्लॉय हुआ, BSOD का कारण बना, और रिकवरी के लिए फिजिकल एक्सेस, एडमिन अधिकार, Safe Mode या Recovery Mode में प्रवेश, तथा ड्राइवर हटाना जरूरी था
- रेगुलेटेड उद्योगों के ग्राहकों के लिए change testing, चरणबद्ध डिप्लॉयमेंट और ट्रैकिंग आवश्यक होती है, इसलिए अगर CrowdStrike ने यह नहीं किया या इससे इनकार किया, तो यह ग्राहकों के compliance उल्लंघन और अनुबंध समाप्ति का आधार बन सकता है
CrowdStrike आउटेज और हर्जाना देयता की संरचना
- CrowdStrike घटना ऐसा मामला है जिसमें एक अपडेट ने बड़े पैमाने पर कंप्यूटर आउटेज पैदा किया
- आउटेज का पैमाना 85 लाख कंप्यूटर निष्क्रिय होने का अनुमान है
- नुकसान 5.4 अरब डॉलर से अधिक आंका गया है
- हर्जाने की संभावना की तुलना फ्रांस के OVH मामले की मिसाल से की जा रही है
- सामान्य अनुबंधों में देयता-छूट प्रावधान अमेरिका के बाहर कई न्यायक्षेत्रों में सीमित प्रभाव रखते हैं, और गंभीर लापरवाही, आपराधिक आचरण या कानून-उल्लंघन से जुड़ी देयता को आमतौर पर छूट देना कठिन होता है
- मुख्य बिंदु यह है कि हुई क्षति और जानबूझकर किया गया आचरण या लापरवाही साथ मिलें तो हर्जाने की संभावना बनती है
OVH मामले में उजागर हुई परिचालन विफलता
- OVH फ्रांस का डेटा सेंटर और cloud प्रदाता है, जो फिजिकल सर्वर, virtual machines और विभिन्न cloud सेवाएँ देता है
- 10 मार्च 2021 को OVH के SGB लोकेशन पर आग लगी
- SGB1 और SGB2 डेटा सेंटर नष्ट हो गए
- SGB3 और SGB4 भी कुछ समय के लिए संचालन-अक्षम हो गए
- कई ग्राहक साइटें नष्ट हो गईं, सेवाएँ और डेटा स्थायी रूप से खो गए, और कुछ ग्राहकों ने OVH के खिलाफ मुकदमा दायर कर जीत हासिल की
- अदालत ने जिस बिंदु को महत्वपूर्ण माना, वह यह था कि सेवा का नुकसान और बैकअप का नुकसान एक साथ हुआ
- घटना के दौरान और उसके बाद पूर्ण सेवा-विफलता हुई
- घटना के बाद अपरिवर्तनीय डेटा-हानि बनी रही
- OVH ग्राहकों को बैकअप सेवा देता था, लेकिन बैकअप भी पूरी तरह अपरिवर्तनीय रूप से खो गए
- कई डेटा सेंटर होने के बावजूद वे वास्तव में एक-दूसरे के बहुत पास उसी स्थान पर थे, और अदालत ने इसे न तो अपेक्षित और न ही उचित संरचना माना
- यह भी अनुचित माना गया कि बैकअप उसी डेटा सेंटर में या उसी स्थान के अन्य डेटा सेंटरों में संग्रहीत हो सकते थे
- OVH ने तर्क दिया कि ग्राहकों को अलग-अलग स्थानों पर कई बैकअप रखने की सर्वोत्तम प्रथा अपनानी चाहिए थी, लेकिन अदालत ने माना कि बैकअप प्रदाता OVH को ही उचित मानकों के अनुसार बैकअप देना चाहिए था
- परिणामतः OVH की बैकअप सेवा अपने उद्देश्य को पूरा नहीं कर सकी और उसे उचित स्तर पर संचालित न की गई सेवा माना गया
CrowdStrike आउटेज की तकनीकी प्रकृति
- CrowdStrike उद्यम डिवाइसों पर इंस्टॉल होने वाला antivirus या EDR (Endpoint Detection and Response) सॉफ़्टवेयर है
- यह सॉफ़्टवेयर कंप्यूटर स्टार्ट होते समय चलता है और Windows या Linux ऑपरेटिंग सिस्टम में कर्नेल स्तर पर गहराई से एकीकृत होता है
- यह यथासंभव जल्दी, अन्य घटकों से पहले चलने की कोशिश करता है
- यह चलने वाली चीज़ों की निगरानी कर सकता है और संदिग्ध चीज़ों को ब्लॉक या रिपोर्ट कर सकता है
- 19 जुलाई 2024 को CrowdStrike ने एक सॉफ़्टवेयर अपडेट डिप्लॉय किया, और उस अपडेट ने जिन कंप्यूटरों पर यह पहुँचा, उन्हें क्रैश कर दिया
- दुनिया भर के लाखों कंप्यूटरों ने एक साथ अपडेट प्राप्त किया और असामान्य व्यवहार की स्थिति में चले गए
- ऊँचे अधिकारों के साथ सबसे पहले चलने वाली संरचना के कारण CrowdStrike में बग या गलत निर्णय अन्य सॉफ़्टवेयर या स्वयं सिस्टम के चलने को भी रोक सकता है
डिप्लॉयमेंट, टेस्टिंग और मॉनिटरिंग के मुद्दे
- CrowdStrike बैंक, ट्रैवल, सुपरमार्केट जैसे बड़े उद्यमों के उपकरणों में व्यापक रूप से तैनात है, और इसका मुख्य लक्ष्य गोपनीय जानकारी संभालने वाले महत्वपूर्ण उद्योग और महत्वपूर्ण उपकरण हैं
- संवेदनशील वातावरण में चलने वाले इस महत्वपूर्ण application के कारण विकास और टेस्टिंग में अतिरिक्त सावधानी आवश्यक है
- घटना वाले दिन अपडेट एक साथ लाखों महत्वपूर्ण डिवाइसों पर डिप्लॉय किया गया, जबकि अच्छी प्रथा यह है कि सॉफ़्टवेयर upgrades को चरणबद्ध तरीके से डिप्लॉय किया जाए
- मुख्य प्रश्न यह है कि टूटा हुआ अपडेट कुछ ही मिनटों में लाखों डिवाइसों तक कैसे फैल गया, और क्या कोई टेस्टिंग या चरणबद्ध डिप्लॉयमेंट था
- ऑनलाइन चर्चाओं में रिपोर्ट आया कि अस्पताल ग्राहकों ने पहले भी यह समस्या झेली थी और CrowdStrike से अपडेट नियंत्रण की मांग की थी
- एक ग्राहक का दावा है कि CrowdStrike ने चरणबद्ध डिप्लॉयमेंट से इनकार करने वाला 50-पेज का मेमो भेजा था
- यदि CrowdStrike के पास चरणबद्ध डिप्लॉयमेंट सुविधा नहीं थी या उसने इससे इनकार किया, तो यह उन रेगुलेटेड उद्योगों की आवश्यकताओं से टकरा सकता है जिन्हें वह बेचता है
- समस्याग्रस्त अपडेट ने डिप्लॉय किए गए कंप्यूटरों पर BSOD पैदा किया, और इसे बाहरी डिप्लॉयमेंट से पहले स्पष्ट रूप से टूटा हुआ अपडेट न पकड़ पाना टेस्टिंग की कमी के प्रमाण के रूप में इस्तेमाल किया जा रहा है
- रिपोर्ट यह भी है कि कुछ हफ्ते पहले Linux के लिए CrowdStrike agent में भी ऐसा ही मुद्दा हुआ था, जिससे इसे केवल एक अलग-थलग घटना न मानने का तर्क बनता है
- गलत अपडेट डिप्लॉय होने के बाद CrowdStrike को समस्या पहचानने और अपडेट रोकने में लगभग 2 घंटे लगे
- महत्वपूर्ण सॉफ़्टवेयर डेवलपर को डिप्लॉयमेंट के बाद यह मॉनिटर करना चाहिए कि चीज़ें अपेक्षा के अनुरूप चल रही हैं या नहीं और कोई समस्या तो नहीं पैदा हो रही
रिकवरी की कठिनाई और ग्राहक क्षति
- प्रभावित कंप्यूटर boot नहीं कर पा रहे थे, और उपयोगकर्ता टिकट बनाने या समस्या का निदान करने के लिए कंप्यूटर तक पहुँच भी नहीं पा रहे थे
- प्रभावित कंपनियों में कर्मचारियों को काम न करने वाले कंप्यूटर मिले और वे अपना कार्य नहीं कर सके
- रिकवरी का एक तरीका यह था कि IT टीम कंप्यूटर लेकर उन्हें पूरी तरह reinstall या reimage करे
- बाद में पता चला दूसरा तरीका यह था कि एडमिन फिजिकल रूप से कंप्यूटर तक पहुँचकर उसे Safe Mode या Recovery Mode में boot करे और फिर CrowdStrike driver फ़ाइल हटाए
- इस रिकवरी के लिए फिजिकल एक्सेस और एडमिन अधिकार दोनों आवश्यक थे
- लैपटॉप को recovery mode में शुरू करने के लिए विशेष पासवर्ड या पासवर्ड वाली USB key की जरूरत पड़ सकती है
- प्रभावित कंपनियों को सभी उपयोगकर्ता लैपटॉप, डेस्कटॉप और सर्वर फिजिकल रूप से इकट्ठा करने में कई हफ्ते लग सकते हैं
- लक्ष्य डिवाइसों की संख्या हजारों से लेकर लाखों तक हो सकती है
- एयरपोर्ट डिस्प्ले टर्मिनल, अस्पताल के मेडिकल डिवाइस और उपकरण, या एलिवेटर पैनल जैसे बंद या कठिन-पहुँच वाले उपकरणों में और अधिक समय लग सकता है
- जो उपकरण फिजिकल रूप से अवरुद्ध हों या जिनका recovery पासवर्ड ज्ञात न हो, उनकी बहाली असंभव हो सकती है
- स्पेयर कंप्यूटर भी इसी समस्या से प्रभावित थे, इसलिए प्रभावित उपयोगकर्ताओं को वैकल्पिक डिवाइस देना कठिन था
- CrowdStrike ऐसा सुरक्षा सॉफ़्टवेयर था जिसका उद्देश्य कंप्यूटरों को चालू रखना और खतरों से बचाना था, लेकिन जिन कंप्यूटरों की रक्षा करनी थी उन्हें ही निष्क्रिय कर उसने अपना उद्देश्य पूरा नहीं किया
रेगुलेटेड उद्योग और अनुबंध समाप्ति की संभावना
- healthcare, finance, aerospace, transport जैसे रेगुलेटेड उद्योगों के ग्राहकों को परिवर्तनों का परीक्षण करना, उन्हें चरणबद्ध तरीके से डिप्लॉय करना और ट्रैक करना आवश्यक होता है
- CrowdStrike कहता है कि उसके पास कई certifications और standards हैं, लेकिन ऐसे मानक विशिष्ट development practices और कई स्तर की टेस्टिंग की मांग करते हैं
- यदि CrowdStrike ने ऐसी प्रक्रियाएँ नहीं अपनाईं और सक्रिय रूप से उनसे इनकार किया, तो यह स्वयं CrowdStrike के compliance उल्लंघन में बदल सकता है
- CrowdStrike के उपयोग से ग्राहक भी compliance उल्लंघन की स्थिति में आ सकते हैं, और जो ग्राहक चाहें उनके लिए CrowdStrike अनुबंध को एकतरफा समाप्त करने का पर्याप्त आधार बन सकता है
तुलनात्मक उदाहरण और अतिरिक्त आधार
-
BitLocker की टेस्टिंग और डिप्लॉयमेंट पद्धति
- BitLocker से जुड़े कर्मचारी की टेस्टिंग और डिप्लॉयमेंट पद्धति पर चर्चा को अतिरिक्त आधार के रूप में इस्तेमाल किया गया है
- BitLocker कंप्यूटर डिस्क को सुरक्षित रूप से encrypt करने का उपकरण है
- कंप्यूटर खो जाने या चोरी होने पर यह दूसरों को डेटा पढ़ने से रोकता है
- यह स्टार्टअप पर सबसे पहले चलता है, और इसके बिना डिस्क से डेटा लोड नहीं किया जा सकता
- BitLocker में बग कंप्यूटर को पूरी तरह निष्क्रिय कर सकता है और सारा डेटा अपठनीय बना सकता है, जो OVH मामले की अपरिवर्तनीय डेटा-हानि से मिलता-जुलता है
- BitLocker अपनी मशीन, अपनी टीम और फिर दूसरी टीमों तक जाने वाले कई चरणों की टेस्टिंग से गुजरता है
-
पहले के CrowdStrike आउटेज का दावा
- एक गुमनाम कंपनी कर्मचारी का पहले के CrowdStrike आउटेज का दावा भी अतिरिक्त आधार के रूप में इस्तेमाल किया गया है
- उस कंपनी का दावा है कि वह पहले भी CrowdStrike समस्या से प्रभावित हुई थी
- कंपनी का कहना है कि उसने CrowdStrike से आधिकारिक रूप से चरणबद्ध डिप्लॉयमेंट की अनुमति मांगी थी, लेकिन CrowdStrike ने इसे पूरी तरह ठुकराने वाला 50-पेज का मेमो भेजा
- यदि यह दावा सही है, तो वह मेमो CrowdStrike के खिलाफ महत्वपूर्ण साक्ष्य बन सकता है
1 टिप्पणियां
Hacker News की राय
मैं फ्रांस में ही एक दूसरी फ्रेंच cloud service provider कंपनी में काम करता/करती हूँ; OVH की घटना को real-time में झेला और उसके बाद के सारे असर भी देखे
OVH को जिम्मेदार service outage के कारण नहीं, बल्कि data loss के कारण ठहराया गया था। Data loss पलटा नहीं जा सकता, स्थायी और निश्चित नुकसान है; कुछ कंपनियाँ तो चलाने के लिए data न होने से लगभग बंद ही हो गईं। इससे भी खराब बात यह थी कि OVH “offsite backup” को data center से सचमुच कुछ मीटर दूर ही बेच रहा था। Service outage दुर्भाग्यपूर्ण है, लेकिन हो सकता है, और दोनों पक्षों के सहमत SLA contract से संभाला जाता है। कुछ दिनों की outage किसी कंपनी को बंद नहीं कर देती
मुझे संदेह है कि CrowdStrike पर कंपनियों के प्रति बहुत बड़ी liability आएगी। अगर वह पूरे नुकसान की भरपाई करे तो कंपनी को बंद करना पड़ेगा। हाँ, healthcare sector अलग मामला है; लगता है कि critical institutions पर regulation और बढ़ेगा
इतिहास की सबसे बड़ी outage एक config parser failure की वजह से हुई, और लगता है कि config/parsing handling में industry best practices नहीं अपनाई गईं; kernel module programming में भी best practices न अपनाए जाने की काफी संभावना दिखती है। ऐसे में damages की वजह से bankruptcy file करने की जरूरत न पड़े, यह सच कहूँ तो अजीब है। इसका मतलब यह नहीं कि software गायब हो जाएगा या maintain नहीं होगा; इसे रोकने के कई तरीके हैं। उदाहरण के लिए Microsoft वैसे भी Falcon को acquire करने में रुचि रखता था
तार्किक रूप से, data जितना ज्यादा अहम था, उसके गायब होने की संभावना उतनी ज्यादा थी। अनौपचारिक आसपास के उदाहरणों में कई users BitLocker इस्तेमाल कर रहे थे, जिसका मतलब है data loss भी बहुत हुआ होगा
सुधार: मैंने देखा है कि कई मामलों में BitLocker encrypted drives recover की जा सकती हैं। असल data loss कितना हुआ, यह जानने की उत्सुकता है
यह title थोड़ा misleading है। असल में यह blog पर डाली गई किसी व्यक्ति की निजी, हालांकि informed राय है; fact statement नहीं
title कुछ ऐसा होना चाहिए था: “मुझे लगता है CrowdStrike liable होगा” या “CrowdStrike को liable होना चाहिए”
यह याद दिलाना अच्छा है कि license agreements में आम तौर पर दिखने वाले general liability waiver clauses, अगर आप दूसरे jurisdictions में business करते हैं, तो US jurisdiction के बाहर बेमायने हो सकते हैं
लगता है कि बहुत बड़ी संख्या में claimants पहले से ही lawyers से बात कर रहे होंगे कि compensation कैसे मिले। सिर्फ फ्रांस नहीं, पूरी दुनिया में ऐसा होगा
इतने सारे jurisdictions होने पर ऐसी चीजें कैसे organize होती हैं, यह जानने की उत्सुकता है
इसलिए दुनिया भर की कई courts और lawyers कुछ समय तक इस मामले में काफी व्यस्त रहेंगे
मैं lawyer नहीं हूँ, फ्रेंच lawyer तो बिल्कुल नहीं, लेकिन OVH से तुलना मुझे सही नहीं लगती
OVH मामले में पूरा backup system fail हो गया था। कई customers का data zero हो गया, और article के मुताबिक “court ने माना कि OVH backup service reasonable standard पर operate नहीं हुई और अपने purpose को पूरा नहीं कर सकी”
इसके उलट CrowdStrike ने customers के kernel को “बस” करीब 1 घंटे के लिए crash किया। उस दौरान वे cyber attacks से 100% safe रहे होंगे। उसके बाद systems को वापस up करने में जो delay लगा, मेरे नजरिए से वह customers की disaster recovery plans पर्याप्त अच्छी न होने के कारण था। यह argue करने की गुंजाइश जरूर है कि CrowdStrike software “reasonable standard” का नहीं था, लेकिन primary impact यानी software crash, OVH की तरह सचमुच आग के गोले में सारा data हमेशा के लिए खो देने जैसा बिल्कुल scale का नहीं है
Software हमेशा crash होते हैं। पसंद हो या न हो, ज्यादातर industries में software bugs को unavoidable माना जाता है। बेशक exceptions हैं। Software bug की “liability” vendor पर होती है, लेकिन उसके impact को mitigate करना उसे deploy करने वालों की जिम्मेदारी है। रोज होने वाले दूसरे software crashes की तुलना में CrowdStrike incident के news बनने की इकलौती वजह यह है कि CrowdStrike के कई customers ने इस software को कई critical paths में डाल रखा था
CrowdStrike ने एक trump card बेचा, और customers ने collectively उससे घर बना लिया
P.S.: इसे CrowdStrike का बचाव न समझें। मुझे लगता है उनका software खराब और ढीले-ढाले तरीके से develop किया गया है। उस लापरवाही की कीमत उन्हें चुकानी चाहिए, लेकिन मौजूदा legal system में ऐसा होता नहीं दिखता। ज्यादा से ज्यादा आगे चलकर लोग अपने wallet से vote कर सकेंगे
flaw से प्रभावित ज्यादातर computers reboot loop में फँस गए थे और fix download नहीं कर सकते थे, इसलिए safe mode boot के जरिए physical action जरूरी था। मेरी समझ में ज्यादातर मामलों में IT technician को site पर जाकर computer तक physical access लेकर fix करना पड़ा
एक हफ्ते, यानी 168 घंटे बाद भी इस flaw की वजह से बहुत सारे computers अब भी brick बने हुए हैं। क्योंकि इसे ठीक करना बेहद मुश्किल है
इसलिए इसे सामान्य crash से काफी अलग देखना चाहिए। Recovery कहीं ज्यादा कठिन है, और इसने एक साथ बहुत सारे computers को प्रभावित किया
ऊपर से कुछ companies अपने recovery procedures में भी fail हुईं। लेकिन procedures अच्छे होते तब भी यह बड़ी outage हो सकती थी। क्योंकि इसे आसानी से rollback नहीं किया जा सकता, और यह आम तौर पर कई दूसरी failures से बचने के लिए redundant बनाए गए कई setups को भी एक साथ प्रभावित करती है
क्या आप समझा सकते हैं कि Falcon जो सुरक्षा फीचर्स देता है, वे ऑपरेटिंग सिस्टम खुद क्यों नहीं देता? ऐसा नहीं कि मुझे बिल्कुल जानकारी नहीं है; मैंने काफी सारे महत्वपूर्ण Linux servers की security भी संभाली है, लेकिन Windows में security की भूमिकाओं का विभाजन उतना स्पष्ट नहीं लगता
Red Hat या Canonical से तुलना करें, तो वहाँ ऐसा लगता है कि users मेरी application इस्तेमाल कर सकें, इसके लिए मैं system security से लड़ रहा हूँ—और अजीब बात है कि वही दिशा ज़्यादा सही लगती है
https://www.theregister.com/2024/07/22/windows_crowdstrike_k...
इनमें से कुछ के लिए OS में default alternatives हैं, कुछ के लिए नहीं हैं, और ज़्यादातर Linux में default रूप से built-in नहीं हैं. उदाहरण के लिए, Linux kernel team के पास कोई malware signature database नहीं है, जिससे नए software components को kernel, init system या shell के execute करने से पहले मिलाया जा सके. Falcon यह करता है
एक और उदाहरण के तौर पर, Linux या सामान्य Linux user space फिलहाल fleet management system के साथ default integration नहीं रखता, ताकि यह जांचा जा सके कि मौजूदा user कोई खास software चला सकता है या नहीं. ऐसे कई मिलते-जुलते सवाल हैं
अंत में, भले ही OS ऐसी services default रूप से दे—जैसे Windows Enterprise version ऊपर बताए गए फीचर्स देता है—फिर भी किसी दूसरे vendor का solution पसंद करना पूरी तरह उचित हो सकता है. उदाहरण के लिए, आप Microsoft की तुलना में CrowdStrike की malware signature list पर अधिक भरोसा कर सकते हैं, और तब Windows Defender के बजाय CrowdStrike खरीदने की वजह बनती है
मैं CrowdStrike या Windows का बचाव नहीं कर रहा. बस इतना स्पष्ट लगता है कि security नाम की छतरी के नीचे ऐसी कई क्षमताएँ आती हैं जिन्हें आप OS में ही नहीं रखना चाहेंगे, और built-in version होने पर भी कोई company किसी दूसरे supplier को चाह सकती है
लेकिन ransomware जैसी real-world समस्याओं को रोकने के लिए यह पर्याप्त नहीं निकला
इसलिए अधिक aggressive third-party solutions का market बना. वास्तविक खतरों के साथ बने रहने के लिए इन्हें बार-बार update होना पड़ता है और high privilege level पर चलना पड़ता है. नतीजा यह है कि ये third-party solutions blue screen या boot loop पैदा कर सकते हैं. ऐसे में update rollout का तरीका बहुत अच्छी तरह design किया होना चाहिए
उदाहरण के लिए, कोई file download करके उसके content को code की तरह execute करना, या जिन भी files तक access है उन्हें upload या encrypt करना
CrowdStrike और Defender ऐसे संभव लेकिन संदिग्ध व्यवहार को handle करते हैं
यह कई systems पर deployed है, लेकिन Windows systems के 1% से कम होने का मतलब absolute terms में अब भी niche ही है. ज़्यादातर लोगों ने खुद CrowdStrike के बारे में भी नहीं सुना था, competitors की तो बात ही छोड़िए
CrowdStrike और antivirus के बीच एक बड़ा फर्क मुझे यह लगता है कि लागत इतनी अधिक है कि यह उम्मीद नहीं की जाती कि हर समय कोई इंसान हस्तक्षेप करेगा. consumer software में privacy issues की वजह से भी यह feasible नहीं है
इस छोटे niche के अंदर भी solutions बहुत heterogeneous हैं, single machine पर उनका खास मतलब नहीं, और हो सकता है कि वे असल में network level पर काम करने के लिए design किए गए हों
consumers के मामले में मुझे पता था कि ऐसी चीज संभव है, लेकिन मैंने सोचा था कि B2B contracts को sophisticated दोनों पक्षों के बीच के contracts माना जाता है, इसलिए contract terms से आगे legislative protection बहुत कम होगी
कानून की मेरी समझ मुख्यतः UK पर आधारित है, लेकिन जब liability पैदा करने वाली घटना health & safety या किसी बहुत अधिक legislated area की नहीं, बल्कि contract performance में सामान्य good faith/competence की समस्या हो, तब liability limitation clauses को निष्प्रभावी करने वाला कानून मुझे ठीक से नहीं पता
इसलिए article में कही बात—कि यह सिर्फ “French legal system” का मुद्दा नहीं है और दूसरे jurisdictions में भी इसी तरह का फैसला आ सकता है—पर मुझे भरोसा नहीं हो रहा
अगर जानबूझकर staged rollout implement नहीं किया गया, तो मेरी नजर में यह negligence जैसा दिखता है, हालांकि मैं वकील नहीं हूँ. canary को मारने की वजह होती है
अगर वे ऐसा नहीं करते, तो यह breach of contract हो सकता है, और liability limitation clauses फिर लागू नहीं रह सकते
यह सिर्फ France की बात नहीं है
अधिकांश, शायद सभी EU देशों में ऐसे कानून हैं जो contract में कुछ भी लिख देने पर भी liability से बचने को सीमित करते हैं
देश के हिसाब से सटीक boundaries मुझे नहीं पता, लेकिन मुझे काफी भरोसा है कि कम से कम hospitals, emergency call services आदि outage से सीधे हुए नुकसान के non-trivial हिस्से के लिए मुकदमा कर सकेंगे
जिस व्यक्ति को समय पर surgery न मिलने से नुकसान हुआ, वह भी संभवतः अपने ऊपर हुए पूरे नुकसान के लिए मुकदमा कर सकता है. हालांकि damages की गणना कठिन होगी, और शायद पहले hospital पर मुकदमा कराना पड़े, फिर hospital बड़े नुकसान का claim करे—इस तरह अप्रत्यक्ष रूप से मामला चलाना पड़े
शायद जिन हिस्सों पर मुकदमा कठिन होगा वे opportunity cost losses, recovery में लगे staff costs आदि होंगे
और कई ऐसे मामलों में, जो न तो जान-माल के नुकसान जितने गंभीर हैं और न opportunity cost losses जितने अप्रत्यक्ष, बड़ा factor यह होगा कि judges negligence की degree को कैसे देखते हैं. यहाँ “negligence” से मतलब सिर्फ वह खास change नहीं है जिसने bug बनाया, बल्कि यह भी है कि risk को reasonable तरीके से कम करने के लिए tools के चयन, approach, business processes आदि में duty of care निभाई गई या नहीं. उदाहरण के लिए, configuration parsing का तरीका अनुचित था या नहीं, industry best practices follow की गईं या नहीं—मेरी राय में तो नहीं लगतीं. या उस driver को boot-critical के रूप में mark करना उचित था या नहीं. अगर ऐसा नहीं होता, तो Windows उसे automatically disable करके restart कर देता
“19 जुलाई 2019 को CrowdStrike ने सॉफ़्टवेयर अपडेट जारी किया” लिखा है, लेकिन लगता है कि वर्ष से मतलब 2024 है
“यह कोई अलग-थलग घटना नहीं है। कुछ हफ़्ते पहले भी Linux के CrowdStrike एजेंट में यही हुआ था और सिस्टम ठप हो गए थे, और उससे पहले भी अन्य मामले हो सकते हैं” वाले हिस्से के लिए, क्या इस घटना का कोई लिंक है?
“CrowdStrike's Falcon Sensor also linked to Linux kernel panics and crashes”, https://news.ycombinator.com/item?id=41030352