There's a simple app to eliminate cel phone use while driving. It comes standard on every model of cel phone I know of, requires no sign-up and has a dead-simple user interface.

The app? The "silent" mode.

I think the fact that it's an American company being ordered to produce the data factors in here. The judge does have jurisdiction over the company, which makes it a different situation from ordering a company in another country to turn over data stored there. If you want to get out of a country's legal jurisdiction, you need to be out of their jurisdiction.

The problem is that you run into situations like one I ran into during the last security evaluation:

1. An e-mail from the company's HR e-mail address says that I need to click on a link within the e-mail to view information from HR that I'm required to review and respond to.
2. An e-mail from the company's HR e-mail address says that I need to click on a link within the e-mail to view information from HR that I'm required to review and respond to.

One of those is a legitimate message from an executive and failure to follow it's instructions will result in possible termination. The other is a fake from IT Security. I have described all significant differences in the messages. Now, tell me which one is which?

The above, in a nutshell, is the problem with most attempts to enforce security policy: the people making policy in the company ignore the security policies when deciding how to do things.

First off, stop worrying about passwords. Most malware doesn't get into systems by way of an attacker cracking passwords. It comes in in ways that bypass passwords entirely, either by getting a user to run it or by getting the user to give the attacker their password.

Second, look at your management culture. Do you expect your employees to routinely click on links in e-mail? Look for things like HR or IT sending e-mails that instruct people to follow links they've provided, or "secure" or "encrypted" e-mail systems that store the messages on Web servers and expect your employees to use a link to get at the contents of the "secure" or "encrypted" message. If you find such things, realize that you're training your employees to be insecure, because you're training them to expect to do as a normal part of their job exactly what the malware will need them to do to infect their systems. Start by removing such things from your management culture. If you need encrypted e-mail, do it within your own e-mail system so that users never need to follow links to read encrypted or secured e-mail. Outlook and Exchange offer this directly. If you need to give employees links to internal web applications or documents, create a Web page or site with a directory of links and train your employees to use a bookmark in their browser to access that site and navigate to the appropriate section where you'll put all the new links they need.

Third, look at your IT policies. Not the ones you wrote, the ones you expect employees to follow. If your policy manuals say "No user-installed software." but your actual policies require users to get and install software from outside, you have a problem. It can be as innocuous as sending zipped archives while not having a program to handle them pre-installed on user computers. It can be as pervasive as not having your IT able to support the myriad of tools your developers need, most of which will by definition not be the kind of thing most desktops would need. But every time you have a situation where what you expect of your employees requires software you didn't pre-install on their systems and where it'd negatively impact an employee's job performance and more importantly their performance evaluations if they refused to install that needed software themselves, you're creating security problems. Sit down and decide how you're going to address this, then address it. It can be as simple as a page of "approved" links to sites you know are safe and where employees can get all that useful software that gets used every day.

Fourth, evaluate your software update policies and IT budget and staffing. If your IT department doesn't have the staff or the budget to monitor the vendors of all the software in use in your organization, test changes and push updates out to your desktops and servers, you need to re-evaluate your IT budget and staffing levels. You need to get most updates installed within 30 days of their release, and you need to be able to get major critical security updates analyzed, tested and deployed within 24 hours. Your IT staff can't do that if security updates are a side item they're expected to handle in between doing everything else. If management wants security to be a priority, they need to back up their words with the resources and budget departments need to make it a priority.

Yes, a lot of that comes back to management. Attitudes towards security come from the top. More importantly, they come from what those at the top do and expect rather than from what they say.

I'm minded though of a saying: "The superior pilot uses his superior piloting judgement to avoid needing to demonstrate his superior piloting skill.". The study tends to bear that out too, as they comment that the decline disappears when you look only at the end results (the score). And in the end, if you're better at juggling dozens of things at once and react faster than your opponent and consistently lose to him, you're consistently losing to him.

