This year for the JavaOne 2013 San Fransisco conference we added a new session track — Securing Java. For those interested, I thought I would share some information about the new track and a sneak peek at some early session acceptances.
Last year at JavaOne 2012 San Fransisco, I was surprised by the number of non-Oracle security presentations at the conference. I didn’t have any hard data at the time but my informal impression was security is important to the entire Java community. There were many presentations across many subject areas like, security features and fundamentals, security expert panels, Glassfish security, Java Card, secure coding standards, and much more. When submitting my session I had some difficulty determining under which track to submit. I settled on submitting my security presentation under, Core Technologies.
Upon conclusion of the JavaOne conference, I confirmed my suspicions around community interest in Java security with some session metrics. I thought with all the security content why don’t we add a security track. I approached the JavaOne conference team with my information and suggestions, and they provided their approval — Securing Java was born. Kudo’s to the JavaOne team, Sharat Chandler (Twitter: @sharat_chander) and Stephen Chin (Twitter: @steveonjava) without their support this track would be just another good security idea that never got off the ground, my heroes. It all sounds so easy and in fact it was.
Now for the early invites, drum roll. Congratulations to the following JavaOne Securing Java track early acceptances (presented in no particular order). It’s a small example of what you will see at JavaOne. Keep in mind cancellations are infrequent but they do occur.
CON2021 “REST Security with JAX-RS”, Frank Kim (Twitter: @thinksec)
CON3122 “Anatomy of a Java Zero-Day Exploit”, David Svoboda (Twitter: @david_svoboda)
CON2570 “Don’t be that guy! Developer Security Awareness”, Markus Eisele (Twitter: @myfear)
BOF5847 “Web Security Vulnerability Remediation in Legacy Java Web Applications”, Gopal Padinjaruveetil, Wilson Rao
Many software developers will never visit a security conference or event. The new addition of the security track for JavaOne provides a unique educational outreach opportunity. If you are unable to attend media is usually available online a short time after the conference.
The number of sessions, quality of sessions and presenters, and topics covered is even better than last year conference. My expectations were definitely exceeded for a first time event. I’m positive the track will be well received and we will all have an opportunity to learn much more about Java security. Many thanks to everyone who submitted!
[Updated Post Friday December 10, 2012]
I thought it would be helpful to share my results with everyone. Figure 2 is chart showing hourly trending for my Internet speed over the last 2 weeks.
|Figure 2: Hourly Trend of Broadband Speed|
My Internet connection to my ISP is 50Mbps. The chart shows I’m receiving slightly less than 1/2 my expected bandwidth. I changed the chart around to produce bandwidth results in megabits per second (e.g., Mbps). Megabits is how my ISP advertises their connections so it’s less error prone for me to think of my results in terms of Mbps. At little Excel magic yields the chart in Figure 2. Now that measurements and charting are in good shape I’m thinking about my data and results. I have come to the conclusion it’s best if I rerun the tests connected directly to my ISPs access point.
In my home network my *NIX host, running the testing, connects to a HP Procurve 1700-8 managed switch, then to a Netgear Powerline AV500 Adapter running as a bridge, then to my Asus RT-N56U router/firewall, and finally to the ISPs access point. It seems likely to me the WAN connection should be the most rate limited of all the gear. However, to eliminate all possibility of error, I’m going to connect the *NIX host directly to the ISP access point and rerun the tests. Sigh.
[Updated Post Friday November 23, 2012]
I made a few improvements I thought I would share. The original program code had interleaving series data in rows. There’s nothing wrong with the data but it’s hard to graph in Excel. I improved the program by moving series data to columns. Once I get all the data into Excel I delete all the columns except: DATE, TIME, ELAPSED-sjc01-10, ELAPSED-sjc01-100, ELAPSED-wdc01-10, ELAPSED-dal01-10. To graph, I select all the data including column headings and choose the graph I want. Following are the improved files.
If you run the tool, following are a few lines of sample data you can expect to see in the new CSV file.
The following is a chart I generated with a few hours of data.
|Updated Figure 1: Broadband Bandwidth Hourly Trend|
Keep in mind if your going to run the new jar you should update your command line like the following.
java -Dfile=./ispspeedtest2.csv -jar ./ispspeedcheck2.jar
I’m interested to see some real data. Happy Thanksgiving! –Milton
Many of us at one time or another wonder if we are really receiving our full Internet bandwidth. There are a number of ways we can get this information. I will cover a few of them as well as provide a small Java executable along with source code so you can experiment on your own.
If your only looking for a quick easy test for your Internet connection you don’t need to write a program. Open your browser to speedtest.net and give them a try. I like speedtest.net and it’s easy to use. In my case, I wanted an hour by hour trend of my Internet connection throughput. To get a trends on speedtest would be bothersome since I would have to run the test manually once each hour. Great tool but you need a little something more if your interested in trends. This monkey has better buttons to push so I decided on a Java project. Moving on, following are some of the questions and points I considered when thinking about my broadband bandwidth.
milton@sparky:~/bin$ tail -f ./ispspeedtest.csv
|Figure 1: Broadband bandwidth hourly trend|
The servers where I download payloads are hard coded in the program for North America only. If you live elsewhere, you will want to experiment with ISPs closer to your region and you will need to make some improvements to the code.
Running the binary depends upon your system but to get it running on my system I use the following. The command launches the program and tells it to log CSV data to the ispspeedtest.csv file in the current working directory.
java -Dfile=./ispspeedtest.csv -jar ./ispspeedcheck.jar
I have tried it under Java 6 and Java 7 on OSX and Java 6 under Ubuntu Linux. If anyone needs some assistance let me know and I might be able to make some changes or suggest some. I’m just not sure who’s interested in this stuff at the moment so I see need to invest anymore time than necessary to help answer my personal curiosities.
Contacting your ISP
Before you decide to share any information with your ISP make sure you have your facts straight. Double check your information, cross check with other tools, etc. It’s easy to misinterpret results or make a programming mistakes if you decide to make some improvements to the code. If you’ve taken all precautions and you still wish to contact your ISP then be courteous. Often raising awareness will get you on the path to resolution. Also keep in mind your advertised bandwidth is not a guarantee. Bandwidth guarantees are available but not generally to consumers since they cost a fortune. Take the time to become familiar with your ISP’s Terms of Service for your Internet connection before you call.
 Alves, J. Clipart – Wavy Checkered Flag. Digital image. Clipart – Wavy Checkered Flag. Clipart.org, 25 Mar. 2010. Web. 15 Nov. 2012. <http://openclipart.org/detail/62779/wavy-checkered-flag-by-j_alves>.
 “Test Your ISP.” Electronic Frontier Foundation. EFF, n.d. Web. 15 Nov. 2012. <https://www.eff.org/testyourisp>.
Monday, Oct 1, 8:30am – 9:30am
Hilton San Francisco – Continental Ballroom 7/8/9
(JavaOne media: http://tinyurl.com/8znynhb)