Fixing Outlook's Ctrl-D usability bug - with AutoHotkey

The letter S is next to the letter D - on my keyboard anyway.

That means when my lifelong q10sec Ctrl-S twitch hits, there's a 1/200 chance I hit Ctrl-D instead.

In Outlook Ctrl-S saves an email, but Ctrl-D deletes it - without warning. In the midst of my work my email vanishes.

This is annoying, but I usually catch it. I make a trip to the Deleted Items folder and drag the email back to Drafts. The other day, however, I was multitasking and didn't notice I'd deleted my email. It wasn't in the UI, it wasn't in Drafts, I probably assumed I'd sent it. Later I emptied my Deleted Items folder (because, by default, Microsoft's slightly daft Search tool includes Outlook Deleted Items, I keep that folder empty).

The email was gone. Minor panic ensued the next day. Fortunately I realized the email was lost, so I responded with an apology rather than being obnoxious.

I resolved to fix the bug. I found very little on the web, really just this one unanswered question: Ctrl-D del adjacent to Ctrl-S save. Either this afflicts very few people, or most don't realize what's happening.

So I asked on our corporate social network (Yammer) and a colleague gave me the answer. He wrote me an AutoHotkey macro that swallows the Ctrl-D key when Outlook is running.

;-------------------------------------------------------------------------------------
#ifwinactive ahk_class rctrl_renwnd32
^d::
return

It works!