That, though, is talking about the development environment itself. Yes, there the developers should be in control of the machines. DevOps, though, is about having developers actually doing operations tasks in the production environment. That's a bad thing, because what developers are good at is very very bad in production. You don't want developers alpha-testing code and fixes where a failed test brings all of your customers to a screeching halt while the developer does a few more iterations to get his fix working right. Plus, frankly most of Operations is boring and tedious (or at least it should be) and as a developer I have little or no interest in making it my day job. I want to solve the problem of making the deployment scripts bulletproof and go on to the next problem, not spend my day watching instances spin down and up (because if I did my job right, that's all the Ops people are going to need to do).

The difference is between developers knowing the operations side and being the operations side. Developers need to know the operations side to know how to write software that Ops can install and manage. And they should be involved in the development environment and installation in the testing environment so any gotchas can be addressed quickly and the developers know exactly what happened and can go back and make sure it doesn't happen again (especially in production). And of course when things really go pear-shaped during production deployments it never hurts to have the developers on tap to tell Ops whether there's a simple, quick workaround that'll salvage the deployment or whether it's time to roll back until they can fix the problem. But those are a far cry from developers doing Operations support and administration work on a daily basis. Frankly they're two radically different skill-sets. They're related, sure, but having a developer doing Ops as a regular job is like having Kelly Johnson keeping a fleet of Piper Cubs in shape. Sure he can do it, and technically he can probably do it better than a regular mechanic, but in a month or so he'd be bored to tears and walking out to go work somewhere where they'd actually let him do his job designing and building planes like the SR-71.

This doesn't really change it, because think how a proprietary SSL library would've handled this. The vulnerability was found specifically because the source code was available and someone other than the owners went looking for problems. When was the last time you saw the source code for a piece of proprietary software available for anyone to look at? If it's available at all, it's under strict license terms that would've prevented anyone finding this vulnerability from saying anything to anyone about it. And the vendor, not wanting the PR problem that admitting to a problem would cause, would do exactly what they've done with so many other vulnerabilities in the past: sit on it and do nothing about it, to avoid giving anyone a hint that there's a problem. We'd still have been vulnerable, but we wouldn't know about it and wouldn't know we needed to do something to protect ourselves. Is that really more secure?

And if proprietary software is written so well that such vulnerabilities aren't as common, then why is it that the largest number of vulnerabilities are reported in proprietary software? And that despite more people being able to look for vulnerabilities in open-source software. In fact, being a professional software developer and knowing people working in the field, I'm fairly sure the average piece of proprietary software is of worse quality than the average open-source project. It's the inevitable effect of hiring the lowest-cost developers you can find combined with treating the fixing of bugs as a cost and prioritizing adding new features over fixing problems that nobody's complained about yet. And with nobody outside the company ever seeing the code, you're not going to be embarrassed or mocked for just how absolutely horrid that code is. The Daily WTF is based on reality, remember, and from personal experience I can tell you they aren't exaggerating. If anything, like Dilbert they're toning it down until it's semi-believable.

Just because the time limit has been raised, that doesn't incur a liability for the debt on the part of anyone who isn't already liable for it. And generally children aren't liable for their parent's debts unless their signature's on the contract. The parent's estate might be liable, but good luck collecting from that once the estate's finalized and closed out. I suspect this'll be what any competent attorney will raise as an issue if the victims get one: "Regardless of anything else, this is not my client's debt and the debt being collectible doesn't on it's own make my client liable for it.".

So, Zynga's racking in the bucks, then?

True, but I've noticed that the F2P games that use that model are now trying to entice players back into monthly subscriptions. I think it's inevitable: if all you can buy is cosmetic, there's no real incentive to spend much money at all and the company starts wondering where all the cash they were supposed to be getting is. I'm of the opinion that the whole "free to play, and we'll make our money off the cash shop" is right in there with "free site, and we'll make our money off the advertising" as a business model.

The attitude stems from something more basic. In conventional games, even bad ones, once you have the game you have everything and how well you do is then up to your own skill and ability. In many free-to-play games, though, the game itself is just the hook. Once you're in, you find that you can't, for all practical purposes, go beyond a certain point without spending money and how much further beyond that you can go depends on how much you can afford to spend. It's why the derisive term is "pay-to-win". In large part how well you do in that type of game doesn't depend on your skill or ability, it depends on how deep your wallet is. And a lot of gamers are offended by the idea that a skilled, knowledgeable player who happens to not be that well-off will by design be less successful in the game than an unskilled, not-very-good player who happens to have well-off parents who'll toss him a couple of hundred dollars a week to fund his entertainment.

How do you figure?

Well, the Federal courts ruled that Proposition 8 violated the Due Process and Equal Protection Clauses of the US Constitution. That sounds like "unconstitutional" to me. The 9th Circuit panel affirmed that ruling, and the en banc appeal was denied. The US Supreme Court heard the appeal and dismissed it on standing, and ordered the 9th Circuit to dismiss the appeal to them as well (which Prop 8 supporters should consider a good thing because had the SC left the 9th Circuit's affirmation in place it would've created binding precedent for the entire 9th Circuit, but the dismissal order reverts it back to a district court decision).

So, question: what does a company do with a senior executive who's harming the company because large numbers of valuable employees and executives don't want to work with him, or at a company where he's in charge, because of his political views? Nothing in California law requires individuals to ignore political views when deciding whether to associate with someone. And it seems to me that deciding to let someone go because he's causing too many other employees to leave is perfectly allowable. So what's a company to do in such a case?

As noted, it wasn't Linus that started the blow-up. It got to this point because Sievers was ignoring more professional, less blunt instructions about it. And yes I'd rather deal with Linus. Because if I pulled the kind of crap Sievers had I'd've expected to have my manager drop my final paycheck on my desk and tell me I had 5 minutes to pack my things and the nice gentlemen from Security would be escorting me out of the building, and no I wouldn't be receiving a separation package because I was being terminated for gross incompetence. I'd rather deal with a manager who'll chew an incompetent developer out for being incompetent, as opposed to one who'll just send off iteration after iteration of "professional" memos about the developer having a problem and never actually do anything about the problem. At least with Linus I could be pretty sure I knew exactly where I stood with him.

Then again, I've written code that did exactly the same thing Sievers' code did. But I did what Sievers should have done in the first place, hung it off on it's own specific enable flag so it couldn't be turned on inadvertently, because I knew it was going to bring the system to it's knees and that was something that should never be able to happen as a side-effect of something else.