electronic communication for the a-social

I'm not anti-social. I can't be; I have a Klout score that hovers around 50. But lately I've realized I'm ready to leave Twitter and Facebook behind.

I started on computers young. My mom and dad were in the position to put me in front of some of the more innovative, connected computing systems of the early 80's. Dad was a pretty senior tech person in the Air Force and my mom was in education research. And we hit the beginning of the micro-computer revolution perfectly. We were one of those early adopters families; we had a passable home computer and a modem in the summer of '78. Within a year, I discovered I had a second cousin who worked at AT&T and was able to get me an account on an early unix machine (and later, on ATTCTC.) I believe I was the only kid in my 7th grade class writing C programs on Unix.

I feasted on the libertarian culture of the usenet and early BBSes. I remember the day I got my first "real" email account and the joy of having to work out how many bangs people needed to put in it for mail to actually reach me. But here's the thing, the libertarian-democratic ideal of the early internet requires people to behave responsibly, not like entitled ass-hats.

Like everyone else on the early internet, I thought of myself as an advanced individual developing tools to make people's lives better. We were developing technology to cheaply communicate across national borders, enable physically disabled people and making geographic distance irrelevant. The 'net was going to change society for the better. We had a few news groups dedicated to porn, but the vast majority seemed to be about bringing people into the electronic forum and letting them find kindred souls to refine their ideas.

I was on the 'net in September 1993 when the AOL hoard overran the Usenet. Several months in, I was pretty amazed to discover that AOL peeps were, for the most part, not the classless hoard we thought they would be. Things looked good.

But then it started being about money, not people.

Don't get me wrong. I'm not a communist. I have a love-hate relationship with Capitalism, but I'm enough of a bleeding liberal to think we should add some reasonable regulation to the markets. But what happened in the run-up to the dot bomb was pretty sad to see.

Financial markets caught wind of what was going on in Sili Valley and every trader with an AOL account realized where the future was headed. Every business school grad who could spell CPU put together a plan to sell hardware, software or information. Most plans were complete garbage, but what did it matter? Once you get initial funding, you keep going until you can sell a chunk of your company to some other, bigger fool.

Where once we built (mostly) working systems to fit the needs of our users, we were now asked to build incomplete systems that looked plausible. Utility was less important than subscriber growth, because the business people wrote some very nice documents describing how, at any moment, they could convert subscriber growth into income. But why do that now when we still have a little money in the bank; we can optimize our profits by growing as big as we can as fast as we can before we start monetizing.

Everyone knows how this story ends: broken dreams, broken products and more than a few broken marriages. Those who survived licked their wounds and got back to building things. This time around we built things we could sell and we much more cautious about pushing lies about converting eyeballs to money.

But one thing that didn't ever come back... the idea that the user is in control. Sure, the user is the "center" of modern digital systems. But that's because Facebook, Twitter and Google are selling your eyeballs to advertisers. And that's okay as long as we're all honest about what's going on. But slowly we started to see federated identity systems manged by big sites leak information about users to advertisers. And don't get me started about the NSA thing.

So this is what we've become: a network of eyeballs to be sold to purveyors of crap. In the words of Tim Rice's KGB Agent from Chess, we're "prostituting ourselves, chasing a spurious star-light -- trinkets on [web pages] sufficient to lead us astray."

I'm not saying Facebook, Twitter and various Google services aren't without utility. They are quite useful at times. But we're paying too high a price for ubiquity of audience and benign voyeuristic pleasures. I love being able to talk to my relatives on Facebook, but do I really need to see so many animated GIFs of twerking celebrities?

And don't get me started about the tech culture that produced the titstare spectacle. In 1978, Aleksandr Solzhenitsyn observed that the United States was "spiritually weak and mired in vulgar materialism." In 2013, I observe that Solzhenitsyn was an optimist.

So what to do about it?

It's interesting to note that Donald Knuth (whom many consider to be the "father" of algorithm analysis) hasn't had an email account since 1990. One wonders how he is able to renew his driver's license or open a bank account. I envy Dr. Knuth's ability to function without a persistent email mailbox, but I'm not sure I could survive completely without one.

To be sure, I think we could all spend a little less time grooming our inboxes; the zero inbox concept seems patently absurd to me. It simply means you subscribe to no mailing lists and haven't given your email address to marketers.

I think the first thing we may want to consider is limiting how "available" you are. It's the third millennium; an email address is not a novel concept. You derive no social capital simply by being online. You don't have to paste your email address on every web page you produce. Consider using a web-form with a comment box (or heck, put your email address on a gopher server somewhere.) Make it easy for a human to reach you, but hard to communicate your email address to marketers and i suspect you'll have a better email experience.

Consider ignoring email through the day. Look at it once in the evening and/or once in the afternoon. Where I work we use an IRC room to communicate for important things and email to communicate status and not-overly-time-sensitive topics. If you want to kill your productivity, marry yourself to your email account.

Second, go without Facebook or Twitter for a day. I do this from time to time. I've never been a "big" Facebook person to begin with. But try stepping away once in a while. It will be there when you get back.

And lastly, consider starting or joining a "dark" social network. I've been working on these things for a bit. A "dark" social network is one with a fixed membership that is completely undetectable by the public internet. You use a browser to access it, but it doesn't have a welcome and registration screen as much as it has a "NOT FOUND" screen for anyone who doesn't know the right URL.

This isn't so much a security feature as it is an obscurity feature. It's bad to have security by obscurity, but if you actually use "real" security features like strong passwords and TLS along with obscurity, you gain the ability to not have to tell the guy you don't like your account name on this hidden service.

Dark social networks are dark only to the degree everyone in the network keeps the network's existence private. And I think we all know how well our friends keep secrets. So be careful out there; just 'cause something's dark doesn't mean it will stay that way.

One bit of "dark fun" I've been having lately is using obsolete protocols. When was the last time you were on Usenet? or used a Gopher server? Heck, most modern browsers don't even support them anymore.

Now I have to run along and update the contents on my gopher server. Cheers, all!

Generating Self-Signed X.509 Certificates

People who know me know that I love to dis on X.509 based security solutions. Whether it's implementations that just plain ignore basic constraints, or popular certification authorities that add an extra zero byte to the end of their certs... it's all just so much fun.

But it's hard to argue with the utility of a properly configured TLS layer. And until we add a TLS extension for using OpenPGP to cart around public keys in TLS handshake sequences, we're sort of stuck with X.509.

I spend a surprising amount of time generating self-signed certificates for testing, so a few decades ago I came up with a bash script to eliminate the drudgery of this process. If you're interested, just grab a copy from GitHub.

To use it, just copy and paste it from the gist page into a file you've chmod +x'd. To use it, just run the script passing the name of the host you're generating a certificate for as the first parameter. It defaults to making 2048 bit keys with no passwords, so don't use this to generate production certs (not that you should be using self-signed certificates in a production environment anyway.)

So if I wanted to create a certificate for www.example.com, and I named the script gssc, i would invoke it like so:

gssc www.example.com

and it would generate two files: www.example.com.key and www.example.com.crt. The former contains the private key and the latter is the X.509 certificate for www.example.com.

The -b, -p and -s options allow you to change the length of the private key, the password to encrypt the private key and the certificate's subject name. So if I wanted to create a 1024 bit private key, encrypted with the password "blargh" and with the subject name "C=IO, ST=Chacos, L=Diego Garcia, CN=www.example.mil," I would use this command:

gssc www.example.mil -b 1024 -p blargh \
  -s "/C=IO/ST=Chacos/L=Diego Garcia/CN=www.example.mil"

Cheers!

In Defense of JavaScript Cryptography

Google "javascript cryptography" and you'll quickly find a fair number of people dismissing JS Crypto as a fools errand. My favorite is the Matasanto Security article entitled "JavaScript Cryptography Considered Harmful." The tone of the article seems a little alarmist to me. But... it also happens to bring up a few really great points. Its critique of the current state of web app crypto is mostly spot-on. However,  the state of the art is evolving quickly and may soon make the Matasano Security article mostly irrelevant.

This post is a brief rebuttal to the assertion that JavaScript cryptography should be considered "harmful." I would completely agree with "fraught with serious challenges" and "difficult to do right," but certainly not harmful.

Why Do JavaScript Crypto?

Before you can make a blanket statement like "JS Crypto is EVIL," you really should list out a few use cases. I think it's fair to say replicating HTTPS functionality in JavaScript is a poor idea. All popular browsers provide built-in support for HTTPS. What's more, these implementations have all been reviewed by multiple people to help ensure correctness and freedom from obvious bugs. So if you're just trying to communicate a password from a browser to a web server, use HTTPS. Don't try to replicate that functionality by yourself with JavaScript.

