Troubleshooting an OS X iOS device recognition problem

There's a bug in OS X 10.6 ("or later") that can make an iOS device unrecognizable: http://support.apple.com/kb/TS3540.

I'm sure a fix is coming. The tech note is worth tracking though because of the sequenced steps in the recommended fix. It's basically a full iTunes uninstall ...

1. delete com.apple.usbmuxd.plist~orig
2. delete iTunes
3. delete AppleMobileDevice.kext
4. delete MobileDevice.framework
5. reinstall iTUnes

Might come in handy for future obscure sync related bugs.

Downloading a shared Picasa web album in OS X

Despite Google's data freedom record, they've done a mediocre job freeing Picasa web albums. I know of only two ways to download an entire album.

You can use the Picasa Web Albums uploader tool to download albums that you own. I think this tool works with non-Intel machines.

If you have an Intel machine you can use Picasa for OS X to download albums you own - and, more importantly, shared albums from other people.

I've done the latter. It works - but it's a pain. Read the documentation: Downloading Albums and Photos. Here are a few additional notes to help out:

1. When you install Picasa it starts indexing your drive. Go to Tools:Folder Manager and mark every folder as exempt. It will stop indexing.
2. Don't bother looking for the option to download from an album URL. It's not there. Yes, this is very weird.
3. Go to the shared album and look for the 'Download' menu item. Click on it. You may see that 'Download to Picasa' is unavailable -- grayed out. That's because you need to quit Safari and restart after Picasa is installed (and perhaps running). Now you should be able to see this option. Click it.

Picasa stored my images in Pictures\Downloaded Albums. I dumped them from their into iPhoto then deleted them.

MobileMe vs. Google Calendars

MobileMe Calendar now supports public read-only sharing using the webcal (.ics) format. There's no public display as an HTML page.

MobileMe users can be invited to view and edit a calendar.

There is no support for subscribing to a non-MobileMe calendar. There is a mechanism for importing from Outlook or (bizarrely) iCal. It's not documented, but I believe Outlook import requires installing some Apple software (iTunes?) and I am pretty sure it won't work with an Exchange based calendar.

It seems users can't share on both MobileMe and publicly! If you make a calendar public you lose the miniscule sharing icon to the right of the calendar name. Weird.

There's some iCal integration, but, judging from a flurry of tech notes, there are lots of bugs. I suspect Apple wants pre-10.7 users to use the web UI and forget iCal. I assume MobileMe Calendar has good iOS calendar integration, but there's no iOS support for editing calendar-associated tasks.

Overall, I'd give Apple a C+ for this effort. If they were to add subscription they'd graduate to B-. The significant advantage over Google Calendars is simplicity and, of course, a far more pleasant UI. The disadvantages are substantial -- no subscription, no web publication, no embedding, etc etc.

Update 10/16: See comments for additional drawbacks. There have also been recent posts from vendors that used to be able to synchronize transactions with MobileMe calendars -- Apple has removed functionality they relied on ...

• Daylite: ... In the process of moving to the new calendar, Apple migrates your existing calendar and deletes the old calendar. In the process of deleting the old calendar, sync services propagates the delete to all sync services clients. Daylite obeys these delete commands (as it should) and moves your calendar data to the trash (lucky we have a trash).
  
  We've communicated with Apple during the MobileMe Calendar beta and we are looking into possible solutions.
• Spanning Sync and the New MobileMe Calendars (Spanning Sync Blog): ... Spanning Sync can sync the new MobileMe calendars to Google, but changes made in Google won't show up on your MobileMe calendars. Unfortunately, Apple specifically disallows syncing of the new calendar format (called CalDAV) using its Sync Services architecture, which Spanning Sync is based on. Spanning Sync can read from MobileMe calendars so "one-way sync" is possible, but making changes to them is currently impossible... we're hopeful that Google will enhance Google Calendar so that it can sync directly with MobileMe without any intervening software. Google is tracking the request for this feature here ...

I imagine Daylite couldn't warn customers due to their beta agreement, but since Apple ignored their concerns their customers have been screwed. Spanning Sync suggests customers revert to the old format.

Apple is not a "nice" partner or vendor, but we already knew that. They are not the best of all worlds, only the best of our world.

I grumpily added my bit to the Google feature request list, though, in truth, I don't use MobileMe because I know Apple won't deliver what I need. I'm not their customer.

The only upside to this story is that MobileMe is using CalDAV, so there's a potential for a better future. I bet OS X desktop support will require 10.7 though, and that OS won't be safe for my use until early 2012.

There's been rumor of a rapprochement between Google and Apple. I hope that's true, because for geeks like me the best solution is combine the best bits of Google with the best bits of Apple (not including MobileMe).

Google's flawed security checklist -- and the right fix from Facebook

I've not seen any official Google admission that account hacking is out of control, but I'm betting my experience is not atypical.

The good news is that Google is doing a (slow) roll-out of two factor authentication; texting a texted pass-token. The bad news is that Google's recent security checklist recommends ...

