It's time to stop using passwords to authenticate users. They were never a very good form of security and they're only getting worse. The latest fiasco is Apache had a breakin with their bug tracker where passwords were logged for three days. The hashed password database was stolen too, facilitating dictionary attacks. At least Apache was hashing passwords: there are plenty of dumbass sites that store passwords in plain text.

Password database theft is particularly bad if users use the same password on multiple sites. Yeah, I'm sure you've never done that. I have 560 passwords stored in Google Chrome right now. To any hackers reading: of course all my passwords are different. They're all at least 16 characters, multicase, and use Urdu punctuation.

So if not passwords, then what? Four alternatives:

1. Two factor authentication, a secure hardware gizmo that generates one-time logins. I have two now, one for my Warcraft account and one for my bank account. They're too expensive to use on every web site but are great for a few high risk accounts.
2. Authentication delegation like OpenID (or in some use cases, OAuth). OpenID works great, right now. Product designers fret about the user experience, but it's not that bad. The real problem is political, there's no major trusted third party providing OpenID without some competitive motive.
3. Client side cryptography authentication. This technology is at least 10 years old, but outside of ssh never widely adopted. The web browser version (client side SSL certificates) is poorly supported and has terrible UI. That's a fixable problem.
4. Password agents. A little browser plugin that maintains a secure set of strong passwords, one for every site you log in to. Works with existing password-based servers but if you're using a browser without your agent (hello iPhone) you're stuck.

That's four different user authentication options that are all more secure than your dog's name with 3s instead of Es. They work best in combination. I'd really love an OpenID provider that used a two factor authentication system to protect me. If it also had a password agent to bridge logins into an old password protected site, then I'd be all set. In fact, that right there is a technology roadmap for a startup. Only problem? It wouldn't make enough money to be worth the liability.

I have a love/hate relationship with Apple products, particularly my beloved iPhone. Today Apple proudly announced they're suing HTC over phone patents: that's firmly on the hate side.

We can sit by and watch competitors steal our patented inventions, or we can do something about it. We've decided to do something about it. We think competition is healthy, but competitors should create their own original technology, not steal ours.

— Steve Jobs

Everyone in the tech industry knows the patent system is entirely broken. Other than a few sleazy actors like Intellectual Ventures there's an understanding in the innovative side of the tech business that you don't file aggressive patent lawsuits. You write a lot of patents, you file defensive lawsuits and countersuits, but in general you don't use your patent portfolio as a big club to try to destroy competitors. Apple's taking a big crap on that detente. It's pretty hard to love a company that is going to exploit the broken patent system to stifle innovation. Not that this is new misbehavior, see also Apple's 1988 look and feel lawsuits.

What's particularly galling is Jobs' language about "stealing". We'll know more when the patents are named, but I have to wonder. Does he think anyone else using a multitouch UI is stealing? Pinch-to-zoom? Seamless wifi/cellular networking? I wonder if Jobs called it "stealing" when Apple took the mouse and windowed GUI metaphors from Xerox?

Frustrated with iPhone data service in San Francisco? Call 1-800-331-0500 and complain; AT&T claims they have no problem. #attfail.

I'm an enthusiastic iPhone user. I'm a captive AT&T customer. They're not awful as cell phone companies go. But their data network is terrible in San Francisco. It's totally random whether I'm going to be able to load a web page at any given time or place; I'd say about 25% of my network requests fail. I've taken to using an offline map just so I don't get lost. I'm not the only one: every iPhone user I know hates the service in San Francisco. So I called today and tried to do something about it. Specifically, I asked for a refund for the $30/month data plan.

It didn't go well. The customer service reps I talked to were all polite and communicative and did a game job in dealing with an unhappy customer. They also refused to admit they had any real problem. In the end they gave me a one-time $10 refund just to shut me up.

The astonishing part of the call was that the CSR did have access to my data records and said she saw some pattern in the data that suggested only 3 requests out of 4 worked. (Specifically, 1kb downloads, which she took to be evidence of a failure.) According to her, a 25% failure rate isn't a problem. And the fact that I've never called and reported problems before must mean everything is OK. No one in San Francisco calls and reports problems, she said, so they must not have any.

Hopefully AT&T doesn't just rely on customer reports and has actual network engineers monitoring their networks. But what we really need is some external, objective measure of network quality that AT&T can't deny. Or just a couple of Apple execs living in the city, fed up with the way their monopoly network provider makes their flagship product look bad.

For my recent geolocation demo I wanted a web page hosted on somebits.com to be all Web 2.0 and dynamically load data from geonames.org. I've never really done AJAX before so I was surprised I couldn't do this remote call because of security restrictions. And I was even more horrified at the workaround. I couldn't find any place where all this is succinctly explained, so here's some notes.

The same-origin policy is a rule web browsers enforce for security. Basically, Javascript code running on a webpage at somebits.com cannot access any resources from any other domains. No access to the DOM of other sites, no cookies, no frames. And, important for AJAX, no XMLHttpRequest to a remote domain. So much for mashups where you load data from multiple sites!

There's a variety of workarounds. The one I used is JSONP which turns the declarative JSON data you would load from a web service into imperative Javascript code. Where a JSON reply from a web service might be

{"balance": "3942.12"}

A JSONP reply would include a function call:

callback({"balance" : "3942.12"})

Why wrap data in a function call? Because the same-origin policy does not apply to scripts! A browser won't let you load a few bytes from a remote server as data but it will happily load those same few bytes as code and execute it. And so you execute the remote JSONP in your page and it calls your callback() function to use the data. A kludge, but frameworks like jQuery hide the mess.