But there are several use cases where JS Crypto may be advantageous. The two I can think of off the top of my head are end-to-end message security and Secure/Stanford Remote Password (SRP) support. Neither of these use cases are directly supported by modern browsers and are of interest to the general community.

End-to-End message security means encrypting a message in such a way that it can only be decrypted by its intended recipient. In the context of JavaScript crypto, this means your favorite email, microblogging or IM web app uses JavaScript to encrypt your message. The encrypted message is then sent to its destination by whatever means and is ultimately decrypted by a web app running on the recipient's machine. In the end-to-end encryption scenario, the server never has access to your decrypted message; and unless you explicitly share your keys with the server, they never will.

End-to-end message security contrasts with "Transport Security" offered by SSL/TLS. HTTPS, which uses Secure Sockets Layer (SSL) aka Transport Layer Security (TLS), encrypts the link between the browser and the web server. To communicate securely with another person, you would send an un-encrypted message to your web server over the encrypted HTTPS link. The server would then forward the message to its recipient using a different (hopefully) encrypted HTTPS link. Because the message is un-encrypted when it gets to the server, the server operator can see the contents of the message. But because the link is encrypted, eavesdroppers listening in to the conversation should not be able to read the message.

Secure Remote Password (SRP), formerly known as Stanford Remote Password, is an authentication protocol with many desirable features: it is resistant to password dictionary attacks and establishes a shared session key which may be used to authenticate or encrypt messages between a client and server. Or, more likely, between a client and a piece of computing equipment "behind" the web server for which the web server acts as a proxy. To be sure, the SRP's utility is diminished by the near universal support of SSL/TLS, but there are definitely situations where it can be useful.

These are not the only reasons why you might want to use something other than HTTPS; but they are two reasonably important use cases not directly supported by SSL/TLS.

The Chicken and the Egg

The Matasano article assumes the reason you're using JavaScript crypto in your browser is to encrypt a user password for its trip from the browser to the server. It then presents this "chicken and egg" problem:

• if you don't trust the internet to securely deliver a password from the browser to the client, why trust it to deliver a JavaScript encryption library?
• and if you use HTTPS to ensure no one's tampered with your JavaScript encryption library, why not just use HTTPS to secure your password and be done with it.

I mostly agree with this assessment. However, there may be a situation where your javascript encryption library is served off a different host than the one you're communicating with. Imagine you're trying to communicate with an 8 or 16 bit microcontroller. There are several on the market today with enough CPU horsepower, memory and IO to speak SLIP or PPP (or even IPv6.) Due to policy, debugging or legal reasons, you may serve TLS pages off the microcontroller using only authentication. It's a bit of a corner-case, but I've actually found myself in exactly that situation. My microcontroller could handle authentication with ECDSA, but couldn't cope with a bulk cipher I was willing to use.

But there are some interesting developments in the chicken and egg question. It turns out there's a group of people working on a specification to introduce cryptographic primitives to the JavaScript in browsers. The Web Cryptography API is an emerging standard from the W3C and will provide basic crypto functions to JS web apps. When widely deployed, this should eliminate most the concerns dealing with the question "hey! where did my crypto implementation come from?"

Good Random Numbers

The Matasano article correctly observes the JavaScript Math.random() function is inappropriate for use in "real" security protocols. It simply doesn't utilize sufficient entropy. Fortunately, Chrome and Firefox have implemented the random number generator from the Web Cryptography API in recent builds. According to this Mozilla Development Network page, support for crypto.getRandomValues() was added in Chrome 11 and Firefox 21.

If you are truly interested in properly implementing security-related protocols, you must use this call instead of Math.random().

Extensible Languages and Insecure Content

IMHO, the fundamental concern with web apps is the risk that occurs when JavaScript's extensible nature meets insecure content. The Matasano article talked about this in the context of downloading javascript to implement crypto primitives, but once a bad guy can inject code into your JS execution context, it's all borked, not just the crypto.

The problem here stems from the fact that JavaScript is, by design, an extensible programming language. It's possible to replace some of the basic functions provided by JavaScript and the DOM API. Here's a simple example where I replace the escape() function with a function that reverses a string before escaping it:

window.prevescape = window.escape;
window.escape = function( input ) {
  var output = "";
  for( var i = 1, il = input.length; i <= il; i ++ ) {
    output += input.substr( input.length - i, 1 );
  }
  return prevescape( output );
};

This example doesn't do anything horrible, but it should demonstrate how easy it is to extend or even replace core JavaScript functionality. And it's just as easy to replace the code that manages import / export of cryptographic keys as it is to replace the escape() function.

The ability to replace or extend JavaScript functionality is a good thing when you're using it to fix bugs or add useful features. But if a bad guy can insert a script tag into your page, all bets are off, you're completely 0wn3d. Since it's unlikely you're going to hack your own web app, we need to figure out a way to prevent black hat script tags from appearing in your web page.

In Conclusion

Securely executing JavaScript applications in a browser is not hopelessly borked. Neither is JavaScript Crypto. You have to take care to defend against common vulnerabilities introduced by user generated content. Unless you defend against a man in the middle by sending content capable of modifying the javascript execution context over TLS, it will possible for a bad guy to insert bad guy code into your web application.

Progress is being made with the introduction of the Content Security Policy and Web Cryptography API specifications from the W3C. We're even starting to see browser developers implement them, which is a good thing.

But more work needs to be done to "secure" javascript code. It could be as simple as making the browser's crypto object read only. This would not eliminate all vulnerabilities, but will reduce the attack cross section. We could also require that all scripts referencing the crypto object adhere to common same-origin protections (modulo CORS or CSP.)

This article reflects my personal opinion, and may not reflect opinions or policies of my employer.

A Couple Useful Aliases for EMACS

Yes. I am an Emacs user. (or, as i call it... EMACS... the editor so ossm, you have to write it in all caps!) But there are a few things I don't like about Emacs, and here's the simple solution I found for them.

Problem 1 : Trailing White-Space is Of the Devil

So if you look at the Mozilla bugs I tried to fix, I think they all have a comment from bsmith and ekr saying something like "uh.. trailing white-space." Yes. It is the sad truth, but God's own text editor has issues with leaving trailing white-spaces in code. I don't remember it used to have this problem in the 80's, so obviously this is Apple's fault.

Seriously though... I could have sworn this didn't used to be a problem. Maybe it's just we had worse tools for detecting trailing white-space and I just didn't notice. But it's really noticeable when you try to generate diffs to attach to bug reports. (The Mozilla process is to attach a diff to a bug, get it reviewed and then apply it to a repository somewhere.)

At first, I simply tried to just delete all trailing white-space in the file I was working on, but any given file in the Firefox source base, one in a hundred lines has trailing white-space so I wound up making diffs with bajillions of updates that had nothing to do with the issue at hand. To me, this stinks of bad form.

Yes, I should have created a bug titled "file foo.cpp has a lot of trailing white-space" and applied the change there, but there was about zero chance of the bug getting a positive review without someone saying "hey! why don't we refactor all the code and add these other features while we're removing all this trailing white-space." And honestly, I got tired of saying "don't make me slap you..." to all the people who suggested this.

So rather than debug a bunch of elisp code, I figured I would take inspiration from the hackers of old and just use a sed script to fix the problem. It removes trailing white-space from lines that begin with a plus ('+') character. If you're familiar with diff or patch tools you'll understand why I did this. Here's the alias I added in my .bashrc file:

alias bongo='sed -e '"'"'s/^\+\(.*[^ \t]\)[ \t]*$/\+\1/'"'"''

You can now do things like this if you don't trust your ability to spot trailing white-space in your code:

hg diff | bongo > current.diff

or if you don't trust other people, you can do this:

cat random.diff | bongo | patch -p1

Problem 2 : I Usually Don't Like EMACS in XWindows

But sometimes I do. So I do the following:

alias emacs='emacs -nw'

This tells emacs to launch in the current terminal window.

Hope these suggestions help, or inspire you to hack your own environment. -Cheers!

just sayin'

so i come from a family chock-full of baptist missionaries. my brain's been kind of stretched over the last couple days trying to square my love for my extended family with my own urge to stand up and call bullshit on this whole southern christian homophobia thing.

so let me just say this to my southern christian friends: i love you deeply and always will. i have no frame of reference to understand your opposition to same-sex marriage, but will accept it since to do anything else would be to deny your personal agency.

