Most states allow deadly force for forcible felonies, and include burglary. The rationale there is that the house may not be empty, and so there may be human lives at risk. It's a reasonable choice.
So, in Missouri, not only can you shoot someone for simply breaking into your house while you're home, after January 1, 2017, you can also shoot them in the back as they run away.
Rate me -1 troll, but I think it's hilarious that "the science fiction future" for which everyone is optimistically hoping is being brought to us by something so prosaic and "dirty" and anti-utopian as murdering people.
Clearly, we need a major war which absolutely requires that every soldier be equipped with a personal jetpack.
Discharging any weapon in a populated area except at a proper range or in defense of your life is generally illegal and a very bad idea.
Often illegal, yes. Firing birdshot into the air is not dangerous. That's why we use shotguns and birdshot to shoot birds. From the air. Birdshot's terminal velocity is low enough that by the time the shot falls to the ground it's not dangerous.
I dont know about Kentucky, however in Texas you can shoot people for Criminal Trespass. You can use deadly force to protect your self and your property.
Texas is the only state that allows deadly force to be used in defense of property. This is a case where Texas is wrong and the rest of the country is right. I'm all for the right to keep and bear arms, I carry daily and am a certified concealed weapons instructor. But deadly force should only be used to defend people, not stuff.
Only fools try to clean or work on their weapon without unloading it.
This.
Further, even after you've unloaded it you should still obey the golden rule of gun safety: never point it at anything you don't want to destroy. If what you're doing requires breaking that rule, first disassemble it so it's no longer a gun. Then, and only then, can you stop worrying about where you're pointing it.
The reason for this is that most people who hurt themselves or others while cleaning their gun *did* unload it first. Or thought they did.
Relatively little of what teens do is going to cause them problems in later life. It's what people do between about 18 and 25 that tends to screw them. Mainly because they're old enough to drink (without having to hide it) but not yet old enough to think (well).
Whatever you do you are still being tracked by default, that is the point of Chrome.
Do you have any evidence to back that claim up?
There are a number of features in Chrome that optionally talk to Google. But you can change them all if you prefer. Do you have any proof that it "phones home" in any hidden way? It should be quite easy to prove; Wireshark is all you need.
FWIW, I know some of the guys who started the Chrome project. Actually, they didn't start Chrome, they started V8. The point was to prove that Javascript engines could be orders of magnitude faster than they were, and to push the rest of the industry to get better, so Google's apps would be able to do more, faster. The rest of Chrome was just to show off V8. Then it became successful, both at pushing Javascript engines to get better, and as a popular browser, and Google started to use it as a test bed for other ideas about how to make the web "platform" better. Security improvements like certificate pinning. Performance (and security) improvements like SPDY and QUIC. UI simplifications like the omnibox (which geeks like to hate, but non-geeks love). Better development tools (though Firebug was and is quite good). And so on.
I don't think "better tracking of users" has ever been a goal, stated or unstated, of the Chrome project. And, seriously, why would it? It's not like the normal web standards don't offer everything that's required for whatever tracking anyone would like to do.
Trial and error, I expect. Look at what other sites do. I realize that this isn't a very good answer. There isn't a good answer, just bad answers that are still better than passwords. Classic OpenID isn't the answer because users don't know how to use it and many RPs don't trust random providers. But as a practical matter providing login with, say, Google, Facebook, Yahoo and AOL will give better than 95% of your users the ability to log on with better security than the password-based model you'd build, and do it just by clicking a couple of buttons.
If you find that your user base tends to have an account with some other provider (no, I can't tell you how to find out who your users are or what they use), then add that.
When the services go down, you can't log in to the relying sites. Luckily, core infrastructure like the account systems is a very high priority for the engineers, and the big providers have plenty of resources to keep them up -- and they do. My bank's site is down far, far more often than Google's auth servers, for example. How much more often? I don't know... I've never seen Google's auth servers down.
Pick the top several and you'll cover nearly everyone. For the tiny percentage of users that remains, you have to either offer password auth (which means all of the work and risks of maintaining a password system, but at least when you screw it up only a tiny percentage of your users will be affected) or push them to get an account with one of the providers you support.
Copy/paste cache scrapers exist, and are common for browsers with bugs. Training people not to copy/paste passwords is a good idea.
You're promoting perpetuating a long-standing, widespread and hugely-damaging user security error in order to avoid a relatively obscure problem which can actually be fixed through purely technical means. Not a win.
What you describe as a problem is actually part of the solution. The problem with classic OpenID was that it was virtually impossible to get, say 1st Bank of MyButt, to use it, because absolutely anyone could be an identity provider. I personally agree with you that classic OpenID was better in that respect, but 1st Bank of MyButt doesn't. They're hemming and hawing about letting Google manage their user's identities, but they will at least consider it.
You're actually very wrong. Long complicated passwords are horrifically impossible to remember causing people to write them down or store them in managers with simpler passwords to open the manager.
Putting them in password managers is the right thing to do.
Length is all that matters for passwords. You're better off with "thatswhatshesaid" (26 ^ 16) than "B4c0nL0v3r!" (72 ^ 11). You're 162 times better off, in fact.
The entropy of "thatswhatshesaid" is far lower than 43,608,742,899,428,874,059,776. Randall Munroe calculated correctly in the XKCD comic, of course. He didn't assume that each letter was random, he assumed he was choosing four words at random from a dictionary of a specific size (about 2048 entries == ~11 bits of entropy per word). Your password is clearly not a selection of randomly-chosen words, and even if it were, it would likely have been from a much smaller dictionary.
This highlights the danger of asking users to pick passwords... even those who think they know what they're doing are likely to screw it up. Munroe's advice in 936 was good... but I think it has mislead more people than it has enlightened.
No, it's much better to use a password manager and let a computer pick large random passwords for you.
If your password is "OPnuo(I&n hKUYNB68IOnih4wOIB*GBi234t73" as it should be,* then yes...
Parent was modded funny, but this is what your passwords should look like -- long and random, and typing them is a PITA. Any web site that disables pasting or prevents your browser or extensions from auto-filling passwords is broken. The sad thing is that most sites that do this (other than those that do it by accident because the devs are clueless) do it because they think they're increasing the security of their users' accounts. They're not.
Solutions like LastPass et al are the best, but honestly just using your browser's password database is better than reusing passwords everywhere. And Chrome and Firefox (at least, perhaps others) offer the option of keeping your passwords synced to all of the devices you use, optionally protected with a master password. Browsers need to offer password generation as well. I think some are working on it.
Of course, the real solution is to get rid of passwords. Web sites should switch to using OpenID authentication. Yes this means that most users will use their Facebook or Google logins, which means that, essentially, the site has outsourced its account security to those other entities. So what? If the developers of random web sites think they can do a better job of account security than Google or Facebook -- they're wrong. I work for Google and previously spent a decade as a security consultant in the financial industry and after seeing how they all work from the inside, I would feel much more secure about my bank account if I could use my Google account (with 2FA, plus all of the analytics and monitoring Google does) to log into it rather than trusting the bank to do a decent job with password-based security. I haven't seen Facebook's infrastructure, but I know people who work there, and they're good. Far better than you'll find at a typical bank, much less J. Random Web Developer.
And the community doesn't respond well to these or any other criticisms. They like the random element, they don't seem to give a crap about characterisation, world build, lore or story telling.
FWIW, I'm not a member of the community. I play Wesnoth off and on for a few weeks every couple of years. I also like the random element and don't much care about characterization, world-building, lore or storytelling. Not that I don't like those things, just that Wesnoth is more of an occasional light diversion for me, so those things don't mean much.
And why shouldn't they allow peer bombs? If the work was so great, then it more than justifies the $625 (5 people).
Sure, it does, which is why managers convert such things into spot bonuses -- which are generally several thousand dollars.
The downside of rewarding primarily with peer bonuses is that it might create a culture of doing good stuff for peers in order to collect peer bonuses rather than doing good stuff for peers because it's abstractly good to do good stuff for peers. I don't know how real it was or was not, but I have heard that some obnoxious Googlers with special skills or access or knowledge made a habit of demanding multiple peer bonuses before being willing to do some task for some other team that needed it. The "one bonus per" rule pretty much eliminates that because -- to people as well-compensated as Googlers -- a single $125 bonus isn't worth the overhead of negotiating; it's much more effective to just be "nice" and do stuff for people who need it, gathering the occasional peer bonus and lots of kudos, as well as building the network of people who will offer support at promotion time and/or help you out when you need it.
The effect is the same: it incents employees with special skills or access or knowledge to help their peers, but makes it more of a "gift economy" where everyone tries to be helpful to others in expectation of eventual good karma coming back to them, rather than one of barter and bargaining in which people jealously protect their advantages.
Management didn't "freak". [...] Erica Baker's manager wasn't happy about it
For a Googler, your ability to reason logically, be critical and optimistic at the same time, and tersely state balanced, affect-free facts based on data, is weak.
"One front-line manager" != "management". The latter implies higher levels of company leadership.
Wow, a $125 spot bonus will get you maybe a day's worth of meals (3+starbucks) in the valley.
Spot bonuses are generally much larger than $125. The spot bonuses I've received have been several thousand dollars each. Peer bonuses are $125. And Googlers don't pay for meals:-)
(I do pay for my meals, but that's because I work remotely. So I don't get all the on-campus perks... but I also don't have the insane cost of living.)
But that doesn't fit the "boo hoo sexism" narrative!
It's orthogonal to that narrative. It could be that Erica's manager decided not to give her the bonuses because she's a woman, or because she's black, and the other manager decided to give her colleague the bonuses because he's a man, or white (assuming he is -- I don't know, but it's probable given the demographics). Or not. Given the vast array of possible reasons for the two managers to choose differently, I don't see any reason to assume it's because they're bigots. My wild guess is that her manager was annoyed by the spreadsheet and the other guy's manager thought it was cool, so her manager found reasons in the rules to reject her bonuses until beaten down by the volume, and the other manager approved them all.
Seems far more likely than sexism or racism to me. But I could be wrong. We don't know, and never will.
Management didn't "freak". The spreadsheet in question is alive and well, and Google employees continue adding their information to it (I did). If management really wanted gone, it would be taken down. Erica Baker's manager wasn't happy about it, and she was invited to talk to her manager about it. It may or may not have bothered someone above her manager; Erica doesn't know and neither do we.
Her manager also chose to interpret the peer bonus rules such that the bonuses peers sent her forward weren't given to her. That's at least partly correct on her manager's part. The peer bonus rules say that any given action/effort can only be rewarded once. If the manager feels that it was a really valuable contribution the manager can choose to discard the peer bonus ($125) and instead award a larger spot bonus (amount variable), but only one peer bonus per act.
What is a little bit weird was that Erica said peer bonuses were rejected before one was approved, so the rejections before the approval weren't due to the one PB per action rule. Also weird is that Erica said her colleague got multiple bonuses for the spreadsheet. That shouldn't normally happen.
Even better, move all applications to the web, so everything runs on central servers which are much easier to manage and secure than a fleet of personal computers. Give users Chromebooks or another thin client configuration and don't let them install software.
This is presumptuous. You're a security guy. You don't know enough about the myriad and varied work the company's employees do to make birght-line rules about how they must do it. Nor will you with any amount of training.
You're presumptuously assuming that I don't understand that there are exceptions.
The approach I recommend will, however, work for the vast majority of employees, assuming the necessary apps exist or can be built (or front-ended... ick, but it sometimes is the best option). Then, with the majority use cases out of they way, the security team can turn their attention to dealing with the special cases -- isolating them, locking them down to the degree possible and monitoring what can't be locked down. Or, in really special cases, training the users and making them responsible for their own security. That last tends to be the best option with developers.
The solution, which security people hate to hear, is to get better at installing and maintaining multiple levels of firewall
Firewalls are not a solution. They're a small piece of a solution, but that's all. Firewalls segment networks, which is good because it reduces the scope of the attacks that have to be considered, but any good security design should assume that attackers will be able to get onto any network that has users.
application sandboxing and/or streaming applications for all office applications
Even better, move all applications to the web, so everything runs on central servers which are much easier to manage and secure than a fleet of personal computers. Give users Chromebooks or another thin client configuration and don't let them install software.
improving intrusion detection
IDS is good, but primarily for reducing the duration of an intrusion and trying to estimate the scope of the damage. IDS almost never reacts quickly enough to stop an intrusion.
dynamic virus removal in real time
Preventing the installation of viruses is far better than removing them.
NOT training users not to download suspicious executables
If the users can't install and run what they download, then it doesn't matter what they download.
or engage in fantastic feats of memory regarding passwords.
Totally. Most enterprise password policies are ridiculous. High-entropy passwords are neither necessary nor sufficient for securing systems. Multi-factor auth is more secure, and makes it possible to set reasonable password policies. Say, eight characters, alphanumeric, maybe require one non-alphanumeric symbol. Annual rotation is good, unless there is some reason to believe the password may have been compromised. Users can deal with that.
Three-factor authentication is great, and not actually all that difficult. One factor is the password. Another is some sort of one-time password generator or, even better, a USB dongle that requires user activation (OTPs can be phished -- a user you can social engineer into giving you their password will also give you an OTP, in fact it's even easier to phish an OTP than a normal password). The third is a client-side digital certificate installed on the machine after verification that it complies with corporate security policies. Use Puppet or similar to not only keep the machine up to date, but identify if it gets out of date and if it does, revoke the certificate.
Another crucial key to successful security is single sign-on. I can remember one moderately good password easily. Require me to know several and I'll have to write them down or reuse the same one everywhere. If I reuse the password we have none of the security benefits of multiple passwords and all of the password management headaches. So users should have one, strongly-secured, account that crosses all company systems. This is another benefit of web apps over local applications: You can secure all of your web apps behind a single set of authentication credentials by deploying them behind a reverse proxy server. That server handles authentication and provides a signed, time-limited user ID token to the systems it fronts.
Also, it's worth pointing out that commercial shippers do insure their transport vehicles. Though larger entities (like UPS) almost certainly self-insure, since they can absorb the risk at lower cost.
Slashdot Mirror
Most states allow deadly force for forcible felonies, and include burglary. The rationale there is that the house may not be empty, and so there may be human lives at risk. It's a reasonable choice.
So, in Missouri, not only can you shoot someone for simply breaking into your house while you're home, after January 1, 2017, you can also shoot them in the back as they run away.
This is even more wrong.
They have the right. Doesn't mean they choose well.
Rate me -1 troll, but I think it's hilarious that "the science fiction future" for which everyone is optimistically hoping is being brought to us by something so prosaic and "dirty" and anti-utopian as murdering people.
Clearly, we need a major war which absolutely requires that every soldier be equipped with a personal jetpack.
Discharging any weapon in a populated area except at a proper range or in defense of your life is generally illegal and a very bad idea.
Often illegal, yes. Firing birdshot into the air is not dangerous. That's why we use shotguns and birdshot to shoot birds. From the air. Birdshot's terminal velocity is low enough that by the time the shot falls to the ground it's not dangerous.
I dont know about Kentucky, however in Texas you can shoot people for Criminal Trespass. You can use deadly force to protect your self and your property.
Texas is the only state that allows deadly force to be used in defense of property. This is a case where Texas is wrong and the rest of the country is right. I'm all for the right to keep and bear arms, I carry daily and am a certified concealed weapons instructor. But deadly force should only be used to defend people, not stuff.
Every redneck knows how: Just clean it.
Only fools try to clean or work on their weapon without unloading it.
This.
Further, even after you've unloaded it you should still obey the golden rule of gun safety: never point it at anything you don't want to destroy. If what you're doing requires breaking that rule, first disassemble it so it's no longer a gun. Then, and only then, can you stop worrying about where you're pointing it.
The reason for this is that most people who hurt themselves or others while cleaning their gun *did* unload it first. Or thought they did.
Relatively little of what teens do is going to cause them problems in later life. It's what people do between about 18 and 25 that tends to screw them. Mainly because they're old enough to drink (without having to hide it) but not yet old enough to think (well).
Whatever you do you are still being tracked by default, that is the point of Chrome.
Do you have any evidence to back that claim up?
There are a number of features in Chrome that optionally talk to Google. But you can change them all if you prefer. Do you have any proof that it "phones home" in any hidden way? It should be quite easy to prove; Wireshark is all you need.
FWIW, I know some of the guys who started the Chrome project. Actually, they didn't start Chrome, they started V8. The point was to prove that Javascript engines could be orders of magnitude faster than they were, and to push the rest of the industry to get better, so Google's apps would be able to do more, faster. The rest of Chrome was just to show off V8. Then it became successful, both at pushing Javascript engines to get better, and as a popular browser, and Google started to use it as a test bed for other ideas about how to make the web "platform" better. Security improvements like certificate pinning. Performance (and security) improvements like SPDY and QUIC. UI simplifications like the omnibox (which geeks like to hate, but non-geeks love). Better development tools (though Firebug was and is quite good). And so on.
I don't think "better tracking of users" has ever been a goal, stated or unstated, of the Chrome project. And, seriously, why would it? It's not like the normal web standards don't offer everything that's required for whatever tracking anyone would like to do.
Trial and error, I expect. Look at what other sites do. I realize that this isn't a very good answer. There isn't a good answer, just bad answers that are still better than passwords. Classic OpenID isn't the answer because users don't know how to use it and many RPs don't trust random providers. But as a practical matter providing login with, say, Google, Facebook, Yahoo and AOL will give better than 95% of your users the ability to log on with better security than the password-based model you'd build, and do it just by clicking a couple of buttons.
If you find that your user base tends to have an account with some other provider (no, I can't tell you how to find out who your users are or what they use), then add that.
When the services go down, you can't log in to the relying sites. Luckily, core infrastructure like the account systems is a very high priority for the engineers, and the big providers have plenty of resources to keep them up -- and they do. My bank's site is down far, far more often than Google's auth servers, for example. How much more often? I don't know... I've never seen Google's auth servers down.
Pick the top several and you'll cover nearly everyone. For the tiny percentage of users that remains, you have to either offer password auth (which means all of the work and risks of maintaining a password system, but at least when you screw it up only a tiny percentage of your users will be affected) or push them to get an account with one of the providers you support.
Copy/paste cache scrapers exist, and are common for browsers with bugs. Training people not to copy/paste passwords is a good idea.
You're promoting perpetuating a long-standing, widespread and hugely-damaging user security error in order to avoid a relatively obscure problem which can actually be fixed through purely technical means. Not a win.
What you describe as a problem is actually part of the solution. The problem with classic OpenID was that it was virtually impossible to get, say 1st Bank of MyButt, to use it, because absolutely anyone could be an identity provider. I personally agree with you that classic OpenID was better in that respect, but 1st Bank of MyButt doesn't. They're hemming and hawing about letting Google manage their user's identities, but they will at least consider it.
But the poster worked as a security consultant for 10 years! And now works for Google, he can't possibly be wrong!
He's probably even written white papers on the subject!
Heh. Your snark falls rather flat, given how egregiously wrong the parent was.
You're actually very wrong. Long complicated passwords are horrifically impossible to remember causing people to write them down or store them in managers with simpler passwords to open the manager.
Putting them in password managers is the right thing to do.
Length is all that matters for passwords. You're better off with "thatswhatshesaid" (26 ^ 16) than "B4c0nL0v3r!" (72 ^ 11). You're 162 times better off, in fact.
26 ^ 16 = 43,608,742,899,428,874,059,776 72 ^ 11 = 269,561,249,468,963,094,528
https://xkcd.com/936/
You're wrong. Hilariously so.
The entropy of "thatswhatshesaid" is far lower than 43,608,742,899,428,874,059,776. Randall Munroe calculated correctly in the XKCD comic, of course. He didn't assume that each letter was random, he assumed he was choosing four words at random from a dictionary of a specific size (about 2048 entries == ~11 bits of entropy per word). Your password is clearly not a selection of randomly-chosen words, and even if it were, it would likely have been from a much smaller dictionary.
This highlights the danger of asking users to pick passwords... even those who think they know what they're doing are likely to screw it up. Munroe's advice in 936 was good... but I think it has mislead more people than it has enlightened.
No, it's much better to use a password manager and let a computer pick large random passwords for you.
If your password is "OPnuo(I&n hKUYNB68IOnih4wOIB*GBi234t73" as it should be,* then yes...
Parent was modded funny, but this is what your passwords should look like -- long and random, and typing them is a PITA. Any web site that disables pasting or prevents your browser or extensions from auto-filling passwords is broken. The sad thing is that most sites that do this (other than those that do it by accident because the devs are clueless) do it because they think they're increasing the security of their users' accounts. They're not.
Solutions like LastPass et al are the best, but honestly just using your browser's password database is better than reusing passwords everywhere. And Chrome and Firefox (at least, perhaps others) offer the option of keeping your passwords synced to all of the devices you use, optionally protected with a master password. Browsers need to offer password generation as well. I think some are working on it.
Of course, the real solution is to get rid of passwords. Web sites should switch to using OpenID authentication. Yes this means that most users will use their Facebook or Google logins, which means that, essentially, the site has outsourced its account security to those other entities. So what? If the developers of random web sites think they can do a better job of account security than Google or Facebook -- they're wrong . I work for Google and previously spent a decade as a security consultant in the financial industry and after seeing how they all work from the inside, I would feel much more secure about my bank account if I could use my Google account (with 2FA, plus all of the analytics and monitoring Google does) to log into it rather than trusting the bank to do a decent job with password-based security. I haven't seen Facebook's infrastructure, but I know people who work there, and they're good. Far better than you'll find at a typical bank, much less J. Random Web Developer.
And the community doesn't respond well to these or any other criticisms. They like the random element, they don't seem to give a crap about characterisation, world build, lore or story telling.
FWIW, I'm not a member of the community. I play Wesnoth off and on for a few weeks every couple of years. I also like the random element and don't much care about characterization, world-building, lore or storytelling. Not that I don't like those things, just that Wesnoth is more of an occasional light diversion for me, so those things don't mean much.
And why shouldn't they allow peer bombs? If the work was so great, then it more than justifies the $625 (5 people).
Sure, it does, which is why managers convert such things into spot bonuses -- which are generally several thousand dollars.
The downside of rewarding primarily with peer bonuses is that it might create a culture of doing good stuff for peers in order to collect peer bonuses rather than doing good stuff for peers because it's abstractly good to do good stuff for peers. I don't know how real it was or was not, but I have heard that some obnoxious Googlers with special skills or access or knowledge made a habit of demanding multiple peer bonuses before being willing to do some task for some other team that needed it. The "one bonus per" rule pretty much eliminates that because -- to people as well-compensated as Googlers -- a single $125 bonus isn't worth the overhead of negotiating; it's much more effective to just be "nice" and do stuff for people who need it, gathering the occasional peer bonus and lots of kudos, as well as building the network of people who will offer support at promotion time and/or help you out when you need it.
The effect is the same: it incents employees with special skills or access or knowledge to help their peers, but makes it more of a "gift economy" where everyone tries to be helpful to others in expectation of eventual good karma coming back to them, rather than one of barter and bargaining in which people jealously protect their advantages.
Management didn't "freak". [...] Erica Baker's manager wasn't happy about it
For a Googler, your ability to reason logically, be critical and optimistic at the same time, and tersely state balanced, affect-free facts based on data, is weak.
"One front-line manager" != "management". The latter implies higher levels of company leadership.
Wow, a $125 spot bonus will get you maybe a day's worth of meals (3+starbucks) in the valley.
Spot bonuses are generally much larger than $125. The spot bonuses I've received have been several thousand dollars each. Peer bonuses are $125. And Googlers don't pay for meals :-)
(I do pay for my meals, but that's because I work remotely. So I don't get all the on-campus perks... but I also don't have the insane cost of living.)
But that doesn't fit the "boo hoo sexism" narrative!
It's orthogonal to that narrative. It could be that Erica's manager decided not to give her the bonuses because she's a woman, or because she's black, and the other manager decided to give her colleague the bonuses because he's a man, or white (assuming he is -- I don't know, but it's probable given the demographics). Or not. Given the vast array of possible reasons for the two managers to choose differently, I don't see any reason to assume it's because they're bigots. My wild guess is that her manager was annoyed by the spreadsheet and the other guy's manager thought it was cool, so her manager found reasons in the rules to reject her bonuses until beaten down by the volume, and the other manager approved them all.
Seems far more likely than sexism or racism to me. But I could be wrong. We don't know, and never will.
Management didn't "freak". The spreadsheet in question is alive and well, and Google employees continue adding their information to it (I did). If management really wanted gone, it would be taken down. Erica Baker's manager wasn't happy about it, and she was invited to talk to her manager about it. It may or may not have bothered someone above her manager; Erica doesn't know and neither do we.
Her manager also chose to interpret the peer bonus rules such that the bonuses peers sent her forward weren't given to her. That's at least partly correct on her manager's part. The peer bonus rules say that any given action/effort can only be rewarded once. If the manager feels that it was a really valuable contribution the manager can choose to discard the peer bonus ($125) and instead award a larger spot bonus (amount variable), but only one peer bonus per act.
What is a little bit weird was that Erica said peer bonuses were rejected before one was approved, so the rejections before the approval weren't due to the one PB per action rule. Also weird is that Erica said her colleague got multiple bonuses for the spreadsheet. That shouldn't normally happen.
Even better, move all applications to the web, so everything runs on central servers which are much easier to manage and secure than a fleet of personal computers. Give users Chromebooks or another thin client configuration and don't let them install software.
This is presumptuous. You're a security guy. You don't know enough about the myriad and varied work the company's employees do to make birght-line rules about how they must do it. Nor will you with any amount of training.
You're presumptuously assuming that I don't understand that there are exceptions.
The approach I recommend will, however, work for the vast majority of employees, assuming the necessary apps exist or can be built (or front-ended... ick, but it sometimes is the best option). Then, with the majority use cases out of they way, the security team can turn their attention to dealing with the special cases -- isolating them, locking them down to the degree possible and monitoring what can't be locked down. Or, in really special cases, training the users and making them responsible for their own security. That last tends to be the best option with developers.
The solution, which security people hate to hear, is to get better at installing and maintaining multiple levels of firewall
Firewalls are not a solution. They're a small piece of a solution, but that's all. Firewalls segment networks, which is good because it reduces the scope of the attacks that have to be considered, but any good security design should assume that attackers will be able to get onto any network that has users.
application sandboxing and/or streaming applications for all office applications
Even better, move all applications to the web, so everything runs on central servers which are much easier to manage and secure than a fleet of personal computers. Give users Chromebooks or another thin client configuration and don't let them install software.
improving intrusion detection
IDS is good, but primarily for reducing the duration of an intrusion and trying to estimate the scope of the damage. IDS almost never reacts quickly enough to stop an intrusion.
dynamic virus removal in real time
Preventing the installation of viruses is far better than removing them.
NOT training users not to download suspicious executables
If the users can't install and run what they download, then it doesn't matter what they download.
or engage in fantastic feats of memory regarding passwords.
Totally. Most enterprise password policies are ridiculous. High-entropy passwords are neither necessary nor sufficient for securing systems. Multi-factor auth is more secure, and makes it possible to set reasonable password policies. Say, eight characters, alphanumeric, maybe require one non-alphanumeric symbol. Annual rotation is good, unless there is some reason to believe the password may have been compromised. Users can deal with that.
Three-factor authentication is great, and not actually all that difficult. One factor is the password. Another is some sort of one-time password generator or, even better, a USB dongle that requires user activation (OTPs can be phished -- a user you can social engineer into giving you their password will also give you an OTP, in fact it's even easier to phish an OTP than a normal password). The third is a client-side digital certificate installed on the machine after verification that it complies with corporate security policies. Use Puppet or similar to not only keep the machine up to date, but identify if it gets out of date and if it does, revoke the certificate.
Another crucial key to successful security is single sign-on. I can remember one moderately good password easily. Require me to know several and I'll have to write them down or reuse the same one everywhere. If I reuse the password we have none of the security benefits of multiple passwords and all of the password management headaches. So users should have one, strongly-secured, account that crosses all company systems. This is another benefit of web apps over local applications: You can secure all of your web apps behind a single set of authentication credentials by deploying them behind a reverse proxy server. That server handles authentication and provides a signed, time-limited user ID token to the systems it fronts.
Also, it's worth pointing out that commercial shippers do insure their transport vehicles. Though larger entities (like UPS) almost certainly self-insure, since they can absorb the risk at lower cost.