We need to be clear about what EV is. It's not about SSL, it's about X.509. It doesn't solve a technical problem because EV identifies no technical problem with X.509 certificates. EV promises a procedural solution to a procedural problem, namely the failure by Certificate Authorities to take reasonable care to check the real-world credentials of certificate requestors in order to determine that they are who they claim to be. In effect, the CAs are saying, "Yeah, well, we were a bit negligent the last time around, but we promise to do a better job next time if you just pay us more money."

So I share your misgivings about whether EV has improved security, but for rather different reasons. And there's nothing saying that we both can't be right.

No big deal? You don't know what you're talking about.

Times may have changed since I used to play with Lego, but let me tell you what it was like. I didn't get an allowance until I was a teenager and even then it was only 25 cents a week. Mowing a lawn in those days was worth $1. Paper routes paid better, but the point is that none of this was available to an eight-year-old child whose creative imagination had exceeded what he could do with a small shoebox half full of bricks. When the smallest box of Lego bricks cost three bucks, any progress on that front entailed a lot of saving and self-denial in other areas.

My friends and I used to pool our collections, of course. Our ambitions weren't entirely frustrated. And we would often get them as gifts, which is how we had any sort of collection to begin with. But no matter how hard we tried, we never had enough to really do anything. So did we, at age eight, understand the value of a dollar? Oh yeah, you bet we did.

The world sucks. The code is in it.

Nicely said. It's true that code shares characteristics of the world at large because it exists to model that world.

Though I can't verify your premise that the world sucks, I can still enjoy it as rhetoric. Certainly the world is complex, and so our efforts to reduce that complexity to something more tractable will meet with varying success. Here are a couple of examples that go against the claims in TFA:

• When I was an undergrad, computer science was just starting to take off as a distinct discipline. Some excellent work had been done in theory of computation - because there is a strong meritocracy operating in the field of mathematics - but no such meritocracy had yet been established for the art and science of writing software. I saw a lot of code on the blackboard and in textbooks that, even to my inexperienced eye, was obviously flawed. The presentation was aesthetically unpleasant and stylistically not even self-consistent. Most of it wouldn't compile, much less produce the expected results. Even then I could do better. I met exactly one prof during those years who actually tested his code before presenting it to the class. So it's not automatically the case that "nearly every sample program in every textbook is a perfect and well-thought-out specimen." I'm sure the situation has improved, because our experience and culture and expectations have changed. I'm sure that it still falls short of perfection, because I can still find occasional errors in CS texts. Not every academic is a great programmer. Some of them are pretty dreadful.
• As concerns "software in the wild", I have the good fortune at the moment to be working at a stellar software development company. It blows my mind how good these guys are. That's not to say their code is perfect, but as something which is actively involving, it's well on the way to being perfect. As far as I'm concerned, it's as readable and engaging as a good novel. Programming idioms are gracefully executed and nothing seems out of place. It's cognitively consonant. I think it's an amazing human achievement that, in just one generation, we have become conversant to such a degree in this new medium of expression that the medium no longer gets in the way but lets the underlying ideas shine through.

If nature provided practically unlimited general computing power really easily, code would be frickin beautiful.

Ah, but it does. What is DNA if not code for operating a certain broad class of 3D printers? But as to whether the code is beautiful, who can say? We can only observe that it produces functional results for the most part. The very fact of its existence in such compact and enduring complexity is a sort of beauty, but is the code itself elegant, efficient, pretty, readable?

We know that most of the gene in a given strand of DNA are turned off. Does that mean that the code is inefficient, or are these sequences like the methods of an enormous class library, written by the brutal evolutionary hand of trial and error, now dormant but having the potential to be activated should appropriate conditions develop? Sure, we don't need gills today, but sea levels are rising.

If every Canadian threatened with legal action over Hurt Locker pirating were to tell the lawyers "I'll see you in court" they would go bankrupt in a hurry

The good news in this is that Canadians already have fair confidence that the courts will safeguard them against this kind of harrassment. The FUD program was never able to gain traction here before, and it's certainly not going anywhere now.

I can say from having worked in both private and public sectors that government is predictably not a first adopter of emerging technology. There may be occasional small bursts of innovation here and there, but overnment culture is highly conservative by nature.

