iCloud calendar invitations have been broken since 2011 and nobody has noticed

I’m not sure what’s more amazing — that this has been broken for five years, or that someone once thought this was a clever idea, or that almost no-one understands what’s wrong…

Warning: iCloud Calendar invitations have unpre... | Apple Support Communities

I suspect few people use iCloud Calendar invitations — or else we'd all know about this. It's not a new behavior, it was first documented in 2011. It's still true.

It's important to know about this.

When you send an event invitation to an email address iCloud will look up the person associated with that email address (possibly using Contacts). If that person has an iCloud email address then the invitation will go to their iCloud calendar. No email will be generated. If they don't actually use that iCloud calendar they will never see the invitation.

If the invited person does not have an iCloud address in contacts then an email will be generated.

So if you invite with a gmail address, and iCloud finds an iCloud address associated with the gmail address Contact (see update for correction), no email will be sent to Google Calendar. Instead an iCloud Calendar event will be created.

There is such a thing as being too clever.

Some details are here: http://apple.stackexchange.com/questions/27449/icloud-calendar-not-sending-invit es/29970

I discovered this while doing research for a book on using smartphones to support independent living for special needs teens and adults. Using my sister’s iCloud calendar I invited myself using my gmail address. I didn’t get an email, and her iCloud account didn’t show a sent message. Google found the 2011 StackExchange comment so I checked my unused iCloud calendar. There was the event, waiting acceptance.

A wonderful example of how being clever can be stupid.

Update 1/22/2016

A family member tells me her iCloud invitations appear to recipients with a name that is only associated with the Apple ID she uses for iTunes purposes — because it’s on her credit card.

This suggests the AppleID lookup is based on the email address associated with one’s Apple ID, not on anything in Contacts.app. I visited the AppleID associated with the iCloud calendar that my test invitation appeared on, and it is associated with two non-Apple email addresses. One of them is the gmail address I used in the test invitation.

Note that many people have multiple Apple IDs. I have four. More, Apple now allows one to have an Apple ID with a non-iCloud email address. Note also that it’s been four years since Cook promised Apple would find a way to merge Apple IDs.

This is my new “Apple FUBAR” example.

Update 11/30/2016

Apple has introduced a new Advanced preference setting to iCloud Calendar (web only) that may have been created to fix this problem. They recommend receiving event invitations by email — “if your primary calendar is not iCloud”. Yes, it’s bizarre that this refers to how an iCloud calendar receives invitations, but I think it turns off Apple’s obscure redirect mechanism.

Update 6/16/2023

I think this is still broken. On reviewing the original Stack Exchange post I saw a reference to a bug with invitations that had locations set. I don't know if that was ever fixed.

Quicken for Mac 2015 is not a bad application

I was once an enthusiastic user of Quicken for DOS — despite an annoying tendency to database corruption. Each month I’d receive a 3.5” diskette of credit card data and I’d update our accounts. Quicken for Windows had more bugs, but I stuck with it.

Then, somewhere around 2000, we went all Mac and there were no good personal finance products. Intuit was becoming seriously annoying around that time anyway, so we gave up and simply updated our investment balances yearly. We tried various Mac finance products, but none of them worked for Emily. Most importantly, they didn’t do a great job of automatically pulling data from our accounts, and many of them tried to push us to storing our financial data in the cloud.

Last year we made another go of it. Despite the worrisome lack of a user guide, we bought Quicken 2015.

Surprisingly, it’s worked well for Emily. Automated data download is odd to setup, but once configured it has done well. The application is relatively spartan, and not always intuitive, but it’s been reliable. With a few configuration tweaks we seem to be keeping all of our data local (these days that’s not easy to tell). The Reports are limited, but they have the main things Emily wants. She likes how the spending reports work.

Of course Quicken for Mac 2015 has only a fraction of the capabilities of Quicken for Windows, but I’m not making that comparison. It’s just useful by itself. It’s also astoundingly small for a 2015 application — only 60MB for the Application.

I don’t know where this product is going to go. Intuit is desperately trying to dump Quicken (“desktop technology” — they want to go Cloud based and many money by doing analytics on customer spending), they can’t have a very happy dev team. We’re going to hold off on 2016 until mid-2015, then we’ll look at the bug reports and evaluate 2016.

For the moment though, I’m pleased to find something that works. I assume finance companies want to lock customers in tight, it’s a real achievement to get data out of them. I doubt Quicken will find a good home, but I hope it somehow defies the odds.

Recovering selected OS X Mail.app messages from a carbon copy cloner backup

Somehow I’d enabled my iCloud Mail account in Yosemite Mail.app. This is irksome, because I don’t use it and, sooner or later, I’d somehow send outgoing emails using that sending service.

Which I did. Somehow. 

Which meant I had a set of Sent emails in the wrong place. Impulsively, in Mail.app, I tried dragging them from iCloud Sent folder to Gmail Sent folder. Something was happening … the dialog “Outgoin Messages”. Yikes! I don’t want them to be resent! So I canceled. (I was wrong, this is what Mail.app does when one is copying from a local store to an IMAP folder.)

All the emails vanished everywhere (I think this is a bug). There was nothing in iCloud Mail on web or OS X and nothing in Gmail — or anywhere else. So annoying — especially because I think I made the same mistake years ago.

I could live without those 49 errant emails, but it’s vexing to lose data. So I turned off internet connectivity and dug into last night’s Carbon Copy Cloner backup (Time Machine restores are so painfully slow I use them as a last resort, and I’m not sure how they behave for attempts to restore a specific set of emails.) The User/Library folder is hidden, but Go To Folder works if you know the path. On my system it’s User\Library\Mail. The actual folder varies by the age of one’s system, my messages are in a V2 folder, not a V3 folder. (I saw lots of weird stuff in there, like a [Mail Lost+Found] folder with old .mbox files. I need to dig through those. OS X Mail is just weird.)

The folder names were odd. The one called IMAP-…. visi.com has my current Gmail data, but I haven’t used visi.com for 10-15 years. Apparently OS X kept the original account name from my 10.3 days. Have I mentioned OS X Mail.app Preferences are kinda horked?

 

The missing iCloud message were in AosIMAP (wonder what Aos stands for?) in a Sent Messages.mbox folder. I copied that to the desktop and used Mail.app Import to bring them in. Despite the .mbox extension I had to use the Mail.app importer, not the .mbox importer.

All the messages were recovered. I found I could copy them safely into the Yosemite Mail.app “All Mail” folder that corresponds to Google’s All Mail, so they were back on Google for search purposes while also available on Mail.app (yes, Mail.app/Gmail integration is scary, mostly Google’s issue).

Sometime I’m going to dig around Mail Lost+Found to see if it really contains old lost messages. I like to keep my data; I’ve got Eudora and Netscape emails in OS X Mail.app from the early 90s.

Update: Most of the .mbox folders in “Mail Lost+Found” were very small. The few that were larger just duplicated messages I already had. So I cleaned out that folder.

iOS 9 Spotlight fail fixed by killing background Reeder.app

iOS 9.2 Spotlight has been driving me crazy on my iPhone 6. I use search to start many of my apps, and at least half the time nothing would show up. I think this started with iOS 9.1, but it got worse with 9.2. I saw complaints about this on Apple Discussions, but I knew it wasn’t affecting everyone. There was something odd about my setup.

Of course restarting the phone would fix the problem, but only transiently. I tried various maneuvers to rebuild spotlight indices; for a time I though removing Contact search was the key. Sometimes disabling Spotlight search for all applications seemed to help — but then it would fail again.

Then I noticed something interesting. Sometimes, after entering a search string returned no results, if I waited a bit, canceled the original string, then reentered, I’d get part of the Spotlight results. Maybe not any of my apps, but perhaps Spotlight Suggestions would show up. Sometimes I’d even see the app list, or Spotlight would show the default “search the web” UI then refresh and show search results.

It almost seemed like Spotlight was trying to work, but something was slowing it down. Perhaps if it’s too slow to respond Apple’s iOS 9.2 code times out. So, even though I have ‘Background App Refresh” disabled, I wondered if a background App was interfering with Spotlight.

So I started emulating my #1 son and routinely swipe-closing (killing) background Apps. (Yes, I know this is supposed to be a bad habit. Except when it isn’t.) After I’d killed 20 or so Spotlight started working again.

With a bit of trial and error I found I only needed to kill one. I only had to kill my #1 most used iPhone app, Reeder 3 for iOS. Spotlight then worked every time.

I don’t think this is a Reeder bug. I suspect it happens when background apps are somehow tying up Spotlight indexing, even when indexing and background app refresh are both disabled for a specific application. Other apps may do the same thing, but since I follow hundreds of Feeds and have Reeder running constantly, I probably see this more often than most. I think there are multiple iOS multitasking management bugs going on here; I’m just glad to have a relatively painless workaround. If you are seeing this problem but don’t use Reeder then do experiment with killing other backrond apps.

Reeder.app has a Sync:Background Refresh setting that I’ve now made “manual” only. I’ll update this blog post when I find out if that works.

A Google Doc I wrote in 2010 has lost its images

Every 1-3 years I write a “solstice letter”. Since 2010 or so I’ve used Google Docs; it’s the best match to sharing it via PDF and web. 