5. "Use a secure connection to sign in. In your Gmail settings, select 'Always use HTTPS.' This setting protects your information from being stolen when you're signing in to Gmail on a public wireless network, like at a cafe or hotel."

I hope it hurt to write that; I hope the author isn't completely numb to corporate evil. Clearly they knew they were dissembling, because they carefully wrote ... on a public wireless network. 

It is true, https blocks most wifi hacking - but that's not what geeks need to fear. Google doesn't tell us (but I do) that ...

1. The primary threat from untrusted machines is not wifi interception, it's keystroke logging.
2. Any machine running XP, including a corporate machine running current antiviral software, is an untrusted machine.

It's obvious why Google is waffling, which is why they've bumped their evil score. (BTW, they do warn against browser plugins that request Google credentials. That's interesting.)

Ironically, Facebook is seriously evil, but this time they're being the good guy. Maybe that's because keystroke loggers are very common on the XP machines of Facebook's heaviest users. Whatever the reason, Facebook is rolling out a keystroke logger fix using a texted "temporary password" -- ahead of Google.

Facebook has the right fix now and Google has an inferior solution that's weeks away. Facebook is frank about their keystroke logger problem, Google dissembles. 

Mirror  world!

Real world numbers: 802.11n 2.4GHz MUCH better than 5GHz

We've been all wireless at home for a while. It's worked better than I'd expected, but I think we have a particularly noisy microwave (too bad ConsumerReports doesn't rate microwave emissions). We also have 5.8GHz phones, though from what I read that's plenty of separation from 5GHz 801.11n.

I've been tweaking our AirPort Extreme location within the usual constraints of phone jack and outlet. The latest location seems pretty decent (corner of our bedroom closet), but I wanted to see how signal/noise "ratio" varied between 802.11n 5GHz, 802.11n 2.4GHz (Apple default) and 802.11n 2.4GHz plus microwave (5GHz is supposed to be out of microwave range).

The result surprised me. First, this discussion thread has some useful references ...

SNR is the signal level (in dBm) minus the noise level (in dBm). For example, a signal level of -53dBm measured near an access point and typical noise level of -90dBm yields a SNR of 37dB, a healthy value for wireless LANs...

SNR Guideline
o 40dB+ SNR = Excellent signal
o 25dB to 40dB SNR = Very good signal
o 15dB to 25dB SNR = Low signal
o 10dB to 15dB SNR = Very low signal
o 5dB to 10dB SNR = No signal...

My inital SNR results across the clients were

• iMac 5i 802.11n 5GHz: 26
• iMac G5 802.11g: 30
• Macbook 802.11n 2.4GHz: 41
• AirportExpress 802.11n 5GHz: 7
• Nintendo Wii 802.11g: 40

Not bad, though it's surprising who good the Wii results are. It's in the basement. Oh, right -  the Airport Express results sucked. Even the 5i results weren't great.

So I switched the iMac 5i and the AirportExpress to 801.11n 2.4 GHz. The results were much better: 

• iMac 5i 802.11n 5GHz: 36
• iMac G5 802.11g: 30
• Macbook 802.11n 2.4GHz: 41
• AirportExpress 802.11n 2.4GHz: 40 (later tests weren't this good however, transcription error?)
• Nintendo Wii 802.11g: 40

I turned on the microwave and the Airport Express dropped to 20, the iMac to 32 -- but even with the microwave on the 2.4GHz SNR was much, much better than the 5GHz SNR.

With the microwave off it's truly no contest. The 2.4 GHz frequency gives vastly better results in our home than the 5GHz frequency.

Obviously, your results will vary. I think I can see, however, why Apple makes 5GHz a non-obvious option on the Airport Extreme.

[1] AirPort Utility - Advanced:Wireless clients to get S/N by Mac address, DHCP clients to get machine name.
[2] Didn't used to work, but does with my latest base station location.

Google URL shortening

When I'm logged in to my Google account, goo.gl/Ou0h Details tells me how often goo.gl/Ou0h (tech.kateva.org) is clicked and gives me visitor information as well.  The information page includes a two dimensional bar code that QuickMark.app decodes as a URL.

The URL shortening page is new, but the service has been around for a while. You can create it from any page using a Google Toolbar or from extensions for Firefox or Safari or from various bookmarklets.

The primary value of Google's service, of course, is that it is likely to be around for a long time, and it comes with a full set of security services. Of course if you ever lose control of your Google account ....

A free lesson in multi-user web apps – Google Docs collaboration

Google has published a 3 part overview of how their Document collaboration framework.

If you’ve ever wrestled with permissive locks and multi-user collaboration (ex: encounter based care) it’s a bit mind blowing. They must have a bucket of patents on this one, but the lessons are free for all to learn and apply …

1. Working together, even apart
2. Conflict resolution
3. Making collaboration fast

If nothing else, these articles do lay out all the issues. They provide a framework for thinking about these problems.

I do love blogs.