I build a lot of web apps. It's something I consider fun. Over the years, I have worked in a plethora of languages in an attempt to build the web application that would make me rich enough to not need to work.

I've written in PHP, Perl, Java, JSP/Servlets, derivative Java langs, Python, C, Ruby, C++, Tcl, Node.js and now go-lang (go).

When I say I've written in these langs, I mean I have released production applications, some that served a dozen+ requests per second, others that never got enough traffic to make that statement. All of them have their strengths and weaknesses.

Over the years, I have developed a distaste for compiled binary languages like C, C++ and Java. Sure they are very fast, usually, but they are not well suited to web application development for a number of reasons, the first and foremost is compiling takes too long, and is a hinderance to quick edits to an application. In fact, compiled languages are such a hinderance to my ability to complete work, quickly, that I actually learned Javascript single page application structure so I wouldn't need to compile Java. Fact.

Since go-lang is compiled, it immediately loses points for me, but strangley compilation isn't my primary gripe with go, it's the language's immaturity. In 2013, the web has advanced a long way, web server frameworks don't just handle parsing a request, they bring mature templating languages, modules, and other critial pieces of infrastructure to the table to provide a genuiely useful tool that facilitiates growing an application instead of fighting with parser errors and wrestling bugs found in unproven software.

It's no longer enough to release a language, library or framework, you need to provide documentation, community and 3rd party components and software, the last being the largest hurdle.

I dislike go's syntax. Of course, I can't stand coffeescript, so take it with a grain of salt. I like my parentheses. Also, I hate strong typing. The web works by passing bits and bytes, frameworks and libraries parse those into strings and then into data structures. Flexilbilty is crucial to the web and strong typing proves only to hinder. While I find strong typing useful for non web application development, I see no place for it in web apps.

It looks like go isn't going away anytime soon, and could possibly even replace C, it still isn't a good fit for web application development, as noted above. C and C++ are fast, really fast. But they make lousy web frameworks. Go ahead, name a few popular C web frameworks. My point exactly, Ruby, Python and PHP are the scripting languages of choice. Between go-lang's compilation, immaturity, clumsy language syntax, and strong typing, it's a curiosity, well suited for utilities and high volume data writes, and lousy for the complex requirements of a web application.

I look forward to seeing where go-lang goes, but I will not be adding it into my toolset, by choice, anytime soon.

Today I decided to release some work I have been thinking about for several years, but have only had the time and skills needed in the past six months to really address it at a serious level.

At the most basic, it's a library for creating a hash signature in JavaScript used to sign requests from a client to a server.

The approach I imagined has appeared more viable as the long held relationship between client and server data passing has evolved from plain text cookies to JSONP and JSON APIs and beyond.

In this demonstration code, a request is generated on the client browser and checked for validity by a simple WSGI server. The credentials used to create a digital signature are stored in local storage as private key and user app secret, as well as a user token.

The purpose is to prevent session hijacking, and similar threats, by both ensuring the request is unique as well as validiating all sent parameters by hashing them with a common secret.

It's unlikely the attacker could simply copy the hashed session value which is common in hijacking tools such as firesheep. And since a "private" value is stored, but never sent over the wire on the client, the attacker must physically compromise the machine instead of merely the network.

This is a work in progress. I would like to support a more traditional oauth pattern, using cookies to transport. However, for now, a signature is computed and sent as a request parameter.

A sample request string

http://localhost:9000/secureok ?token=f2779006bd65ad654e908a00d7ecf41fb391b307cfd341c8f24b608315bb6be9 &_auvr=1.0&ts=1352905876 &signature=0a37700e8b8a9bce427e3d97466dc32a9097b4ba952bd5a5b285916f3b72ab44

source code

The library also seeks to eleminate PII, Personally Identifiable Information, from requests and uses a token that is matched in the database for a user. Usernames, user ids or other personal information should never appear in a GET request which may consequently end up in a log file.

