There are probably good reasons why the 'windows crowd' doesn't POST here, but I'll bet you there are a hell of a lot more windows users who peruse these pages than you think.
Hehe. Some of us even POST here. Basic survival gear. If there's a problem I need to know about it will show up on slashdot much much earlier than on microsoft.com. That's from Melissa onward. Seems like it took Microsoft a week to find out about Code Red.
(Also Google gives a much better search of Microsoft's knowledge base than Microsoft itself;)
(Also/. is probably the only source of unbiased information about Microsoft. (And yes I am aware that there is a lot of bias, both sides))
Journalists, IT managers, and 'similar' comprise what percentage of the population? Direct, rather small, but add a couple orders of magnitude for direct friends and at least another for friends of friends. The influential people are influentential because they know a lot of people (and a lot of people know them).
Finally, what are the odds that of all the possible failure modes software can have, one absolutely not designed to deactivate a product does so. No, the odds are that a failure of something (hardware, malware, foreign software) fails in a way that can (will?) be attributed to deactivation.
A carefully worded press release from Microsoft's PR firm does not really do that much to allay suspicion. It has to do with how much "weasle room" there is between what the statement appears to say and what it actually does say. Also, since this is a PR firm, rather than someone from inside Microsoft who would be an a position to know, it is probably safe to conclude that they can only say what they have been told.
Dunno what all is behind it, but looks like the beginning of a good urban myth.
You're thinking the only way to build a secure core is to define badness, that is to define what must be blocked. Actually, no. (But I am phrasing things rather carefully and your reaction is totally correct if you didn't parse everything precisely)
BUT... You have a similar problem trying to define goodness. Carefully define everyone/everything who/how/whatever will ever befriend you during your uncertain future. However you try, you definition of friendly will have in it something fatal.
A simple checksum on binaries -- trivial to implement in a program loader. Probably tried a few times and abandoned. As soon as you encounter a certain type of bug, you have just ensured that the bug is unfixable, unpatchable. There is a quick and easy fix but applying it makes the system permanently unusable. (Actually makes a very effective "logic bomb";)
And, extreme security makes computing far less transparent, often to the exclusion of any reasonable work flow for day to day tasks. If security could be transparent (not sure it can), that would help.... no business likes fielding support issues for an entire corporation just because their network is PKI (ever administrate Sun's version?). Methinks the reality is that losing transparency means losing security.
(I once worked at a place that had a thirteen-rule requirement for setting new passwords... it was so intrusive, I kept a printout of the rules on my monitor to try and avoid a twenty-minute guessing game session for setting new passwords. What was really funny was at one point the "rules" conflicted with one of our systems, so you couldn't define a qualified password that the system could use. Hilarious.)... And the next step is... Breaking security is "hilarious". "Hilarious" is a good thing not a bad thing. A Rube Goldberg contraption trying to fake security will have predictable consequences.
Any time you have many eyes which know what is supposed to be going on, it is rather hard for any outsider to penetrate. Any time you have superfluous and illogical rules trying to enforce someone's bad idea of security, there are just too many unwatched cracks, too many ways to get around things.
Looks like several of 'em in the same general space. Other than specific references to Windows 2000, seems relevant regardless of epoch.
[4] RJ Anderson, "Why Cryptosystems Fail" in Communications of the ACM vol 37 no 11 (November 1994) pp 32-40
[1] GA Akerlof, "The Market for 'Lemons': Qual- ity Uncertainty and Market Mechanism," Quarterly Journal of Economics v 84 (August 1970) pp 488-500
From the paper,
The theory of asymmetric information gives us an explanation of one of the mechanisms. Consider a used car market, on which there are 100 good cars (the `plums'), worth $3000 each, and 100 rather trouble-some ones (the `lemons'), each of which is worth only $1000. The vendors know which is which, but the buyers don't. So what will be the equilibrium price of used cars? If customers start off believing that the probability they will get a plum is equal to the probability they will get a lemon, then the market price will start off at $2000. However, at that price only lemons will be offered for sale, and once the buyers observe this, the price will drop rapidly to $1000 with no plums being sold at all. In other words, when buyers don't have as much information about the quality of the products as sellers do, there will be severe downward pressure on both price and quality. Infosec people frequently complain about this in many markets for the products and components we use; the above insight, due to Akerlof [1], explains why it happens. The problem of bad products driving out good ones can be made even worse when the people evaluating them aren't the people who suffer when they fail.
Even if the people evaluating are the people who suffer, it's like the quality of snake-oil offered for sale. The quality is much much lower if the ingredients do not have to be listed. That's really the reason that Microsoft gets all the malware. You don't know what's in it. You don't know what it's doing. You don't know what it's supposed to be doing. The OPEN of open source is enough to shift the balance even if the quality were much much worse than closed. You can expect similar when IT tries to secure the system from the users.
One final crack about the economics of security. The price of a compromised machine give a very accurate overall economic view of the worth of security. This is similar to the price of a hit-man as a measure of crime-in-the-streets. When this price is too low (five cents ????), you know something is wrong, very wrong.
The end users often (unfortunately) have the final say in usuability and therefore the extent of security.
THERE'S your problem. The end users have the final say on security. Really. It's like the bit about physical security. Security is not about the hardest way in (IT and management controlled) but the easiest way in (user controlled). Now it is completely feasible for management and IT to delude each other about the state of security. I assume that is the normal state of affairs.
If stuff in an office needs to be secured, is the door locked when the occupant is not present? Is the computer the most sensitive thing in the office?
Since this is about security, a bit of nitpicking is in order.
There are at least two meanings.
It's easy to know when you do have a bug. You do. Just no idea what, where, how, etc. You can even use statistics to draw confidence intervals on the number and severity of the bugs.
It's easy to know when you do have a bug. Assuming that if you have a bug you'd know it. This one is false, very false. It is quite possible for a bug to exist and to not be demonstrable under any circumstances. I've had lots of situations where it was necessary for TWO bugs to get together for anything to show up. I've even had a triple -- and that one was downright spooky.
To further complicate matters, bugs are not created equal. Counting bugs is about as silly as counting money tokens (equating pennies with $100 bills, except that computer stuff is not nearly that equal).
want my operating system to frigging work right, not report on me, not protect me, not help me, I want it to do it's job and let other programs do the other stuff and NOT crash when the other programs crash
Hmmm, sounds like you want OpenBSD. The emphasis is on doing things right (rather than trying to do everything).
Oh it will kill the OS, the legitimate ones that is, eventually.
Whatever mechanisms Microsoft uses to do this thing will be reverse engineered by the bad guys (as if they didn't have enough ideas already) and used to make some very hard to discover and eradicate malware. This malware will be a bit broken and will kill the OS.
However, I suspect that depends on a degree of good faith.
The nature of software is that there are many unknowns. Consequential damages can potentially occur from many unforseeable causes, consequentially there is a fundamental assumption that "we did the best we can, but...".
When the vendor of the software is acting in bad faith, and deliberately and intentionally damages the legitimate operation of someone else's computer system, seems like there are some rather stiff criminal consequences, and probably some stiff civil penalties as well. There may be a lot of bias in the courts toward business, but surely there is still a faint trace of equity.
However, it's very possible to leave people in the lurch in an Open Source project, just like a proprietary project
The difference being that with a proprietary project there is nothing you *CAN* do about it legally. With Open Source, you can always be your own maintainer. Doesn't give you the ability, but at least nobody is stopping you.
Thanks for a rational explanation. We old geezers have a much easier time handling accurate explanations than these attempts that cannot possibly be correct.
How to take an underused single processor and have it look like you've got another processor (or close enough to make it worthwhile). Not really a second processor, but for a lot of stuff it works like one. This does allow some operations to occur simultaneously. Kinda unlikely that simultaneous anything is good to have happening inside any kind of scheduler.
Hmmmph. I'm an old geezer and I don't give the modern generation much credit. Best I can tell, the state of the art has gone steadily downhill since the early 70's. The hardware has gotten (much) bigger and faster, but the knowledge of what to do with it has
32-bit versus 64-bit. Any idea just how big 32 bit is? How bit 64 bit is? It's kinda hard to explain what you don't understand. When you do understand what you are trying to explain, the additional life experience of the elderly makes it much easier. What is hard is the "bigger is better" when you have no comprehension of why (and the reality is that it isn't).
The advantage of 64-bits is that it takes twice as much memory to represent anything.
Can't the same trick be used to make a rootkit-safe environment?
Yes, provided you know exactly what the rootkit looks like and does.
Unfortunately, you are committed to looking exactly for something specific, the rootkit writer knows what you are looking for, and should be able to get by your defenses with some ridiculously bad disguise.
What about providing a grounding path of some kind to short circuit the energy?
Not a chance. Something about conservation of energy. Now if somehow you could get something in the middle of it to convert the energy to a "useful" form, you could probably do something. A big enough wind farm in the middle of a hurricane -- lots of energy. Temperature difference between surface and deep waters -- lots of energy.
If you know exactly what you are doing, it should be possible to make stuff happen in one place rather than another -- maybe like a lot of little storms rather than one huge storm. I suspect we are nowhere near the level of knowledge required.
"In theory there is no difference between theory and practice. In practice there is." -Yogi Berra
Theory is always a gross oversimplification. Assumptions are made, not because they are valid, but because without them computation is impossible and they seem not to cause too much error in at least some of the cases of interest.
I can only hope this is supposed to be sarcastic, but...
Unfortunately, the sarcasm is that it likely isn't sarcasm. There is some assumption that if nobody goes looking for the security flaws, the security flaws will cease to exist.
[sarcasm]If you don't go looking for bugs, the bugs won't exist.[/sarcasm]
If you have a bug, the best you can hope for is for the bug to be demonstrated in a spectatular but essentially harmless fashion. What normally happens is that people get bit without even realizing it.
If that argument were valid, we'd all be better off going back to the medieval guilds. No thanks.
If you have a perfectly competitive market (ie no lock-in), there is very little room for profit, and hence for investment in research and development.
Backwards. That seems to imply that the reason for research and development is to be a fair way to apply some of the profits from your locked-in customers. I doubt that companies even start out that way. It would be nearly impossible to stay that way. Margins are thin and your competitors have the edge in research. You can maybe stay alive a bit longer by remaining dumb. But the best research and development comes when your best chance for survival comes from disruptive advances in the technology.
"The long line is a non-paracompact Hausdorff -dimensional manifold constructed as follows. Let be the first uncountable ordinal and consider the set" from http://planetmath.org/encyclopedia/LongLine.html
For Cardinals, there are precisely as many rational numbers as there are prime numbers.
Engineering systems so that it's difficult or impossible to do "stupid things" is mandatory.
Now for important things like peoples' health, how do you engineer the food system so that people do not do stuff so that they die off too early? How do you engineer cigarettes so they are not a health hazard? Ditto Ethanol.
There are a very few things where it is feasible and productive to engineer systems to lessen the likelihood and the consequences of doing stupid things. Generally this is done by investigating the aftermath of what happened when somebody did something stupid or got unlucky. Sometimes you can change things so that repeat performances are less likely.
Actually, we mostly agree. The only safe way to have executable attachements is to not have executable attachements. This includes all sorts of executable turing machines -- very hard NOT to make them. Executable attachements are an accident looking for a place to happen. The idea of "opening" a program (ie running the program) confuses the notions of program and data -- once confused does not get unconfused.
proper security Actually executable attachements are an incredibly bad idea even for lousy (bad) security.
You have "your" computer. I send you an attachement which makes your computer do my bidding. Whose computer? If I can, you have no chance of security, certainly not anything that could be called "proper" security. To have any chance (of even poor security), you need to be immune from any such. No I do not mean patched for the known holes. I mean immune from the unknown holes.
I find it highly ironic that the author used 11 words in two languages to make the statement, "Don't be wordy."
Actually he didn't make that statement at all. (only when the words outperform silence)
The meaning is closer to "If you don't have anything to say, then don't say it". (11 words in one language)
Don't be wordy implies that "the words underperform silence".
A big word must be a better fit to break-even with a smaller word. Obsidian is black. It is also shiny. It is also quite hard. It also takes a very sharp edge. If the word obsidian is used when black is meant, it indicates an extremely poor vocabulary, actually.
Computers are very much like cars... Either you learn enough about how they work, yourself, or you pay someone else to do it for you.
"should", I'd agree. "is" seems to be different. Googling, and the modern "safe" way of life seems even deadlier.
Hmmmmm, from http://www.earth-policy.org/Updates/Update17.htm "The World Health Organization reports that 3 million people now die each year from the effects of air pollution. This is three times the 1 million who die each year in automobile accidents."
Even some statistics that show that war is safer for the military than peace (because of auto accidents)
Slashdot Mirror
Nah. Too much like cooking (without a cookbook).
There are probably good reasons why the 'windows crowd' doesn't POST here, but I'll bet you there are a hell of a lot more windows users who peruse these pages than you think.
/. is probably the only source of unbiased information about Microsoft. (And yes I am aware that there is a lot of bias, both sides))
Hehe. Some of us even POST here.
Basic survival gear. If there's a problem I need to know about it will show up on slashdot much much earlier than on microsoft.com. That's from Melissa onward. Seems like it took Microsoft a week to find out about Code Red.
(Also Google gives a much better search of Microsoft's knowledge base than Microsoft itself;)
(Also
0.001% is one out of 10,000
Journalists, IT managers, and 'similar' comprise what percentage of the population?
Direct, rather small, but add a couple orders of magnitude for direct friends and at least another for friends of friends. The influential people are influentential because they know a lot of people (and a lot of people know them).
Finally, what are the odds that of all the possible failure modes software can have, one absolutely not designed to deactivate a product does so.
No, the odds are that a failure of something (hardware, malware, foreign software) fails in a way that can (will?) be attributed to deactivation.
A carefully worded press release from Microsoft's PR firm does not really do that much to allay suspicion. It has to do with how much "weasle room" there is between what the statement appears to say and what it actually does say. Also, since this is a PR firm, rather than someone from inside Microsoft who would be an a position to know, it is probably safe to conclude that they can only say what they have been told.
Dunno what all is behind it, but looks like the beginning of a good urban myth.
They WILL NOT fire that senior partner who is bringing in the big bucks because he did something stupid on the computer
Hmmm.
senior partner who is bringin in the big bucks
computer
Basic security. You don't risk valuable resources (senior partner) to preserve cheap resources (computer).
You're thinking the only way to build a secure core is to define badness, that is to define what must be blocked.
... You have a similar problem trying to define goodness.
Actually, no. (But I am phrasing things rather carefully and your reaction is totally correct if you didn't parse everything precisely)
BUT
Carefully define everyone/everything who/how/whatever will ever befriend you during your uncertain future.
However you try, you definition of friendly will have in it something fatal.
A simple checksum on binaries -- trivial to implement in a program loader. Probably tried a few times and abandoned.
As soon as you encounter a certain type of bug, you have just ensured that the bug is unfixable, unpatchable. There is a quick and easy fix but applying it makes the system permanently unusable. (Actually makes a very effective "logic bomb";)
And, extreme security makes computing far less transparent, often to the exclusion of any reasonable work flow for day to day tasks. If security could be transparent (not sure it can), that would help.... no business likes fielding support issues for an entire corporation just because their network is PKI (ever administrate Sun's version?).
... And the next step is ...
Methinks the reality is that losing transparency means losing security.
(I once worked at a place that had a thirteen-rule requirement for setting new passwords... it was so intrusive, I kept a printout of the rules on my monitor to try and avoid a twenty-minute guessing game session for setting new passwords. What was really funny was at one point the "rules" conflicted with one of our systems, so you couldn't define a qualified password that the system could use. Hilarious.)
Breaking security is "hilarious".
"Hilarious" is a good thing not a bad thing.
A Rube Goldberg contraption trying to fake security will have predictable consequences.
Any time you have many eyes which know what is supposed to be going on, it is rather hard for any outsider to penetrate.
Any time you have superfluous and illogical rules trying to enforce someone's bad idea of security, there are just too many unwatched cracks, too many ways to get around things.
Other than specific references to Windows 2000, seems relevant regardless of epoch.
[4] RJ Anderson, "Why Cryptosystems Fail"
in Communications of the ACM vol 37 no 11
(November 1994) pp 32-40
[1] GA Akerlof, "The Market for 'Lemons': Qual-
ity Uncertainty and Market Mechanism,"
Quarterly Journal of Economics v 84
(August 1970) pp 488-500
From the paper,
Even if the people evaluating are the people who suffer, it's like the quality of snake-oil offered for sale. The quality is much much lower if the ingredients do not have to be listed. That's really the reason that Microsoft gets all the malware. You don't know what's in it. You don't know what it's doing. You don't know what it's supposed to be doing. The OPEN of open source is enough to shift the balance even if the quality were much much worse than closed. You can expect similar when IT tries to secure the system from the users.
One final crack about the economics of security.
The price of a compromised machine give a very accurate overall economic view of the worth of security. This is similar to the price of a hit-man as a measure of crime-in-the-streets. When this price is too low (five cents ????), you know something is wrong, very wrong.
The end users often (unfortunately) have the final say in usuability and therefore the extent of security.
THERE'S your problem.
The end users have the final say on security. Really.
It's like the bit about physical security.
Security is not about the hardest way in (IT and management controlled) but the easiest way in (user controlled).
Now it is completely feasible for management and IT to delude each other about the state of security. I assume that is the normal state of affairs.
If stuff in an office needs to be secured, is the door locked when the occupant is not present? Is the computer the most sensitive thing in the office?
It's easy to know when you do have a bug
Since this is about security, a bit of nitpicking is in order.
There are at least two meanings.
It's easy to know when you do have a bug. You do. Just no idea what, where, how, etc. You can even use statistics to draw confidence intervals on the number and severity of the bugs.
It's easy to know when you do have a bug. Assuming that if you have a bug you'd know it. This one is false, very false. It is quite possible for a bug to exist and to not be demonstrable under any circumstances. I've had lots of situations where it was necessary for TWO bugs to get together for anything to show up. I've even had a triple -- and that one was downright spooky.
To further complicate matters, bugs are not created equal. Counting bugs is about as silly as counting money tokens (equating pennies with $100 bills, except that computer stuff is not nearly that equal).
want my operating system to frigging work right, not report on me, not protect me, not help me, I want it to do it's job and let other programs do the other stuff and NOT crash when the other programs crash
Hmmm, sounds like you want OpenBSD.
The emphasis is on doing things right (rather than trying to do everything).
That it will merely cripple the OS, not kill it?
Oh it will kill the OS, the legitimate ones that is, eventually.
Whatever mechanisms Microsoft uses to do this thing will be reverse engineered by the bad guys (as if they didn't have enough ideas already) and used to make some very hard to discover and eradicate malware. This malware will be a bit broken and will kill the OS.
There's no warranty for "resulting damage".
...".
However, I suspect that depends on a degree of good faith.
The nature of software is that there are many unknowns. Consequential damages can potentially occur from many unforseeable causes, consequentially there is a fundamental assumption that "we did the best we can, but
When the vendor of the software is acting in bad faith, and deliberately and intentionally damages the legitimate operation of someone else's computer system, seems like there are some rather stiff criminal consequences, and probably some stiff civil penalties as well. There may be a lot of bias in the courts toward business, but surely there is still a faint trace of equity.
However, it's very possible to leave people in the lurch in an Open Source project, just like a proprietary project
The difference being that with a proprietary project there is nothing you *CAN* do about it legally.
With Open Source, you can always be your own maintainer. Doesn't give you the ability, but at least nobody is stopping you.
Thanks for a rational explanation.
We old geezers have a much easier time handling accurate explanations than these attempts that cannot possibly be correct.
How to take an underused single processor and have it look like you've got another processor (or close enough to make it worthwhile). Not really a second processor, but for a lot of stuff it works like one. This does allow some operations to occur simultaneously. Kinda unlikely that simultaneous anything is good to have happening inside any kind of scheduler.
Hmmmph. I'm an old geezer and I don't give the modern generation much credit. Best I can tell, the state of the art has gone steadily downhill since the early 70's. The hardware has gotten (much) bigger and faster, but the knowledge of what to do with it has
32-bit versus 64-bit. Any idea just how big 32 bit is? How bit 64 bit is? It's kinda hard to explain what you don't understand.
When you do understand what you are trying to explain, the additional life experience of the elderly makes it much easier. What is hard is the "bigger is better" when you have no comprehension of why (and the reality is that it isn't).
The advantage of 64-bits is that it takes twice as much memory to represent anything.
Can't the same trick be used to make a rootkit-safe environment?
Yes, provided you know exactly what the rootkit looks like and does.
Unfortunately, you are committed to looking exactly for something specific, the rootkit writer knows what you are looking for, and should be able to get by your defenses with some ridiculously bad disguise.
What about providing a grounding path of some kind to short circuit the energy?
Not a chance. Something about conservation of energy.
Now if somehow you could get something in the middle of it to convert the energy to a "useful" form, you could probably do something. A big enough wind farm in the middle of a hurricane -- lots of energy. Temperature difference between surface and deep waters -- lots of energy.
If you know exactly what you are doing, it should be possible to make stuff happen in one place rather than another -- maybe like a lot of little storms rather than one huge storm. I suspect we are nowhere near the level of knowledge required.
"In theory there is no difference between theory and practice. In practice there is." -Yogi Berra
Theory is always a gross oversimplification.
Assumptions are made, not because they are valid, but because without them computation is impossible and they seem not to cause too much error in at least some of the cases of interest.
I can only hope this is supposed to be sarcastic, but...
Unfortunately, the sarcasm is that it likely isn't sarcasm.
There is some assumption that if nobody goes looking for the security flaws, the security flaws will cease to exist.
[sarcasm]If you don't go looking for bugs, the bugs won't exist.[/sarcasm]
If you have a bug, the best you can hope for is for the bug to be demonstrated in a spectatular but essentially harmless fashion.
What normally happens is that people get bit without even realizing it.
If that argument were valid, we'd all be better off going back to the medieval guilds. No thanks.
If you have a perfectly competitive market (ie no lock-in), there is very little room for profit, and hence for investment in research and development.
Backwards.
That seems to imply that the reason for research and development is to be a fair way to apply some of the profits from your locked-in customers. I doubt that companies even start out that way. It would be nearly impossible to stay that way.
Margins are thin and your competitors have the edge in research. You can maybe stay alive a bit longer by remaining dumb. But the best research and development comes when your best chance for survival comes from disruptive advances in the technology.
Infinity and Infinity+1 are the same thing.
For Cardinals: TRUE
For Ordinals: FALSE
"The long line is a non-paracompact Hausdorff -dimensional manifold constructed as follows. Let be the first uncountable ordinal and consider the set"
from http://planetmath.org/encyclopedia/LongLine.html
For Cardinals, there are precisely as many rational numbers as there are prime numbers.
There is a LOT more to infinity than you think.
Engineering systems so that it's difficult or impossible to do "stupid things" is mandatory.
Now for important things like peoples' health, how do you engineer the food system so that people do not do stuff so that they die off too early? How do you engineer cigarettes so they are not a health hazard? Ditto Ethanol.
There are a very few things where it is feasible and productive to engineer systems to lessen the likelihood and the consequences of doing stupid things. Generally this is done by investigating the aftermath of what happened when somebody did something stupid or got unlucky. Sometimes you can change things so that repeat performances are less likely.
Actually, we mostly agree. The only safe way to have executable attachements is to not have executable attachements. This includes all sorts of executable turing machines -- very hard NOT to make them.
Executable attachements are an accident looking for a place to happen. The idea of "opening" a program (ie running the program) confuses the notions of program and data -- once confused does not get unconfused.
proper security
Actually executable attachements are an incredibly bad idea even for lousy (bad) security.
You have "your" computer.
I send you an attachement which makes your computer do my bidding. Whose computer?
If I can, you have no chance of security, certainly not anything that could be called "proper" security.
To have any chance (of even poor security), you need to be immune from any such. No I do not mean patched for the known holes. I mean immune from the unknown holes.
I find it highly ironic that the author used 11 words in two languages to make the statement, "Don't be wordy."
Actually he didn't make that statement at all.
(only when the words outperform silence)
The meaning is closer to "If you don't have anything to say, then don't say it". (11 words in one language)
Don't be wordy implies that "the words underperform silence".
A big word must be a better fit to break-even with a smaller word.
Obsidian is black.
It is also shiny.
It is also quite hard.
It also takes a very sharp edge.
If the word obsidian is used when black is meant, it indicates an extremely poor vocabulary, actually.
Computers are very much like cars... Either you learn enough about how they work, yourself, or you pay someone else to do it for you.
"should", I'd agree. "is" seems to be different.
Googling, and the modern "safe" way of life seems even deadlier.
Hmmmmm, from http://www.earth-policy.org/Updates/Update17.htm
"The World Health Organization reports that 3 million people now die each year from the effects of air pollution. This is three times the 1 million who die each year in automobile accidents."
Even some statistics that show that war is safer for the military than peace (because of auto accidents)
You can laugh or you can cry.
Laughing's better.
That is the nature of humor.
With humor you maintain your sanity in an insane world.
If everything worked and made sense, you would not need humor.