Picasa web album face tagging - not only fun

I didn't think my wife and her brother looked that much alike, but I can't argue with Google's face recognition algorithm. At a particular angle, in a particular light, there's a definite resemblance!

Yes, Picasa's facial recognition software is a grade 2 event ...

Gordon's Notes: Singularity alert: Picasa web album face tagging

... Yeah, we all knew it was coming, but it's creepy-cool anyway. Not quite goose bumps, but a grade 2 singularity event. (Grade 7 is when the Great God Google refers you to your soylent green processing station, Grade 1 is personalized search.)

So will Google link the faces to the appropriate Google Profile? You just know they've got that one on their social networking strategy. (So how do kids get their profiles? Is it like Confirmation?)

I love it. Now if there were only some way to sync the tags back to iPhoto ...

I'll report on my tech blog after I try it. I'm sure the servers will be smoking tonight, so it'll take a few days. (Update: yeah, it's pegged. Stuck at 44% of faces.)..

It took a day or so, but a lot of faces are recognized. The tagging UI is excellent. I was joking about the Google Profile, but I wasn't far off. Google matches tags against one's Gmail contacts and attaches email addresses in the tags.

Now we need to sync the tags back to iPhoto. This really needs to be in the next version of everyone's photo management software.

Privacy? Hah. That's strictly for the impoverished and the ultra-rich.

CroCari: the future of OS X browsers

With the release of Chrome for Windows, all OS X geeks think the same thoughts:

1. Safari/web kit should be replaced with Chrome/web kit.
2. The Camino engineers are best able to integrate Chrome with OS X

So this is very good news.

Daring Fireball Linked List: Pinkerton

Mike Pinkerton, long-time Mac web browser developer, and one of the leaders behind the Gecko-based Camino, is also involved in Google’s efforts to create a Mac browser based on Chromium.

Chrome + Camino + Safari = CroCari.

Software evaluation: now we have to watch out for license tokens!

[See the update -- 1Password changed their policy today!]

I was read to buy 1Password. I clicked to purchase, and discovered 1Password uses license tokens!

Damn.

I'd never have invested in testing the product if I'd known that. These encrypted license tokens are a pain to manage and store. I want nothing to do with 'em. Mercifully, they're not too common ... yet.

So now I'm back looking for an iPhone password management solution. Maybe FileMaker will deliver Bento/iPhone with encryption and I won't have to bother with a dedicated app.

I'll try to avoid this mistake again. From now on, I'll walk through the purchase process before testing a product to avoid an entire class of nasty surprises.

Update 9/3/08: To be fair to 1Password, I went to the trouble of writing an email so they'd know this was a problem for one customer. They wrote back and said something like "yeah, you're right, as of today registration gets you a regular registration number". So they'd been hearing this was a problem. I'll download the new version and register tonight.

Chrome comments

So now my old XP box has Firefox, Safari, IE 7 and Chrome.

This is good.

• When you enter "about:memory" in the title bar you get "stats for nerds". The Browser stats compare Firefox 3.01 and Chrome "0.2.149.27".
  
• Shift-Esc brings up the task manager, listing evil Plug-Ins like Flash. Sure feels like an OS to me.
• There are a few options, like putting the home button on the toolbar.
• When you type a url, the file name is in faded text. Cute.
• Nice emulation of FF 3's best feature -- the all-in-one status bar. IE copied it too. This is good.
• I enabled Gears for Google Docs, it created a shortcut of the form:
  "C:\Documents and Settings\jfaughnan\Local Settings\Application Data\Google\Chrome\Application\chrome.exe" --app=https://docs.google.com/"
• You can search History, but it doesn't integrate iGoogle history.
• Ctrl-B toggles the bookmark bar.
• The "chrome" is pleasingly minimal. No separate status bar, no menu to speak of, so it really uses the screen well.
• The address bar also integrates Google search, and it searches all visited web pages.
• Lunarpages, a web service provider that I've recently replaced with DreamHost, has an invalid security certificate (yeah, they have problems). FF gives me a dire warning, but lets me visit. Chrome just wipes them away -- no error message, the page can't be visited.
• The "courier" font size on ToodleDo is unusably small with Chrome. It's usable with FF, IE and Safari.
  

Since the address bar searches all visited web pages, does this mean that if you visit a web page you've been keeping "secret" (obscure URL), that Google is now going to index it?

Rumor says the OS X version is far away - alas.

Update: Chrome search against pages visited is run against an archive stored on the local machine. So those mildly secure since obscure pages are not exposed.

indexed - the site

indexed. Very fashionable among coastal geeks, we midwest people learn everything late. Very cool site about messaging by sketching.

PS. Google Reader is much better at browsing older posts than bloglines ever was. I just set the display mode to "all items" and sample the archives over time.

Then I share the ones I really like. (Note my Google Reader share page has a feed).

Chrome blame: you don't think they mean Flash, do they?

Page 8 of the Google Chrome comic is about "placing blame where blame belongs".

There's a bit of intensity in this topic. I'm left with the sense that Google engineers are upset with a common plug-in, an its tendency to wreck browsers.

