Implementing Google's two factor authentication

I've been planning to switch to Google's two factor authentication once it was a few months old (time for bug fixing), so James Fallows recent experiences only confirmed my schedule. Interestingly he's not the only recent victim. I assume, based on my personal experience, James' wife was the victim of a keystroke logger infection (was she using a Mac client?) or password reuse.
It worked pretty much as per my notes. Google's setup process takes about 15 minutes, including installing the authenticator app on your iPhone or Android device (other phones get SMS authentication). A few things to note ...

• Emily pointed out that I need to add two factor recovery directions to our password database, so if I become abruptly dead or incapacitated she knows how to get my stuff. In particular I will put the backup verification codes into a piece of paper she has access to.
• I needed application-specific passwords created for OS X Mail, iOS Mail, Google Voice iPhone, Reeder.app, Spanning Sync (forgot that one) and probably a few more.
• It is a nuisance to enter the generated 16 character app-specific passwords on the iPhone -- but the white space feature is very nice. Would be great if the Authenticator app on the iPhone could handle assigning app-specific passwords. Google.app on my iPhone works with two factor; when I tried entering an application specific password it told me to use my two factor password. Just like my desktop, it can be configured to "remember me" for 30 days. (If you lose a device, you have to get access to Google to remove its credentials).
• I don't think you can copy paste the numeric codes to from Authenticator.app to Google.app. You have to load into short term memory and tap them in.

Two factor authentication means I'm willing to enter Google credentials on relatively untrusted machines (given https encryption). That means ...

• Whatever password I enter on those machines will be public (that is a keystroke logger will catch it sooner or later). So there's no sense using a complex or difficult to type password. The main value of the password is to protect me when my phone is lost. I've reverted to an easy to type password that I expect will become "public". In other words, a Level I password.
• I can now stop using the Google App identity I setup to facilitate access to shared resources from insecure machines (such as corporate/office laptops)
• As per Google's recommendations, I carry the verification codes in my wallet. I also have a printed set Emily can access.

See also:

