Not really. Any government can get their state CA included in the windows root CA list just for the asking. OSX and Firefox are slightly more restrictive, but not in a useful way, they allow lots of state CAs as well.

This is a broad problem with the HTTPS system, too many unrestricted root CAs with no concern for realistic security scenarios.

This is not a good system, but it has nothing to do with Tunisia. The wikileaks cable you posted doesn't even talk about SSL, just about how using supported Microsoft software in the government will make the government more effective at everything, including domestic espionage.

The entire point of SSL is that you don't trust the network.

[citation needed]

NH is mostly a mixture of exurbs and retirement/vacation homes for Boston, so it's economic model is "leech of the city" and it's social safety net is "move to Massachusetts". California has nowhere to beggar-thy-neighbor to.

New Hampshire has the lowest birth rate in the nation, California's is above-average. Children are expensive but necessary.

Small states tend to do a better job getting their money's worth from the federal government. California is a massive wealth exporter to the rest of the country. The California federal tax/spending shortfall is about the same size as the California budget shortfall.

The problem with overtesting is that a positive test on someone with no symptoms or high risk factors gives you very little information, due to the risk of false positives.

There are lots of cures for cancer, most of them made by drug companies. They don't all work on every (or even most) types of cancer, but they generally either work or don't after some finite number of doses, then you stop taking them.

The reason there's no pill to fix heart disease isn't because the drug companies are hiding the secret cure in a warehouse next to the ark of the covenant, it's because heart disease is a result of decades of physical damage to an organ, all drugs are going to be able to do to a condition like that is slow the damage or reduce the consequences.

findstr isn't a powershell command, it's just a console .exe program that comes with windows.

The salt isn't a second secret, it's there to prevent the use of a pre-constructed rainbow table for the standard hash functions. Without a rainbow table, you can still do dictionary attacks of weak passwords--and there is no way to prevent this short of not using passwords for authentication. This only harms people who use guessable passwords and re-use passwords between sites.

I love how the article is equally fact-free, but makes sure to include several opinion polls.

At least in the US, take-home pay doesn't dominate the entire cost of an employee to a business. Most of those costs don't scale down with less work. Think recruitment, most benefits, management, much office equipment/floor space, IT overhead, training...

Also, most employees not don't do fungible factory work anymore. Putting 25% more workers on a project doesn't get 25% more done. For any job with a high burden of communication or analysis (i.e. most knowledge worker jobs that aren't easily automated), every hour is more productive than the last up to the point the worker gets tired and quality drops.

If employees are actually working productively 40 hours a week (and not just seat-warming and fiddling with facebook because it's expected), then dropping to 32 hours would be a drastic reduction in productivity and would eliminate a whole lot of marginal workers and companies. (If they are just seat-warming, you could just let them go home but that wouldn't reduce unemployment)

If you want to do work-sharing without messing everything up, either figure out how to reduce per-employee fixed overhead (more cash pay, less benefits, more telecommuting, less ability to sue your employer, more off-job training... basically make everyone a contractor) or do it more long-term, like making working 4 out of 5 years the norm

Wikipedia made it official policy that all biographies are uncritical fan-sites years ago.

It would have automatically died yesterday along with everything else that didn't pass before the ending of the 111th Congress.

The chemical detectors false-positive on new electronics smell (they picked up a new GPS unit i bought) and don't detect PETN carried on the person (we know because the underwear bomber didn't get a second look). They have more accurate swab tests, but they only use them to let people who false-positive fly, not in a way that would catch anything. They're less a fundamentally bad idea than the nude-scanners, but still trivially defeatable.

We have an easier time studying airport security collectively than individually: The TSA has a 0% success rate at enormous cost. It is quite possibly the least effective security system in history.

This seems pretty reasonable; when you search for the name of a popular movie (for example), " torrent" is almost always one of the top autocomplete hits, and the results you get from that are usually garbage or worse. There's probably a ton of people getting trojans and viruses, or scammed, by these sites by mis-clicking. They're not making it any harder to access this stuff intentionally, they're not being filtered from the actual search results.

You're right, there is no objective way to say which is the "correct" google.com, you have to have some trusted body giving out monopolies on individual names. But that's not the problem that needs to be solved: the problem here is the body revoking names afterwards.

I think that it *is* possible to create a system where names are assigned permanently and can't be taken back. It might look something like this:

1. You buy example.com in the traditional manner from an untrusted legacy registrar.
2. You generate yourself a public/private keypair, and with it claim ".hash" or somesuch. These domain names won't collide and you can prove your ownership with a digital signature.
3. Any of several partly-trusted CAs signs a non-expiring DNS record pointing example.com to .hash.
4. Said CA retires their certs rapidly, say weekly, and publishes the entire list of signed DNS records somewhere publicly accessible. Each signature links to the next in a manner that proves they have signed no other records with that cert. (*)
5. You upload your signed example.com record to both the legacy DNS and a secure hash-based p2p network. (**)
5. You upload a regular, updatable/expiring DNS record for .hash into said network as well.
6. Upon doing DNS lookup, DNS servers ask the p2p network for valid, signed records; if they exist they are cached and the legacy DNS is not consulted. If not (or more likely in parallel), legacy DNS is asked and if a valid, signed *.hash redirect is found it's cached and reinserted into the p2p network (hopefully forever). Only if no signed records at all are found is the old, vulnerable record used.

If ICANN/the department of louis vitton/whoever tries to hijack the domain name, they'll only do so for users not on the new system. Upgraded users will ignore the change.
If the CA tries to make forged records to redirect your permanent redirect it will be invalid (if done after the fact) or publicly detectable (if done in advance).
If you're running a security-aware DNS client and your middle-tier DNS server is up to shenanigans the certs won't verify.

The best part is this could be done from the middle-out without the consent of ICANN or need to reconfigure client devices--you just need one upgraded DNS server anywhere in the hierarchy above you.

There is no possible after-the-fact ambiguity over who owns the name so long as all the CAs get together and promise not to re-assign an already used name (which would be detectable and should result in them being banned from making further assignments)

(*) I think this is a solved crypto problem and a workable solution is described in the 1996 version of Bruce Schneier's Applied Cryptography but I don't remember where I put it
(**) This is a theoretically a solved problem and mostly solved in practice

Given the state of Afghanistan infrastructure, it would probably cost more than that to excavate whatever pile of rocks fell on him circa December 2001.