Nope.

This is brilliant timing, and it isn’t a direct attack on Apple. It’s clear that all Amazon cares about is being the leading ebook retailer, not whether their hardware sells more than the iPad or any other device for that matter. That’s why they have an ebook reader/store app for every device on the planet; you want to use an iPad, not a Kindle? Great! We’ve got an app for that.

What we’re seeing here is a gold rush. Even if the iPad was a commercial failure (it won’t be), the hype surrounding it has force fed the reality of ebooks in the faces of the mass market for the first time.

People who would never have otherwise heard of ebooks now have.

People who always assumed they’d be complicated have now seen a dozen video demos of iPad and it’s “Books” app, and have realized they aren’t.

How many people watched Charlie Rose’s interview with David Carr and Walt Mossberg about the iPad? It was border line pornographic.

People are going to want an iPad, but not everyone will be able to afford one. That is the Kindle’s new target demographic, and how it will ride out the iPad storm.

Now all they have to do is assure their ebook store beat’s Apple’s own in terms of price, quality and catalog size. The flood gates are open, and I think it’s going to be a good time to be Amazon.

Battle.net Authenticator

Account security in massively multi-player games is a big concern. If you play World of Warcraft, you know how often accounts are compromised. In the last 6 months we’ve had our guild bank emptied twice when high-ranking members had their accounts compromised, and a handful of our lesser ranking members have had their hacked characters’ inventory and gear liquidated and traded to, presumably, gold resellers. Blizzard isn’t alone in this problem, of course. Even NCSoft’s Aion, a very recent MMO release, is having major issues with this. Simple truth of the matter is no MMO account is safe from being hacked, phished or brute forced and compromised when all we use is traditional username/password schemes.

However, there is a solution to this; authenticators. Blizzard and Square Enix both sell a hardware key fob solution to secure accounts (in the case of Blizzard, there is a free iPhone app that does the same thing.) Essentially, it adds a second, randomly generated password to your account that changes every ~30 seconds. So, you login with your traditional username/email and password, press the button on your key fob, and enter the code to login to the game or access your account management settings.

If you’re familiar with Paypal’s Security Key program, it’s essentially the same thing.

Obviously, there are great benefits towards using security tokens like these to secure online accounts. Someone could lift your username and password from a phishing scam, but they still couldn’t access any important element of your account without the random token. No two key fobs will generate the same code at the same time, so it’s nearly impossible to brute force. Even a keylogger installed on a player’s computer is rendered useless, unless the hacker is somehow watching your input in real time and enters your token as you do within that 30 second window (not likely.)

Blizzard and Square have tried to push players towards getting their accounts secured with authenticators by offering perks like vanity pets and increased storage space for your characters, but I’m still surprised at how many players are completely clueless that these devices exist. That might be changing in the case of Warcraft, where word on the street is Blizzard will be requiring the use of these security tokens with or perhaps even before the Cataclysm expansion is released. This means Blizzard will either be shipping these devices out for free, or will be bundling them in with the Cataclysm retail box.

Bizarrely, the community seems divided on the issues of whether this is a good thing or not. I don’t see the negative, outside of the minor inconvenience of having to remember where your device is, and the pain of getting your account reset if your device is lost (or, as was the case of a few friends of mine, when they upgraded their iPhone firmware and rendered their security tokens broken. [This issue should be fixed now, though.]) I love the idea of the security token mechanism, and I expect virtually every MMO going forward to begin supporting this kind of authentication, perhaps even mandatorily.

Until we get there, though, there are a few stop-gap solutions companies like Blizzard could put into place to help secure accounts without investing in new hardware.

Password Case Sensitivity — The most obvious flaw in Blizzard’s security system is the fact that their passwords are case-insensitive. So, if you’re a clever player, and you used a variety of capitalization in your password to help protect it from brute force attacks, those efforts are for not. Seriously, who thought this was a good idea? You dramatically cripple the effectiveness of your security system by not including this.

