Is your iPhone broadcasting your name via Bluetooth?

Very likely!

I developed BlueScan, an Android Bluetooth scanner, as a research project to better understand Bluetooth usage in the wild. The app scans for Bluetooth devices (Low Energy and Classic) and stores the results in a database on the phone which can then be downloaded for analysis.  As a mobile app, it allows me to identify nearby Bluetooth signals as I'm driving around town - essentially war driving for Bluetooth except that it's scanning passively - it just listens for broadcasts but does not initiate any connections.

Initial Observations: 

After a couple of days of on-again off-again scanning as I tested the app, I had a look at the data I had collected. The most obvious observation based a small dataset of 152 devices was that one quarter of the Apple users (mostly iPhones, iPads and Macbooks) were broadcasting their full names via Bluetooth. 

Here is the breakdown based on the 152 devices in the dataset:

• 36 of the 152 devices were Apple devices
• 9 of the Apple devices included both first name and last name identifier, as in "John Abraham's iPhone"
• 19 of the Apple devices had just a first name identifier such as "John's MacBook Pro"
• Only 8 of the 36 Apple devices were broadcasting but not including some sort of personal or device naming in their broadcasts

In infosec, we'd characterize this as unnecessary information disclosure. While information disclosure by itself is not always a high risk security issue in the enterprise information security realm, it's best practice to avoid doing so. In the consumer realm this is a privacy issue and you never how or when this kind of information can be used or aggregated with some other data. Given the number of Bluetooth scanners in public places thanks to the adoption of Bluetooth Low Energy and the boost from iBeacon, Apple users should be aware of this. 

Considerations for Cross Platform App Development - Direct iOS/Androd SDK vs. Titanium Appcelerator

After having developed a number of apps on both iOS and Android, using both native SKDs as well as a cross platform development toolkit (Titanium Appcelerator) , I thought I'd reflect on some of the benefits and drawbacks that I experienced using Titanium as opposed to doing development directly in the native development environments. With more experience developing on Android with Java than on iOS with Objective-C, this comparison is based more on my specific Android/Java experience, though it's applicable to both.

• Documentation: I found the Titanium Appcelerator documentation somewhat lacking in detail and incomplete. This issue is somewhat mitigated by the fact that the developer community Q&A site is active enough that answers to most questions can readily be found. However, I'm a big fan of Google's developer documentation in general and along with the over-abundance of StackOverflow activity, it's always a pleasure to develop in a Google environment.