Since this library must work in unison with several other aspects to create a secure experience, I wanted to lay the ground work for more robust requests on the web via JavaScript, and release this code in order to collect feedback from other developers concerned with securing common requests made via AJAX through webapps.

Feedback is strongly desired from developers with a background in security or cryptography, though no bad ideas will be turned away. Please open issues in github

View source code

Flow

• /signup OR /signin
• /index
• /secureok <-- validate signature

For the future, my immediate plans are as follows

• Use clientside certificates or other device beyond localstorage
• Provide an optional oauth format for sending signature in header or cookies
• Enable clientside cookie signing for handling binary assets and allowing "page level" user login.
• Setup demo pages on live website
• Enable HTTPS on demo server
• Address more secure way to pass credentials to client beyond HTTPS

Greasemonkey to the rescue! Works in FF and Chrome, and any other browsers that support greasemonkey.

Get it on Userscripts.org

Direct install via github

The code repo.

Don't have greasemonkey? Drag this unhijack twitter bookmarklet to your toolbar and execute it on Twitter.com to unhijack your links. On Internet Explorer, you can right-click and select “Add to Favorites…”

A Little Background

On Monday evening I noticed that Twitter had launched new features for their link wrapper t.co. I'm hard pressed to call this Twitter's shortener because it wraps all links on Twitter and helps them fight spam.

Normally, the t.co features go unnoticed. For example, at least 6 months ago at the beginning of 2011 Twitter began replacing the href tags on twitter.com with the t.co wrapped link. I noticed this minor change during routine development work on http://chrome.bit.ly.

However, this latest change is causing the http:// to be hidden on links sent from the web interface. While this is helpful in saving a few characters per tweet, the side effect is a bit jarring. Specifically, if a user copies the text of a link, something like j.mp/eBzhRu, Twitter injects their t.co link instead of the selected text! This short video demonstrates this behavior http://j.mp/kOFbIi

It didn't take long to identify the offending behavior and a quick hack later via greasemonkey and the pain has stopped. The trick couldn't be more simple, cause the window.twttr.tco.displayToTco method to always return false. Easy enough

window.twttr.tco.displayToTco =function(){}

Comments thoughts and improvments are all welcome, hit me up on github or on twitter.com/gregory80.

Over the last several years, there have been many articles that have explored the changing mobile landscape. Most notably are this post from Fred Wilson and this post by Robert Scoble that foretold of the mobile revolution. I even got into the conversation via a post on my now defunct personal blog that plainly stated mobile needs to be cheaper, much cheaper, in order to ever realize a true revolution that would affect anyone outside of the tech-sphere, aka those of us geeky enough to buy any gadget that looks cool.

While the price-point issue remains a severe distraction from a true mobile revolution, Apple's move in 2010 to prevent 3rd party software on the iPhone platform began to shape how I see the future of mobile playing out over the coming weeks, months and years. Despite my personal position on Apple's decision, and what the web at large appears to view the decision as, I am not surprised by Apple's action.

Apple has long practiced platform lock-in. The blog diveintomark.com, does an excellent job explaining Apple's practice in this area. This post explains lock-in in detail and informs the rest of this article so take a few minutes and read what Mark had to say 4 years ago. After Apple announced it's iPhone policy changes, Daring Fireball was quick to defend Apple's decision to continue platform lock-in. As stated by diveintomark.com and daringfireball.com, this is Apple's decision to make, but ultimately, it will be looked back on as the moment that defined Apple's potential growth and ownership of the overall cellphone market.

There are three factors to keep in mind when looking at the growing mobile market. First, lock-in. By it's very nature, lock-in, isn't new to the cellphone market. We all sign contracts with mobile carriers to get our devices cheaper. Second, the vast majority of the cellphone market aren't smartphones, such as the iPhone, Palm Pre or Nexus S, it's regular old cheap phones, the very kind we clamored for 10 years ago as cutting edge. These regular cellphones run one OS and aren't extensible in anyway. There isn't an app store for my old Motorola Pebble. Cellphones as a computing platforms are unique to smart phones such as the iPhone or Android. Third, the mobile market is highly regulated by the FCC since mobile phones have the ability to emit radio frequencies.