Since I grew up on TSRs (if you don't know what that means then you are blessed in more ways than one) so I try to avoid system hacks like this, but Outlook's Ctrl-D bug has broken me. Since I've signed up, I now need to find other ways to use this utility...

Pinboard and IFTTT - blog, task, share

Despite concerns about too many moving parts, I'm still using Reeder, Pinboard and IFTTT as my core information process workflow. I just added two more IFTT actions based on single character Pinboard tags. The current set is:

• s: Reeder/Pinboard shares with the tag s are "shared" via IFTTT to Twitter and WordPress (it's a public tag, so there's a Pinboard feed too).
• t: Reeder/Pinboard shares with the tag t generate a Gmail email to a 'secret' toodledo address that creates a task. This is most often a f/u task on a product I'm interested in.
• b: Reeder/Pinboard shares with the tag b generate a Gmail email to a 'secret' toodledo address that creates a draft Blogger post. (I prefer this to IFTT's limited Blogger channel). These are subjects I would like to write about.

I enter the one letter space separated tags when I share to Pinboard from Reeder.app for iOS and OS X, or from Google Reader. Many posts have two or three tags.

Password security: what if your desktop were stolen?

For various reasons, in addition to using 1Password (always encrypted), I keep a comprehensive set of family user credentials in a FileMaker database that began life over 15 years ago.

I need it to be accessible to Emily or my estate, particularly if I'm dead or incapacitated. I don't like making it too accessible though; recently a neighbors home was vandalized and some computers were taken. Losing hardware is always a problem, even if you have homeowner's insurance and good backups [1], but losing an unencrypted comprehensive password file is a bigger problem.

On the other hand, I don't need to defend against the NSA. The chances is low that anyone stealing my Mac would even bother to Google ways to browse the file system, or would know how to use FileMaker. It's even less likely that they'd scrape deleted or cache data. I just need need decent security.

Whole disk encryption would be more than decent [4], but I'm running Snowie [2] on the main machine. So I do that just on my MacBook Air. Instead this is what I do for the password file and for similar data:

• Used Disk Utility to create a 500 MB 256bit encrypted sparseimage in Users/Shared and moved my files to it. These images ignore permissions by default, that's what I want.
• I set permissions on both the sparseimage file and the mounted disk image to give r/w to Emily and I and nothing to anyone else. (You can't set permissions for the mounted image on the sidebar, you have to navigate the Finder to view the mount)
• In both of our user accounts I mounted the image and allowed OS X to store the password in the user keychain (so anyone knowing our login pw can get it).
• In both of our user accounts I added the image to the User Accounts login items.

With these settings every user can see a folder called 'confidential' (hint) but only Emily and I can open it.

 

It's just enough security so that if our home server were stolen I'd be able to revise our passwords over days rather than hours. [3]

 

-fn-

[1] I'm a believer in using two relatively unrelated techniques to do at least daily backup. For me thats Carbon Copy Cloner and Time Capsule/Time Machine with offsite rotation of 3 disks containing clones of varying age.

[2] Not only is Lion a memory/perfomance slug, it's also tied to iCloud -- which has been a bit of a disaster for me. I'm hoping to skip to Mountain Lion; maybe I'll get some features to go with the bloatware and the iCloud malware.

[3] The way I configure CCC deleted files are kept in archives. So after moving the database to the disk image I deleted it on CCC. That's not too bad a risk however because my clones are stored on an encrypted image (for offsite backup). So even if they take my backup disk they won't get much of benefit. If thieves took my Time Capsule I'd be in trouble with copies of the unencrypted file. So I opened TM and told it to delete ALL backups of the file (made me nervous to do that!). So I feel relatively covered, at least to the level of a typical burglar/vandal [4]  But wouldn't Time Machine backup the data to an unencrypted store anyway? Maybe a disk image is a better idea?

Update 7/18/2012: There's an odd permissions bug with creating documents on the shared image that limits this somewhat. Regardless of permissions on either the disk image or the mounted disk, whichever user mounts the image first has the "most" access. That is both users can open and edit existing documents/files, but only the first user to mount the image can create new documents. The second user gets this error message:

The operation can't be completed because you don't have permission to access some of the items.

This happens even though the image is configured to ignore permissions with both journaled and non-journaled MacOS formatted images and with sparseimage and standard image.

The workaround, paradoxically, is to turn off "ignore permissions" for the mounted image. With permissions enabled both users can read and write to the mounted image.

 

Don't try converting a MacBook Core Duo to Lion

We converted our 2006 MacBook Core 2 Duo dual USB to Lion a few weeks ago.

Don't bother; the MacBook isn't up to it. It's too slow.

I suspect more memory or an SSD drive would help, but, really, six years is a long time for a laptop.

I think we're due for a new machine. When we get one I'll wipe this machine and revert it to Snow Leopard. That would mean no more iCloud, which is, at this point, a feature.

Incidentally, it has the flaking plastic border problem that's common with older plastic MacBooks. It started doing it four years ago and has been stable since; we use scotch tape to close the gaps. A friend tells me Apple will replace the broken plastic for free, even on quite old devices. The hassle isn't worth it for us, but it would be nice if that were true.

The Outlook 2007 blocked sender list import file function is flaky: how to fix it.

This summary is not available. Please click here to view the post.

Hotel iCloud

"… Welcome to the Hotel California
Such a lovely place (Such a lovely place)
Such a lovely face
Plenty of room at the Hotel California

"We are programmed to receive.
You can check-out any time you like,
But you can never leave…"

Eagles, Hotel California

I'm in recovery from a tedious multi-update post on my failed iCloud transition, and still digesting all I've learned. I'd like to pass on one conclusion.

iCloud really is different from MobileMe. 

MobileMe was a peer-to-peer synchronization service. My data lived on my machines, as well as on MobileMe.

iCloud is a server solution with local caching. The data moves to iCloud, it is no longer On My Mac.

Yes, I know it seems to be in the usual AddressBook folder, but as I discovered the real source of truth is remote. When there is a clash of opinions on the state of data, iCloud wins. If your data goes bad, you need to fix things on iCloud. Good luck with that.

Perhaps even more importantly, this is a one way trip. Yes, if you know the ins and outs you can copy Contacts back to your Mac and remove them from iCloud. You cannot, however, get your Group relationships back. That data has checked into Hotel iCloud.

With iCloud, OS X Mail and Address Book/Contacts are much more like Google Mail/Contacts -- which also has an offline mode. Apple's data lock is stronger than ever, and I have a very bad feeling about the next version of iTunes.

Chrome broken in OS X due to certificate change: Issue 108238 - Canary asks for access to every keychain item

I got hit with this bug on my Air: Issue 108238 - chromium - Canary asks for access to every keychain item.

We had to change the certificate we use to sign Chrome.

Transition code was included in (stable channel) Chrome 19.0.1084.53 and 19.0.1084.54 to migrate your Keychain items. If you’re on the stable channel but did not launch one of these two versions, upon update to 19.0.1084.56, your Keychain items were “lost” and need to be reauthorized manually.

There is a mitigation in place for 19.0.1084.56 and newer: when Chrome automatically updates itself, the updater will perform the transition. Unfortunately, this is only effective if the updater has permission to do this, and that’s generally only the case when you’re on a “user ticket,” and not when “Set Up Automatic Updates for All Users” has been used.

The correct thing to do when such a dialog appears is to click “Always Allow”. We don’t anticipate any further Keychain changes like this for a very long time, and we hope that in the future, if we do need to make such changes, to have a longer time in which to let the transition run.

It's an interaction bug between Chrome Sync, OS X Keychain, Lion, and a certificate signing change with a short overlap period:

The at-update reauthorization is intended to handle the reauthorization for users who rarely restart Chrome and might miss out on the at-launch step during the window where Chrome is signed by the old certificate but has the new reauthorization code in place.

It hit a machine I rarely use where Chrome was probably running, so when I restarted it the old cert had expired.

There's no plausible workaround, the Google support forum thread on this topic has quite a few deleted messages. The fix seems to be to switch to Safari or Firefox. In a case like mine, where there are hundreds or even thousands of passwords in the Keychain, tapping "Always Allow" repeatedly can take a very long time. Chrome is unusable for now on my Air.

I'm curious as to why Google made this fairly urgent change to their Chrome code signing cert. My Google searches didn't turn anything up. I assume it's related to a significant security breach.  The silence is curious.

Update: Since this was not my main machine I applied the drastic "fix" of deleting my entire #$#$ user login keychain because Google was supposed to 'regenerate it'. Which it sort of did, but the process turned into a slog of bugs and issues far too tedious to list (including a password displayed in a font that rendered a zero as an o. Even after the Google sync was done I am still out many passwords on that machine that are used by other apps. I really don't recommend this approach. It's easier to switch to Firefox or Safari.

So far tonight Google and Apple are causing me similar amounts of pain.