Login Strikes — It’s an obnoxious feature when you forget your password, but it’s a great way of combating brute force attacks. Banks use it all the time for online account access. Essentially, you have X attempts to login before logins are disabled for Y minutes. So, if someone is brute forcing your password, they only have a very narrow window of attempts before they’re locked out from trying for awhile. Hackers use automated scripts full of combinations of commonly used passwords, dictionary words, and frequent number combinations to throw at a authentication system like an MMO’s to try and guess what your password is.

My only guess as to why Blizzard in particular hasn’t included this particular function is that our accounts are getting slammed with brute force attempts far more often than we may realize. If this is the case, we could potentially be frequently locked out of our own accounts because of these anonymous attacks, causing an increased number of calls to these companies support centers. In this case, the only way these companies could combat this problem is by offering a means of changing your username, which can be difficult from a technical standpoint, introduces a level of complexity to the system, increases the odds of players forgetting their usernames (and thus, potentially increases support center calls.) In the case of Blizzard, username changing isn’t an option, as you now login with your email address instead of a username with the Battle.net system.

Still, this would be an option for many MMO developers, and an option worth serious consideration.

OpenID — Here’s an interesting thought that crossed my mind; why not allow players to use OpenID to identify themselves? Decentralize security from your database and put it in the hands of the more tech savvy players. Obviously, it wouldn’t be an option for most of the market’s player base, but it could be an interesting experiment and lead to some fascinating innovation by the community. Allow players to build their own authentication mechanisms and secure their accounts through their own means, whether it’s usernames and passwords, or image-based schemes, or riddles, or whatever. Crowd-source your security.

Finally, there are two other avenues we could investigate to improve the current security token scheme we’re seeing. These are USB-Based Security Tokens and a Standardized Token System. One complaint I hear against security key fobs is that they require you to keep track of them, and require you to go out of your way to input the code. Granted, this only adds a few seconds to the login process, but it is an obnoxious element. Instead, why not use a USB key approach? The player plugs their security token into a free USB port. The game detects the hardware key, and inputs their randomized token for them during the login process. This still requires you to know where your key is, but assuming you only play from your home, you can just leave it in a USB slot and not have to worry about it. This might be a complicated for web-based account management though, but using browser plugins (*shudder*) it would be possible to still take advantage of the token system.

Also, considering that more and more MMO developers will begin introducing and perhaps requiring security tokens, wouldn’t it make sense to have a standardized token system for all MMOs? Our key chains could potentially be full of these things (if you’re an MMO addict like I am!) in a few years to come. If a third party stepped up and said, hey, we’ll sell your company branded security token hardware for your games, offer a simple API to integrate it into your authentication process, and allow players to use a single key to access all their MMO accounts, this company would make a fortune. Seriously. Somebody out there needs to get off their asses and do this.

So, there’s some random food for thought on MMO security. What would you suggest developers do to secure player’s accounts? Do you like the security token approach? Why or why not?

My variation of this Automator workflow will:

• Detect when a Kindle is mounted.
• Confirms if you want to sync your device with Instapaper.
• Deletes any old Instapaper files on the device.
• Downloads a fresh Instapaper archive and places it on your Kindle.
• Asks if you want to dismount the Kindle, and does so if chosen.

Once you have this workflow in place all you really need to do is plug your Kindle in and wait for it to do it’s thing. Couldn’t be easier.

One issue to be aware of: while you have your Kindle mounted, any insertion of USB drives (or anything that will show up in /Volumes for that matter) will start the script. I’m looking for a workaround on that one, but it’s a relatively minor issue. Plug it in, sync it, unplug it. That’s the point of it, anyway.

You must also be signed into your Instapaper account through Safari for the Instapaper archive to be downloaded successfully. Automator uses your Safari session to grab the file.

Finally, the script should work with any number of Kindle devices, but only one may be plugged in at a time for the sync to work properly.

