4 ms·

Why would something so existentially important such as a 'security model' be blocked at the code-level, let alone 'code being checked in'? Would that be someth

by jariel 6y ago

Why would something so existentially important such as a 'security model' be blocked at the code-level, let alone 'code being checked in'? Would that be something discussed long before anyone implements anything? It touches every part of the system and informs the very essence of the product.

ChuckMcM 6y ago
You know that phrase "Reality is complicated"? Smart people tend to over estimate their understanding of complicated subjects, and it irritates them when it appears you are making something more complicated than it "should be." Even though the error is their over estimation, not the complexity of the solution. If you combine that with their ego being unable to accept that something is more complicated than they assume, then you get the situation where they propose a solution that is simple, easy to implement, and wrong. Add to that a measure of "hurt" from feeling like the messenger is getting the credit that you are due. And you get someone who directs their anger at the messenger not the message. Yes, it's broken, yes it's dysfunctional, but it's just business. If you are in that spot you can assuage your hurt feelings by forcing the simple/wrong solution through to "prove" to yourself that you have more power. In all fairness I don't blame the engineer. They fully believed that their simple solution was completely adequate. I do however blame the management that put up with this. They are the ones who should have been looking out for the company/technology and not whose feelings would be hurt by doing the right thing. Several years later James apologized to me for not doing the right thing, and I appreciated that, but I also recognize that while my system was much more secure and would have not had the vulnerabilities that were later found, it was more complicated and thus harder to validate, and it could have just as easily been broken in a different way.
- jariel 6y ago
  I appreciate the fact that the Security Model may have been 'simple' - and frankly 'simple' is usually better with these things. However - it doesn't abnegate the fact that no matter how you slice it the 'Security Model' is an important thing unquestionably deserving of some open discussion among participants, because there existential consequences. Especially with Security - it's not one of those things that's ever obvious. This is why we have bug bounties, certain kinds of open source - it generally benefits from 'a lot of eyes, and pondering'. It's probably something you might try a few versions of and not even make your mind for a bit. The evidence that 'it's a big deal' is in your own response: the solution was screwed up, and Java paid a big price. The fact that anyone 'right or wrong' was trying to put together a solution and just 'check it in' frankly is a little frightful. Engineers threatening to quit, and decisions made on the basis of that are comical. If this narrative is authentic, then it seems Java Security Model - and probably a bunch of other things were just 'slammed together' by a bunch of smart guys passionately working on it, arguing, playing games' and we're lucky to have what we have today I guess. Imagine what we would have if there was some intelligent social deliberation there.
  - ChuckMcM 6y ago
    What gave you the impression that security wasn't discussed? At the time the group was pretty small, about 12 engineers depending on how you counted. Besides Mark Miller who had done the foundational work on Joule at Agorics I also had Whit Diffie to help with the cryptographic aspects, and access to some of the top infosec people of the time. Literally as soon as we started prototyping "Webrunner" (which later became "HotJava"), the web browser written in Java, we started talking about the risks associated with loading executable content from a server you didn't trust and running it on your computer. Everyone agreed we had to do something but not everyone agreed with how much we should do given that Sun was going to toss the language anyway and so we would be lucky if we got half the number of users that Tcl already had. I was nominally tasked with solving this problem and chose to solve it to the best of my ability. To do that I created a system for signing Java code, a capabilities model that would prevent unauthorized code execution, started Sun on the path of licensing a right to use the RSA patent, added an entire crypto subsystem to the sys.* code base, negotiated with the NSA a system that would allow Sun to actually ship strong encryption in an interpreted language, and designed some structure that had to be in the JVM to support this framework. But what you have failed to grasp is that at the time the prevailing attitude at Sun corporate was that this was a 'throw away' project and amongst some of the engineers in the team, they were more interested in showing off their language design skills rather produce something that was an actual product. After all, as these language designers reasoned, Java had removed all the things that made C and C++ unsafe right? So if the language was correct (as the reasoning went) it couldn't possibly be used to do something bad. One of them felt all of this "security complexity" was unnecessary. They also felt that my checking into the code base this complex stuff was disruptive. But they did agree that there needed to be "something" so they wrote the SecurityManager class over the weekend and called it done. And threatened to quit when I tried to get it undone.

