Unlike with Lavabit, there's no single master key for TrueCrypt that can be gotten from the developers that'll decrypt any TC partition. The best the NSA could get is the ability to create their own signed binary package with their own modifications and have it appear as the official package on TC's site. The problem with that is that the TC code's open so anybody can build from source and compare with the official build and see that they aren't the same. And any compromise of the source (eg. weakening the cryptography) would be instantly revealed in the diffs. The whole NSL thing sounds dodgy, and doesn't quite fit. It seems more likely that, with Win7 and later moving to supporting only GPT disks, the TC developers found they can't add that support and decided to throw in the towel.

In any case, the version of TC from before this change is still available and as far as anyone can tell is still secure. I'd be leery of switching to other encryption software that's known to be less secure until someone comes up with a definitive vulnerability in 0.71.

They say developers will still be able to install locally. My guess is that if you enable developer mode (checkbox in the extensions page) you can still use local extensions like always.

Kaspersky AV installs it's extensions in Chrome, and frankly I a) don't want to depend on the Chrome Store for them since I can only trust them if they come directly from Kaspersky and b) don't want them disabled since I installed Kaspersky specifically for this purpose. I can see refusing to enable local extensions until the user confirms they ought to be there, but Chrome isn't the only source of browser components on my computer.

Ethanol's got a lower energy density (less energy per gallon) than gasoline. That's chemistry and there's no known way around it, to deliver a given amount of power you have to burn more fuel and the more ethanol in the mix the greater the difference. I do see a hit to gas mileage, it's not significant for highway driving (steady high speed) but it really starts to show up in city driving (lots of stop-and-start, lots of time in low gears for power getting the car moving). Ethanol's also got an oxygen atom in it's structure, which the components of gasoline mostly lack. That results in the same problem as with oxygenated gas: it looks like a leaner mix (more air per unit fuel) to the sensors in the engine, which results in the ECU setting the injectors to run richer (inject more fuel per cycle) to get the programmed ideal air/fuel mixture resulting in higher fuel consumption. Oxygenated gas was a great idea for carbureted engines, but it doesn't play well with modern EFI engines and I don't think there's been a model sold in the US since 2000 that isn't EFI.

Before the Navy goes this route, they need to sit down and read the short story collection "I, Robot" by Isaac Asimov. Everyone's familiar with Asimov's 3 Laws of Robotics. They seem reasonable. Yet, every story in that collection (and in fact most of Asimov's robots stories) is about how the 3 Laws fail in practice. If you want to try doing a better job of writing ethical rules for robots than Isaac, you'd better be familiar with how to work through all the ways those rules can backfire on you. For instance, that question of the soldier who needs traction to avoid death. If you write the rules to allow the robot to inflict pain to prevent worse, what happens when a unit's ordered into a situation that'll result in a lot of them dying and the robot decides that inflicting the pain of broken legs (which can be repaired) will prevent those deaths? That's entirely in line with the rule you gave it, after all...

I think in these cases it'd be even simpler: the letters don't actually spell out what part of the patent is infringed or how the recipient infringes it. It'd be the equivalent of sending a letter saying the recipient's violated a contract and has to pay penalties or face a lawsuit, without saying what contract, with who, or how the recipient's violated it. The state should be able to deal with that aspect of it without going anywhere near the patent itself, that kind of behavior should constitute bad faith even if the underlying patent's valid.

A lot of trolls do send out letters without any basis, because a lot of people will take a cheap settlement rather than spend the money to fight it, go through discovery and all it's costs, and get the suit dismissed. Take a look at the SCO v. IBM lawsuit, where the SCO executives were fairly explicit about not caring whether their claims would stand up or not because it'd cost IBM more to fight and win than to settle so they figured IBM would just settle. Anti-patent-troll laws aimed at this sort of vague accusation help because it forces trolls to be explicit up front about what they're accusing their victims of which gives their victims more opportunity to knock the accusations down early on before it gets expensive.

The problem is that if you do this, you remove all your slack. If you cut it to just enough people to do the work if they work 100% of the time, the first time someone calls in sick you don't have enough people to do the work. If you get a sudden spike in business because of a holiday or special, you don't have enough people to handle the extra work. If something goes wrong, you don't have anybody to assign to handle it without leaving you short-handed. And that's before you even get to the need for workers to take breaks during the day to avoid burning out.

It's the same problem that's plagued just-in-time delivery of inventory. Sure it saves money to have stock and raw materials delivered just as they're needed. But the moment a storm or a port strike or anything delays deliveries, you're in a world of hurt because you don't have any inventory on hand to tide you over. Sure it's saved you money, but it's made your business much more fragile and the costs of even one shut-down can easily eat up any savings.

Technically they didn't leak private files, because the files weren't ever private. They were public with the URLs not published in an index anywhere, so you had to know the URL to access them. Dropbox and Box simply forgot that those URLs would appear in HTTP Referer headers, exposing them in the logs of any site linked to from within those "private" documents. Security by obscurity... isn't.

A document isn't private unless it requires at least some kind of authentication to access it, eg. setting up HTTP authentication, or using a system like Google Drive uses where you have to be logged in on your Google account to see documents shared with you.

I've had good luck with an Ion cassette-to-USB deck for ripping an old tape collection to digital on the computer. They've got a VHS-to-USB one as well: http://www.ionaudio.com/products/details/vcr-2-pc.

Any standard that's effective and easy to use will not be accepted by the advertising industry, so making the "success" of a standard contingent on that last is nonsense. The DNT standard does serve one useful purpose whether or not it's accepted: it provides a single, easy-to-interpret, unambiguous indication to advertisers as to whether or not the user has consented to tracking. It removes their ability to say "Well, they didn't say otherwise so we assumed they're OK with it.". It does that whether or not they honor it, and it gives us a good talking point when it comes to policy and regulatory discussions: "The DNT standard exists. It's in use. It's easy to interpret on their side. They're the only ones sticking their fingers in their ears going "Na Na Na Can't hear you!".". That makes regulation an easier sell.

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.