• Cross Platform Compilation. For the McRun Running Calculator of which we have an iOS version and an Android version, we developed first for iOS and released a couple of versions using Titanium Appcelerator getting the app stable on iOS before moving to Android. Development time for initial release was perhaps an 8-10 week project. This included working through UX considerations, directing graphic design, and also working thorough the process of implementing and testing the algorithm that is the core of the McRun app. Other than having to do additional graphic work (see below) to support android, much of this effort translated to Android with zero additional effort. However, while much of the backend code was easily ported to Android, most of the UI components had to be completely redone on Android. Appcelerator calls their cross platform framework as a "write once, adapt everywhere" platform, in which perhaps 80% to 100% of the code can be re-used. My experience is that now that we have revised the code to support both Android and iOS with conditional branching in the code (if (platform=="iOS" { // do iOS stuff } else { //do Android stuff }) and some conditional includes per platform, the code is now perhaps 90% compatible across both platforms. Eventually, we might strive to release updates on both platforms concurrently. Right now, we're one code base, and we release on one platform, then later do a release on another, and things get broken across platforms in the process. On our first Android build when the UI was so broken that app was in no way usable - complete jumbled spaghetti - fixing this and getting release ready was about a 3 week project. So from an effort perspective,  it required an additional 1/3 of the iOS development effort to release on Android.

• Graphic Assets: Beyond the actual porting to Android, it's important to understand that the screen size and density permutations on Android is really extensive as compared to iOS which owns the entire hardware and software stack. Android development required multiple versions of graphics to support the various device configurations. This effort was wrapped into our porting effort mentioned above, but would have been required even if our app was purely an Android only app. iOS is easy in this respect - though I suspect this will change in the future.

• Performance: I have found that Titanium performance on iOS to be very crispy. The load time is fast and the UI is very responsive. While the same app built on Titanium for Android suffers from extremely slow startup time. I suspect (and hope) this is an issue we'll be able to debug (more on this below) and resolve, but as of now, this remains an open issue and - for me - remains a big negative factor with Titanium Appcelerator.

• Debugging: One challenge with Titanium Appcelerator is debugging on-device Android debugging. Developing directly in Java provides easy access to debug, error message, stack traces, etc. This is something I am still working through, so I may have more to say, but for now, I am still unclear on where my issue is on my app load performance issue on startup and on-device debugging capabilities aren't helping.

• File size: An app built on the Titanium Appcelerator platform might be a 6MB Android APK file, whereas the same app built directly on Android with Java, would likely be less than 1MB; this is similar with iOS. While mobile devices are resource constrained on many levels, I don't believe that file storage is the biggest constraint. So, while this is definitely something to be aware of, this is not necessarily a deal breaker.

• Hardware support: One benefit of using Titanium Appcelerator as compared to an HTML5 cross platform solution (at least the last time I checked) is that you get access (albeit indirectly) to the device APIs that control the hardware; so in theory as a developer you get full access to cameras, audio and sensors, such as the accelerometer.  Where this breaks down however, is where Appcelerator opts not to support an element of the API. For example, with BlueScan, my Android Bluetooth 4.0 scanner app research project, direct development in Java worked best as Titanium chose not to support Bluetooth. I have contacted Appcelerator directly and submitted an Issue that has been unresolved for months. Furthermore there are quite a few comments on the developer message boards that have gone unanswered by the Appcelerator team, so Bluetooth support doesn't appear to be on the horizon. There is a 3rd party module available but I didn't want to entrust my core code to a module that seemed to have limited usage and unproven support. Furthermore, as a research project, I needed to be tinkering at a lower level with Bluetooth capabilities, so I did not want to be abstracted from the API. Not all apps are appropriate for Titanium.

• API Updates: One risk of using a framework like Appcelerator's Titanium is that their team needs to react and revise their platform as the underlying Android and iOS APIs evolve. I have seen a number of API updates (including the update to support the iPhone5) during my Appcelerator development cycles and was always surprised how quickly the Appcelerator team reacts to updates. This has never been an issue for me.

• App store submittal: I haven't noticed any difference in my experience submitting to the app stores based on my development platform. As a security guy I like the Apple closed system, but as a developer Android is refreshingly simple and fast.

These are just my un-scientific observations. What's the best approach for cross platform development? I guess as with most anything, that really depends on the specific requirements, but there are merits to either approach.

Android: Java Adapters & Loaders

After porting the McRun iOS app to Android, I realized that using a cross platform framework was not going to work for my Bluetooth scanning data collection project as I needed better access to the radio hardware interfaces.  So I developed BlueScan directly on the Android SDK. While I am always a fan of Google's developer documentation, I found that the Java frameworks for adapters and loaders a bit abstract. As such I documented the framework for a very common development scenario: accessing a database and providing the results to a ListView with favorable UI performance.

The following diagram provides the overview of my class implementation to implement this in the BlueScan Bluetooth 4.0 scanner.

I leveraged a number of resources for getting my arms around the framework:

• The Android Programming book by the Big Nerd Ranch team had descriptive examples as well as a good reusable SQLiteCursorLoader class, which I used here.
• Android's android.widget.Adapter.
• The API guide for List View.

Git - List files in repository

Here's a quick way to list files in your git repository: 

git log --pretty=format: --name-only --diff-filter=A | sort -

Flask / Python Web Development Resources

I've been doing some web development using a Python/Flask/PostgreSQL/Heroku stack. In the spirit of documenting some of my doings for my own reference, Below are some of the resources that I wanted to make note of. Some of the work I am doing is on my GitHub repository, while some of my mobile apps and anything that involves sensitive data is offline.

Flask

• Flask documentation: Flask is a lightweight python web development framework. I was drawn to Flask because of its simplicity. It does much less magic behind the scenes.
• Flask, PostgreSQL, Heroku blog post: A good intro into Heroku specific configuration.
• Heroku Python/Flask documentation: Documentation directly from Heroku.
• Flask, SQLAlchemy tutorial: Extensive multipart web dev tutorial.

RESTful API

• RESTful design blog post: An excellent discussion on RESTful APIs in general as well as API implementation with flask. This was particularly useful for the mobile API I am building.

Sessions and Login

• Flask-Login: User session management module for Flask.
• Flask-Login blog post: Tutorial on session management with Flask-Login.
• Flask-Login example: Hosted on GitHub.
• itsdangerous: Secure session signing Python module.

Heroku: API Unavailable

I went to update some content on my Heroku hosted Python/Flask app and was unable to upload / git push the app due to an "internal server error" and associated "We're investigating issues with an API database failure. We're recovering the database now" message.

Pretty scary, and not a confidence builder given it's my first week testing the service. However. on the upside the downtime (for me) was just a few minutes and the live production web app was still available during this time using the public URL.

Below is a log of the session.

Login... Password (typing will be hidden): ! Internal server error. ! Run `heroku status` to check for known platform issues. j2mac:jello j2$ heroku status === Heroku Status Development: yellow Production: No known issues at this time. === API Unavailable 2013/02/28 19:27:56 (~ 13s+) 2013/02/28 19:27:56 (~ 13s ago) issue We're investigating issues with an API database failure. We're recovering the database now. j2mac:jello j2$ heroku status === Heroku Status Development: yellow Production: No known issues at this time. === API Unavailable 2013/02/28 19:27:56 (~ 1m+) 2013/02/28 19:27:56 (~ 1m ago) issue We're investigating issues with an API database failure. We're recovering the database now. j2mac:jello j2$ date Thu Feb 28 11:29:13 PST 2013 j2mac:jello j2$ git push heroku Counting objects: 7, done. Delta compression using up to 8 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 1.06 KiB, done. Total 4 (delta 2), reused 0 (delta 0) -----> Python app detected -----> No runtime.txt provided; assuming python-2.7.3. -----> Using Python runtime (python-2.7.3) -----> Installing dependencies using Pip (1.2.1) Cleaning up... -----> Discovering process types Procfile declares types -> web -----> Compiled slug size: 23.9MB -----> Launching... done, v77 http://stormy-citadel-6634.herokuapp.com deployed to Heroku To git@heroku.com:stormy-citadel-6634.git 8563d23..0fb61d6 master -> master j2mac:jello j2$

Idealist (sortable): Python, Flask, Jinja2, Javascript and Tablesorter

I've been experimenting with Python and the Flask web development framework. Combined with hosting on Heroku, I was surprised how quickly one could get a web app up and running. For my experiment this weekend, I created a sortable table of the business model and technology ideas from my previous blog post.

In the spirit of documenting my efforts, here are the ingredients to this micro app:

• Python v2.7.1: An interpreted open source programming language, with an incredible number of modules/resources available
• Flask: a Python-based web development language (BSD Liscense)
• Jinja2: a Python-based templating engine for web development
• Heroku: a cloud-based web application hosting platform

Below, is a sample of the result embedded from the live Heroku site, but since this Blogger blog platform seems to scrub Javascript from the iframe to be able to sort the list may have to go directly to the site hosted at Heroku.

<Note: this may take some time to load as it's hosted on a development Heroku dyno and goes into sleep mode when accessed sparsely.)

FBI Surveillance Van - WiFi Network

I've heard of people having fun with naming their WiFi networks with funny names and the FBI strategy is always mentioned. So I was amused this week as I was out to dinner with the kids in downtown Santa Barbara. I pulled out my iPhone and this is the network list that was found. Pretty funny to see the "FBI Surveillance Van" name used in the wild. While my first thought was, "ha ha, that's pretty funny," I must admit, I did have a gander out the window to see if there happend to be a blacked out van parked out front.

Nike+ Accelerator Ideas

On December 12, 2012, Nike announced their Nike+ Accelerator program in which 10 companies, selected by way of an online application, will be given API access to Nike+ API, mentoring, $20k, and several months of time working at the Nike campus in Portland, Oregon. The program is for companies that intend to leverage "Nike+ technology to create products and services that will inspire athletes across a broad range of activity and health goals including training, coaching, gaming, data visualization and quantified self." The programs is managed in conjunction with TechStars.

As an athlete, mobile app developer and Internet of Things enthusiast a friend who also happens to be a mentor for the program suggested I have a look. While I opted not to apply for various reasons, I thought it was interesting to brainstorm a couple of concepts, just to see what popped.

Data Access & API
First off the data & API, the opportunities are really dependent on the kind of access is available.  What data available via the API provided by Nike?

The information on the Nike developer site are limited but it appears that the data available on the site is limited to the data for a particular user. For example, I could build an app in which a user could log in and access their Nike+ data, which would allow me to present in the app the user's data in my own format or for my own purposes. 
Nike describes their data access into the following four categories. I have included the JSON (JavaScript Object Notation) data structures at the end of this post. These are directly from the Nike developer documentation. 

Aggregate Sports Data: This is a list of "Nike experiences" for which the user has data. An "experience" is, I believe a category of data. For example the Nike running app would collect one category of data and their Fuelband product would collect another.

List Activities: Lits of activities with with summary information for each, including Activity ID, time, duration, calories burned, NikeFuel earned and the device which recorded the data.

Activity Detail: Provides similar data attributes as the data structure above, but for an individual activity.

GPS Data: GPS data in 3-dimensions (lat, long & elevation) for an activity.

Accelerator Questions - Nike+ Accelerator / TechStars

I was looking at the Nike+ Accelerator program recently and found that I had referenced the submission questionnaire a couple of times. I thought it was worth summarizing the questions here as they are part of a general question format (from the Unified Seed Accelerator Application by the Kauffman Foundation and TechStars) that various accelerator programs use. While perhaps the jury is still out on how effective these accelerators will be in building sustainable companies, the questions are good. Each of the various programs custom tailor their own questions, but they seem to mostly use the same ones. 

Below are the questions from the Nike program.

• What is the name of your company?
• Please describe your business in 140 characters or less.
• In more detail, what will your company do or make? What's new, interesting, or different about what your company will do?
• If you have a website or demo/prototype, what's the URL? Please provide username and password if necessary.
• Business Video: Please provide a video < 3 minutes long which best describes your business. Production value is not important to us, it can be quick and dirty.
• Team Video
• Please provide a video < 3 minutes long which best describes your team. Production value is not important to us, it can be quick and dirty.
• Please tell us about each founder and their role. Explain how you met and how long you've been working together. Please be thorough because we place a great deal of importance on the team.
• For each founder: First Name, Last Name, Email, Role/Title, LinkedIn Profile, Twitter, Github Profile
• Explain how the company will make money.
• Please provide information on current or likely competitors. Include key differentiators. Please include URLs.
• What are some things that the team (or its members) have built in the past? Please include URLs.
• Can each of the founders attend the entirety of the program, or do some of you have other obligations during the timeframe of the program? If not, please explain.
• Not including the founders, how many additional employees are there? Please provide LinkedIn profiles and Github URLs (if applicable).
• Where is your company located?
• Please provide information on money the company has already raised, and any information on fundraising plans for the future.
• Why should we choose your company?
• I understand that Nike will receive many applications for this program and many of them may include similar ideas. I also understand that Nike is under no restriction with regard to the companies it contracts with and the products and services that it develops or offers.

The Killer (Sensor) Surfing App

I had sensors on the mind after my post documenting some of my favorite mobile device sensors, so when a friend said there was still some surf at Rincon, I decided to head down this morning. The surf dropped since yesterday, but was still fun. However with sensors on the mind it really got me about the ultimate sensor. The killer app for sensors. That would be a sensor that lets you know that the surf is good. 

But before you say, hey just go look at the models. That's not exactly the point. Kind of, but not exactly. I love SwellWatch 3D - here's the Rincon forecast and I always appreciate that resource. But the problem with the forecast is that it only shows a couple attributes. These are key attributes, yes, but still missing a couple elements that characterize a good session. Surfing is just incredibly fickle, and so many minor factors influence a good session. For example, today the model looked a lot like the day before, however, if you'll notice it's about shoulder high, whereas the day before it was head high, and way more consistent. Also, it was more crowded than yesterday. If you look in the background of the pictures, count the surfers.... a lot. And that's only a small slice of the point.

Mobile Device Sensors

I've been evaluating the sensors available for the various mobile devices and thought I'd document some of the highlights. Sensors are an interesting aspect of mobile devices because your mobile device, whether Android or iOS,  tablet or phone, solve the last mile communication problem of many sensors. Many sensors are very local in their communication distance capabilities, either tethered with a cable, or short range like the 50 meter Bluetooth Low Energy range. However, your mobile device can link a sensor to the Internet via your wireless cell phone carrier, or via your phones WiFi connection. Furthermore mobile devices provide the computing platform and user IO functionality for sensors. So with mobile devices you have the computational, communication and user IO covered, which allows for cost effective development of sensors and sensor applications. I'm interested in sensors for both end-user capabilities as well as APIs so I'll be sure to note any APIs.

For starters, similar to the my business model and technology idea list, here is a high-level overview of some of the sensors I've been finding. 

External Sensors

HiJack: More of a sensor development platform than a sensor itself, Hijack is a University of Michigan project that provides a general purpose hardware and software platform to build sensors using power and IO from the iPhone's 3.5mm iPhone audio jack. The hardware, pictured below, is a small board with an integrated headphone jack. The software API allows the creation of general purpose sensors. The hardware is available at Seeed Studio. Some demo project built on the platform include an EKG monitor and soil moisture sensor.

The Idea Funnel

If you envision the process of brainstorming an idea to actually executing on a business opportunity like a sales funnel, then you might break up the process into distinct phases:

Phase 1 - Brainstorming

Phase 2 - Filtering / Reducing

Phase 3 - Market Validation

Phase 1 is all about volume, just brainstorm ideas. Then Phase 3 is where you might go after 1 idea or maybe do an initial market validation exercise with perhaps 3 ideas. Phase 2, and what I want to explore here, is how you narrow the ideas down from a bunch to just 1 to 3 ideas? I am not sure, but the first step might be to determine the criteria. These will be different for different people or organizations, but for me here is what comes to mind:

Business Model and Technology Ideas

As a believer that it’s not about the idea but the execution, and further that even a good idea will really evolve as a team vectors into the right set of features and market opportunity, I thought it would be safe (and fun) to list some of the various ideas I’ve looked at recently. Some of these are based on a need that I have (but not necessarily anyone else). Others are just random ideas. Some just look like fun to build. And some I guess are just downright ridiculous. But in the spirit of brainstorming, where more is better and it’s better to just get some ideas out there to evaluate, reduce and solicit feedback, I include the list below. Feedback welcome:)

I have also experimented with a sortable version of this idealist using Python/Flask/Javascript/tablesorter and hosted on Heroku.

Approach to Market Validation

I was recently talking to a California company about moving their products into the enterprise security space. The company has some really interesting data analytics capabilities that correlate complex relationships in big data. Below was my first go at documenting an approach for how I might attack the effort. I've been a student of the market validation process, and - to give credit where credit is due - I have included references below. Also, thanks to David Telleen-Lawton (and his 20 years of market validation experience) for feedback on this.

Overview of Market Validation Approach
Market validation is a structured process in which new product offerings are validated in terms of customer need and product requirements. The process provides a rapid, structured and repeatable approach to vetting ideas, identifying potential customers, market segments and messaging, while quickly determining the Minimum Viable Product (MVP) feature-set such that a viable product, business model and sales approach can be quickly identified. The antithesis of this approach is to define requirements in a vacuum after unstructured feedback from 5 meetings, spec out an expensive v1.0 product release, build it for a year only to find out that you built something that nobody wants. Or talking to 10 customers and identifying 10 “must have features” and building a product that only 10 customers will buy. The market validation thinking is more about quickly getting customer feedback and iterating the product (back of the napkin, diagram/presentation, mocked-up demo, prototype, beta version), such that when version 1.0 is released you know you are solving a generalized problem that customers will pay for - and you will have tested the messaging, know the sales requirements/channels and have tested the pricing. In fact, ultimately, you’ll already have your first paying customers lined up before you release v1.0. The process as outlined below (the timeline is measured in weeks, or a couple of months) begins this iterative process and defines the product, customers, problem and product-market fit, but the process should really continue into perpetuity as the product continually evolves. If the real estate mantra is location, location, location, then the market validation mantra is, get-in-front-of-customers, get-in-front-of-customers, get-in-front-of-customers!

Exercise to earn credit to watch TV

As I evaluate opportunities, one idea that I have been looking at involves apps, hardware and fitness for students, among other things. In the spirit of "it's not the idea, it's all about the execution" I felt no risk in posting an overview of the concept here. As a mobile app developer I really understand the app dev cycle, but the hardware component here is unchartered territory for me, though I believe there may be some opportunities to leverage an existing bluetooth power strip and API for phase one.

Exercise to earn credit to watch TV

The plan ties into the craze for fitness apps and sensor devices, such as Fitbit, Nike+, but leverages all of that rather than competes. It scales and can be built iteratively. Furthermore, the platform could be extended to address various markets, so the market potential is significant. 

The concept is to create a system that requires kids to exercise to earn credits which would be redeemed to watch TV. This ties into the American collective consciousness that kids are not getting enough exercise, watching too much TV, gaining weight, getting diabetes, etc., and generally increasing the burden on the US healthcare system ($2.5 trillion dollar industry and 17+% of GDP*). The credit system addresses a problem of such scale that it is a key initiative of Michelle Obama** and UnitedHealthCare*** .

Phase 1: Create an app and associated hardware device (bluetooth enabled smart power strip). The app stores credits and those credits are used to turn the power strip on from the app. The TV is connected to the power strip (you could create a locking version to prevent tampering, or just include a unique colored zip tie or security tape that would make it obvious if the power strip were bypassed). This could be live in perhaps 6 months. The credits could be input into the device manually by a parent for starters, but could quickly be extended to include the sensors in the phone, other apps or a Nike+ device.

IFTTT - If This Then That

IFTTT is  a web-based service that allows any user to sign up and associate events and actions with their various social media and online accounts. For example, you could set up an action that triggers a Tweet whenever you post to your blog, or you could setup a trigger to send your phone an SMS message if the temperature reaches a certain level.

A number of predefined services are setup (see image below) such that actions can be associated with services readily. For example, setting up the example triggers I mentioned above required perhaps a dozen clicks and a few keystrokes, perhaps a minute of effort.

Cosm, a good first stop for things

Cosm - a data exchange platform for the Internet of Things

For me Cosm was an early stop in my exploration of sensors and Internet-connected devices. As I prototyped a remote sensing device using the Arduino open-source hardware development platform, quickly the question arose question: "I built in Internet protocol connectivity, but how do I web-enable the device?" The immediate and easiest answer was Cosm which changed it's name from Pachube after being acquired by LogMeIn, an information technology remote access solution provider.

Cosm  provides a web-based platform to which you can connect your Internet-connected device. Cosm includes a web API so your device can easily send and receive data to/from the Cosm servers. Using Cosm with your device is as simple as signing up for a free Cosm account via their website, then using the API to send data to your Cosm account. An a Cosm client example using Arduino shows just how easy it is to send data to Cosm; the actual C code for the connection is shown at bottom.

Cosm supports JSON, XML and CSV data formats and leverages a flexible REST API so that any web-enabled device can store and manage data on Cosm. Compare this to say If This Then That, which serves as an application level central dispatch, in which application events from one of your services can send events to other services (when I post to my blog, send a tweet). Cosm provides a general purpose HTTP-based foundation to store your device and sensor data as well as a central point in which you can build out your own network.

// this method makes a HTTP connection to the server:
void sendData(int thisData) {
  // if there's a successful connection:
  if (client.connect(server, 80)) {
    Serial.println("connecting...");
    // send the HTTP PUT request:
    client.print("PUT /v2/feeds/");
    client.print(FEEDID);
    client.println(".csv HTTP/1.1");
    client.println("Host: api.pachube.com");
    client.print("X-PachubeApiKey: ");
    client.println(APIKEY);
    client.print("User-Agent: ");
    client.println(USERAGENT);
    client.print("Content-Length: ");

    // calculate the length of the sensor reading in bytes:
    // 8 bytes for "sensor1," + number of digits of the data:
    int thisLength = 8 + getLength(thisData);
    client.println(thisLength);

    // last pieces of the HTTP PUT request:
    client.println("Content-Type: text/csv");
    client.println("Connection: close");
    client.println();

    // here's the actual content of the PUT request:
    client.print("sensor1,");
    client.println(thisData);

  } 

Path - from one thing to the next

New beginnings; as of January 1, 2013, I have moved out of any operational role from Redspin,  the information security company that I founded in 2001. After a decade as a target on which to focus my passion for technology, it's time to focus my energy elsewhere. The sun sets, but it also rises. While many things are uncertain for me as to what the future brings (as perhaps with anyone), one constant in my life has been my interest in technology, the Internet and the business models and startup opportunities associated with this evolution.

As I focus my time and energy into the areas of technology innovation that interest me most, I thought a blog would be a useful tool to document my efforts. Not only will it provide a basis for communication, but the format will also provide a timeline as I evolve my thinking into my next business model or opportunity.

So I don't have any expectations as to what this blog will include or fulfill, other than it will provide a place for me to periodically document areas of technology that I am working on.