[SystemSafety] Crowdstrike's crowd strike

[Steve Tockey]

I am now sitting—stranded—at Las Vegas airport because my flight home has been cancelled due to the Crowdstrike debacle. The earliest I can get out is on Monday, a 48 hour delay. Since it’s their fault, I should, realistically, be able to bill them for the added expenses of having to spend another two days here.

Or, no doubt, they have cleverly written their contracts in a way to excuse them of all consequential liabilities of their stupidity . . . 



— steve



On Jul 20, 2024, at 2:56 PM, paul_e.bennett at topmail.co.uk wrote:

On 7/20/2024 at 9:31 PM, "Thomas Netter" <tn at thomasnetter.com> wrote:
> 
> https://www.crowdstrike.com/terms-conditions/
> 
> 8.3  Services Warranty. CrowdStrike warrants to you that it will 
> perform all Services in a *professional* and workmanlike manner consistent 
> with *generally accepted industry standards.* (...)
> 
> 8.6 (...) CROWDSTRIKE TOOLS ARE *NOT FAULT-TOLERANT* AND ARE NOT 
> DESIGNED OR INTENDED FOR USE IN *ANY HAZARDOUS ENVIRONMENT* 
> REQUIRING FAIL-SAFE PERFORMANCE OR OPERATION. NEITHER THE 
> OFFERINGS NOR CROWDSTRIKE TOOLS ARE FOR USE IN THE OPERATION 
> OF AIRCRAFT NAVIGATION, NUCLEAR FACILITIES, COMMUNICATION SYSTEMS,
> WEAPONS SYSTEMS, DIRECT OR INDIRECT LIFE-SUPPORT SYSTEMS, AIR 
> TRAFFIC CONTROL, OR ANY APPLICATION OR INSTALLATION WHERE FAILURE
> COULD RESULT IN DEATH, *SEVERE PHYSICAL INJURY, OR PROPERTY DAMAGE.*
> 
> Question is then: if your piece of software is so successful that its failure can lead to 
> millions of people piling up as exhausted crowds, causing an emergent behaviour of
> aggressivity, possibly people hurting themselves as the environment becomes
> hazardous due to software failure, and wanting to break everything to cause loss or
> severe damage to equipment/property... hasn't it become a safety-critical piece of 
> software even though it was not originally intended to be one?
> 
> Thomas

One has to wonder why we do not strongly emphasis the need to develop all software
as with attendant risk assessment and hazard mitigation considerations. Not to do so
leads to lazy coding practice IMHO.


Regards

Paul E. Bennett IEng MIET
Systems Engineer
Lunar Mission One Ambassador
-- 
********************************************************************
Paul E. Bennett IEng MIET.....
Forth based HIDECS Consultancy.............
Mob: +44 (0)7811-639972
Going Forth Safely ..... EBA. https://electricboatassociation.org/
********************************************************************

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety