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.

An iPhone 3G with unchangeable black wallpaper - solved (groan)

Skip to the end for the (sob) solution ...
--
Tim's 3G wallpaper was black. For him this was not a feature. He likes setting his wallpaper, though not always to my tastes.

I tried restarting his iPhone, but the problem persisted. Then I installed 4.1. That went oddly; it threw up a very cryptic and long error code about a firmware update failure, but then it completed. (Yes, I wish I'd noted the error code. These sorts of number codes are typically useless, but they're better than nothing.)

The phone seemed fine, but the wallpaper was still black. Interestingly it let me choose an image, but only the lock image changed - but there was no error code and no option to choose a background image.

After that I ran the troubleshoot gamut ...

• restore default settings
• erase all from iPhone then reactivate
• force into DFU (Device Firmware Update) mode do a new (4.1) firmware restore

The repeated firmware install went without an error, but even that didn't work!

I think next fix I can imagine would involve jailbreaking and browsing the file system to see if I can locate an odd image stored with some kind of permissions or lock problem. Or I could try an Apple store.

Or it could be a memory hardware error.

Puzzling.

Then I tried restoring the phone, and I got "an error occurred ... -402636802". I then looked at the app install and it was grayed out. I knew what that was due to!

I disconnected from iTunes, turned off restrictions (App Install), reconnected, and let iTunes finish the app restore.

Still can't fix the black background (missing background image really) problem.

Update:

I figured this one out.

Remember, it's been a while since I used a 3G.

The 3G never had changeable wallpaper. Only the lock screen could be changed. Tim misled me by phrasing this as a lost feature. In reality he just wanted me to make his phone work like his parents' phones.

Well, that was certainly educational. Embarrassing too. At least it was a cold gray day.

The phone is fine. The install bug is real though.

When Safari locks up - Kill Flash process

A #$!@ ad on Salon locked up Safari.

I started Activity Monitor, sorted by Process Name, and force quite Flash Player (Safari internet plug-in).

Safari lives again.

Death to Adobe.