by jariel 6y ago

ChuckMcM 6y ago

You know that phrase "Reality is complicated"? Smart people tend to over estimate their understanding of complicated subjects, and it irritates them when it appears you are making something more complicated than it "should be." Even though the error is their over estimation, not the complexity of the solution. If you combine that with their ego being unable to accept that something is more complicated than they assume, then you get the situation where they propose a solution that is simple, easy to implement, and wrong. Add to that a measure of "hurt" from feeling like the messenger is getting the credit that you are due. And you get someone who directs their anger at the messenger not the message. Yes, it's broken, yes it's dysfunctional, but it's just business. If you are in that spot you can assuage your hurt feelings by forcing the simple/wrong solution through to "prove" to yourself that you have more power. In all fairness I don't blame the engineer. They fully believed that their simple solution was completely adequate. I do however blame the management that put up with this. They are the ones who should have been looking out for the company/technology and not whose feelings would be hurt by doing the right thing. Several years later James apologized to me for not doing the right thing, and I appreciated that, but I also recognize that while my system was much more secure and would have not had the vulnerabilities that were later found, it was more complicated and thus harder to validate, and it could have just as easily been broken in a different way.

jariel 6y ago
I appreciate the fact that the Security Model may have been 'simple' - and frankly 'simple' is usually better with these things. However - it doesn't abnegate the fact that no matter how you slice it the 'Security Model' is an important thing unquestionably deserving of some open discussion among participants, because there existential consequences. Especially with Security - it's not one of those things that's ever obvious. This is why we have bug bounties, certain kinds of open source - it generally benefits from 'a lot of eyes, and pondering'. It's probably something you might try a few versions of and not even make your mind for a bit. The evidence that 'it's a big deal' is in your own response: the solution was screwed up, and Java paid a big price. The fact that anyone 'right or wrong' was trying to put together a solution and just 'check it in' frankly is a little frightful. Engineers threatening to quit, and decisions made on the basis of that are comical. If this narrative is authentic, then it seems Java Security Model - and probably a bunch of other things were just 'slammed together' by a bunch of smart guys passionately working on it, arguing, playing games' and we're lucky to have what we have today I guess. Imagine what we would have if there was some intelligent social deliberation there.
- ChuckMcM 6y ago
  What gave you the impression that security wasn't discussed? At the time the group was pretty small, about 12 engineers depending on how you counted. Besides Mark Miller who had done the foundational work on Joule at Agorics I also had Whit Diffie to help with the cryptographic aspects, and access to some of the top infosec people of the time. Literally as soon as we started prototyping "Webrunner" (which later became "HotJava"), the web browser written in Java, we started talking about the risks associated with loading executable content from a server you didn't trust and running it on your computer. Everyone agreed we had to do something but not everyone agreed with how much we should do given that Sun was going to toss the language anyway and so we would be lucky if we got half the number of users that Tcl already had. I was nominally tasked with solving this problem and chose to solve it to the best of my ability. To do that I created a system for signing Java code, a capabilities model that would prevent unauthorized code execution, started Sun on the path of licensing a right to use the RSA patent, added an entire crypto subsystem to the sys.* code base, negotiated with the NSA a system that would allow Sun to actually ship strong encryption in an interpreted language, and designed some structure that had to be in the JVM to support this framework. But what you have failed to grasp is that at the time the prevailing attitude at Sun corporate was that this was a 'throw away' project and amongst some of the engineers in the team, they were more interested in showing off their language design skills rather produce something that was an actual product. After all, as these language designers reasoned, Java had removed all the things that made C and C++ unsafe right? So if the language was correct (as the reasoning went) it couldn't possibly be used to do something bad. One of them felt all of this "security complexity" was unnecessary. They also felt that my checking into the code base this complex stuff was disruptive. But they did agree that there needed to be "something" so they wrote the SecurityManager class over the weekend and called it done. And threatened to quit when I tried to get it undone.