• Gordon's Tech: RIP Password - Google's two factor authentication (2/2011 - how it works)
• Gordon's Tech: My Google (gmail) account is hacked - by ductus.com (9/2010)
• Gordon's Tech: After the Gmail hack - passwords and security (9/2010)
• Gordon's Tech: Google hack lessons - where the geek risks are (9/2010)
• Gordon's Notes: Google's two factor authentication and why you need four OpenID accounts (9/2010 - where we're going)
• Gordon's Notes: Thunder in the Cloud: Lessons from my hacked Google Account (9/2010) - most comprehensive post

Update 4/18/11: I've found a hole in the system. You can set any computer to save 2nd factor authentication for up to 1 month, but you can't revoke this remotely and there's no UI to undo the change locally. Since the extended authorization cert is saved as a cookie, you need to delete cookies on the machine to re-enable Authenticator requests. So you should really reserve extended authentication for trusted machines. A corporate laptop, for example, should not be considered a trusted machine.

Update 5/1/11: I'm surprised how often I need to generate a single use application specific key. For example, I just had to do one for the Google's iPhoto PIcasa image uploader. I'm up to about 13 of 'em. Bit of a pain really. I've contemplated storing one for general reuse in my password database but haven't done that yet.

Update 7/4/11: I still rely on two-step verification, but Google needs to do a lot more work on this.

Update 9/8/11: I rethink it all.

Google Fail: The Google Video download options

Google is terminating old content on mine on two services.

They're terminating pre-Google Blogger accounts that haven't migrated and they're terminating Google Video data. For various reasons I've data in both places.

Must be time from spring cleaning.

Personally, I don't mind losing the data. I'll say good-bye to the Google Video data; for one thing I don't think YouTube has the privacy controls GV had. I'm disappointed, however, with the way Google is doing this ...

... On April 29, 2011, videos that have been uploaded to Google Video will no longer be available for playback. We’ve added a Download button to the video status page, so you can download any video content you want to save. If you don’t want to download your content, you don’t need to do anything. (The Download feature will be disabled after May 13, 2011.)

We encourage you to move to your content to YouTube if you haven’t done so already...

.. Once a video has been downloaded, “Already Downloaded” will appear next to the Download Video link.

If you have many videos on Google Video, you may need to use the paging controls located on the bottom right of the page to access them all.

The classy approach would have been to provide a one click transfer from GV to YouTube.

Remember this as you migrate to the cloud.

Adding events to Google Calendar: generating quick add statements

Some parts of Google Calendar are pretty cool. Event import ain't one of 'em. I've gotten CSV import to work, but it's more than ugly. It's dumb [4]. Worst of all, if you make a mistake you can hose your calendar. There's event undo, but not import undo [1].

So when I had to enter 15 games from my son's calendar, I tried typing them in. That got tedious fast. I'm no good at data entry; I get bored. I make too many mistakes.

Instead I tried a middle-ground that worked pretty well. I dumped the event list into Numbers.app [2], then I wrote a simple Concatenate function [3] to construct Quick Add friendly statements like:

Baseball: LINWOOD MONROE - HIGHLAND PARK at HIGHLAND PARK on May 17, 2011 at 4:15 PM for 2 hours

I then pasted the statements into Quick Add one after the other [4]. Unfortunately Quick Add doesn't allow one to specify a target calendar, so they all went into my personal calendar. I had to do a search on "Baseball: " to find them all, then edit each one to move it to the shared family calendar. Even with that quirk it was relatively painless to enter data this way.

Which says something about how bad CSV import is!

[1] I though I'd read that Google was introducing a rollback option for calendars, but I can't find it. Must have been my imagination. 
[2] I bought it on the app store for a pittance, and I'm getting quite fond of it.  The font display is surprisingly bad, but that's not unusual in OS X (Mac Classic fonts were better, and Win 7 is best). Where it bests Excel is layout -- you can put as many table/spreadsheets on the work surface as you want.
[3] This doesn't work very well in Excel. In Excel a reference to date produces a date serial number in Concatenate. I believe this is a defect, and it's probably as old as time. I'm glad Numbers.app goes its own way. The function looked like this: =CONCATENATE("Baseball: ",E3," at ",F3," on ", C3 ," at ",D3," for 2 hours")
[4] A smart import function would use quick add style NLP to process any number of lines into events, then it would allow a user to correct the list, then it would import. With an undo option of course.

Picasa web albums and color management

[See the updates at end. My initial impression was based on dated material.]

I finally consolidated my images with Google's Picasa web albums: Migrating images from SmugMug to Google's Picasa image store - Lessons in data lock and business models.

It was a painful process.

After i was done I reviewed my newer images. They don't look nearly as good as they should. In particular they looked better on SmugMug.

Turns out Picasa web albums don't support color management (ICC, colorsync, etc). (See also - all these discussions get "closed to new replies" pretty quickly.)

Please cover your ears while I scream.

Ok, you can uncover now.

I used to use sRGB profiles, so the lack of color management was less apparent -- even with Mac/PC gamma issues (newer Macs quietly converted to PC Gamma). Now I use Adobe RGB color profiles, and I get to see how badly Picasa's color management sucks.

Sometimes you just can't win. I've started a newer thread on the online help forum, but I doubt there's any good news. I wonder if I'm going to have do my own image sharing and give up on the online services.

Update: A google support tech tells us that Picasa Web Albums will use the colorsync profiles of images uploaded with Picasa 3.8. I've a question pending on whether this is also true for Google's

Update 4/5/11: More from Google ...

Uploading via the Picasa Web Uploader should also preserve your color profile, and I tested this with Firefox 4 and Safari 5 on Snow Leopard and it's looking good on my end. Photos 1600 pixels or smaller are still color managed, but their thumbnails currently aren't (to help decrease load times)

Update 4/9/11:

your color profile is also preserved on photos 1600 pixels or smaller, but the thumbnails for these smaller photos (when you're on your album page, not a photo page) don't preserve your color profile. This only affects thumbnail previews, not the actual photos themselves.

If I understand this correctly, Picasa now preserves color profiles. Thumbnails for images smaller than 1600 pixels displayed on an album page are not color managed (how would the browser manage conflicting directions from hundreds of images?). A photo page should always use the preserved color profile.

See also:

• Mac OS X v10.6: About gamma 2.2: "Some images that do not contain color profiles might appear darker in Mac OS X v10.6 than they did in earlier versions of Mac OS X.  Adding the sRGB IEC61966-2.1 profile or Adobe RGB (1998) profile to these images lets them display correctly."
• Gordon's Tech: Smugmug: just use sRGB and be happy
• John's Digital Photography Page - color profiles (old)

Migrating images from SmugMug to Google's Picasa image store - Lessons in data lock and business models

Life is fractal. That is, sampled at scales small and large, it resembles itself. Sometimes I think this is profound, especially when looking at smoke rings of galaxies, but maybe I'm just having flashbacks.

So you don't need to spend 15 years in healthcare IT to understand why progress is slow. You only need experience migrating an address book between a PalmOS device to a Windows platform to OS X to Google Contacts (see also: synchronization is hell). That will tell you everything you need to know.

Similarly you don't need to be a corporate CEO to understand the strategic role of switching costs. It's very easy to switch between Subaru and Honda, not so easy to change checking accounts or move from Microsoft Office to Google Docs. Business strategies differ [2]; though this is never discussed in the sycophantic business book business. You only need to look at moving photo libraries from SmugMug to Picasa Web Albums [1] to learn this.

I am doing this now, and it's an interesting process. As expected, the switching costs are high. In most cases it's not worth the bother; if you have the original collections in iPhoto or a similar app it's best to abandon the old image libraries and start over. I'll explain first what you can move and what you can't, and what the implications are.

What you can move

• SmugMug will bundle all images into a single archive, hosted on Amazon's S3 servers, and allow download. This is commendable, and better than many vendors offer.

What you can't export from SmugMug (what you lose)

• Original file names.
• All metadata other than what's embedded in EXIF files (so you do get the image acquisition dates).
• Any titles, comments, notes.

This data lock story has interesting implications:

1. If you have the original albums/libraries in iPhoto/Aperture then you usually don't want to bother migrating albums. (In my case I have them, but for a few albums it's marginally more convenient for me to download and upload again even without metadata.
2. SmugMug is minimally useful for offsite image backup. Images without metadata are better than nothing, but you should not consider SmugMug to be any kind of alternative to image backup.
3. If you ever edit annotations online, then you deepen your data lock. Nobody, not even Google, allows export of this kind of metadata (likes, commentary, etc.). The business advantage of  "social," and "Cloud services" comes from the high switching costs created by data lock.

Fortune 500 corporation or photo hobbyist, fractal life means lessons are easy to learn.

[1] Why am I moving? SmugMug decided years ago not to invest in OS X support. I gave them a few years, but then I reluctantly migrated my newer images to Picasa web albums, which had significantly better OS X (and later mobile) support. Now, in the interests of simplifying my online life, I am consolidating and giving up my old collections.

FWIW, here's why I would start with Picasa today, though a professional photographer would certainly prefer SmugMug. My decision has nothing to do with price, SmugMug is $30 a year and if I promoted SmugMug I'd probably pay nothing (referral fees). In fact, since Google charges differently for storage, they might be marginally more costly.

1. Google's data freedom policy (data liberation team) is enough by itself to make my decision. Google supports full data sync, including metadata, to a cross platform app. No other vendor does this.
2. SmugMug's lack of support for metadata export means it's not a supplemental backup store. Google's data freedom means it is.
3. SmugMug has wisely focused on the professional photographer, but that means most of their services aren't useful for me.
4. SmugMug is vastly better for printing images, photo merchandise etc. I print about 3 images a year.
5. Picasa has far better OS X integration, though Apple is no help here.
6. Google's image sharing interface is easier for my mother to use.
7. I need to simplify my technological life. That means Google and Apple for me -- the right balance of coopetition. Between the two of them I get what I need.
8. I am very annoyed that SmugMug auto-renews my account, and offers only immediate cancellation rather than a non-renewal option.

[2] Companies with captive customers face terrible temptations, companies with mobile customers have different temptations. Think of the relationship between divorce laws and the status of women.

Update 3/26/11: I downloaded a few albums, but it was pretty tedious to connect what I downloaded to the album names shows in SmugMug. I have the originals, so I focused on a few albums for a group where I probably didn't keep every original. The rest I vaporized. One less vendor to deal with.

See also:

• Gordon's Notes: smugmug review: full res image sharing and photo printing (4/2004 - when I first became a customer. Back then my tech posts were in Gordon's Notes.)
• Gordon's Tech: Smugmug: just use sRGB and be happy (1/2006). Today we're still struggling with color profiles, but I with Windows 7, IE 9, Chrome, Safari and 10.6 maybe we're slowly getting to what we expected around 1998.)
• Gordon's Tech: SmugMug + PictureSync vs. Google Picasa Web Albums (9/2006). I thought SmugMug's future was limited. Wrong -- they seem healthy still! They found a paying market in professional photographers, and they took full advantage of high switching costs.
• Gordon's Notes: The rise of software rental (aka software as service) (2/2010). Another perspective on switching costs.
• Gordon's Notes: Cloud data: Should I trust (Simplenote) Simperium? (8/2010). Low switching costs make Simperium trustworthy if you assume all the data is public. Low switching costs make for honest and relatively ethical companies. This is, incidentally, why geeks love Dropbox.
• Gordon's Notes: Google has a Data Liberation team (3/2009). More than anything Google says, and more than anything else they have ever done, this has been their most important non-evil act.
• Gordon's Tech: Evernote's import/export test (updated) (7/2008). Evernote is better now, but I have not returned to study them. For them the data lock temptation must be irresistible.
• Gordon's Tech: data lock: All of my Gordon's Tech 'data lock' tagged posts.
• Gordon's Notes: data lock: All of my Gordon's Notes 'data lock' tagged posts. (Yes, I think data lock is interesting!)

Why cropping an 18 megapixel image isn't as good as an adequate telephoto

An 18 megapixel image has twice the data as an 9 megapixel image.

So does that mean a 135 mm telephoto and an 18 megapixel sensor can do as well as a 270mm telephoto and a 9 megapixel image?

No.

Why not?

Because when you crop the 18 megapixel image, and double the apparent size, you also double the image noise.

Blogger's text editor: I make another plea for a rational approach to paragraph formatting

It took considerable restraint for me to write this so politely.

Please stop using div tags to define paragraphs - Blogger Help

My blogs start around 2002, when Blogger used carriage returns to delimit paragraphs. They extend through the time that Blogger used <br> tags with or without hidden carriage returns.

These days, with either the "new" or legacy editor, it's unclear to me what Blogger does. I only know that when I use MarsEdit, Ecto or the native editor I see pairs of div tags. This causes a mess. Depending on which editor I use paragraphs vanish or spacing doubles. If I open older posts with the editors I get no paragraph spacing.

If I go into preferences I see:

"If Yes is selected, single hard-returns entered in the Post Editor will be replaced with single <br /> tags in your blog, and two hard-returns will be replaced with two tags (<br /><br />))."

Of course br tags are no longer used, so this language is simply wrong. If set it to "No" my old posts format incorrectly. To put it mildly, this is a mess.

I would like Blogger to use tags to, you know, delimit paragraphs. I would like Blogger to convert older posts to use <p> tags. Please Blogger, stop using <div> and <br> to define paragraphs, it's not what they're made for.

It's hopeless (yes, I've tried changing templates). Alas, I don't think there's really any way to move my blogs and keep any sort of reasonable formatting across 5,300 or so posts.

See also:

• Blogger's 3 year paragraph debacle - the case of universal line break conversion (10/2010). There have been years of complaints, until most everyone who cares has moved to WordPress. (Spammers don't care.)
• Gordon's Tech: Migrating from Blogger to WordPress - a guide