iPhones are a luxury item, by design. But, they are also phones. As much as I want my smart phone to do cool things, I want it to make phone calls reliably. Phone calls that aren't being monitored or recorded by some rogue app I install. This is the most important feature of a cellphone. It's fair to say that the iPhone makes phone calls, and does a decent job of it.

By restricting the iPhone, Apple has established three things. One, the phone is stable; Two, the iPhone is safe for the masses, aka the non computer savy; Three the iPhone will progress at the pace Apple determines and approves. However, the iPhone will ultimately be the Apple of the larger PC computer industry or the the askjeeves of search -- a minor player. Phones that allow looser controls for third party developers can, and will, be favored, just as Microsoft Windows was favored for desktop computers. Companies, corporations and individuals will target the largest market that has a lowest barrier to entry. As of yet, however, this device is still unknown and this is why the iPhone continues to dominate conversation regarding the smart phone market.

The Mobile market needs the following four items realize a revolution.

• Cheap smartphone
• Cheap phone/data plans
• Open Operating System
• Open mobile carriers

While the phones continue to get cheaper, only Google has entered the market as a viable contender for an open mobile operating system, which could ultimately mean Google will emerge as the dominant company in the mobile realm. But this of course is no guarantee.

Envision the future of mobile with me for a few minutes. A future where your mobile device is more than just a toy, but rather a sophisticated device that ties itself into the fabric of your daily life.

At Seven on Seven 2010, my co-worker, Hilary Mason and her artist partner, Marc Andre Robinson, presented the concept of attaching a transmission and recording devices to regular objects. Essentially giving disposable items a recordable history. Their specific example was an umbrella http://ourumbrella.com/ with a JSON API, that could produce GPS coordinates, take photos and capture audio.

In the mobile revolution, any physical object could be attached to your open mobile device. Maybe it's your umbrella, perhaps it's your credit card, or maybe it's your dog's collar. While Apple may allow such things in the future, their current stance is to only allow restricted access to low-level mobile OS events. Essentially, Apple is the governing body for the device you own. As useful as this is during the transition into the mobile revolution, it's less than ideal for the actual mobile revolution.

The really interesting, and useful, part of a mobile revolution is paying with your phone. Not through services or having a device to read a credit card. Instead, I want to pull out my phone, rather than some piece of plastic in my wallet. Similar to those little 'go passes' banks created for key chains.

How awesome would it be if I could walk into Duane Reade, download their shopping cart App over free wi-fi, then I could just scan any QR code in the store and send a payment from my bank via my smart phone!

And who am I to say any of these things? I'm just a web developer with a background in journalism. I'm not any better at predicting the future than anyone, but I can tell you some hard facts: 13-17% of the US lives below the poverty line and the median income for the US is about $50,000. Smart phones are expensive at the moment, even the $99 ones. Then, there is the data plan, and if you aren't rich, $80+ a month, or $960 a year, for a cool toy is hardly a justifiable expense.

The iPhone had just 10 percent of the global smart phone market in 2009. That's tiny! In 2009, traditional mobile phone sales totaled 269.1 million while smart phones totaled 36.1 million for the same period of time. That means the iPhone is 1% of the total combined smartphone and traditional cellphone market.

The iPhone is cool and there is definitely a shift underway from traditional cellphones to smart phones, but the majority of popular conversation regarding mobile still surrounds the APIs that Apple will allow access to. For example the camera or GPS coordinates of the device, this creates a world where only the toys can shine on the iPhone as a platform, for example foursqaure.

