GV Mobile is back - wait for the reviews

GV Mobile has returned to the App Store, presumably due to FTC pressure on Apple. Is the Battle of Google Voice entering a new phase?

It's now GV Mobile +. I bought it, but you shouldn't until you read some reviews. There are already troublesome signs

• Sean didn't manage to update his web site prior to launch.
• It's not an update to GV Mobile, so you pay again. I'm actually fine with that, but it does mean GV Mobile customers should wait for reviews.
• It wasn't tested on the iPad.
• It apparently doesn't run on 3.1 -- and there's no mention of that in the iTunes description! (Bad form.)
• It's not compatible with Google's "Multiple sign-in" feature.

Basically the developer got caught out, GV Mobile + was not ready for launch. Give it time, read the reviews, and one demerit to Mr Kovacs.

Update 9/25/10: Working fine in light use. Probably coincidence, but the voice connections using this methods have been better quality than what I was getting dialing direct. It's faster and more reliable than setting up a long dialing sequence with pauses. I use it 3-4 times a week to call Canada.

Reeder vs Byline: Battle of the iPhone Google Reader clients

I've used the Google Reader client Byline. app on my iPhone for over a year. The latest version is the best to date, but it's still has synchronization problems. It continues to show me articles I've read.

Reader itself has problems of this sort, but Byline is significantly worse. So lately I've been trying Reeder. I wrote this quick review for the app store ...

Bad news first. It crashes more than it should, but not more than Byline. Secondly it needs a manual, and it desperately needs a "reset" button to wipe its local store and force a reload from Google Reader. Thirdly it get its sync state confused, but no more than Byline. Lastly it doesn't precache the source pages, so Byline has a big edge there. There's no support for creating a Google Reader "Note" status update (Byline doesn't either).

Now the good news. The under-documented UI is elegant -- once you figure it out. (Programmers raised on games think life is a role playing adventure.) Readability is excellent. There's an option to open source pages in Instapaper Mobilizer - a vast improvement over Google Mobilizer. Services and configurability is excellent. Performance is great, so stability is now a bigger issue. It shows Following (Byline doesn't) - but here it gets counts wrong.

Bottom line - definitely worth the money, currently the best of breed, room for stability and synchronization improvements and, for the love of Binary, please add a reset option.

I think Reeder is a better app than Byline -- for the moment. It's not perfect though. If the developer doesn't fix a few bugs soon I'll take a look at Mobile RSS next.