Today I discovered the 2010 document has lost its images. The text is there, but the images are gone. I tried downloading as PDF, but they don’t show there.

It’s a significant non-recoverable Google Cloud data loss, probably related to old versions of Google Docs.

I’d saved a local .docx version to my personal web site so I still have something like the original. Because I’m a particular kind of paranoid; that is, the experienced kind.

Not good Google. Not good at all.

Emergent phishing attacks

This one amused me.

I have an email address in one of my domains that redirects to an immutable long-random-username address assigned by Appigo. Messages to that address create tasks on Appigo’s ToDo.app [1]. Today when I opened ToDo.app I had a task that included a phishing attack link. The “Dear xxx” introduction included the username portion of my redirect task.

This clearly wasn’t a specific ToDo.app phishing attack; it was a routine email phishing attack. Gmail would have sent it directly to spam, but of course this route bypassed spam filtering. Having a phishing attack appear on my task lists was an emergent result of using a “secret” email address as a data interface.

The good news is that the email redirection I used is also a form of defense. Appigo doesn’t provide a way to change their secret email address (not smart of them), but since I created a short memorable version their immutable “backdoor” was not exposed. I can change the redirect address I control.

Intelligent systems are rather hard to secure. Which is why the Internet of Things is a mistake. Make no system smarter than it needs to be…

[1] I use this app extensively on iOS and OS X, but I don’t recommend it because there’s no data export or archiving support. Of course most of the competition are no better, but OmniFocus and Toodledo provide export.

The Apple Way or the Google Way: A rough draft for comment

I’m writing a book on supporting special needs teens and adult independent living with a smartphone. I’m covering both iOS and Android in the one book (if Microsoft pays me I’d do them too :-), so I had to write a chapter comparing them. Except that’s not what I had to write, when I started I realized that I wasn’t comparing iOS to Android as much as I was comparing the Google Way (Android, iOS) to the Apple Way (iPhone).

I’ve done a very rough draft below, I’d love to get comments here or email to jfaughnan@gmail.com (or jgordon@kateva.org if you prefer). By way of context we’re an iPhone/Mac family who do most things the Google Way, and while I do appreciate my iPhone 6 (screen pop!) I’ve been quite impressed by an ultra-cheap Lenovo moto-e phone I bought for this project. I think Apple used to do great software, but they lost that knack around around 2006, when Steve Jobs killed iMovie 6/iMovie HD. So it’s a fair fight now.

Life would be simpler if either the Apple Way or the Google Way were clearly better. Unfortunately, life isn’t like that. So there’s no simple answer to the question “What phone should my Explorer use?”.

In general Guide and Explorer should use the same smartphone. Very few people will want to know learn the ins and outs of two devices. So if you and your Explorer favor the same solution you can skip the rest of this discussion.

School experience doesn’t help much. Most schools, even those that favor iPads over Chromebooks, use gCloud services. This tends to favor Android phones, where gCloud is the only option. On the other hand, as we noted earlier, iPhones can be used with Google’s solutions — it’s just a bit more complicated.

There’s a cost advantage to Android phones, but it’s not as big an advantage as it first looks. If you disregard the deceptive cell phone contract “costs” and look at the real cost of an unlocked phone, you can buy a remarkably powerful Android phone for as little as $100. The least expensive iPhone currently costs about $450. That’s a big difference, but even a good mobile phone plan will cost $40 a month (more below on saving money there). Over two years the Android device will cost $1,920, the iPhone will cost $2,270 or 15% more. At the end of that time the iPhone probably has 2 more years of useful life, but the Android phone will be obsolete. Of course if your Explorer tends to lose or break phones, that $100 phone is awfully appealing.

The iPhone has other advantages that justify some of that price premium. Apple Stores provide excellent technical report and service. iPhones get regular and reliable software updates and are much less vulnerable (so far) to malicious software attacks (malware). If you stick entirely with iCloud iPhones are significantly simpler to use than Android phones.

Apple’s software is typically easier to use and learn than Google’s software. It’s also easier to restrict and control an iPhone. Those are real advantages for our users.

In theory, for a vulnerable population, the iPhone with iCloud (not gCloud) has other advantages. Google makes its money from advertising and selling information about its software users, Apple makes money from selling goods and services. In practice I’m not sure how much different this makes … so far.

There’s one last consideration. If you choose an Android device and gCloud it’s not hard to switch to an iPhone. Google wants your advertising attention regardless of what device you use; you can bring gCloud with you. If you choose an iPhone and iCloud though, a move to Android will be more painful.

The good news is that whatever choice you make, you can easily defend it! Both Android and iPhone will work. Just try to avoid supporting both and Android and an iPhone. That’s too much work.