I think it's amazing that foursquare has a $100 million valuation. I love foursquare and I use it. But it's a toy. They presented it at NY Tech Meetup as a game - making your social life a game. And yes, the data they collect is awesome as hell. But it's still a toy. Smart phones have yet to fullfil any real needs I have when I'm walking around. Sure, the mp3 player and camera are handy, but most people wouldn't have carried those around as separate devices if their phone didn't have such things.

Whenever I leave my apartment, I must have the following items: my iPhone because it's my phone, MP3 player, a way to connect to the internet and check email; my apartment keys and my wallet, which contains:

• my health insurance card
• several credit cards
• cash
• business cards
• Hale and Hearty free salad stamp card
• an electronic key card for my office
• an electronic key card for my apartment

These are the needs I want my cellphone, my smartphone, to meet. My two key cards emit an RFID signal. If I forget my key cards, I cannot get in to my house or my office. If I lose one of the cards, someone else might be able to get in. Why can't my cellphone do this for me? Both keycards sit next to each other in my wallet and they both work, so clearly they are emitting on different frequencies. Why can't my phone broadcast this? It can connect to the Internet over 3G, Edge or Wireless so it can clearly beam a signal out as well as receive a signal.

There will never be an iPhone app for that.

I'm certainly not suggesting the Apple App store has no purpose or that I don't derive value from it. For instance, I have an application on my iPhone from Citibank that will let me check my account balance, send payments or transfer money, but I can't walk into a store and use it like I would piece of plastic with a magnetic strip and my signature, or my barely secure 4 digit pin number. How about I generate a 400 digit private key, automatically, every time I enter an amount to a local vendor and forget the signature altogether.

There will never be an iPhone app for that.

What about a call screen app? Imagine, being able to send certain numbers directly to voicemail, or better yet an being able to block out going calls to certain numbers, perhaps when you're out having a few drinks with friends. Unfortunately, this cannot occur on the iPhone as they do not allow access to the incoming or outgoing call API. There is an app that is available if you Jailbreak your iPhone, but since that voids the warranty, it limits the potential usefulness of the mobile application.

There will never be an iPhone app for that.

These needs aren't eccentric. They aren't even absurd, but they are revolutionary for the current mobile landscape. This is where mobile needs to go in order to be an actual revolution. Apple has chosen where it wants to be in this battle: safe, secure and locked-in. So I am backing Google since it's the only open operating system in existence for mobile.

And what happens when I loose my phone after this revolution occurs? I just log into a website and deactivate the entire thing, or tell the police where it is by turning on the GPS remotely.

And when the revolution is over, my current plastic credit cards would become useless, my electronic keycards would no longer be needed. I could finally take some plastic out of my wallet and replace them with more free salad cards from Hale and Hearty.

References

Apple Lock In

http://diveintomark.org/archives/2006/06/02/when-the-bough-breaks http://daringfireball.net/2010/04/why_apple_changed_section_331 http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler

Poverty Statistics

http://en.wikipedia.org/wiki/Poverty_in_the_United_States

Seven on Seven Project by Hilary Mason and Marc Andre Robinson

http://ourumbrella.com/

foursquare.com valuation

http://kara.allthingsd.com/20100416/can-yahoo-nab-foursquare-for-125-million-or-will-vcs-prevail-the-race-for-the-hot-mobile-start-up-nears-its-end/

Mobile Market Share Statistics

http://ourumbrella.com/ http://news.cnet.com/8301-13579_3-10245339-37.html http://www.gartner.com/technology/home.jsp

RFID

http://www.zdnetasia.com/chip-implant-gets-cash-under-your-skin-39159260.htm

Android by Google

http://en.wikipedia.org/wiki/Android_(operating_system)

iPhone by Apple

http://en.wikipedia.org/wiki/IPhone

Mobile Revolution

http://www.avc.com/a_vc/2009/10/a-big-week-for-the-mobile-web.html http://scobleizer.com/2010/01/11/is-the-mobile-tech-press-wrong-in-positioning-apple-vs-google/

QR Code

http://en.wikipedia.org/wiki/QR_Code