You don't suppose they mean Flash?

I'm looking forward to Chrome. In a world of Chrome/Safari/iPhone/Web Kit, IE 6/7/8, and Firefox 3 even the most clueless web app vendors have got to start thinking about standards.

As a Web Kit user I'm also grateful for the automated QA the open source Web Kit platform is getting.

Thanks Google!

Update: After the comic slipped out ahead of time, Google put out an emergency blog post pre-announcement. It will be out in beta tomorrow for Windows, Mac and Linux to follow but no timelines given.

Migrating a domain with related Google Apps and hosting files to a new service

A year ago I wrote about adding adding Google Apps services to our existing mnspecialhockey.org domain. Back then Lunarpages managed most of my domains and sites, but I fired them recently.

Now I'm migrating my domains and hosted files to DreamHost, including mnspecialhockey.org. I was worried about that one. How do you migrate Google Apps?

Briefly, if you know the sequence to follow, the answer is -- very easily.

I've not only migrated mnspecialhockey.org, I've also added a new subdomain, files.mnspecialhockey.org to hold files (something Google doesn't really do) and I've restored the news.mnspecialhockey.org subdomain for our blogger blog (Lunarpages broke that).

The hardest part for me was understanding how things work. Once I knew that, I knew what to avoid and what to do. Understanding took a couple of days and help from DreamHost tech support; execution took minutes. (See migrating my domains and hosted files for the steps involved in switching the domain itself.)

To understand how the magic happens you have to know what 3 entities do:

1. The registrar (Tucows, will be DreamHost): maintains the relationship between the domain names we type (mnspecialhockey.org) and the IP address of the name server you are using.
   
2. The nameserver owner (DreamHost): routes all kinds of requests for web pages and services
   
3. The web site provider (also DreamHost): provides file services, http and ftp, etc
   
4. Google Apps for a domain: provides google apps (available only to person who can provide domain ownership)

Next you have to know two key things:

1. You can do whatever you want to the DreamHost DNS settings, but until you tell your registrar to use the ns1.dreamhost.com nameserver nothing will happen. So you can get everything ready at DreamHost, the turn it on by switching nameservers at your registrar. You can switch back to Lunarpages just as easily. It doesn't matter whether DreamHost or Tucows or Network Solutions or eNom or GoDaddy is the registrar.
2. For a request for "calendar.mnspecialhockey.org" to work you need to do two things:
   a. set up a rule in your nameserver provider's DNS to route all traffic for calendar.mnspecialhockey.org to ghs.google.com. This is done by a CNAME (below)
   b. in your Google Apps you need to setup a custom name that exactly matches the name you created in the CNAME.
   

Ok, so that's complicated. Let's walk through an actual transaction.

When I enter "calendar.mnspecialhockey.org" in my browser, the Internet's DNS system first "asks" where to route the request. The registrar for mnspecialhockey.org knows to send all domain traffic DreamHost nameservers - because I told it to use those nameservers.

So the requests go to the DreamHost nameserver. As we see in this picture of DreamHost's nameserver the subdomain request is then routed through a CNAME to Google (ghs.google.com).

So the request for calendar.mnspecialhockey.org effectively goes to Google. On the other hand fubar.mnspecialhockey.org, for example, would have to be handled by DreamHost.

When Google gets this transaction it sees it's a request for "calendar.mnspecialhockey.org". It matches this request against the custom URL I assigned my Google Apps calendar through my Google Apps Dashboard, and it renders the correct calendar.

Ok, if you understand all of the above then you're ready to understand how I migrated mnspecialhockey.org, and its related Google Apps services, from Lunarpages to DreamHost. You may also see why Google Apps are so loosely related -- they are really only bound together at the DNS level.

In this case everything was already setup on the Google Apps side, including using Google's now obsolete Page Creator to manage our web pages.

I just had to setup the DNS at DH so it had the right CNAME settings to direct traffic and handle mail. These are totally generic, the traffic gets routed to the right Google Apps because of the matching domain names, not because of anything special in this table.

1. I used DreamHost's "fully host domain at Google Apps" first. That created almost all the CNAME and MX (mail exchange, see DNS record types) settings in the above image.
   
2. I manually added the CNAME entry of "news.mnspecialhockey.org". I'd made a corresponding change in a Blogger blog, publishing it to "news.mnspecialhockey.org".
3. I changed the nameserver settings at my registrar (Tucows at the moment) to the ns1.dreamhost.com, etc settings.

That was it. Everything worked as before, except that Lunarpages had broken things and couldn't fix them. So now it really worked.

I wanted one more thing though. I wanted a place to store files -- something Google Apps does very poorly.

That was easy too. At DreamHost I created a subdomain of files.mnspecialhockey.org.

I configured that subdomain so anyone entering "www.files.mnspecialhockey.org" would go to "files.mnspecialhockey.org" (a DH configuration setting).

So now I had my files section -- with FTP services too.
It took a while to understand this, and a bit of time to write it up, but not time at all to do it. DreamHost tech support was very helpful, though they did have to correct themselves a couple of times.