See also (reviews found by search on [Reeder Byline "Mobile RSS"]:

• Reeder vs. Byline – An Instapaper Addicted Mobile RSS App Review: He loves what I miss -- the caching of full pages in Byline. In the end, he's torn.
• Reeder 2.0: Finally, An Awesome iPhone Feed Reader Arrives
• iPhone’s Missing Feed Reader – Shawn Blanc: Likes Reeder, but wants more

Update 9/30/10: No contest. Reeder is much better. There are bugs (Followed count), and crashes, and I miss the original page pre-caching -- but it's still the clear winner.

The Cisco WebEx ARF Player for OS X - convert to MP4

Welcome to the world's only documentation on the Cisco WebEx ARF Player for OS X.

You have come here because you downloaded a WebEx ARF file. These are used by some training companies. You brought it home, and you want to put it on your Mac so you can convert the ARF to .MP4 and transfer it to your iPhone. Perhaps you know that the ARF Player for Windows will export to Flash, WMV and (takes @ 1 hour) to MP4.

You have downloaded the OS X version and completed the installation. Now you're ready to begin.

Except ... where's the application?

Sigh. I might as well tell you directly. The OS X version of the ARF Player has no conversion options. All it does is play the ARF file. The executables are installed in your User Library:

/Users/(user name)/Library/Application Support/WebEx Folder

There's no Application UI, but if you double click on an ARF file it will play. There's also a shortcut on your desktop

I suppose we should be grateful that they used an OS X installer with a log. I think the uninstall is deleting the Library Folder.

If you want to convert to .MP4 on a Mac, you'll need to run a VM.

Yes, Cisco does suck.

You can, however, play back the ARF file and use Audio Hijack to grab the audio as it plays and save it as an AAC or MP3 file.

Resetting permissions from the OS X 10.5 and 10.6 Installation DVD

The Installation DVD has the ability to reset permissions using, oddly enough, the "reset password" utility. CNET Fix-It describes this tool in the context of moving files between user account and resetting their permissions..

How-To: Migrating to a new user account in OS X | MacFixIt - CNET Reviews:

Insert your OS X installation DVD (the gray restore DVD that came with your computer should work) and boot from it by restarting while holding the 'C' key down.
Select your language and choose 'Reset Password' from the 'Utilities' menu.
In this utility, you can reset the permissions on your home directory, so follow the instructions to do that on your new account.
When the permissions have been reset, reboot the system with the 'Shift' key held down (it boots to 'Safe Mode') and try logging in to your new account.
If everything is successful, then reboot normally.
Go to the 'Accounts' system preferences and remove your old account, choosing the option to delete the home folder for that account.

I'd never heard of this 10.5 (Leopard) feature. The utility can be used to cure a permission bug related to "apply to enclosed items" that afflicted me in 10.5. MacWorld describes the permissions fix, and the bug, best ...

... the permissions problem ...  can arise if you make a change to the Sharing and Permissions listings in the Finder’s Info window for a folder in your Home directory, and then select the “Apply to enclosed items” option from the Info window’s Action pop-up menu. You’re especially likely to see these symptoms if you do this for the Home directory itself, but I believe the issue can also arise if you perform the action on subfolders...

... sudo chmod -RN ~ ... removes all Access Control List (ACL) modifications from all items in your Home directory. These modifications can come from certain changes made to the Sharing & Permissions section of an Info window.

Next, start up from a Leopard Install DVD and select Reset Password from the Utilities menu. Here is where the new feature appears. This utility has been around for quite awhile, certainly prior to Leopard. However, the Leopard version sports a new option—Reset Home Directory Permissions and ACLs.

... it’s not clear (at least not to me, with my limited UNIX background) why the Terminal command is even needed, as the Reset Password action appears to include what the command does. I could not find any documentation for the Reset Home Directory Permissions and ACLs action, so I could not confirm this for sure.

Second, it is not clear whether the symptoms are due to a bug in how “Apply to enclosed items” works, which Apple will hopefully fix—or if you are simply never supposed to use the command with your Home directory.

Is this a good time to mention that I hate OS X Permissions.

I checked my copy of the Tidbits book "Take Control of OS X Permissions" but they seem to have missed this one. I'll send in a reference to this post so they can add it with the next update.

Apple's support glitch - .Mac (dotmac) accounts don't work properly

I tried Apple's new support system - Express Lane. It looked ok until I tried their Support Profile feature ...

Apple - Support - My Support Profile

... We're sorry, you are signed in with an Apple employee or contractor account that cannot be edited with My Support Profile...

I've seen this before. Old timers with .mac Apple IDs are incompatible with Apple's customer database. It's been years, but they can't make the conversion.

Apple is probably waiting for us to die.

Google hack lessons - where the geek risks are

I've learned a lot about security risks since my My Google (gmail) account was (harmlessly?) hacked. I'm still learning, but I need to return to some of my recent posts and correct the mistakes I made.

Some impressions today ...

1. Google is not working this problem well. Their ownership authentication strategies smell of stale desperation [1]. Do they have corporate progeria?
2. The risks for non-geeks are different from the risks for geeks. We all know the non-geek risks: trivial passwords, dictionary attacks, phishing, etc.
3. The risks for geeks are password reuse, password capture and careless "secret question" password resets. "Strong" (high entropy) passwords don't help with any of these.
4. Password reuse risk comes from using the same password at multiple sites, one of which has weak security, or goes bankrupt and loses control of its data, or is a honeypot - either by design or by hack.
5. Password capture risk comes from virus/trojan keystroke loggers (esp. at work), browser exploits (esp. at hacked sites), and, potentially, fraudulent apps (desktop, iOS, Android).
6. Password reuse and password capture risks are synergistic.
7. Security (secret) questions have traditionally been considered a security risk created by companies with accelerated dementia (see also), but, in a world in which passwords may be too easily stolen, they might be a good idea, assuming Google keeps a history of security questions and answers. (We don't know if they do. I assume they do.)

For a geek then, risk mitigation involves

1. Do not ever enter your primary Google credentials on an untrusted platform. Never at work, never on an XP machine, never for a web site, never for an untrusted app. This means you need to create a secondary, personal, full Google account and grant it limited access to core Google services. The secondary account is used on untrusted platforms and is disposable.
2. Don't use OAuth and similar technologies. No, they don't store your high end credentials. The problem is the whole point of OAuth is using strong credentials with the OAuth provider, but then you can't use those credentials on untrusted platforms.
3. Don't reuse your high end (Google) credentials. This is a royal pain. Practically, it means you can only manage 2-3 high end memorized credentials (pattern based password versioning is high risk), so you can only have 2-3 high value services. Low value services get disposable passwords.
4. In the unlikely event that you own a phone that doesn't reveal your gmail address, consider signing up for text message password-reset.
5. Make the Security question your friend. Write your own question, and use either a passphrase you use nowhere else or just enter a GRC password. Write down the answer on paper and save it somewhere safe. Keep the question and answer in your encrypted iPhone password database.

I need to point out a few more things about the Security question [1]

1. If your account is hacked you need to change your Security question. Why? Think about it. You can't read it. You don't know if the person who had control of your account changed it. You can set it to what you meant it to be.
2. Since the Security question can be changed, we have to assume Google keeps a record of past responses. Otherwise it's worthless. On the other hand, if Google keeps a history of Security question/answer pairs then any weak Security question will be a problem forever.
3. Make your security question response an unguessable password or pass phrase. Don't reuse it, this is a special account. Put it on paper and in your encrypted iPhone password repository.

-- footnotes

[1] I'd like Google to provide a unique secret account identifier visible only to persons with password access. This can then be a form of identity claim, with none of the weakness of the Security question or the history problems. The hacker would know it, but so would the true owner.

Update 9/20/10: Ideas on how OpenID could be the solution, not the problem.

After the hack: A disposable Google Identity

Aside from the tedious task of reviewing and upgrading a large number of passwords, the biggest change I've made after my Google account was hacked is that I no longer enter my important credentials on untrusted devices. That includes any machine that lives in the virus and Trojan infested world of the XP based American corporation.

This is a bit of a pain. It would be less of a pain if my iPhone had a keyboard [1] and could drive an external display, but that's a few years away.

For now I'm taking a two step approach when I work with devices I don't control (non-OS X/iOS).

1. Using email as a transaction source.
2. Creating a disposable alter ego - a full gmail identity with limited privileges.

There's a lot of typing work I can do using email to "secret" addresses. I can mail tasks to Toodledo which in turn sync to Appigo's ToDo.app on my iPhone. I can mail drafts or posts to Blogger. I can mail invitations to my Gmail address that will turn into Calendar invites. I can't (yet) mail to Reader Shared Notes, but there are workarounds [2].

Of course a keystroke logger will capture these addresses, but there's no money in abusing these and the damage potential is pretty small.

The second task will be much easier when Google finishes the big project of integrating Google App identities with the Gmail/Google Account infrastructure. When that's done it will be easy to create disposable identities with shared access to calendar and contacts. That's many months away however, and based on some early testing a standard Google App account isn't quite good enough.

So for now I created a full Gmail account to serve as a disposable identity. It will have access to our family calendars and will have read/write (but not admin) access to my blogs but minimal access to Contacts. If I lose control of that account, I'll remove its privileges and walk away.

Annoying new world!

[1] I'm hoping to buy a kb like the one I used to use with my Palm Vx ten years ago, but I get the sense manufacturers are waiting for iOS 4.2.
[2] I mail to buzz.kateva.org which I follow in Reader. I Google Reader share from their.