Which gets to the root of the question: If they are allowed to force you to disclose the combination to a safe, is the password to a hard disk any different?

A judge can impose fines as a part of a contempt citation. I suspect that a $1,000,000 fine would be sufficient to force liquidating all or most of your assets.

It's an interesting question of whether a judge can force you to disclose the combination of a safe. Usually the police just force the lock because it's easier, but in principle, they should be able to force you to disclose the combination (if, for instance they have reason to believe there's an anti-tamper device on the safe).

I believe that "the crime of failing to give up your password" is actually the crime of contempt of court.

And that means that the jail sentence is essentially forever. They can literally put you in jail and seize all your assets until you give up the password.

If it's privacy focused, why is it that people don't get the ability to approve who adds them to their circle? There have been a number of people on G+ complaining about this already.

Actually many (most?) applications written for NT 3.5 will still run on Windows 7. Some set of applications need to have compatibility shims added (most of which come with the OS) but yes, they'll still run.

There's certainly a set of applications written for NT 3.5 that won't work on Win7. But that set is vanishingly small.

Ok, I've got to ask: Which people within the borders of Iraq attacked the US?

I totally support and supported the Afghanistan invasion for exactly the reason you listed ("Don't attack the US or let people who attack the US use you as a safe harbour"), and I oppose(d) the Iraq invasion for the exact same reason: As far as I know, nobody who was living in Iraq attacked the US and Iraq didn't harbour any of the people who attacked the US.

Umm... Flash is an ActiveX control.

There hasn't been an ActiveX vulnerability in a REALLY long time (like maybe a decade?). But ActiveX is a plugin technology. When people talk about ActiveX being insecure, they're really saying that plugins are insecure.

And guess what: Every browser out there (except iOS browsers) has a plugin model. There are only two things that make ActiveX plugins different from any other plugins:
      1) A web page can suggest an installation location to use for the plugin (unlike Firefox which recommends that you install plugins from their own site)
      2) ActiveX plugins are all digitally signed (on the internet). That means that it's hard for bad guys to deploy vulnerable plugins. This isn't a huge deal because bad guys just use vulnerabilities in existing signed plugins. And they can use #1 to point the user to plugins which have known vulnerabilities.

That's basically it.

There are two possible reactions to telling the IT guys about the exploit: (1) you give them enough information to harden their systems proactively (adobe flash scripting has a problem when dealing with flibberjabber elements) or (2) you give them vague information (there's a bug in flash somewhere).

The first is probably enough to give the bad guys enough of a clue for them to figure out the vulnerability and you've just created a 0day. The second isn't enough information for the IT guy to figure out how to protect their systems.

If there was a way for a vendor to tell only their customers about an upcoming issue, without letting the bad guys know, that's another thing. It's exactly why Microsoft created the MAPP which lets antimalware firms know about upcoming patches before they're released.

shutdown-p basically nailed it but I want to dig a bit deeper.

There is no such thing as absolute security. There is no software available to end-users that is 100% secure (there may be very special case scenarios but they're not mainstream). Because of this, security is primarily a risk management problem.

So when you decide to take a patch, you have to weigh the risks of taking the patch (it might break some LOB app) against the risk of *not* taking the patch (you might get hacked).

We make these choices every single day when we get patches from vendors. Sysadmins (who have to keep entire corporations alive) are very risk averse (deploying a patch which shuts down the accounting department is likely to be a career-limiting-move) and that means that they want to make sure that every patch is tested before they deploy it.

So when they see a patch, they need to weight the risks. There is *no* debate that the bad guys reverse engineer patches. They do. That means that once a patch is deployed, the risks of *not* taking it skyrocket.

If you release patches once every few days, that means that sysadmins are constantly putting their line of business apps at risk.

Somewhat off-topic: Every once in a while, someone at work asks about the benefits of moving some internal server from its traditional port to a new port (for instance moving the SMTP server from port 25 to port 9998). The purists always respond with "that's just security by obscurity", to which the pragmatists respond "yeah, but it works to remove certain classes of threats. It won't stop a dedicated attacker who's actively probing your ports, but for most automated attacks, it can be highly effective".

So yeah, a little "security by obscurity" helps.

Before the patch is made, many of these exploits are not widely known. Sometimes they are, but normally they aren't.

As I understand it, the risk is that once the patch is published, the bad guys reverse engineer the patch and publish exploits for those patches (usually within 6 hours). So if you delay patching after a patch is made, you put your machines at increased risk. So scheduling an update so that IT folks have time to react is a good thing.

The one exception is when the exploit is published *before* the patch is published. In that case, it makes sense to push an out-of-band patch and to hell with the sysadmins schedule.

Actually for the NTLM hash mentioned in the article, the maximum effective password length is 7 characters.

That's why the NTLM hash was replaced 15 years with NTLMv2 which doesn't have that weakness. And the NTLM hash has been turned off since Windows Vista.

There's no difference between XP and OSX w.r.t. bugs in imaging codecs (and OSX has had plenty of them). You can 0wn the machine with either.

The original assertion was that the OSX's sudo prompt was some how better than Windows UAC prompt or XP's mark-of-the-web. And realistically they aren't really that different.

I truely wish that were true. But if it were, there would be no malware for Windows Vista and Windows 7, since they also require that the user acknowledge a prompt before installation. And there would be no malware for Windows XP either (since it prompts users because a program downloaded from the internet might be dangerous).

Unfortunately a UAC prompt (or sudo prompt) doesn't stop the "I really want to see the dancing bunnies" problem - people will bypass any dialog box you put up to run their application. Consider the Bagle family of malware. They use a password protected Zip file for their payload and even though the user needs to enter the zip file's password, they *still* manage to propogate.

Yeah, and how long did it take Microsoft to harden Windows?

Back in the 1990s when you reported a buffer overflow to a company, their usual answer was "So what, it's only a theoretical vulnerability, it can't be used to attack our product - all you can do is crash my app, you can't get reliable remote code execution".

In the intervening 10 years, most companies no longer feel that way.

To me, the "speculative at best..." comment seems disturbingly familar to the old complaints about the buffer overflows.