Download

You can download my workflow and customize it for yourself. You’ll want to move the file to your ~/Library/Workflows/Applications/Folder Actions directory and work with it from there. Alternatively, you can build the workflow manually.

Install the Workflow

1. If you downloaded the pre-built workflow, ensure it’s been copied to the location I mentioned.
2. Open Finder and press Control+Shift+G. In the prompt, enter “/Volumes” and press Enter.
3. If you don’t have the path bar enabled in Finder, go to the View menu and select “Show Path Bar.”
4. Right click “Volumes” in the path bar and select “Folder Actions Setup…”
5. Attach the “Update Kindle with Instapaper.workflow”, ensure both checkmarks are checked.

Plug in your Kindle, and watch the magic. ;)

Build The Workflow Manually

1. Open Automator and create a new Folder Action. Set the “receives files and folders added to” drop down to “Volumes” (select Other, then press Control + Shift + G and enter “/Volumes”, press Go and then OK.)
    
2. Add a “Run AppleScript” action with the following code:

   on run {input, parameters}
   
     tell application "Finder"
       if exists disk "Kindle" then
         return input
       else
         error -128
       end if
     end tell
   
     return input
   end run

3. Add a “Ask for Confirmation” action. This will allow us to cancel our Instapaper update if we’re not ready for a fresh copy.
    
4. Add another “Run AppleScript” action to check for any existing Instapaper files on the Kindle, and move them to the trash for us.

   on run {input, parameters}
     
     tell application "Finder"
       set kindleFolder to "Kindle:documents:" as alias
       set instapaperFiles to every file in kindleFolder where
         name of it contains "Instapaper-ReadLater-"
       move every item of instapaperFiles to trash
   
       -- If you'd like to automatically empty your trash, uncomment:
       --empty the trash
     end tell
     
     return input
   end run

   Lines 5 and 6 should be on one line.
    

5. Add a “Get Specified URLs” action. Delete the default URL and add http://www.instapaper.com/mobi.
    
6. Add a “Download URLs” action. Point the Where value to your Kindle/documents folder..
    
7. Add another “Ask for Confirmation” action. This time we’ll be asking whether we want to dismount our Kindle or not.
    
8. Add one more “Run AppleScript” action to dismount our Kindle from the file system, allowing us to just unplug the device without any further steps.

   on run {input, parameters}
     
     tell application "Finder"
       if exists disk "Kindle" then
         try
           eject "Kindle"
         end try
       end if
     end tell
     
     return input
   end run

    

First, here’s what the related portion of my lighttpd.conf file looks like. We’re just replicating what Lessn’s own .htaccess file tells Apache to do.

$HTTP["url"] =~ "^/g/-/" {
  server.error-handler-404 = "/g/-/index.php"
}
$HTTP["url"] =~ "^/g/" {
  server.error-handler-404 = "/g/index.php"
}

Important – I have my Lessn installation located at /g, so you’ll want to tweak these rules to match wherever you installed yours.

Now open up Lessn’s /index.php. Beneath the includes we’ll be adding a few lines to grab the token from the request uri, like so:

include('-/config.php');
include('-/db.php');

if(!isset($_GET['token'])) {
  if(isset($_SERVER['REQUEST_URI'])) {
    $_GET['token'] = substr($_SERVER['REQUEST_URI'],
          strrpos($_SERVER['REQUEST_URI'], '/') + 1);
  }
}

There you go: a functioning instance of Lessn on lighttpd. Enjoy.

I want my computer to work. All of the time. No exceptions. (Who doesn’t?)

I don’t care whether you use Windows, a Mac, or Linux; you’ll encounter show-stopping problems, and probably a lot more frequently than you care to admit. That isn’t to say the web isn’t without it’s problems. Datacenters go down, tables get corrupted, and worse of all things get hacked. The difference is, if a site goes down I can come back to it later. If my desktop OS goes down, I’m screwed… and potentially my data is screwed along with it. A reliable web service won’t suffer the same fate.

