And this is why the incredible Hulk is, and will always be our greatest scientist.

It's not like the government has a monopoly on mismanagement and failure.

http://www.statisticbrain.com/startup-failure-by-industry/

Success is hard anywhere you go.

If I recall correctly, the Donner Party didn't undertake cannibalism because it was entertaining or educational.

And while arguments can be made against the necessity of killing animals for sustenance - there are many mechanisms that we employ to make life better on what ultimately ends up on our dinner table. (Free range whatnot, humane slaughtering, etc)

With regards to the question about becoming your own signing authority - it's not that difficult really from a technical standpoint. If you've ever generated a self-signed certificate you've satisfied the most basic mechanics of the operation.

The rub is getting your root certificate onto clients. A good example of this is the process that Microsoft requires - you must have infrastructure that meets certain criteria with regards to security (physical and digital), submit to third party auditing once or twice a year, etc etc. None of which is very difficult as long as you have the money and tick off all the boxes on the checklist.

However, consider for a moment that it's not just Microsoft you have to deal with, but Apple, Firefox, Opera, Chrome/Google, Android, Nokia, WaWei(sp?), etc.

There's no guarantee that an application will utilize an OS-wide keystore, and in some cases they don't - but ship their own list of 'trusted root ca' certs.

So with each vendor that provides an application or operating system you have to then convince them that you're (1) trustworthy (2) a big enough player that they should even bother. And even then, what motivation do they have to do YOU the favor of shipping your cert? There's more than likely for lack of a better term "distribution fees", (rhymes with payola) to get your cert out there into the world.

An alternative to this is that you get an intermediate CA certificate from an existing CA (which negates any security you would bring to the table being a sub-root to someone else who could just create a cert pretending to be you) - but there's very little motivation aside from providing a skeleton key to your certs as a root ca because if you're reselling certs that's less certs for them to sell anyway.. why would they dilute the market like that?)

Long story short - the SSL certificate business is essentially a money printing operation that if you want a slice of, you'd need to grease a lot of palms (some of which are probably ungreasable), spend a lot of money.

This will likely never change because there's no motivation for existing players to change it and plenty of motivation for them to keep it as is.

If you want the security of rolling your own keys and don't have the infrastructure to deploy them to clients through an installer (i.e. you're an online vendor that accepts 'walk-in' internet traffic) - you're screwed.

If you run your own network and want to provide SSL services without using any upstream providers - just make deployment of your cert part of machine imaging / bring-up / maintenance.

If they really were thinking about customers, the contract would be a no-penalty cancel-anytime-you-want contract that would lock you in for a specific price for a non-trivial amount of time.

I'm skeptical and will stick with AT&T out of laziness for a while. Prove me wrong T-Mobile and I'll switch. But even though cellular has been one-sided customer-screwing contracts since the inception of the service - contracts can actually protect _both_ parties if you do them right. No contract == No guarantee.

Yeah - when the user tells the browser where to go.

Javascript being able to run off and talk to whoever it wants? And that being an expected pattern?.. That's different.

Web-browsers being able to both open socket connections to arbitrary remote end-points, and be listening / processing data for incoming connections?

Worst idea ever. If anything ends up being responsible for destroying the internet - this is it. It's just going to be a giant mesh of infected browsers constantly doing battle, like the dust-clouds of dead nanites from the Diamond Age.

You fucking web guys. Take WebRTC, Flash, PHP, JSON, Flash, native browser plugins and all the other half-baked non-standard make-it-up-as-you-go-along "technologies" and go fuck yourselves.

Either they're so lazy they don't care or they don't know how to get rid of them.

If you feel bad about circumventing their terrible business model, just wait until they're broadcasting commercials directly into your dreams.

And they laughed at me for wearing the tinfoil hat! Who's laughing now!

... Yeah. Windows admins usually are the uncontested experts about OSX and Linux malware ...

If your program is 'the kernel' then that qualifies as 'as bad as the division bug' && 'it's a big deal'.

I think the answer is basically just 'yes', regardless of the veracity of any of the claims in the article, regardless of what you may think of their practices or the quality of their product.

If you work in intelligence and you don't encrypt your email, you are a joke.

Sarcasm aside, drawing the distinction between why one would do this on a printer vs. why one wouldn't want to do it on a desktop UI.

The reason printers have less and less buttons (when possible) can more accurately be attributed to a cost-cutting feature (less buttons == less hardware to manufacture, less moving parts to replace when they break in the field, less warranty problems, etc). If you don't get bothered by having to hold buttons down to get them to exercise new behaviors - this is all fine and good.

If I had to click and hold anything for 10 seconds in a UI I'd find a new UI. While pixels are finite on a desktop, they're still free.

Lieberman Software, a security and identification software vendor.

Yeah. Sounds like a completely scientific report with no bias to me.

How do you like them executables, I got her PE header!

I'm not quite sure what the 'bug' here is.. First off, Apple's LDAP is 'OpenLDAP'. So. Is this a flaw in OpenLDAP or Apple's configuration for OpenLDAP?

Also.. LDAP is kinda like DNS, except most places don't secure it. To see this in action, download Apache LDAP Studio, connect to your friendly local LDAP server and start browsing around (without authentication).. Most times you can get an almost full LDAP dump from a remote server without authenticating at all. Generally the only 'protected' elements are the passwords. You can enumerate users, groups, etc.