Java is so riddled with security flaws that I am not sure why Google decided not to offer an alternative language when it decided to release Android Studio. As far as I can tell this is just a switch from Eclipse to InteliJ. Even worse is the the fact that Java is still being used for new development.
It's time to kill Java but Google and its ilk are continuing to promote a language that is riddled with security problems thereby prolonging its useless life. Schools still teach the language without any discussion to about its security flaws.
Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts
Thursday, December 11, 2014
Friday, April 11, 2014
So much for open source, crowd source, and all other sources
The programming mistake that resulted in Heartbleed:
“I was working on improving OpenSSL and submitted numerous bug fixes and added new features…In one of the new features, unfortunately, I missed validating a variable containing a length.”The model relies on crowds except when crowds are sparse (oxymoron?) and quick reaction. This model applies to Wikipedia and financial markets as well. It relies even more strongly on so-called "self-correcting" mechanisms since crowds can also act like herds.
After he submitted the code, a reviewer “apparently also didn’t notice the missing validation,” Seggelmann said, “so the error made its way from the development branch into the released version.”
Dr Seggelmann said the error he introduced was “quite trivial,” but acknowledged that its impact was “severe.”
Apparently, mistakes such as Seggelmann’s aren’t rare. Programmers on Reddit sympathized with him and swapped stories of their own coding errors.
“Really, the only reason that most of us haven’t caused such a massive f—up is that we’ve never been given the opportunity,” one wrote.
So if errors like these are easy to make and have potentially disastrous consequences, why isn’t something being done?
“It would be better if more people helped improving [OpenSSL],” Seggelmann told Mashable via e-mail. “The more people look at it, the less likely errors like this occur.”
Apparently not a conspiracy either:
Seggelmann, who lives in Münster, Germany, told the Herald he didn’t insert the error on purpose, as some conspiracy theorists have suggested.
“It was a simple programming error in a new feature, which unfortunately occurred in a security relevant area,” he said. ”It was not intended at all, especially since I have previously fixed OpenSSL bugs myself, and was trying to contribute to the project.”
But what if some agency hypnotized him to make the mistake? Conspiracies can never die - they just take on a different form.
Tuesday, July 21, 2009
A software writer's perspective on the financial crisis
Not just any software writer[emphasis mine]:
I wrote the software that turned mortgages into bonds. ... The packaging of heterogeneous home mortgages into uniform securities that can be accurately priced and exchanged has been singled out by many critics as one of the root causes of the mess we’re in. I don’t completely disagree. But in my view, and of course I’m inescapably biased, there’s nothing inherently flawed about securitization. Done correctly and conservatively, it increases the efficiency with which banks can loan money and tailor risks to the needs of investors. Once upon a time, this seemed like a very good idea, and it might well again, provided banks don’t resume writing mortgages to people who can’t afford them. Here’s one thing that’s definitely true: The software proved to be more sophisticated than the people who used it, and that has caused the whole world a lot of problems.
... I was told to rewrite the entire system. Make it all push-button. Flexible and faster. Traders told us what they wanted, and we wrote the software code to make it possible. We were on the cutting edge. ... Working with another programmer, I wrote a new mortgage-backed system that enabled investors to choose the specific combinations of yield and risk that they wanted by slicing and dicing bonds to create new bonds. It was endlessly versatile and flexible. It was the proverbial money tree.
... Our software was rolled out to ride the latest wave. Traders loved it. What had taken days before now took minutes. They could design bonds out of bonds, to provide the precise rate of return that an investor wanted. I used to go to the trading floor and watch my software in use amid the sea of screens. A programmer doesn’t admire his creation so much for what it does but for how it does it. This stuff was beautiful and elegant.
The aim of software is, in a sense, to create an alternative reality. After all, when you use your cell phone, you simply want to push the fewest buttons possible and call, text, purchase, listen, download, e-mail, or browse. The power we all hold in our hands is shocking, yet it’s controlled by a few swipes of a finger. The drive to simplify the user’s contact with the machine has an inherent side effect of disguising the complexity of a given task. Over time, the users of any software are inured to the intricate nature of what they are doing. Also, as the software does more of the “thinking,” the user does less.
And in a scene that could have come out from Liar's Poker:
Now that I was spending more time on the floor, I wondered why the men’s room always stank. Then one afternoon at three, when I was in there taking a leak, I discovered the hideous truth. Traders had a contest. Coming in at eight, they never left their desks all day, eating and drinking while working. Then, at three o’clock, they marched into the men’s room and stood at the wall opposite the urinals. Dropping their pants, they bet $100 on who could train his stream the longest on the urinals across the lavatory. As their hydraulic pressure waned, the three traders waddled, pants at their ankles, across the floor, desperately trying to keep their pee on target. This is what $2 million of bonus can do to grown men.
I wrote the software that turned mortgages into bonds. ... The packaging of heterogeneous home mortgages into uniform securities that can be accurately priced and exchanged has been singled out by many critics as one of the root causes of the mess we’re in. I don’t completely disagree. But in my view, and of course I’m inescapably biased, there’s nothing inherently flawed about securitization. Done correctly and conservatively, it increases the efficiency with which banks can loan money and tailor risks to the needs of investors. Once upon a time, this seemed like a very good idea, and it might well again, provided banks don’t resume writing mortgages to people who can’t afford them. Here’s one thing that’s definitely true: The software proved to be more sophisticated than the people who used it, and that has caused the whole world a lot of problems.
... I was told to rewrite the entire system. Make it all push-button. Flexible and faster. Traders told us what they wanted, and we wrote the software code to make it possible. We were on the cutting edge. ... Working with another programmer, I wrote a new mortgage-backed system that enabled investors to choose the specific combinations of yield and risk that they wanted by slicing and dicing bonds to create new bonds. It was endlessly versatile and flexible. It was the proverbial money tree.
... Our software was rolled out to ride the latest wave. Traders loved it. What had taken days before now took minutes. They could design bonds out of bonds, to provide the precise rate of return that an investor wanted. I used to go to the trading floor and watch my software in use amid the sea of screens. A programmer doesn’t admire his creation so much for what it does but for how it does it. This stuff was beautiful and elegant.
The aim of software is, in a sense, to create an alternative reality. After all, when you use your cell phone, you simply want to push the fewest buttons possible and call, text, purchase, listen, download, e-mail, or browse. The power we all hold in our hands is shocking, yet it’s controlled by a few swipes of a finger. The drive to simplify the user’s contact with the machine has an inherent side effect of disguising the complexity of a given task. Over time, the users of any software are inured to the intricate nature of what they are doing. Also, as the software does more of the “thinking,” the user does less.
And in a scene that could have come out from Liar's Poker:
Now that I was spending more time on the floor, I wondered why the men’s room always stank. Then one afternoon at three, when I was in there taking a leak, I discovered the hideous truth. Traders had a contest. Coming in at eight, they never left their desks all day, eating and drinking while working. Then, at three o’clock, they marched into the men’s room and stood at the wall opposite the urinals. Dropping their pants, they bet $100 on who could train his stream the longest on the urinals across the lavatory. As their hydraulic pressure waned, the three traders waddled, pants at their ankles, across the floor, desperately trying to keep their pee on target. This is what $2 million of bonus can do to grown men.
Wednesday, January 14, 2009
R wish list
Was part of an R discussion - I haven't really used R except for the VARS package and I've been trying to make the switch from SAS but it hasn't worked because of all the pre-processing that I have to do to get a data set for analysis.
My wish list for R is as follows (and they may already be there just not to my mediocre knowledge or quick Google searches of the R discussion list):
1. An input statement for processing text files like SAS - this is key to reading public use files that are usually very large and having to avoid reading the entire file using read.table or the fortran syntax for reading files.
2. Several commenters noted that you can read files without using data frames and I was not able to find a reference to it on the R-discussion list. I'm thinking that this is achieved using vectors or matrices but haven't quite figured it out yet.
3. A first dot and last dot syntax similar to SAS or an egen statement similar to STATA.
4. it would be nice if the R foreign package has a keep or drop statement so that I don't have to read the entire data set into memory. I tried to read the public use version of World Values Survey Data which was in Stata xpt format but the memory limitations on my computer couldn't handle it.
I realize that R is NOT a data processing package and something like Perl could also work BUT it's always nice to have everything integrated instead of having to deal with two languages and porting abck and forth between languages to do what I consider basic data processing tasks. I consider data analysis 90 percent processing and 10 percent analysis and then another 100 percent fooling around with different packages to get the results I want.
My wish list for R is as follows (and they may already be there just not to my mediocre knowledge or quick Google searches of the R discussion list):
1. An input statement for processing text files like SAS - this is key to reading public use files that are usually very large and having to avoid reading the entire file using read.table or the fortran syntax for reading files.
2. Several commenters noted that you can read files without using data frames and I was not able to find a reference to it on the R-discussion list. I'm thinking that this is achieved using vectors or matrices but haven't quite figured it out yet.
3. A first dot and last dot syntax similar to SAS or an egen statement similar to STATA.
4. it would be nice if the R foreign package has a keep or drop statement so that I don't have to read the entire data set into memory. I tried to read the public use version of World Values Survey Data which was in Stata xpt format but the memory limitations on my computer couldn't handle it.
I realize that R is NOT a data processing package and something like Perl could also work BUT it's always nice to have everything integrated instead of having to deal with two languages and porting abck and forth between languages to do what I consider basic data processing tasks. I consider data analysis 90 percent processing and 10 percent analysis and then another 100 percent fooling around with different packages to get the results I want.
Subscribe to:
Posts (Atom)