An all too common sight.

Now, Google unveiled quite a bit of new information on Chrome OS today, and officially opened the code for the first time to developers. I have a mostly positive impression coming away from the webcast, but I do see a couple of problems that Google hasn’t really addressed.

The Good

#1, The OS is self-repairing. That is, if a byte goes bad, or someone develops a piece of malware that circumvents the sandbox and eats your OS, the machine will revert to a good copy patch itself to a fresh state. No lasting harm done.

#2, Dead simple. I could see slapping this on an old laptop and giving it to a grandparent (see Bad #1.) No file system confusion, or worries about viruses, or needing to ensure they have the latest updates. It’s a set it and forget solution for the tech-clueless.

Chrome OS UI (Mockup)

#3, You can login to your Google account on any Chrome OS-based netbook and instantly have access to an identical looking “desktop” as you have on your own machines. Your bookmarks, browser history and even theme are synced and displayed. Fantastic. This also means, of course, if you drop your netbook and kill it, you can buy a new one and be right back where you left off in no time.

#4, It’s free. Netbooks running the OS won’t have to worry about Windows licenses, and thus keep the cost of their hardware cheap. Granted, Linux has always been an option for the same reason, but this is no standard Linux OS. I don’t care if it’s Ubuntu or Fedora or Gentoo; there is no such thing as a user friendly desktop Linux environment. It appears Chrome will be the answer to that problem.

The Bad

Solid State Drives. I understand why Google is going that route– the performance advantage is huge over traditional drives– but requiring them to use the OS is absurd. I get requiring a SSD on new devices that ship with Chrome OS. I think if someone walks into Walmart and buys a Chrome OS-loaded netbook, they would expect tip-top performance.

But let’s say I’m not going to walk into Walmart and buy one. Let’s say I have a perfectly fine laptop sitting next to me that I want to give to Grandpa. Chrome OS is an easy choice, because all he does it check email and browse the web, and I don’t want to have to worry about him getting viruses. Alas, unless Google changes it’s mind on this, that isn’t going to be an option- because that old laptop doesn’t have a Solid State Drive. Who cares if Grandpa’s OS takes 7 seconds or 7 minutes to load? It’s a free PC, and it’s running your OS, Google.

If I’m savvy enough to install Chrome OS my own hardware, then I should be free to do so. Don’t lock me into your ideas of what a netbook should be.

The Ugly, and questions left unanswered

Privacy. I’ve always been a proponent of the “privacy is dead” argument when it comes to the Internet… or in any context, really. There isn’t such a thing. Still, having every aspect of my OS… my bookmarks, my customizations, my browser history… housed on Google’s servers is a little concerning even to me. I’d like to see us able to define a different sync-point than Google’s servers. Like Mozilla Weave or Xmarks, let us use our own FTP server as a place to store this cloud data as an option. At the very least, give us an indication of what sort of encryption you’ll be using to secure OS data.

Is there room for gaming on a Chrome OS device? Of course we aren’t going to be playing World of Warcraft on these things, but Google hasn’t mentioned if they’re going to support hardware acceleration at all, or whether OpenGL support will be bundled. NVIDIA’s Ion netbook platform is growing in popularity; will there be support for that? They demoed a Flash game; considering the sandboxed environment, will they be open to partnering with companies like Unity and OnLive to deliver cloud-friendly plugins for gaming?

Likewise, considering Chrome is all about HTML5, and a major aspect of HTML5 is it’s local storage capabilities; how is Chrome OS going to handle this? Will there be a finite amount of local storage for these things, or is Google imagining a way of syncing this data to their cloud and somehow still maintaining offline capacity? Perhaps there will there be no such thing as offline capacity, considering Google’s buyout of the 700MHz frequency spectrum, or are these devices going to be sold by cell carriers with built-in modems?