At first blush this seems crazy. It's insecure to let me load remote data but it's fine to let me run remote code? But I'd misunderstood the purpose of the same origin policy. The reason somebits.com can't load stuff from geonames.org isn't to protect somebits, it's to protect geonames! Without this policy XSS attacks would be trivial; any Javascript code in your browser could steal cookies from other sites, inspect private data, etc. Apparently executable Javascript is considered not-private, so I'm allowed to execute anyone else's code anywhere. (Terrible assumption, no doubt there's already a class of XSS attacks against JSONP services.)

Frankly the whole thing smells rotten and shows just how complex and twisted the Javascript security model is. There's a couple of proposals for more cleanly enabling remote web service requests. Firefox 3.5 implements HTTP access control, a W3C standard where a website can say "go ahead and let anyone load this content remotely". IE8 implements XDomainRequest, which is restricted to "anonymous" requests to limit security exposure. And so the squabble continues.

Awhile back I wrote about removing the obnoxious left side sidebar on iGoogle with a magic URL parameter. It changed, the new secret to make the product work right is to go to

http://www.google.com/ig?hl=all

hl now, not gl.

My secret agenda is to get enough people doing this that the iGoogle team notices the traffic in their logs and makes no sidebar an official option.

Yesterday I tried to load some music on my iPhone for the first time in a year. The result was a complete iPhone apocalypse. Long story short; at some point iTunes decided to do an incredibly long and slow sync of some music I didn't want to copy. With no progress bar, no indication of how long it'd take, and no cancel button. So I did the only sensible thing and unplugged the phone.

The result? Not only did I have no music on my phone, but now I had no third party applications, either. Well I had a couple, some random subset were left behind. The other apps were deleted. Along with their data. Including a month's pain-stakingly collected diet data, gone forever.

Two-way sync is hard. But it's not that hard. iTunes' model is apparently that it has the canonical copy of what's on your phone. Only it doesn't update that model correctly in all cases, and then deletes whatever is on your phone that doesn't match the incomplete copy on iTunes.

I can sort of understand that failure with the music library; your iTunes install is the only conduit for putting music on to the phone. But apps can be installed independently, and generate their own data on the phone. iTunes can't be sure it has seen all the app data; so why be so casual about deleting it? Even if you can count on the user not to unplug the phone mid-sync, what happens if iTunes crashes? Or the machine crashes? Or the cat knocks over the phone? Or the power goes out?

I've made a sport of iTunes-bashing on my blog and Twitter the past few years. It's a bit obnoxious, but every time I try to use iTunes I'm stunned at how bad it is, particularly on Windows. Apple's reputation of building humane, user-friendly software is completely misplaced in this case.

About once every six months I do some hack which involves caching web pages on disk. While hacking I always just write stuff to a cache directory so I can load it / replay it quickly. And inevitably I forget about the crappy cache and when I run the job for real I only remember three days later when the directory has an unwieldy 200,000 files in it.

Operating systems fail in all sorts of charming ways when you have a directory with "a lot" of files, typically over 10,000. Both the Vista and Linux kernels no longer seem to have O(n) operations on directories, so deleting all the files is no longer O(n^2). But the tools still freak out. For example, rm * doesn't work if the expands to larger than the command line limit.

Vista has a host of joys associated with giant directories. Opening the directory in the file shell actually works. Selecting all files and deleting doesn't, though, and the entire UI becomes unresponsive on a directory with even 20,000 or so files. del * from a command line does seem to work, but is awfully slow. I finally wrote some custom Python to unlink the files quickly only to find they were in a search indexed directory; the entire deletion process would freeze for 20 seconds at a time while the indexer chewed over the removals. Ugh.

By the way, if you ever need to remove a bunch of files the lower level you do it, the better. Even rm does more examination of the file than you want. Here's a quick python hack that seems pretty efficient.

Want to use Subversion on Windows Vista, with the svn+ssh protocol (you know, the only sane one?). It's remarkably tricky, but it's doable. There's a bunch of incomplete docs on the web, including Wingware and Piwigo. Here's the steps in schematic form.

1. Install the command line Subversion client for Windows. Yes, you have to register for an account to download this free software, at least from collab.net.
2. Install PuTTY, the free ssh client for Windows.
3. Get PuTTY configured so it's using Pageant as an ssh key agent. When you can use Putty to log into your SVN server without typing a password, you're set.
4. Go to a command line and verify you can run
   plink server hostname
   without typing a password. Plink is what PuTTY named the command 'ssh'.
5. Go to
   C:\Users\username\AppData\Roaming\Subversion
   and edit the file config (in Notepad or whatever).
6. Head down to the [tunnels] section of the config and enter this line (all one line, but with lots of \\ quoting nonsense)
   ssh = C:\\Program\ Files\\(x86\)\\PuTTY\\plink.exe
7. Test everything from a command line.
   svn info svn+ssh://server/...
8. Swear at Microsoft for moving the paths for everything in Vista. And swear at the Subversion community for not producing a humane Windows install.

Every time you fetch a web page, your browser sends a special User-Agent string to the server telling it what software it's running. It's defined in RFC 2616:

This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations.

Fast forward to 2009, and here's the User-Agent string you get from Google's fancy new Chrome browser: It's like a browser salad! But the Google guys aren't doing anything wrong, this boneheadedness has to be there in order to satisfy the "automated recognition" part of the spec. Chrome's just a little ol' chameleon.

Do you use iGoogle? Do you hate the sidebar on the left side that wastes 100 pixels with useless tabs and an advertisement for Google Talk? There's no official way to turn that sidebar off. But if you set your start page to http://www.google.com/ig?gl=all, why there's your iGoogle page without the sidebar. Lovely.

Don't get me wrong, I love iGoogle. I've been using personalized start pages for years and iGoogle is the best. It loads super fast, it's easy to configure, and it has enough useful modules to keep me occupied. Just don't appreciate some product manager deciding to keep features in front of me that I do not want.