I totally agree. I guess I didn’t make it as clear in my posting. I think that my enumerated list of issues to find falls into your category #1. Your category #2 problems are specific to the design of the browser and what it is trying to do and I mention this :

“There are certainly more vulnerabilities that are specific to the designs of the browsers or plugins but this is a good start. Eliminate these and the bar has been significantly raised.”

We are still in the mode of lots of category #1 bugs. You say they are typically easier to fix and I agree. But everyone with Quicktime installed and Java turned on is currently vulnerable and that is a category #1 problem. Let’s not throw up our hands that since we can’t fix #2 easily that we shouldn’t fix #1.

-Chris

While I agree that tackling the browser security, there are really two different categories of attacks/vulnerabilities we’re interested in that aren’t represented in your taxonomy.

1. Attacks against the integrity of the client machine/environment
2. Attacks against the integrity of the browser itself

Category #1 problems are implementation problems. Category #2 problems are architectural problems.

Attacks against #1 are in a lot of ways easier to fix. Fixing them doesn’t rely on any complicated understanding of HTML, Javascript, Java, browser security policy and whether it actually works, etc. Attacks that target these vulnerabilities are reasonably well understood, and while critical, they ought to be relatively straightforward to fix.

Attacks against the browser and its security model itself aren’t going to be nearly as easy to fix. First we’d have to actually understand the browser security model, and then we’d need to invent a time machine to stop from ever making the mistakes we did in HTML+Javascript integration that allow most/all of the browser integrity attacks in the first place.

Solving #2 requires changes to the protocols and the overall architecture of the browser security model, which I don’t expect to see soon.