You don't get points for taking risk with taxpayers' money. You do, however, get points for showing an abundance of caution which typically leads to endless meetings, signoffs, prototypes that nobody can be bothered to evaluate and reams of documentation that nobody will ever read. And so, taxpayers' money is still wasted, but you see, it's being wasted accountably. And in some sense this is preferable to simply going off the rails because of insufficient oversight.

But you can see why something like IPv6 is not getting fast-tracked by government. Hey, I was the only one among some thirty Network Administrators in my group to have actually done any actual network engineering. Most of my colleagues wouldn't be able to tell you the difference between an IPv4 and an IPv6 address. That's no exaggeration, I assure you. It's not that they're not earnest and hard-working. They're pretty good people. But not given to pushing the envelope, I'd have to say.

Here's a corner case that might help to define the space of possibility for people who want to maintain a durable technological career.

This is my 42nd year of writing software. After about five years of that, and halfway through an honors degree in CS, I had gotten seriously into systems programming, because it was cooler, deeper, more sophisticated, more interesting, and because in those days there was a such a painful lack of good development tools that to do anything else struck me as a waste of time.

In such a long career, I've gotten to try my hand at all kinds of wonderful things. I've designed global networks and programming languages. I've covered the range from architecture to operations, I've instrumented kernel code, written device drivers, and directed supercomputer facilities. I've worked in research, industry, and government. I've worked in several countries.

And I'm not particularly smart. This is the main point I want to make. I have a lot of breadth and depth to draw upon, but no brilliance. I reason carefully and explicitly rather than relying on brilliant leaps of intuition. I write beautiful code that's a pleasure to read and maintain. Very rarely is it clever or hard to understand, because among other things I'm committed to clear documentation, and there's nothing quite like trying to document a flawed design to make you want to go back and fix the design. So I think I represent an edge case for a certain kind of excellence that challenges the prevailing - and false - dichotomy between rockstar leadership and rockstar development. There is a middle way, and I bet that a lot of you are travelling on that way. But because it's not about drama, it doesn't call attention to itself.

This year, I'm working at a very cool place that's deeply committed to open source, and is rapidly making a name for itself in private PaaS. Compared to every other career experience I've had, the level of intelligence at this place is fucking off the scale. In this group, I'm nowhere near the smartest guy in the room. Yet, in their wisdom, the management here somehow picked me from among all the other hopefuls for this senior position.

So, here I am, surrounded by all this amazing talent, trying to keep up. To put a whole PaaS stack together is not a trivial undertaking, especially with evolving goals and such fierce competition in the industry. This in itself definitely constitutes another edge case. There's a need for real genius here, no question. We have to move forward very fast on several intersecting fronts, as fast as we can possibly go, and not trip each other up.

Somewhere near the intersection of these two edges is a zone of exceptional performance in which an abundance of genius is, I hope, tempered with something more reflective and methodical. Decades ago, I used to tell the young hotshots that it's no good designing something that nobody else can maintain. The group I'm in with today doesn't need to be told anything so obvious as that. They already get it. But still, their habits of thought cause them to be impatient, to miss details, to speed impulsively from one shiny new thing to another without regard for the turbulence left in their wake. I think this is probably a necessary cost for the kind of work we're doing. It may be necessary but it's not sufficient. You also want to keep everyone tuned harmoniously, make sure that the core areas are being solidly filled in, that reasoning is explicit, that risks are identified and mitigated, that we can sustain what we're doing and not become spread too thin.

I find that it's been hard to earn credibility in this group, particularly among the younger people, when you are not actively advocating for some sexy new thing. That's what they like to hear about, perhaps to a fault. And so, in my first couple of months, I was sniped at quite a bit more than I regard as proper to reasoned debate among professionals. What's interesting is that the situation is turning around. I'm winning these arguments. Why? Because, having no genius to defend, my ego is not at stake. I have superior social skills, so I meet the occasional little pissing contest with better grace (having already made my full share of mistakes in the past.) Now I'm only interested in getting at the truth, and that requires not much more than careful, methodical reasoning along with a certain measure of kindness.

