Friday, February 22, 2008

3DTelemetry beta is here!

In a previous post I eluded to a project I was working on involving GPS and OBDII vehicle data. The beta is now online and ready for download here. All you need is an NMEA compatible GPS device or logger, and an OBDII scanner if you want to import vehicle data (3DTelemetry will create maps without OBDII also).

3Dtelemetry takes data logged in your favorite OBDII scan tool (growing compatibility list here) and merges it with the GPS data that it (or an external GPS logger) aquires along your drive. 3DTelemetry then exports the data into KML format for viewing within Google Earth. So, essentially you will be able to see on a 3D map that your Mass Air Flow pressure was 2lbs in corner 4 and the engine reported 6400RPM while you were passing grandma's house.

This is obviously going to be an ongoing project and I will update my blog with any dramatic changes, but check the site (http://www.3dtelemetry.com) for the latest information. Debugging from the passenger seat has presented an entirely different programming experience, but this one has been allot of fun to create so far. Special thanks to Jay and the gang at Autoenginuity and others for fielding my incessant questions about OBDII.

I intend to keep the application free during this initial beta phase and then very affordable once we have a valid release. I think there are too many high priced doodads out there for the amateur racer these days. So if you enjoy your car and you're looking for something useful and cool that wont break the bank check it out!

Please feel free to drop me a line with any suggestions or comments!

Tuesday, December 04, 2007

Making sense of the Global Positioning System

Thanks to the U.S. Department of Defense (and good ole President Ronald Reagan) GPS signals are freely available for civilian use. The fact is, today GPS is basically ubiquitous in most people's lives. Most new cars use it to show you where you are and your proximity to the nearest Starbucks. Raising the "cool factor" bar for technology using GPS is its implications on the Internet as we know it. For example people are geocoding their images in their online photo albums, Cool apps like Google Earth, Geocaching and all sorts of new creative games using real places are sprouting up all over the Internet (people are going outside again!). Basically, with GPS the Internet can break out of it's closed linear stage and becomes part of our real three dimensional world. Very cool, but more on that later - let's dive into what makes the Global Positioning System tick and how you can take advantage of the technology in your next project.

You will find that most GPS devices out there (USB GPS for your PC, handheld GPS's, etc etc) will report data from satellites in a neat standard format called NMEA. NMEA uses a serial ASCII protocol to send GPS data to your application for consumption. The resulting comma delimited data is piped out or logged sentence by sentence from your device. The NMEA format makes it easy to take the data and parse it anyway we'd like. Now we could just use the software that came with our Microsoft's Streets and Trips or Earthmate GPS but that's no fun.

Decoding GPS log files
There are many different types of NMEA sentences. Luckily they are all in an easy to read format. The first field is the sentence type and will start with $. I am only going to focus on a couple sentence types that give us our position information. For the purpose of this blog, we'll ignore the other sentences but there is plenty of references online about them.

My favorites, $GPGGA and $GPRMC. You will find that these two will have all the data you should need for tracking.

Example sentence (GPGGA):
$GPGGA,192122,3514.7971,N,07634.7585,W,1,04,01.3,00006.2,M,-035.9,M,,*79

Translation:
$GPGGA,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh

Here is what each field means:
1 = UTC of Position
2 = Latitude
3 = N or S
4 = Longitude
5 = E or W
6 = GPS quality indicator (0=invalid; 1=GPS fix; 2=Diff. GPS fix)
7 = Number of satellites in use [not those in view]
8 = Horizontal dilution of position
9 = Antenna altitude above/below mean sea level (geoid)
10 = Meters (Antenna height unit)
11 = Geoidal separation (Diff. between WGS-84 earth ellipsoid and
mean sea level. -=geoid is below WGS-84 ellipsoid)
12 = Meters (Units of geoidal separation)
13 = Age in seconds since last update from diff. reference station
14 = Diff. reference station ID#
15 = Checksum

Example sentence (GPRMC):
$GPRMC,192137,A,3514.7966,N,07634.7588,W,000.0,000.0,310707,,,A*66

Translation:
$GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a,m*hh

Here is what each field means:

1 = UTC time of fix
2 = Data status (A=Valid position, V=navigation receiver warning)
3 = Latitude of fix
4 = N or S of longitude
5 = Longitude of fix
6 = E or W of longitude
7 = Speed over ground in knots
8 = Track made good in degrees True
9 = UTC date of fix
10 = Magnetic variation degrees (Easterly var. subtracts from true course)
11 = E or W of magnetic variation
12 = Mode indicator, (A=Autonomous, D=Differential, E=Estimated, N=Data not valid)
13 = Checksum

By parsing these etypes either in real time by reading the data from a COM port, or from an existing log file you can use the coordinate information in any way you choose. I am currently working on a cool (Ok, I think its cool..) vehicle tracking application that I should be releasing here on this site soon. There are allot of good examples floating around with source code that should give you a handle on using this data.

In closing, the Global Positioning System is a powerful resource that you can tap into and enable your applications to become spatially aware. This opens plenty of doors for new and innovative apps - so get coding!

Wednesday, August 29, 2007

XSS vulnerabilities, do they even care?

Is your site at risk? If you knew it was would you do anything about it? I would hope so, but, you'd be surprised. I've found many "very large" companies online with exploitable vulnerabilities in their main websites that could potentially be very embarrassing and costly.

This article is the start of several where I will test the philosophy of "responsible disclosure" by contacting 5 companies and notify them of security holes that I have found in their sites - even offer assistance and resolutions - to see how long it takes for them to fix them, if at all. I'll keep the names of the companies to myself and just describe them as "industry/estimated # of employees". Just a little white hat test that should get interesting.

By now, most companies and organizations have a little more than a static html brochure online. Most sites are actually full blown online applications either purchased "off the shelf", developed in house, or custom developed by some third party. Dynamic sites, although a necessity, can potentially open doors when improper techniques are used when developed. Once your web application is online, mal-intented site patrons have all the time in the world to pick apart your site for potential vulnerabilities. I speak from experience as web applications that I have created have even been the target of attacks in the past - and I'd be ignorant to think they wouldn't be targeted again in the future.

Some background on the method of the day, XSS..

For this test I'm going to focus on one facet of web application security, XSS(or more confusingly CSS in some cases - not Cascading Style Sheets). XSS stands for cross site scripting and is generally a method employed by hackers to inject their own modified code into your site. I have identified a diverse range of flawed websites below to see what, if anything, their reaction is to someone telling them they have a problem. Here are the companies and description:

1. Retail/95,000 Employees- notified webmasters 8/30/2007
2. Government/1,000 Employees- notified webmasters 8/29/2007
3. Manufactoring/23,000 Employees- notified webmasters 8/30/2007
4. Transportation/19,000 Empl0yees- notified webmasters 8/30/2007
5. Pharmaceutical/2,000 Employees- notified webmasters 8/30/2007

If you'd like for me to take a quick run through of your site, drop me an email with the URL and I'll be glad to send you what if anything I find (time permitting:)

So, there you have it. I'll post updates as responses come in. Let the whirlwind begin.

Tuesday, July 03, 2007

Displaying fiscal year with VBScript

In an effort to drive engineers bananas, at some point a financial wienie decided that a normal calendar we've been using for thousands of years just wasnt up to par. Fiscal dates took root in the government and corporate America, surely chaos would ensue..

Truthfully, fiscal dating makes more sense to companies because the organization can then make their own rules and target the start and end dates around important production times or downtime.

There are many good ways to generate the fiscal date information, I've found that one really quick and dirty way to display just the year is by using vbscript datedd and datepart.

Our example will use the Government fiscal year which starts October 1 so will need to add one year to the current year if it is October, Nov, or Dec.

<%
if (DatePart("M",Date)) = "10" then
FISCALYEAR = DateAdd("yyyy",1,date)

elseif (DatePart("M",Date)) = "11" then
FISCALYEAR = DateAdd("yyyy",1,date)

elseif (DatePart("M",Date)) = "12" then
FISCALYEAR = DateAdd("yyyy",1,date)

else
FISCALYEAR = DateAdd("yyyy",0,date)
end if
%>

If your fiscal year starts in, say, August.. August is the 8th month so start your script with
if (DatePart("M",Date)) = "8" then
and then continue through the months through the end of the year (12). Happy scripting, or rather, fiscalling!

Wednesday, June 06, 2007

Version 2.0 is here

I've been offline for a while in anticipation of our new son, and we're happy to report that he's finally here. Ryker Douglas Butcher was born on May 11th, 2007 weighing 8 lbs and 20 inches.

Click for Details

Now that he's here, it's time to put him to work - be on the lookout for some upcoming blogs on a couple of projects I am cooking up in the lab utilizing RFID technology.

Sunday, December 03, 2006

Take Control of High Level Userid's

It's been a while since I published anything so I figured I would drop a quick tip/suggestion for account administration that works well. One of the most overlooked and dangerous habits of system administrators, development staff etc is good plan for safe usage of high access user accounts. Obviously it's bad practice to allow users to perform all of their day to day responsibilities (email, web browsing, etc.) while logged in as an administrator. These accounts should be reserved only for performing the duties in which they were created for. If allowing otherwise, one of your power users users will eventually succumb to a virus or browse some illegitimate website and reak much more havoc on your infrastructure as they potentially would logged in as a normal user.. Not a good plan.

So, how is your staff supposed to do their jobs without having an administrator account? One simple solution that works well is to create two separate accounts for these users. One account should have very minimal access levels allowing just the basics. The users should use these accounts as their login everyday. Make the second id's similar to the first but prefix them with a standard naming convention like "admin" to make them easier to manage. The second id's should have all appropriate permissions for all of the employees tasks.

Now, forcing your users to login and logout all day long will make them go bananas, and truthfully you will not get anyone to abide by this for very long without forcing and denying things link email on the administrator accounts. To make every one's life easier, you could create a batch file for each the users that executes the RUNAS command, and fires up the command prompt running as the admin user.

Example of the batch file contents:
runas /user:domain\administratorid cmd

Drop a shortcut to the batch on their desktops via AD to make it really easy for them. There's also alot of good options in the runas command that you can take advantage of like using alternate profiles if need be.

Now that we have our user logged in with a stripped down account, and they are running the cool custom command prompt as the administrator you should be all set. The user can actually drag and drop any program into this command prompt (Computer manager, SQL manager, etc) and voila - it fires up as the admin account. The user can keep this prompt running all day and use it over and over whenever they need to access an admin level application.

In closing - Having a good, organized strategy for account access is paramount in creating a safe, secure and happy infrastructure.

Tuesday, February 28, 2006

Standards in enterprise level intranets

This is more of a best practices blog than a technical one. After seeing several large enterprise level intranets grind themselves to near uselessness, I figured it was time to shed some light on why standards can be so important.

Defined standards is an often overlooked part of a companies internal computing strategy, yet in my opinion a very important one. Introducing standards into web systems will in the long run save user frustration, save time, save money, and ensure that an organization's investment in their information is accessible.

Keeping a few simple things in mind when laying out your design will inevitably create a better end user experience.

Successful enterprise level intranets should contain usable, organized information. Feel free to babble on about the history of your company on your extranet, remember to keep your intranet environment concise and to the point. The key is the intranet is a tool, and when users brains are highjacked by lack of organization an extraneous information the effectiveness is lost. The end users should be able to retrieve what the are looking for quickly, and then to move on.

Early intranet adopters usually have chaotic web structures. Many larger companies have a disorganized or non existent web structure because their strategy was (and is)to piece together all their departments home made websites. Every department has a self proclaimed web aficionado, and that person was typically usually tapped to "put together" and maintain that dept's intranet site. This leads to a host of issues including lack of central management, unbalanced traffic loads (both physical loads and "political") and my personal pet peeve - departmental branding which I will get into a bit later. All of these things lend themselves to an inefficient end user experience. It may sound harsh, but taking the design liberties away from your rouge developers will foster a user centric and standard web experience. Management of corporate intranets should be centrally managed in regards to design and function, actual content should be delegated.

Drop the fancy logos. One thing that I have seen over the years in most or all of the patched together intranet systems is custom departmental logos popping up. Some facets of an organization will in fact need self branding, but keep in mind most don't and when they don't they add to the confusion factor. Adopt a rendition of your corporate logo, and create a clear background for sublevels to modify with a picture explaining what it is that they do. Your company has already spent millions of dollars developing an image for itself, it may hurt, but it is better than your fancy new logo that you made in Photoshop. Sub-branding also throws off new users. I speak from experience when I say an intranet with a different header image and logo in each site makes a new employee wonder how many different companies are involved. Sure departmental pride is a good thing, but who do you actually work for - creating sub logos projects you are on a different team altogether and not working for a common goal.

In closing, it is easy to see why we need standards. Designing the superstructure of your intranet smart will make your investment give a much higher return. So, develop your design standards in regards to Look/Feel, Navigation, and keep them user focused! Long story short - all development including back end systems, graphics, and applications should be agreed upon at a corporate level by development staff and management. Delegate content management tasks the guys in each dept whose experience consists of making a website for their local church. Good luck, you're gonna need it.