Fixing Lion's "application downloaded from the internet" bug

OS X warns users the first time we open a newly downloaded application.  The message is "xxx is an application downloaded from the internet. Are you sure you want to open it?"

It's a helpful warning. Problem is, for some apps I installed into Lion, it shows every time I open the app. Annoying.

I suspect the bug is that I installed them from my Admin account, but am using them from my non-admin everyday account. A permissions bug in other words. OS X usually has these, no reason for Lion to be different.

The fix for me has been to copy the app to my desktop. Then delete it from the Applications folder. Then drag it back to the desktop. This changed the permissions to read/write for me and ended the warnings. I then tested from my admin account and didn't get warnings there.

Not a bad workaround until Apple fixes this annoying bug.

Update: Thinking about this more, I bet the bug hits if you install from Admin, but never open the app from Admin. Next time I do this I'll switch to my Admin account and open it there.

Banks that support Direct Connect (OFX) with iBank

IGG, the makers of iBank for Mac, list banks that support "DirectConnect" (OFX transactions without website login). This is the kind of information I want when evaluating a bank. (Any bank that supports DirectConnect with (ugh) Quicken should also work with iBank.)

The list is dated 2008, but i'm told it's regularly updated. I hope that's true and that they market this more prominently.

Lego Universe for Mac

I'm trying to install Lego Universe on the Mac. It's a software monstrosity. I'm guessing a botched port of a windows app done by a low bid offshore team.

Lego is becoming a four letter word.

Update: It didn't work. I suspect it can't run on a non-admin account. During early installation the data input fields were partly scrambled and inaccessible. I deleted it and cast a spell upon Lego. The locusts are coming guys.

Services manager for OS X

MacOSX : Services Manager: Apple's top secret utility for managing OS X services.

More from OS X Hints: Better management of OS X Services - Mac OS X Hints

Toodledo: How you can give me the search I need with your current architecture

I've been a Toodledo web app customer for years. I use their web task management service with Appigo's ToDo.app.

It's an old relationship born of historic necessity. Toodledo and Todo don't approach tasks and projects the same way, there's the usual awkwardness of dueling data structures. These days most people would want to use Toodledo's cloud service with Toodledo's iPhone app or Appigo's Todo.app with their Todo online.

I've lived with the two for a while though. I appreciate Appigo's elegant iOS client, and it rarely fails me. That reliability means a lot. I know what works with Toodledo and what doesn't; I only use what works. On the other hand, I admire Toodledo's wide range of task integration and data liberation policies, especially the ability to mail myself a task. That's huge.

On the other hand, I need Todo's full text search. I've been pestering Toodledo to provide full text search of my tasks for (literally) years. They won't do it. So I have full text search of tasks on my iPhone but not on the web. On the web I can only search within a field (default is the task title).

Frustrating. I'm ready to leave both of them for something better. Still, I'll make one last try to persuade Toodledo that they can give me 80% of what I want without abandoning their current infrastructure.

Toodledo, here's the search I want built using your save search function, where "term" is the string I want to search on.

See, it's not so hard. You can do this with your current infrastructure by

1. Let me save this search with a name.

2. Let me make the named search my default search.

3. Provide a checkbox that means "search all fields with this string". Check it and gray out two of the fields leaving me one to type in (there are more elegant UIs obviously, this one has the fewest changes).

Thanks for considering this!

Update: Even simpler. Just let us save this as the standard search.

Update 9/12/11: This time Toodledo had a different response to my inquiry: "This is on our to-do list, but it is our policy to not comment on our roadmap or delivery dates for future feature improvements or bug fixes.". Joy!

iPhone calendar bug: list view one day off

Odd bug! My iPhone's calendar list view was one day off. The day view was fine.

Fix was to turn off google calendar sync to remove those calendars. Then turn it back on.

New one!

Making the most of Google's alternative "2-step" verification model

It's been almost five months since I implemented what I then called Google's two factor authentication. My original enthusiasmwaned significantly as I better understood what Google had done, and how they'd stalled.

Now I'm in a more or less grumpy but stable relationship with Google's "1.4 factor" security model. I wouldn't call it "enhanced" so much as "alternative". If you're not careful, you may end up less secure than when you started. It is definitely not for everyone -- indeed, it's for hardly anyone who uses anything but Google's web UI to access Google services.

I'll share here how I currently live with what Google calls 2-step verification. First, I need to explain what it really is. Disregard Google's labels and descriptions; they're dangerously misleading.

To begin with, consider two kinds of access to Google Services (mail, calendar, documents, etc):

1. Browser based access to Google's services (Ex: Google Docs, Gmail, Google account, Plus, etc)
2. App based access to Google's services (Ex: IMAP/Mail.app, G+/Google Plus.app, Calendar/Calendar.app)

When you sign up for "2-step" you get two kinds of authentication for browser based access to Google services and one kind of authentication for App based access (including many of Google's iOS apps, such as the brand new blogger.app [1]).

Yeah, it's a mess.

There are two kinds of password/token access to Google's browser based services, including the ultimate service -- your Google account security controls:

1. Combination of a standard user-defined password and a token (app created or SMS messaged)
2. "Break the glass" emergency one-time use verification codes for when a token is lost

For App based access you use your Google Account to create one or more long (high entropy, secure if not captured) passwords. Contrary to Google's descriptions, these are not application specific. They're just alternative passwords for non-web services. You can create one and use it for fifty apps (iOS, OS X, XP, multiple machines, etc, etc) or you can create fifty. You can revoke these, but good luck figuring out which to revoke. In practice, if you think you've been compromised, you have to revoke them all. (It's possible that if Google thinks you've been compromised it would revoke only the password used. I'd still revoke them all.)

These Google-generated passwords are powerful. You can't use them for browser access, and  you especially can't use them to get to Google Accounts, but you can use them for API access to all mail, all calendar, iOS access to Docs, etc. The more you create, the harder it is to keep track of all all of them, and the more vulnerable you are. Most of us, however, need these. Often.

So here is what I now do

1. On my work machine, which is not a trusted machine, I use only web access and I require Google to ask for a token at all times. (There's a bug though. Unpredictably Google will decide to trust the machine for a month. As I mentioned, Google seems to have lost interest in 2-step! Even on a "trusted" machine, however, you need a token to mess with security settings.
2. On trusted machines, including my OS X personal machines and my iOS devices, I use the same Google generated password for all apps. I create it once and store it in my encrypted 1Password database. (In the past, before I realized how this worked, I created many "app-specific" passwords. I'm gradually removing those to improve security and simplify revocation.)

See also:

• Gordon's Tech: RIP Password - Google's two factor authentication
• Gordon's Tech: Implementing Google's two factor authentication
• Gordon's Tech: The massive security hole in Google two factor authentication
• Gordon's Tech: Google's two factor: Three weeks later
• Gordon's Notes: Google's two factor authentication and why you need four OpenID accounts
• Gordon's Notes: Life with Google Two Step Verification - Sign-in Failed with Places.app
• Gordon's Notes: The New York Times' bad password advice - and what you should do instead
• Gordon's Tech: Google Chrome sync does not work with 2-step verification
• Gordon's Tech: Google's 2-step verification is the spawn of Satan - iPhone upgrade edition

-- fn --

[1] Wrong! It actually follows a newer practice. It uses a web UI for login. When you try a generated password it requests the browser password then redirects to a (crude) web UI for token entry.