And finally, some of the projects that I'm working on are finally spinning up in production. That's a fair test, isn't it? I think people were skeptical at first because I didn't dash off a quick and brilliant prototype as they would have done, but approached the design with quite a bit of forethought. I don't hear many "it will never work" assertions any more, given that everything is integrated, documented, and working perfectly.

Thank you for pointing out a flaw in my argument.

What I should have said was that your claim was akin to choosing at random from the original class population. What are the chances that you will pick a competent surgeon from among them, knowing that only 10% will graduate?

It's still not the case that this population is somehow more competent for being larger. But this seems to be exactly what you're claiming, that from a large school you'll pick any graduate, but from a smaller school only provided it had higher graduating standards.

Don't you see that, no matter how you slice it, the size of the graduating population doesn't matter? It could be a huge class or a tiny one, you're still going to be picking at random. This is the basis of statistical sampling.

So what your saying

"you're"

Numbers can be manipulated to make a lot of meaningless points. ... I think sheer numbers would qualify the Indian people as being representative among the most fluent.

Indeed, numbers can be manipulated, so that when they give rise to blatant nonsense in support of a self-contradictory assertion, no reasonable person would regard them as credible.

In any case, thanks for such a concise demonstration of both. According to your own claim, the Indian population has a 10% proficiency in English. If you want to infer that this makes them among the most fluent then you have an unusual concept of fluency. Will you apply this same concept when choosing a surgeon? First find the largest medical school in the world, then choose at random among the bottom 10% of the graduating class.

Oh, and don't forget to tell us how that works out for you.

That makes no sense. First of all, IT is simply not "paint by numbers", except at the most junior level. The surface of what IT undertakes to do is constantly expanding. Anyone with intermediate to senior responsibility in the field has to master a very broad corpus of knowledge concerning the performance, scalability, integration, fault-tolerance, security, and usability of hundreds of different subsystems interacting in complex ways.

This has to be done not only within the limitations of today's technology but in anticipation of what is likely to emerge in future. IT is therefore very much an applied science, just as software development is. The published literature in both fields makes this clear. You have to recognize what's possible, what's optimal, and what's elegant, because nobody will be telling you the right answers. You and your professional peers will be proposing solutions to the problems of the day, and finding ways of measuring them against each other. Only at the end of that process will you know the right answer. (This is called science, by the way.)

Some few of those solutions become standard practice that can be reduced to "paint by numbers" and taught at the trade school level. But one of the things that makes these fields so active is that, once such solutions are established, they tend to become automated and invisible. Attention shifts to a new set of challenges made possible by the preceding technology. So trade schools are fine as far as they go, but the knowledge they offer to someone working with computing and network infrastructure has a rather short shelf life. If you want enduring payback for your studies, you have to learn the science.

Um, thanks for sharing your ignorance.

Micro-managing I.T. is almost never wise.