but i do disagree with you, and likely i always will. i hope that in time you will see same-sex marriage does nothing to diminish your marriage. i hope you recognize the desire to live in monogamous marriages extends to all sorts of people: gay, straight and all things in-between. i hope you will see that the gender of a child's parents has infinitely less to do with that child's welfare than the love and support offered the child from the parents.

my take on christ's message is we must all seek salvation by challenging ourselves to love those whom we once hated. the "conversion experience" is a chance to open our hearts and see the reflection of the divine spark hidden in the souls of others.

i love you not because the bible tells me to love you, but because it brings me closer to  my god. i do not agree with you, but i love you and no matter what you think about me or my marriage, i always will.

Learn how to encrypt your email with FREE tools (in Santa Cruz)

I was planning on meeting a few people for coffee on Thursday night (27 June, 2013) at Caffe Pergolesi in Santa Cruz and show them how to set up PGP/GPG + EnigMail so they can do encrypted email. Then a few more people started asking if they could come by...

So... if you live in Santa Cruz and want me to help you setup PGP/GPG Encrypted email (so the feds / advertisers / spouse can't read your email) come on by. If it's not raining, I'll probably be sitting outside speaking loudly about encryption technology.

So... 7:30 'til about 9ish at the perg this coming Thursday. Bring your laptop.

And if you already have a PGP key, come on by and we can do the key signing thing.

Installing VMS on Your Raspberry Pi

What is more pure than young love? And my first love in high school was for VMS, Digital Equipment Corporation's operating system from the late 70's. Sure, Unix (tm) and it's derivatives are the work-horses of modern computing, but VMS was the first "real" operating system I used. Using VMS in the modern era makes me a bit of an anachronism, but there were plenty of features I still kind of miss from the old days:

1. A sane default editor. Sure, I love emacs and vi, but you have to admit, their obscure key-commands create a bit of a learning curve. VMS's default edit command used arrow keys to move around and saved changes by default. (okay, this is more of a nit than a real feature, but still...)
2. Versioned files. VMS's file system, FILES-11, allowed you to save multiple revisions of the same file. When you created a file with an existing name, the default behavior was to create a new revision. If you made a total hash of things, reverting was as simple as deleting the most recent version.
3. Pervasive Help Files. Help files were managed centrally and IMHO thought out a little better than the Unix man page system. Also, the command to get help was help, which is more intuitive than "man."
4. Logical directories spanning devices. While not as "pure" as "union directories," it was possible to set the current working directory to a list instead of a single location in the filesystem. This had the effect of letting many commands search for files in multiple directories.

But the most important reason for using VMS these days is it's fun to challenge your status quo and try new things. And besides, I had a lot of fun with some of those old MicroVAXes, so this brings me back to a fun time in my life.

Setting up a VMS system is relatively easy (even for a novice.) The good people at trailing-edge.com distribute an open source VAX Emulator (and btw, the simh emulator emulates many other old systems.) Hewlett-Packard, the current owners of VMS, offer downloadable VMS install media free of charge for non-commercial hobbyists. And Phil Wherry has put together a really top-knotch guide for installing VMS on the simh emulator.

So if you want to join me in VMS-style retrocomputing, it should be as easy as downloading and installing the emulator, requesting a hobbyist license from HP and following Phil's install instructions.

A few things have changed since Phil wrote his install guide, so here are a few notes you may want to read to avoid frustration:

1. Don't use a wireless network as your primary network interface. Unless you use the TUN/TAP bridge described in the 0readme_ethernet.txt file in the simh source distribution, you may encounter issues placing your wireless network device into promiscuous mode.
2. HP no longer requires you to buy physical install media; you can download the files you need to install VMS directly from the web. You still need to enroll as a hobbyist with HP, but the process is a little easier and takes considerably less time than it used to. HP requires you to be a member of a properly sanctioned users group before handing out licenses, but if you've forgotten your DECUS subscriber information (like I have) you can apply for a free online account with DECUSERVE.ORG. Once you're signed up with them, head over to openvms.org for more info on how to create the account.
3. After you register, you'll get a license file from HP. Search for the VAX-VMS entry; it should look like this:
   

   $! This PAK issued on DD-MMM-YYYY HH:MM
   $ Call CheckLicense "VAX-VMS" "DD-MMM-YYY"
   $ IF ($STATUS .EQS. "%X107880D3") .OR. ($STATUS .EQS. "%X107880CB")
   $ THEN
   $!
   $ LICENSE REGISTER VAX-VMS - 
   /ISSUER=DEC - 
   /AUTHORIZATION=HOBBYIST-VA-KEYxxxxx-xxxxxx - 
   /PRODUCER=DEC - 
   /UNITS=0 - 
   /TERMINATION_DATE=DD-MMM-YYYY - 
   /ACTIVITY=CONSTANT=100 - 
   /CHECKSUM=y-yyyy-yyyy-yyyy-yyyy
   $!
   $ LICENSE DISABLE VAX-VMS/LOG/PRODUCER=DEC/ALL
   $ LICENSE UNLOAD  VAX-VMS/LOG/PRODUCER=DEC
   $ LICENSE ENABLE  VAX-VMS/LOG/PRODUCER=DEC/AUTH=HOBBYIST-VA-KEYxxxxx-xxxxxx
   $ LICENSE LOAD    VAX-VMS/LOG/PRODUCER=DEC
   $ ENDIF
   $ !

   
   When it's time to enter the license info during installation, enter only the fields that are listed in the license:
   
   

   Issuer [DEC]: DEC
   Authorization Number []: HOBBYIST-VA-KEYxxxxx-xxxxxx
   Product Name []: VAX-VMS
   Producer [DEC]: DEC
   Number of Units [1]: 0
   Version []:
   Product Release Date []: 
   Key Termination Date []: DD-MMM-YYYY
   Availability Table Code []: 
   Activity Table Code []: CONSTANT=100
   Key Options []: 
   Include Node []: 
   Product Token []: 
   Hardware-Id []: 
   Checksum []: y-yyyy-yyyy-yyyy-yyyy
   

   
   

At the end or the process, you should have a perfectly serviceable VMS System. Enjoy!

Code released for the Discovery Web Desktop

"Disco" is a new project I'm working on to produce a high-quality desktop interface experience via a web browser. There are a couple "mainstream" reasons for wanting to do this:

• Your desktop & data follows you between machines
• Software distribution costs are pretty minimal
• As long as someone backs up the server, you don't have to worry about it (much)
• It's an easy way to implement a base UI if you're making a dirt cheap computer system.

But the main reason I'm doing it is to create a platform for my unholy experiments in web application security and web-crypto. The code is at a "proof of concept" stage, but over the next couple of week's I'll be adding in the functionality from Swimming Vegetable, web widgets and (possibly) BReATHE. So if you like polished, finished web applications, this probably isn't for you.

But if you're brave... check out the Disco web desktop at http://disco.meadhbh.org/ and the source code at  https://github.com/ohmeadhbh/disco -- cheers!

On the coming of "the internet of things"

A year ago I would have talked about "THE INTERNET of THINGS." Now I'm more content to talk about "the internet of things." Capitalization can be important; just ask e.e. cummings. Seriously thought, whether you call it the IoT (Internet of Things) or Ubiquitous Computing or whatever, the ubiquitous future just isn't coming into focus.

I've been sort of thinking about this for a couple years, but it was Chris Anderson's recent tweet that got me thinking about it:

I've got ~every "Internet of Things" device, from Twine to Electric Imp, & have seen all the demos. But still can't find compelling uses...
— Chris Anderson (@chr1sa) April 20, 2013

@chr1sa is a well-known tech journalist and gadget aficionado. As Editor-in-Chief at Wired, he's been in a position to see just about every new gadget that comes down the pike. So when he starts tweeting things like  this, you have to start wondering about the IoT market. Is it vapourware? Are we just still way early? Are IoT projects suffering from poor marketing? Maybe IoT is successful, we just haven't noticed.

Before we look into the crystal ball, let's look back and find out more about ubiquitous computing...

A Brief Bit of History

Many of us first heard of ubiquitous computing by way of Mark Weiser. Mark was a brilliant guy who, in the late 80's, was thinking very deep thoughts about the relationship between people and computing machinery. Keep in mind, this is well before the web or the mobile revolution or Google or Facebook. In the late 80's computers were generally thought of as being "those beige boxes on your desk." If you were part of the computing elite, you might have a 19 kilo-baud modem to gab with people on your favorite BBS.

At a time when your average computer visionary was rambling on about how the Internet would change the world, Mark was talking about a radical new way to interact with computing machinery. In his 1991 article for Scientific American called "The Computer for the 21st Century," he leads with the statement "the most profound technologies are those that disappear."

By the mid-90's a few core concepts in "Ubiquitous" or "Calm" computing had emerged:

• The purpose of a computer is to help you do something else
• The best computer is a quiet, invisible servant.
• The more you can do by intuition the smarter you are; the computer should extend your unconscious.
• Technology should create calm

Despite the fact these ideas were being spawned by some of the same smart people who brought us Ethernet and Graphical User Interfaces, they were largely ignored in the dot-com era. The industry was too busy consolidating heir gains from selling main-street incremental improvements over BBSes.

During the technology marketing intermezzo of the "dot bomb," we started hearing rumblings of a new "Internet of Things." It's easy to think that the Internet of Things is just the previous decade's Ubiquitous Computing with a slightly different marketing pitch; and if you only look at the technology, it probably is. But if you look at the business objectives, they're nearly polar opposites. (More on this later...)

The mid-2000's was a relatively difficult time for technology vendors. The Dot Com bubble soaked up a tremendous amount of venture capital; after the bubble burst, that money was lost and investors started asking serious questions from tech firms like "how are you going to get money out of this? and if you say ad sales, i'm going to slap you."

Ubiquitous Computing, with it's promises of changing the way people thought about computing, was a high-risk business proposition. If you did everything right, you could become "the Microsoft of Ubiquitous Computing." But it was very difficult to forecast what the market would look like in the ubiquitous future. Our experience was with selling devices you could hold and with software you could see running. "Ubiquitous" promised us a world where we wouldn't notice the computer. Talking about a product that is virtually indistinguishable from the background makes marketing people very, very nervous.

It's no surprise people started talking about "the Internet of Things." You could actually put your brainstem around it. The IoT is about putting a IPv6 address on every small device so it can stream information to your desktop (or maybe a server app somewhere in the cloud.) Medical and Logistic industries were to be revolutionized by IoT technology, goes the common narrative. After that, the technology will become cheap enough we'll start putting sensors in lightbulbs, carpets, planters, car tires, and every other thing we can see. We'll be awash in environmental data; all we need do is peek into the ether and pluck out the bits we're interested in.

IoT technology has worked somewhat well in the logistics arena; bar codes on inexpensive packages, RFIDs in consumer products and Wi-Fi enabled smart-buckets on factory floors have improved supply chain automation (and presumably enhanced manufacturing efficiency along with it.) Medical sensors have gotten smaller, cheaper and a more disposable in the last couple of decades. But we're a long way from the star-trek future where the ship's computer will constantly monitor your health and tell you need to take emergency meds or call a doctor.

The Unenviable Now

So we're now in a place where Chris Anderson (of all people) puzzles about the usefulness of Twine and Electric Imp. What's up with that?

Context. That's what's up with that. And narrative. And a seamless experience subsuming into our unconscious. Twine & Electric Imp are technology solutions for people who have already figured out some of their environmental computing problems. Unless you know you need temperature, pressure and humidity sensors or need to connect your digital bathroom scale to your iPhone, they come with no use context. There is no default story you can tell the consumer that puts them in the narrative.

I hate to say it, but some of these products are problems in search of a solution.

But it may be okay that you, or me, or Chris Anderson can't find a use for Twine or Electric Imp. As long as there is someone out there who can. Eric von Hippel's texts on innovation talk about "lead users" who identify solutions for specific problems early in a technology life-cycle. If you can't find the mass-market demand for a product, it might just be that you're not in a situation where a particular technology solves your problem.

So it may not be that there is no demand for IoT tchotchkes, it may just be there's no well defined mass-market demand.

Lower Case "internet of things"

There's a joke in the Artificial Intelligence community that "Artificial Intelligence is 10 years off... and has been for the last 50 years!"

Very few people now believe we'll see early ideas of Artificial Intelligence come to fruition in our lifetimes. That is to say, we probably won't have to worry about AI's like HAL-9000 going on astronaut killing sprees anytime soon 'cause we're unlikely to see an AI that can generally simulate all aspects of human cognition.

But even though we don't have intelligent robots doing all the work we want to avoid, the study of artificial intelligence has led to some wonderful technologies like natural language processing, neural networking for image stabilization and even self-driving cars.

These spin-off technologies are often called "lower case artificial intelligence" to distinguish them from the holy grail, upper-case Artificial Intelligence people simulators like HAL-9000 or William Gibson's Wintermute.

So even if we haven't seen the benefits of "The Internet of Things," maybe products like Nest, Hone and various heart rate monitors are the lower-case "internet of things."

Features of a Good Cloud Operating System

I'm a fan of "the Web." I drank the Web 2.0 Kool-Aid and believe in the Internet's ability to dis-intermediate, disrupt and enable.

I like "the cloud" even though I know most ASPs are probably storing my password in the clear or hashed with MD5.

I live in fear of the day Google decides to switch off Google Docs or Google Music. I worry that I sometimes depend on services that fail a year after launch.

I'm a "lead user" living on the bleeding edge of technology. Stuff *mostly* works, but I wish I could stop worrying and love the web.

I've been waiting for other people to build software that makes me less nervous, but I'm starting to get tired of waiting.

I want to build a "Web Desktop" that lets me keep my data where I want to keep it and display data the way I think it should be displayed. Here are a few ideas I'm kicking around for software I'm about to build.

Idea 1 : I decide where it's hosted

I know this isn't an answer for everyone, but I don't mind too much if I have to put up a server. Heck, I might just load the software onto a Raspberry Pi and serve it from my house.

If someone hosts the software I write for me and charges me a couple bucks per month, I'm down with that. As long as they're trustworthy and clueful.

Idea 2 : I want to see a dashboard instead of a screen saver

When I wake up in the morning, I would love to see a Dashboard on my Roku screen. Or as my laptop's screen saver. Or whenever I hit F1.

What I put on my dashboard will be:

1. Today's Calendar
2. Weather info for the next two or three days (but certainly for the next twenty-four hours.)
3. List of the top five "To Do's" (both personal and work.)
4. Upcoming deadlines or important dates.
5. The "Has North Korea Nuked Austin Yet" indicator.
6. Traffic information about my commute.

The web app I'm going to build will be something like a "dashboard construction set" so you'll be able to put stuff you like on your dashboard. I don't really track my Klout score and could care less how many friend requests i have outstanding on Facebook. But that might be important to you, so I'll figure out a way to do that. And I'll build a simple widgety client thing so other people can build dashboard widgets. I probably wouldn't have to do this if JavaScript widgets didn't suck on Linux (and let's not even mention how they disappeared from Windows.)

