> Notice the "if you are writing unprivileged code" predicate on that paragraph. > First, what do they mean, "if"? It's not 1998 anymore, and nobody is writing

> Notice the "if you are writing unprivileged code" predicate on that paragraph. > First, what do they mean, "if"? It's not 1998 anymore, and nobody is writing Java applets.* I think the intent is clarified by an earlier paragraph: The IPE rules are designed for code to handle untrusted code, including in applet containers and servlet containers, such as JBoss and Tomcat, and any libraries these containers may depend on, such as the Java core libraries. If you are writing Java core library code, or code that is used in a servlet framework, the IPE rules apply to you. If you are writing only desktop applications, applets, or servlets themselves, however, you can ignore the IPE rules. I think the author, trying to be fair and balanced, is conceding that there is a small amount of code, written by a few people, that is subject to the IPE rules, which complicate the writing of secure code. Does that mean that for the purpose of writing such code, Java is "as insecure" as C? He doesn't say that, or even suggest it; he's merely pointing out that it mostly doesn't matter, since very few of us write such code. > Java is categorically more secure than C. Notice how the article doesn't open with that statement? I did too The article is written very coyly and the author doesn't show his hand until the end. I started out tempted to have the same reaction you did, but then I got to this sentence in the third paragraph: We acknowledge that the number of rules for any domain is an interesting but not persuasive metric regarding the domain's security. Then I thought, okay, maybe this isn't as stupid as it looks, let's see where it's going.