Ain't it the truth? On the other hand, there is a lot of knowledge sharing to be gained from respectful listening. If you have weekly operations or status meetings, make sure that someone from IT is at the table. Everywhere I've been where that was the practice has been a pleasant and effective workplace. When systems are running well, they're essentially invisible, and this is a highly desirable state of affairs. It's quite the opposite of neglect, but if there isn't active communication about what's going on, how do you ever expect to tell them apart? (Until it's too late, of course, and the chronically-underfunded, under-appreciated infrastructure finally falls down hard.)

this goes against the process of using virtualized servers since you can't do physical segmentation on a virtual machine

Ah, but you can. Modern hypervisors (and this includes lightweight Linux paravirtualization containers such as OpenVZ) are able to provide a virtual network for the nodes running under it. Often they have fairly limited capabilities, but anything worthy of the name will support basic VLANs. That's to meet exactly your segmentation requirement.

I sympathize, but your answer tells me that you're determined to repeat the same failed approach to problem resolution.

I've told you one way to get out of that. Switch providers, if you can. Switch to a smaller outfit, one in your community, if you can.

Here's another way. If you're not making reasonable progress, escalate. To do this most effectively, you should proactively record your conversations with the provider and make sure it's accurately timestamped. If you hit someone intelligent and knowledgeable at Tier 1, congratulations. If not, waste no further time. Politely request an escalation. If they push back, politely repeat the request and mention that you are recording the conversation. If they drop the call, hit redial. Anyone at Tier 2 is about 10x as likely to know what you're talking about. And if that doesn't work, request a further escalation and again explain that you're recording the call "for quality assurance purposes." They all do it, so don't be shy.

How far can you take this? Well, the senior network engineers are about as technically proficient as you're going to find anywhere. I used to reserve about 10% of my time for designing test frameworks so that we'd have hard evidence when calling bullshit on the modem vendors. If you manage to get to me, I'll back you up. Though honestly, any Tier 2 or Tier 3 you get should be more than sufficiently experienced. They've taught me a few things I didn't know.

If the problem is not technical but a result of policy, then you can skip the Director of Operations and go straight to the executive level. But you have to have laid the previous groundwork or you won't be taken seriously. I was once spammed for about a year by a large telco. Not only did I keep meticulous records of my polite requests to desist (web forms, emails, phone calls) but at about month 3 I said, "Hey, I get it now. The reason you're not acting on my requests is because you think this is something other than a violation of your own Acceptable Use Policy. You must be requesting services from me. You want me to process these spams in exchange for a fee. No problem! For $100 per unsolicited email, I will read and evaluate the content and send a concise written summary to you at the end of each month. I will take further unsolicited email from you as constituting acceptance of these terms."

So it went. I sent in regular summaries and invoices to their legal address, until they had racked up about $10K in unpaid debt. As it happened, just then their VP of Operations went on national radio to allay some of the many customer service concerns being raised by the public. I called in and identified myself, explaining that they owed me $10K in unpaid fees for reading their spam, and would the VP be able to help me or should I take the matter to court?

I never got paid, and I never took them to court. But the spam stopped two days later and hasn't been back since. My point is, you have to get serious, and you also have some fun with this stuff or you'll just end up whining about it on Slashdot. And what kind of a life is that? You decide.

Um, yes. Grossman seems to insist on conflating the entire Internet with web browsers. A browser exploit is therefore prima facie proof that the Internet is defective by design. It's not surprising that he also conflates browser vulnerabilities with system vulnerabilities.

So you're right. His proposed solution, to replace a general-purpose browser UX with a bunch of dedicated clients, is what everyone else in the room recognizes as good old client/server. This is such a familiar design pattern that we can weigh in fairly confidently about its strengths and weaknesses relative to the current state of the art regarding the web.

Certainly the web is being asked to do vastly more than it was originally designed to do because (same story as always) people generally prefer convenience over security. Designing for the web is convenient. You don't have to deploy client applications or worry about platform compatibility. Whee! Such freedom to innovate.

And so you end up with phpMyAdmin. Remote system administration is fine, as long as it can be done securely. Never mind whether the admin agent is secure, how can you determine whether your end is secure, when in the same browser and user account you're configuring the server and playing Texas Hold 'Em?

Yes, there is a place for dedicated client apps. Was this ever in doubt? No, I didn't think so either. Brilliant indeed!

Perhaps she mean MAC address. I can imagine that happening to anyone in the middle of a long dreary shift.

I worked for a few years as one of the senior network operations guys at a company that provides customer support on behalf of various regional ISPs. This was in Canada, where the expectation when calling tech support is that you will find a fellow human being on the other end of the line, not a weary, disinterested or passive-aggressive drone.

We didn't run a sweatshop. Most of our senior people had come up through the ranks. We didn't impose scripts on people. What we did do was hold sessions every few months to find out what questions and issues the staff were hitting, discuss what were the probable causes and what could be done about them, and then work with the staff to get that information into their wiki. It was a good place to work.

And still there's a certain percentage of staff who come into work after a night of partying, or who have newborns at home, or who just broke up with the love of their life, or who are going to school part-time. So, yeah, sometimes they space out and say dumb things. Other times, they'd blow your mind with how perceptive they are.

I think the main difference between that and what you experienced would be found in attitude. It's really hard to like talking to support when they make you feel like a worm that got squashed on the bottom of their shoe. That's not a very concrete thing to file a complaint about, but in my opinion when you see that then the rest inevitably follows. And let me tell you, it does not have to be that way. I appreciate that often you don't have much choice, but try switching to a smaller provider if you can.