Continuity and Spotlight highlight the need to closely examine where our data goes

On Monday, I dutifully installed iOS 8.1 to enable Apple Pay on my iPhone 6, intending to test it out later in the day. (Spoiler: I did not.) This also let me turn on Continuity, the suite of seamless connection features between iOS and Mac OS X devices signed into the same iCloud account. My mid–2011 MacBook isn’t capable of Handoff and Instant Hotspot, but it can manage SMS forwarding and phone calls.

Later in the day, three seemingly unrelated events occurred. First, I logged into Twitter in a browser that wasn’t currently authenticated, and because I have two-factor authentication (2FA) enabled, Twitter sent me a text message after I successfully entered the password—and it appeared on my Mac, as Apple advertised. Huh, I thought.

Second, I read a detailed account of the information that Yosemite sends Apple for Spotlight suggestions, which could provide enough detail to pinpoint an individual, and associate search terms and other factors with a user. Rrrrmmm.

Third, in the evening, The New York Times released a story about a man-in-the-middle attack in China against Chinese users to swipe login information from iCloud users following the release of the latest iPhones. Humphf.

Taken at face value, these are three unrelated issues: a reduction in security for SMS-based 2FA, a leak of private data, and an attempt to disrupt the integrity of a secure connection. I’m neither going to spin conspiracy theories nor misstate the severity of any of these things.

Rather, I want to highlight how we should always examine new paths of information, and not offer a knee-jerk dismissal of associated concerns. Because our digital identifiers are so easily spread, stolen, and misused, anything that changes where data is sent—or how it’s interrupted—should be examined thoughtfully.

Take SMS forwarding. Most of the two-step/two-factor systems used in business require a hardware token, an authentication app, or specialized software to produce the second factor that validates a login. (See last week’s column for more background on these two-part logins, and I’ll be writing more in the future about them as well.)

Twitter is an exception with a footnote. When you enable its version of 2FA, “login verification,” you can opt between having an SMS message sent with a code each time or using the Twitter app (in iOS or Android) to confirm your login. I’ve opted for SMS, because I prefer to not even have the Twitter app installed, and many people I know are in the same boat. (SMS can also be useful if you lose a phone or are restoring one, before you complete the loop to install and verify the login within the Twitter app!)

A common rubric of two-factor authentication is combining something you know (a password) with something you have, typically a physical device that generates or receives a unique token or that, by mere possession and unlocking, you prove ownership and can verify at least that you have the physical thing. Apple’s “trusted device” model for iCloud two-step logins qualifies: you have to have an iOS device that you can unlock to view the code. Apple also lets you, however, choose to send a SMS code instead of using a trusted device. (A third kind of factor, something you are, relies on biometrics.)

It troubled me, therefore, to see the SMS message with my Twitter second-factor verification code appear on my Mac, even though the Mac is something I have, because prior to SMS forwarding, such text messages only appeared on a single device: my iPhone, which I carry with me or have nearby always. If I am logging in from a Mac and the code appears on the same Mac, albeit through a different path, have I subverted some or all of the benefits of the second factor?

Apple’s implementation of SMS forwarding allows all logged-in iCloud accounts, no matter on what network they are, to receive the SMS message. The way in which an iPhone or other iOS device will signal receipt will vary depending on your alert settings and whether Messages in OS X is the frontmost app.

Where it gets complicated is only in cases in which someone manages to obtain my password (what I know) and can also have access to my computer (what I have) in an unlocked state while I’m not in proxmity. While all other Continuity features require either a Bluetooth connection or to be on the same local Wi-Fi network, SMS forwarding works whenever your phone and any other device have access to the Internet. That would seem to magnify the risk—that the computer and phone could be half a planet apart.

But in practice, it’s hard to imagine a scenario in which that’s an issue unless you give someone your password, have written it down, or left it in a readable place on your computer and routinely leave your computer in an unlocked state, where a roommate, partner, child, or parent—or burglar or thief—could gain access.

In any scenario in which that was true, it’s easy to make sure you don’t fall victim to it: don’t share your password or make it available in any easy to find way; and in Security & Privacy, set Require Password to a low interval. (Remember that it’s your sleep or screen saver delay, whichever is less, plus the interval after Require Password before the computer is locked.) I also always recommend using Find My Mac and FileVault for remote locking and data encryption.

The other two Monday situations were of a different nature. The “fix macosx” folks examined the kind of data that Yosemite sends in its default installation to improve search results for the new integrated Spotlight. Again, the situation isn’t necessarily surprising or disturbing, except for three elements: sending user information is on by default; disabling it requires at least two settings; and Apple didn’t disclose enough information as it provided a heaping of additional detail to the Verge after the “fix macosx” site went up.

Apple’s fuller explanation assuages fears, but doesn’t explain why one has to turn off as many as three settings, including Location Services, and why it wasn’t so elaborate in its user disclosure. As Caitlin McGarry wrote a couple of days ago, “Apple is wading into sensitive territory with new features in Yosemite and iOS 8 and on new iPhones.… The company has to prove it can be trusted with search results if people are going to hand over more personal data.”

One could argue that Apple should offer a skippable, simple tutorial before it enables the sending of information that would inform users precisely what it’s sending. (In brief, it attaches “blurred” location information and other data to a token that it says persists no longer than 15 minutes, and doesn’t retain IP addresses.)

Should we have just shaken our head at the original report and said, we’re sure Apple is doing everything right? Absolutely not, an opinion aided by its need to more fully disclose.

Finally, the attempt, likely by the Chinese government, to intercept iCloud authentication sessions would seem unrelated, but it ties into one part of this pattern of needing to observe and be aware in our risky world. The subversion attempt uses a man-in-the-middle (MitM) attempt with privileged network resources that stand between a user and Apple’s servers. But because of Apple’s encryption, that MitM can only present a forged Web security certificate.

As Apple notes in a page it posted to help people understand the problem, an invalid certificate produces an error in browsers that shouldn’t be bypassed. Over time, browser makers have made it more complicated to accept an invalid certificate as both the risk and the actuality of MitM attacks has grown.

If we are trained to ignore security red flags, we might see these warnings and think, “Oh, it’s the Internet. I’m just going to click click click to bypass these alerts, because I’m trying to get something done.”

We can’t let ourselves be lulled into complacency; we need Apple and others to highlight the security implications of any changes so that we all—the technically minded and average user alike—continue to pay attention.