It would be super-awesome if I could make it with different dashboard layouts for 1920x1080, 980x1228, 600x800 and 320x533.

Idea 3 : It's about the context, stupid!

Why is this such a difficult concept for software vendors to grok. I am more concerned with "context" than with apps. or documents. "Context" is not about tools, but about tasks. "Context" has less to do with workflow artifacts and more to do with "Who am I doing something for?" It's also about understanding what I'm willing to be distracted with.

What does this mean in practical terms?

First off, I need multiple virtual desktops (or webtops, since I'm implementing this in a browser.) When I'm in the work virtual webtop, I don't want to see facebook updates. I don't really want to see personal email alerts. I'm happy to take calls from my family, co-workers and my child's school, but that's about it. In my personal virtual webtop, I only want to see work email alerts for "important" emails.

And most importantly, I don't want to see either a grid of applications OR a grid of documents, I want to see application AND document icons.

And when I open a document in the work webtop, it should stay in the work webtop, even if i switch to the personal webtop.

To me, context is about:

1. Things I do
2. Things I do it to
3. Who I do it for
4. What I'm willing to be distracted by

Idea 4 : No. Really. It should work everywhere.

It's unlikely I'm going to write a twenty page document on my mobile phone. I would like to be able to open a document, search for the word or name I just realized I mis-spelled, fix it and save the document back to the cloud.

If it works on the desktop, it should work on the mobile phone. If I'm stupid enough to try to edit documents on a mobile phone, I have larger problems than some product manager worrying that it will be a sub-par experience.

Idea 5 : Well-Defined APIs would be nice

In the glorious future, when we have our Internet of Things, we're going to get data from all sorts of little devices. It would be nice if they spat out data in well-defined, possibly self describing chunks. Things they speak to should have well-defined APIs. I want my car's gas tank meter to send data to my dashboard app so it can wake me up 15 minutes early 'cause it knows I'm headed to San Francisco tomorrow and I don't have enough gas for a round trip (ergo, I have to hit the bio-diesel station on the way into the city.)

Idea 6 : Apps should "play nice" with the dashboard.

To the degree it's possible, I would like widgets and UI components for apps to bundled up and delivered to my user agent (web browser) as discrete chunks. I want to be able to set a theme (like large text, high contrast, etc.) and have that theme be honored by widgets and app UIs. Yes, I understand this means I'm going to have to have a reasonably robust and potentially non-css styling language. I hope I can just get away with LESS stylesheets run through handlebars templating.

Idea 7 : Data and code come from anywhere

Yes. I know. It's an XSS attack waiting to happen. But I'm confident I can code safely, especially with the Content Security Policy API coming down the pike. Maybe in the future we'll have a reputation service instead of an app store. Before you install an app, you can automagically check with your constellation of reputation providers. That way the devout, morally straight Mormon down the street can point to the LDS reputation service to prevent his kids from downloading the Suicide Girls calendar app, while I can add the Wicked Grounds recommendation service to my list of app reputation providers.

Idea 8 : Maybe we could have accessibility features that don't suck

JavaScript heavy applications have the reputation for not playing well with screen readers. Maybe we could include a text to speech renderer in the system and convince app developers to expose data to the renderer. In the glorious future, we're bound to have web apps working on mobile phones in cars, so a voice API might not just be for the vision impaired, but also for drivers who want to work hands-free.

Other features like high contrast and large print themes should also help the over forty crowd.

In Conclusion...

So... I haven't started on any of this yet, so feel free to chime in. I'm mostly spitballing ideas, but I'm going to start coding tonight. I'll come back in a couple days with a pointer to a GitHub repo and a few notes. Cheers!

On Cloud User Experiences -- Maybe the Network Really Is the Computer?

John Gage is famous in Silicon Valley for coining the phrase "The Network is the Computer" way back in the 90's. Sun Microsystems took the phrase as it's product management mantra a couple years later. This was a bit of a leap for most people in Sili-Valley, leading to a number of jokes at Sun's expense (my favorite was a t-shirt that read "No wait.. the network is the network, the computer is the computer. Sorry for the confusion.") Gage may be eventually proved right (though Sun might have been decades ahead of the market on this one.)

Software as a Service (SaaS) has been a viable mechanism for delivering solutions to customers for at least a decade. The number of Application Service Providers (ASPs) are growing at least as fast as Independent Software Vendors (ISVs) focused on desktop systems and if we are to believe the trade media, corporate IT managers are clamoring for more Cloud-Based solutions. ISV growth is focused on mobile platforms (almost exclusively Apple iOS and Google Android.)

But maybe there's a future for the mobile web. Maybe the idea of buying and explicitly downloading a an app will go the way of the floppy disk. There are several very good economic reasons for corporate users to move to the mobile web; if ASPs can deliver half-way decent experiences via the mobile web, they have a good shot at taking a chunk of the mobile and desktop app market away from existing ISVs.

And who knows... maybe the next desktop computer you buy will run a web-oriented operating system like Google's Chrome OS or Mozilla's Firefox OS.

So what is a Cloud-Based Operating System anyway?

Ask a hundred product managers what a "cloud based" operating system is, and you'll probably get one hundred different answers. There are a lot of people who use the term to describe customized Linux-based OS distributions optimized to run a browser (and little else.) Google's Chrome OS is the exemplar of this class of distros, but it's certainly not the only one. Other people will tell you the term "Cloud OS" means a particular web application running in a browser that lets you perform typical tasks like editing documents, sorting pictures and even sending documents off to be printed.

But I think I agree with John Gage on this one; "the" computer is no longer the one on your desktop (or in your hand.) If you think of "the computer" as that thing that performs data manipulation tasks on your behalf, it's now spread out across your desktop, your phone, your tablet, your home router and any number of servers across the network. So if "the computer" is now spread across so many different systems, then "the operating system" is too.

Nomenclature fails us in this regard; in the mind of a typical user, terms like "computer" and "operating system" have evolved beyond their technical definitions. "Computer" is synonymous with "Desktop Personal Computer" or "Laptop Computer" these days. You rarely hear people refer to their smartphone or game console as "a computer." And what do most people know about operating systems? Not that they're privileged code bases which manage system resources, but that "an OS is the thing that draws windows on the screen and determines which apps you can run."

From a technical perspective, it seems wrong to call a collection of application software running on a constellation of computers an "Operating System," but from the user's point of view, that might be the most salient feature of future systems. In the future, users may stop looking for the Windows or MacOS X logos on shrink-wrap boxes and start looking for the "Salesforce Compatible Data Source" logo on various web pages.

In the future, when people talk about "the operating system," i believe they'll be talking about network APIs that let systems from different organizations safely share a user's data for the purpose of doing something useful for that user.

No, Seriously, What do I install on my PC?

In the future, I think there will be less "installing" going on. I believe you'll browse to an application's web page, click the "I Agree" button on the EULA and User Interface components will magically appear on your devices. Where we now have App Stores, I think we'll have independent reputation app databases in the future. As part of the process of "installing" a future Cloud-Based OS app, you can configure your user interfaces to check one or several of these reputation databases to ensure they're not malware (or that they don't use bad language, or that they don't show naked people, or ...)

People have long since stopped installing operating systems on hardware (with the exception of power users and Linux fanatics.) PC-based video games are now increasingly distributed online (see Valve Steam or search Amazon for "software download.") Even with bandwidth, security and server costs, online distribution is much cheaper than putting DVD-ROMs in physical boxes. The only reason to distribute your software through a physical retail chain is to appeal to those people who still prefer to buy "things" in computer stores.

In the future, we may see the thin client market evolve into a "slightly thicker client" market. Thin-client class hardware might be fitted with an embedded Linux operating system which boots into a browser. The browser's home page would be set to Google Apps, Facebook, Salesforce or a "Web Desktop" like Glide or G.ho.st. Maybe Microsoft or Oracle will leverage their relationships with enterprise customers to build a "Enterprise" Web Desktop.

Or maybe Community ISPs can become relevant again by selling cheap thick clients that point at Web Desktops served by their systems. Ditto for wireless operators.

What do you install on your PC of the future? Nothing. It's all over the net.

Where does my data go? Where does it rest?

So hopefully you've been asking yourself, "Hey!? Who's got my data!?" Imagine me waving my hands as my eyes glaze over and I solemnly intone, "It's in the Cloud! Beyond the confines of physical reality!"

I would hope that at this point, you would be thinking of how many seemingly decent ASPs can't seem to properly hash your password. There are true risks to putting all of your data out in the cloud. Luckily for web application operators, it's easier to quantify beneficial cost savings than detrimental security risks.

There is no simple answer to "how much risk can I tolerate?" Enterprises will (no doubt) insist that sensitive corporate information be stored on their own servers or those owned by trusted third parties. Individual consumers, who may be using the web to share data with friends and family, may be more risk tolerant.

Any viable web of the future must be flexible enough to support the high-assurance requirements for enterprise customers and the cost-sensitive nature of the consumer market.

Value Added Interfaces

If you go to any typical online application today, the way you get data into the application is by direct user input or uploading files from your PC. And yes, I do mean PC. Even though it's possible to upload  photographs and videos from tablets and smartphones, uploading other data files is a less than compelling user experience.

In the future, I believe we will see "Value Added Interfaces." These will be RESTful Web APIs applications use to share data on a user's behalf. For example, imagine you had a mailing list in a spreadsheet on Google Drive. Ideally, you should be able to give a Google Drive URL to a network based printing house who will do a mail merge for you. The printing house's software queries the Google Drive URL for a CSV formatted address book and "does the right thing."

I believe it will be possible to effectively secure these interfaces; even sensitive data will be available to authorized consumers. In the future, payroll companies like ADP may provide an interface directly to Intuit so your personal tax information is fed directly into the Intuit app. Or Exxon will provide details of fuel purchases directly into your corporate accounting system.

If we want to enable a "all my internet of things data is in the cloud" future, we'll need to move past our reliance on file uploads. They are a legacy of the PC era.

What will I see when I log in?

I have to admit, I don't like the term "Web Desktop." It enforces a PC era model on the cloud-based mobile data future. I don't like the idea of a grid of applications 'cause many times it's useful to think of documents or tasks or modes of thought. Twitter is talking about expanding the types of "cards" they use to summarize information in tweets. Maybe a stack of twitter-esque cards would be a suitable interface? Maybe a "dashboard" summarizing information and tasks of interest to you?

I don't know what you'll see on your screen when you log-in in 2018. Whatever it is though, it will likely be rendered using JavaScript and HTML5.

W00T! Computer Game Camp!

I love being an adult, but there are times I'm jealous of my child. This week was one of them.

The Offspring was enrolled in the Santa Cruz Maker Factory's week-long Minecraft Camp and the one-day Intro to Game Design Course. People who know my child and I, know of our family's love of all things Minecraft; so it's no surprise the Minecraft Camp was a hit. But it was the Intro to Game Design (for 9-12 year olds) course that surprised me. It was the best enrichment activity for my small one I've seen in a while.

Okay... a little bit of background. I'm not the worlds best games programmer. I wrote a couple simple games in the early 80's for the Apple Lisa and Atari 520ST. I also worked at Linden Lab for a while, trying to make Second Life a better place for everyone. But I don't really consider myself a games programmer. Part of the reason is game developers are some of the most overworked computer programmers I've seen in a while. So it was with a mildly heavy heart I heard The Offspring select game development as a career at age 8.  Yes, very cool my child wants to do something technical with an artistic bent; sad that it's a career that involves less sleep than a mother wishes for her child.

But seeing the joy that (not only) my child expressed during the Game Dev Course sorta changed my mind on this one. My kid positively lit up during the class.

Yesterday's class was taught by Joe Allington, who is himself finishing up a degree program in game design at UCSC. Joe was a great instructor, bringing a palpable love of the subject matter and excitement to the course. He used YoYo's GameMaker Studio as a platform to step the kids through game programming basics: (what we used to call) player graphics, basic game logic and simple animation. By the end of the course, the kids were adding their own animations and sounds, adding new game elements and effectively building completely new game levels. (Note: there's a free version of GameMaker Studio for Wintel and Mac at YoYo Game's web site - we downloaded it and are using it continue hacking platfomer levels.)

I give this course a thumbs up. If you have a child between 9 and 12 who likes games, check it out. (Also, I was happy to see the class was not all-male. Don't shortchange your daughters' futures by thinking they won't like or be able to handle game development. Girls can do GameDev too!)

Web War II

Another 100 word story for Crap Mariner's contest. Check out all the contest entries, they're fun!

"Captain Gecko reporting as ordered!" the middle-age, bedraggled officer said as he reported in. Colonel Layout returned his salute and gave his subordinate a quick glance. After years of Web Wars Gecko was still a solid soldier; frayed around the edges, but still solid.

"Gecko," the colonel started. "This damned campaign has flipped over to quirks mode and reports are the border: just turned red. General staff fears it'll be dotted with holes after the next event loop"

"Gecko, you have a right to know. Franky, we have reports..."

The rest was lost in the scream of a page reload.

smuggery = smugness + buggary

This is a story I wrote for Laurence Simon's 100 Words Story challenge over on OneADayUntiltTheDayIDie.Com. If you write words, you should go over there and do a couple of the challenges.

The only thing that saved ol' Jim Malone was the wet darkness of the city street. Leaning back to avoid the crooked merchant's fist, the old war wound and rot-gut whisky conspired to plant him face-first on the pavement.

All the way down he's looking at the flash of the tommy gun. That's got to be Li-Sheih's boys. "Crap," he thought to himself, "led them right to the old man."

He woke next to an old dead body, the crowd starting to close in; pellets of tea scattered on the sidewalk and the stench of pu-ehr in his nose.

Swizzles Matlow

"Swizzles Matlow" is the name of a British confectionery company. But my friend Beta commented it was the perfect name for a character in a pulp noir novel, so I came up with the following two snippits. Both received a good reaction from my Facebook friends, so you'll probably see more of Swizzles and Nick. The second one started out as a comment to a one line status update a friend of mine made about measuring cups, that's what the measuring cup reference is about. Bonus points if you know where Mary-Allen is.

In Which Swizzles and Nick are Introduced...


She walked into the room with a gait that hung in the air like a broken question mark. "Aren't you going to buy me a drink, Mr. Danger?" she asked.

"Not sure I want to get involved with a dame who can break punctuation marks," I replied. "Besides. wehaven't been introduced. You obviously know my name, but what do they call you at the orthography repair shop?"

Her eyes flashed for a moment and a smile dusted her ruby-red lips as she said "Names? Names aren't important; they never were. But if you need something to need a convenient placeholder for cognitive processing, you can call me Matlow... Swizzles Matlow."

Swizzles and Nick Share a Tender Moment


It was a dark and stormy night as a shadow moved across the half-lit back alleys of the city. Two figures meet on a lonely street-corner. Masked by darkness, the first man's chiseled face is briefly lit by a quick drag from a cheap cigarette, betraying a crooked nose and a two-day old beard. Throwing the butt into the street, he muses about the fragility of life while watching the gutter-water carry the dirty cotton trash into the storm-drain. How like life; carried by barely seen forces towards an ignominious end.

"Do you have the package?" he finally asks, his words slow and deliberate.

"Right here. You have the cash?" the other says in reply. Her soft voice betraying a femininity hidden under an oversized Canada Goose(tm) parka.

"One dollar, ninety-eight Canadian; just as we agreed." he says, reaching for his wallet.

"SLOWLY!" the other demands, her instincts tripped by the sudden move of a hand into a breast pocket.

"Don't panic, Swizzles, I'm just going for my wallet," he says in his calmest voice. "You're my best source, there's no way I'm letting you get hurt." A wallet slowly emerges from behind his overcoat lapel. Flipping through the cash he peels off two one dollar bills. "Here, keep the change," he says, holding out the bills.

"You're a saint, Mr. Danger," she says, "and what do you know about getting hurt."

"Swizzles!" he pleads, a faint note of pain in his voice, "that's not what I meant." He continues, his voice beginning to crack, "And I think we both know about pain." Regaining his composure, his solid persona re-emerges with stern determinism in his voice, "Let's keep it about the transaction."

Opening the package he examines the merchandise. At once he discovers the flaw: "WHAT ARE YOU TRYING TO PULL HERE!" he yells. Two men he didn't notice before down the street suddenly stiffen and look their way.

"You asked for a measuring cup. I brought you a measuring cup. What's your problem!?" As she speaks the men down the street begin walking in their direction.

He talks fast to try to hurry the transaction. The interlopers down the street are walking slowly and cautiously, but it won't be long 'til they're close enough to make it a bad day for the both of them. "This isn't a cup! It's metric. And it's 250 milliliters. A 'cup' is an imperial measure. It's close to 240 milliliters. I can't use this!"

Swizzles thinks fast and makes a fateful, snap decision. The men now rapidly approaching are clearly part of the Mary-Allen Tong. She knows Old Man Li will be furious he was cut out of the deal. "Here! Take Mine!" she nearly screams as she removes her personal measuring device. "It's a third cup measure I use for rice, textured vegetable protein and other dry goods. It'll get you through 'til we rendezvous again."

Danger grabs at the cup and suddenly he finds himself grabbing her hand. He doesn't want to let go. A tear begins to well up from the corner of his eye, washed away by the cold rain coming off the lake. "Let go, Nick," she says, "you have to let go."

"I was a fool to let you go before," he says, his eyes locked on hers. His eyes, open to her completely, perhaps for the first time, reveal the depth of his love and the pain he endured when they fell away from each other.

"Oh Nicky!" her voice trembles, clipped by a quivering lower lip. "You must let me go."

Her head turns as she pulls her hand away from his. She doesn't look back as she walks out of his life once more.

On the north side of town a private dick drunkenly mumbles the words of old love songs, poisoning himself with cheap liquor just to get to sleep. In the background, the story on the TV news is about two unlucky south-side mob enforcers who wound up dead. Empty Micky's Big Mouth bottles litter the floor of his cheap hotel room and somewhere a woman cries herself to sleep.

Growing Corn

“I don’t want to hear your philosophy if it doesn’t grow corn,” he used to say to me. It was a quote from an old geezer who lived on the reservation up the highway.

There was a perfect place he knew to picnic on Highway 200 behind a stand of trees. We used to go and eat and talk and make out. He knew the owner so it wasn’t trespassing, he said. In the summer it was perfect; it was just warm enough to take some of your clothes off and there was a cold stream to stick your feet in if you got too hot.

We went up just about every day after he graduated; except Sunday. Sunday was for church -- I felt weird going to church in the morning and sneaking off to the woods in the afternoon. Every week I got the lecture about how much God loved me, and while it felt good to make out. Okay, okay, we were making love -- having sex. I don’t like that; just say we were making love. But I know God loves me, but making love felt too... it felt too fundamentally right to be a sin. But back then I was still a little unclear on my personal relationship with Christ. It seemed rude to hurt God’s feelings, but it still felt like it was okay.

So we would be up there just about every day for an afternoon picnic. In the great outdoors with not a stitch of clothing between us; but it still felt safe. No one could  see us but the songbirds. We talked about a lot of things; never about him leaving though. After making love we would lay back and try to see the clouds through the trees, saying which of our friends they looked like.  I didn’t realize clouds could look like baseball players and cheerleaders and debate team captains, but they can. We talked a lot about writers; he said he wanted to go to college and become a writer.

He certainly did read a lot. That’s where he got the corn quote from. Or the quotes about religion. And the quotes about people. He had a lot of quotes handy and memorized some of the Shakespeare sonnets. I read them now and they sound funny; but when someone’s reading them to you...you just don’t know what it’s like ‘til someone does it.

One time I got very angry when he teased me about going to church every Sunday. “Religion is the opiate of the masses,” he said. I told him I didn’t like how he would say things about my church; he didn’t know anyone there. They are all good people and help each other out; just like any religion tells you. Even humanism says it’s a good idea to be nice to each other, or at least that’s what I read.

One time I started talking about how being kind sometimes means confronting people you love; kicking them in the butt, so to speak. But then he cut in with “your philosophy doesn’t grow corn!” and try to splash water on me.

At the end of the summer I had finally gotten through to him. And for a couple weeks we had some really great times. Be patient, all ye sisters with well-read boyfriends; one day you will get a word in edgewise.

The night before he left for the Marines we drove out one last time and lay under the trees. It was starting to get chilly at night, but there were still a few lightning bugs around. They were like little stars hung under the firmament of leaves and branches.

I got a few letters from him when he was in training and a few more when he was overseas. They weren’t regular, but I could kind of tell things were rough. I think he was trying to hold on to anything normal in his life, so I would write him back telling him to stay safe so we could drive back out to our old picnic spot and he could tell me all about writers and philosophy.

There are no secrets in a small town and everyone knew we were going steady. No one asked me to prom ‘cause they knew I would say no. My last quarter in high school, everyone knew I was ready to be gone. When he got back from the Marines, we were going to move to Northfield and give the “young couple in college” thing a try.

It was weird when his father came over to the house. I don’t know what I was thinking he was doing there. His dad was the town dentist; I honestly thought he was coming to scold me for not brushing my teeth after lunch or something. We almost got all the way through it before we both broke down crying. First me, then his dad. He had died from wounds received during a firefight in an area that was supposed to be safe; that’s all I remember.

I used to go out to our spot up on Highway 200 from time to time and scatter wild rice to try to get the songbirds to fly in close. It was always Blue Jays that would take the rice, but I guess that’s okay.

One day I saw a couple of kids up near our old spot and thought it best to give them some distance. I guess our old spot wasn’t as private as I thought.

The next summer I came home from Moorehead and asked his dad to go with me to church.. We sat in the back row while the preacher talked about forgiveness and light in the darkness and everlasting life. I don’t know if I believe in heaven; if there is an after-life, it’s better and different than this one. After the service we hugged and he walked up to look at a painting of Jesus on the cross. He looked at it like he saw something for the first time and slowly walked back out to the car.

Sharing Things (Vaguely Securely) with Mobile Devices

One of the things I do in my work is very basic User Experience problem solving. A fun problem just emerged and I wanted to share some of the work I've been doing on it.

So a couple weeks ago I was talking with a friend whose mobile app is 98% finished. They've been having a fun time, getting to play with all sorts of new technologies: Augmented Reality, Near Field Communications (NFC) and the latest UI widget sets. At one point, we attempted to share data between our handsets (which is what the NFC portion is for.) Well.. it turns out there are still a few snags in sharing data between devices from different manufacturers (and possibly different versions of the Android OS.)

I am not an expert in making NFC work on Android, but I've got to think if it was hard to share data between a Android Ice Cream Sammich and Anroid Jelly Bean, there's no hope of getting things to work when you try to communicate with iOS users (not to mention Boot2Geko, BlackBerry or WinMobile)

So I got to thinking... how do you easily communicate a small amount of data between two devices when the users are standing next to each other? It should go without saying, this transfer should be reasonably secure; an eavesdropper should need to be close enough that the people involved could see large antenna or telescopes sticking out of their backpacks.

The industry is gearing up for NFC and that's great, but I can't help but think someone in the value chain is going to try to put a wall around users. If it's not Apple or Samsung forcing users to use a manufacturer-specific UI or API, it's probably going to be the carriers being jerks and requiring app developers to pay stacks of cash to digitally sign apps that can use NFC devices.

So I then hit on the idea of using QR Codes as a sort of "poor man's NFC."

Sure, QR Codes aren't super popular in the states, but there's enough support in Europe, Japan and US Geek circles to make it worth thinking about.

My idea is to add a "show QR code" feature to apps or mobile web pages. The QR Code resolves to a randomly generated URL that has just enough smarts to communicate application state or data from one mobile device to another.

So... if I wanted to add a "share this track" feature in my audio player app, i would press a button and a QR Code encoding a URL for that track would appear on my screen. The person I want to share it with would use their QR Code scanner to scan my screen and be taken to a "meet in the middle" application out on the mobile web.

The "meet in the middle" app should be specific to the transaction; it should only allow that one particular track to be shared and the URL should be active for only a few minutes or even for a single use. If this is part of a legitimate music sharing service like Spotify or Rhapsody, we probably should log the user in to make sure they're allowed to receive the track. Authorizing the user isn't strictly required for sharing data through random URLs embedded in QR Codes, but it's probably a good idea. Once the receiver scans the code and is redirected to the "meet in the middle" application, it can do whatever it needs to do to complete the transaction.

But anyway... the big idea here is there may be some roadblocks to deploying NFC for generic sharing applications, so consider "meet in the middle" URLs encoded into QR Codes. QR Code readers are more or less universal for smart phones and bad guys would have to get close enough to scan someone's screen to get the randomly generated URL.

I put together a very basic demo at the QR/UX Demo Page and invite you to try it out!

Taking my Radical Tech Agenda to the Air

At 10AM on Saturday, February 9th,  the Union of Benevolent Electrical Workers (UBEW will be co-hosting GeekSpeak, the local weekly tech radio show and podcast. We will be discussing our "radical tech agenda" amongst other things.

If you're unfamiliar with GeekSpeak, you should check them out. I listen to them most every week -- strangely, they come on the radio about the same time I'm usually starting my weekend soldering projects. So for me, it's great... I have a soldering iron in hand, listening to people on the radio talk about geeky subjects. If you're a pod-casting type, you can subscribe to their feed via the NPR Podcast Directory.

The Union of Benevolent Electrical Workers (aka UBEW) is a "radical collective of individuals doing socially beneficial things with technology who come together for mutual assistance." We're like a Dadaist users' group focused on things that help the local community. For instance, UBEW and the Santa Cruz Free Skool offer classes in tech-related subjects ranging from PHP & Java programming and cryptography to basic soldering.

There's also an outside chance we'll talk about the etymology of the term "Code Mollusk."

If you're in the Monterey Bay area, you can listen in on 88.5 KUSP or repeaters at 89.1 (Hollister/Gilroy), 89.3 (Downtown Santa Cruz), 91.3 (Palo Colorado Canyon) and 95.3 (Big Sur Valley.)

If you live somewhere else, you can listen on the web using the KUSP web player at http://www.kusp.org/listen-live.html .

Feel free to call in during the show and toss questions our way. 831.476.2800 or 800.655.5877
In short, we like to think we're doing good things for our community and we're going to be on KUSP 88.9 at 10AM next Saturday (February 9th, 2013).

A Tale of Six Keyboards

Your keyboard sucks. It's okay, mine sucks too.

I'm not saying they're unusable, but I've been thinking about some of the UI work I did in the 80's and 90's and realized that computer keyboard design has converged on a usable, but still mildly sucktastic norm. I'm going to talk about the standard US 104 key keyboard, but standard keyboards from other countries suck in very similar ways.

Keyboard 1 : PLATO Terminal

So look at this keyboard; it's from a PLATO Computer System terminal from the 1970's. If you look closely, you'll see a few keys that might seem strange to modern sensibilities. I'm quite partial to the EDIT, COPY and ERASE keys. Think about the number of times you hit Control-C each day. In the 1970s we had our own key for common operations, we weren't technologically devolved cretins content to swallow the UX pablum from Cupertino and Redmond!

So you might be wondering why i'm so excited about a fixed-function key. Why not just reprogram one of the function keys on the top of most keyboards and be done with it? I could probably make well-reasoned arguments why certain functions should have their own keys. But it really boils down to the fact that in the thirty-five years I've been messing with computers, I've never once used the CAPS LOCK, SCROLL or PAUSE key and have nearly worn out the ligaments in one of my fingers pressing control and S at the same time (not to mention Control-C, Control-V, Control-Z, etc.) The big problem I have with the modern keyboard is that I think it could be better. PAGE UP and PAGE DOWN are universal on keyboards (well... at least on keyboards that don't have fruit on them.) It's time to give COPY, PASTE, CUT, UNDO, OPEN and SAVE their due.

Keyboard 2 : The Atari 800

So let's skip forward a few years and look at another keyboard. This one's from the Atari 800. If you look on the right side of the keyboard there are keys marked SYSTEM RESET, OPTION, SELECT and START. The user typically used the OPTION and SELECT keys at system start-up to navigate a menu of options and pressed the START key when all the options were correct. This being the 1980's the SYSTEM RESET key was used to rescue the user when the system was unduly horked.

So what do we have so far? The PLATO terminal had function-specific keys for things you did mostly AFTER you logged in and the Atari 800 had keys whose canonical use was to select options prior to launching software. Imagine how many fewer times your mother would call you if, after her PC booted up, PC BIOSes displayed a menu on the screen and lit up LEDs under the few keys that navigated you through the following options:

• START WINDOZE,
• BOOT OFF A THUMB DRIVE (DID YOU KNOW YOU COULD DO THAT?) and
• DO SOMETHING REALLY COMPLICATED THAT YOU SHOULDN'T EVEN THINK ABOUT DOING UNLESS YOU'RE UNDER 19 YEARS OLD OR HAVE BEEN TO COLLEGE.

Keyboard 3 : TRS-80 Model 100

Now here's my favorite keyboard. Believe it or not, I still have one of these things. They last for about three weeks on four AA batteries and take about four seconds to boot up. The TRS-80 Model 100 keyboard is almost a counter example. If you look closely at the keyboard, you can see that it has eight function keys. And you might be thinking to yourself, "Hey! I though you hated function keys!?" And you would be right. I mostly do. This keyboard is the exception to the rule; and here's why. On the Model 100's keyboard is a key marked LABEL. If you press it, the specific function of each of the function keys is displayed on the bottom row of the screen. Some DOS software from the old days used to do this on IBM PCs as well. But all of the built-in software on the Model-100 did it, and that's the cool part.

One thing I would LOVE to see (and may try to hack into various open source browsers) is to have the functions of each of the function keys be displayed if you press the SCROLL key. It's not like anyone is actually using the SCROLL LOCK key.

Keyboard 4 : The Epson QX-10 (VALDOCS)

Moving on, check this out! It's the keyboard for the Epson QX-10 VALDOCS and it is MAGNIFICENT! I still have dreams where me and the QX-10 HASCI keyboard are skipping through fields of fresh wild-flowers together. Look at it! It has an individual key for just about every thing you would want to do: copy things, change font sizes, etc. Sure, the Margin Release button on a word processor is probably a little excessive, but that's the way I roll.

This keyboard also had keys that were supposed to launch different applications like a drawing program and a spreadsheet. This function has been re-introduced in some keyboards recently and this makes me happy.

Okay... two more to go, don't give up on me now...

Keyboard 5 : The Macintosh Portable

Behold the majesty that is the Macintosh Portable. Okay, maybe "majesty" isn't the right word. It had crappy battery life and weighed more than my drunk college roommates I had to carry home from time to time. But it did have one very, very cool feature: you could open the keyboard cover and move the trackball to the other side of the keyboard. This was great for left-handed mousers like myself.

In my dream world, all keyboards would be like this, you could open up the cover and (re)move the numeric keypad. Or replace the numeric keypad with a trackpad. Or a touch screen. Or a couple rows of function keys.

Keyboard 6 : The Google ChromeBook

So sure... it's unlikely we'll see major changes to computer keyboards anytime soon. But I am happy to report one hopeful sign: Google has removed the CAPS LOCK key from their ChromeBook line. It's been replaced by the SEARCH key. Hallelujah!

Thank you for listening to my screed. As you can tell, I'm passionate about the relatively obscure subject of computer keyboards. And to be sure, most modern computer keyboards are just fine. But the next time you start typing, take a moment to consider... they could be better

The 104 Button Mouse

In the old days, geeks used to amuse themselves with arguments over how many buttons a mouse should have. I think we all know the argument: Doug Engelbart's original mouse had one button, therefore all mice forever and ever should have one. Or... the UX wizards at Apple decided one button was correct, therefore we should never have more than one. ever. Heck, even some early OS/2 and WinTel only had one or two buttons. (Yes, there was a era before all mice had three buttons w/ scroll wheels.)

My argument was always that mice should have zero buttons.

If you look at that thing next to your mouse... the thing with all the keys on it... yeah, the keyboard! those aren't enough buttons for you? In the late 80's / early 90's i put together a mockup of a system that used F2 - F5 as Select, Move, Resize and Delete. So instead of worrying about left- or right- clicks or alt- or control- clicks, you just used the mouse as a pointing device, then used the keyboard to specify the operation you wanted to perform on the thing under the mouse pointer.

Just for giggles, I setup a very basic prototype at http://info.meadhbh.org/mousetest.html . If you're hip to a new experience, just click on over and give it a try. To use it, move your mouse around on the screen, pressing various keys creates, moves, resizes and colorizes boxes:

• N - creates a New box
• M - toggles "Move Mode" - hit 'M' again to stop moving the box
• C - cycles through a few colors
• R - toggles "Resize Mode" - hit 'R' again to stop resizing the box

Cheers!

Mining Big Asteroids : Psyche Direct

In which I talk about another idea for mining metals for asteroids...

So a lot of people know I have an interest in space: I've been a lifelong amateur astronomer, I originally studied optics and planetary science in college and I recently had the privilege of helping Skybox Imaging work out some of the kinks in their flight control system. And if you've spent any time with me recently, you know it's hard to get me to stop talking about some of the recent developments in "New Space" (click on that link if you're unfamiliar with the term, it's worth the few minutes it will take.)

Today we heard about the launch Deep Space Industries, the second of two major companies focused on harvesting ice and metals from asteroids. Sure, it sounds like science fiction, and it probably is in the near term. But in the medium and long term, the only reason it sounds like fiction is simply that no one's done it before.

DSI has an interesting idea: instead of sending astronauts or robot miners to the asteroids, they want to bring small asteroids into High Earth Orbit where human beings can have a much easier way of getting to them. Rather than spend six months travelling to your target, a year there and six months back, you spend a couple years tugging a relatively small 5 or 10 meter asteroid here where it only takes a couple days to get to.

Cool stuff.

Planetary Resources, who announced their plan to mine asteroids last year, has a slightly different (perhaps more obvious) plan: just go to a small asteroid and mine it.

Also very cool.

But as cool as both these companies are, they're both planning on doing a lot of prospecting before they start mining operations. Sure... you have to do some prospecting, but both companies are planning on launching constellations of small satellites to search for appropriate candidates before engaging in extraction operations.

This seems a little wasteful to me. Given the time value of money, the sooner you can turn a profit, the better. So why spend several years looking for small asteroids when asteroid 16 Psyche seems to be a large chunk of nickel-iron floating out in space?

If your plan was to scrape metal off 16 Psyche and bring it back to Earth orbit, you would still need to develop the technology for mining in space. And it's unlikely you could make a mining robot without sending at least one prospector craft to get a good look at your mining site. But, instead of spending time looking for a candidate, you would be developing deep space mine-bots.

I call this plan "Psyche Direct" (apologies to Robert Zubrin.)

1. Develop the prospector craft.
2. Send the prospector craft to 16 Psyche.
3. Begin developing mine-bots (bus, power, return craft, etc.)
4. Analyze results from prospector, use them to refine the mine-bots.
5. Send the mine-bot to 16 Psyche.
6. Return to Earth orbit with metals.
7. Profit!

I just wanted to get this idea out there and see if anyone has comments... More to come!