Category Archives: Apple

Siri’s Headphone Tax

I wrote earlier today about Siri’s impressive, instant attentiveness on the iPhone 6s. I remarked that although I had set out to report a bug to Apple, I discovered it was actually a very awesome feature.

Unfortunately, I still have a Siri-related bug to file today. Armed with my knowledge that, as a rule, Siri will begin processing instructions at the moment the home button is pressed, I have been exercising it quite a bit. But after I popped on some headphones and headed out for a walk, I discovered an unfortunate shortcoming: Siri’s instant attentiveness is thwarted by the presence of headphones.

For some reason, if headphones are plugged in, iOS goes through the old-and-busted delay in which you must wait for the audible signal that Siri is ready to listen. The result is that, having gotten used to it being instantly ready, you will push the home button and start talking, only to hear the tell-tale audio signal and realize that it hasn’t actually been listening yet.

I’m hoping this is a bug in which the old mechanism is simply being inappropriately activated while headphones are plugged in. I don’t think there’s anything about activating the audio out through headphones that should inherently limit Siri’s ability to be instantly attentive. In fact, with headphones plugged in I can still get an instant response when I use “Hey Siri” to precede my request.

In summary: Siri starts listening instantaneously on an iPhone 6s, whether you’re in silent or non-silent modes, provides you haven’t made the mistake of plugging in headphones. Filed as Radar #22881933

If It Ain’t Fixed, Break It

I have always kept my phone on silent, and thus come to depend on vibration feedback for a lot of workflow tasks. One such task is invoking Siri by holding the home button, to make a quick inquiry or request.

On my iPhone 6, long-pressing the home button always resulted in a short pause before a pleasant vibration indicating that Siri was ready to listen. I trained myself to wait until that vibration was felt before bothering to speak, lest Siri miss anything important.

On my iPhone 6s, however, there is no such feedback. Apple “broke” it. I was all in a huff this morning to file a bug about this, sure in my knowledge that the usability of the phone had been diminished by removing this feedback. Every time I invoke Siri now, in the absence of vibration feedback, I wait to see the tell-tale animated sound wave detector. I’m never quite sure when Siri is ready for me.

I complained on Twitter about the problem, hoping there was a secret setting that I had missed when restoring my phone. I got lots of commiseration from folks who also miss the feedback, and assurances from others that I simply needed to set my “vibrate on ring” or “vibrate on silent” settings correctly. I appreciate the responses, but they were all wrong. And I’m wrong. We’re all wrong.

Apple “broke” the haptic feedback associated with invoking Siri, by “fixing” the problem that there had ever been any latency before. Have an iPhone 6s or 6s Plus? Go ahead, I dare you: hold down the home button and start talking to Siri. You will not escape its attention. It’s ready to go when you are, so it would be obnoxious of it to impose any contrived delay or to give taptic feedback that is uncalled for. Siri has become a more perfect assistant, and we have to change our habits to accommodate this.

The elimination of latency in Siri’s attentiveness seems related to the fact that Apple have added dedicated functionality to the phone’s M9 chip to allow Siri to remain efficiently at attention:

The integrated M9 works so efficiently and intelligently that Siri is always on and waiting for your voice commands. You can easily activate Siri by saying “Hey Siri” whenever your iPhone 6s is nearby.

The lesson is that sometimes our instinct tells us something has been terribly broken, when it has actually been gloriously fixed. Now you can quickly dictate “Hey Siri remind me to file a bug about Siri feedback,” before quickly amending yourself: “Hey Siri delete the reminder,” and dismiss any perceived obligation you felt to tell Apple just how “buggy” the iPhone is.

Familiar Spell Checking

Even if you’re a great speller, automatic spell checking provides a valuable safety net, often preventing us from sharing with the world our own individual ignorances of the languages we communicate with.

For years, spell checkers of all kinds have relied upon word databases to determine that a word has been misspelled. I’m sure it’s at least a little bit more complicated than this, but in a nutshell: if the word you’ve just typed is not in this enormous list of words, then it’s probably a misspelling, and is marked as such.

Thus as you type your master works, when you either flub your typing or can’t recall the correct spelling, most modern editors will flag the word in question, for example by showing a red squiggle below it.

One challenge, though, is that for any individual, a number of words that are spelled correctly may nonetheless be absent from spell checker’s enormous database. One great example of this is the variety of proper names we deal in that may not happen to be included. For example, if I were a Boston Red Sox fan I might type Dustin Pedroia’s name often, and at least OS X’s built-in spell checker would mark it as incorrect. The workaround for these situations is to control-click the word and, from the popup menu, select “Learn Spelling” to avoid future flagging of the item.

The problem can be especially annoying when the OS repeatedly flags the names of people in your own family. For example, my own last name, “Jalkut,” is incredibly uncommon and would be flagged as a misspelling by most spell checkers in the world. However, on my Mac it is not, even though I’ve never asked the system to “learn” the spelling. In fact, none of the names of my family, friends, or business associates are marked as misspellings. How does this work?

Apple’s engineers realized that they could spare you the hassle of “learning” these spellings, since they already have access to a massive database of proper names that matter to you. Your Contacts database. If you’re on a Mac right now, open up the Terminal application and paste in the following line:

/System/Library/Services/AppleSpell.service/Contents/MacOS/findNames

The result that should come flying down the terminal window are the proper names of everybody and everything in your Contacts database. Specifically, Apple consults every entry in your database for the following attributes:

  • First Name
  • Middle Name
  • Last Name
  • Nickname
  • Maiden Name
  • Organization
  • Address
  • City

Each of these words, if present, is used to augment the already-massive list of correctly spelled words. So if you happen to know somebody named Frenk Xssl, who lives in Cwmystwyth and works for Infinitea, you can write all about them and their work, and never be bothered once by the tell-tale red squiggle of a word misspelled.

Everything But The Web

Since Apple announced the new Apple TV on Wednesday, we developers have been poring over the details of what the SDK will, and what it won’t allow us to achieve on the platform.

One of the most surprising, and most impactful limitations to the SDK is that it provides no facility for presenting web content in an app. Not only is there no built-in “browser” on the Apple TV, third party apps are unlikely to be able to offer any web browsing functionality.

This is a big deal, but many people see it as a wise choice on Apple’s part: by forbidding the use of web technologies, they will encourage app developers to design natively for Apple TV. On iOS, by comparison, a large number of “native apps” that are downloaded from the App Store are in fact only thin wrappers around web content. These offer the same interactive experience that a user would have if they navigated to the company’s site in a browser. Forbidding web views on Apple TV all but guarantees that developers will provide a more tailored experience, designed in the spirit of Apple’s guidelines.

But forbidding web content outright will also be an unnecessary impediment to many developers whose apps are either tastefully implemented with the help of web technologies, or whose core functionality is to deliver content — not web sites, mind you — that happens to be formatted with HTML. Daniel Pasco of Black Pixel points out that his company’s NetNewsWire, an RSS news reader, falls squarely into this category. On that point, although I have a hard time imagining the utility of a blog editor on Apple TV, my own MarsEdit would also be “unfairly” restricted by this policy.

As Pasco acknowledges, we don’t know Apple’s real motivation for omitting web views from Apple TV. There may be technical challenges or performance shortcomings that contributed to the decision. But let’s assume for the sake of reasoning that it is purely political, that they want to discourage “web wrappers” and to promote a more native look and feel in TV apps. I propose that Apple could strike a compromise that would serve those ambitions while also supporting the tasteful handling of web content in apps. How? By forbidding network access to web content. Apps themselves could still access the network, but not from within their web views.

Blocking network access from web content would immediately knock out the “web wrapper” type of native app. Any such app that connects to a site meant to also serve regular web browsers will be rendered useless if the referenced resources from the site are not allowed to load. Images would be blank, stylesheets omitted, etc. A clever developer might try to overcome these limitations by taking all network loading into their own hands, but I expect this would be a complicated mess and quickly encourage such a developer to seek a less cumbersome solution.

On the other hand, all apps that use web content tastefully would be liberated to continue doing so. Whether an app simply uses a small web view here or there to support the native UI with styled text and images, or if it is a full-fledged news reader like NetNewsWire, the ability to capitalize on WebKit’s core functionality to convert web content into a visual format should be no more controversial or politically limited than the ability to process TIFFs, JPEGs, and PNGs and turn them into attractive, or not so attractive, visuals in an app’s interface.

I’m not sure where JavaScript support should stand in this “compromise.” It would be somewhat ironic to omit it, seeing as the Apple TV supports a whole framework for creating apps that is based in JavaScript, but I can also see an argument that supporting JavaScript in web views is too much of a lure away from using native iOS technologies. Personally, I think they should include it and let developers decide whether there are suitable use cases for it, but I imagine the vast majority of current iOS developers would be extremely satisfied to be granted the mere ability to render static HTML content in their Apple TV apps.

I’m excited about the Apple TV even if, like many developers, I haven’t quite wrapped my head around what I could or should develop for the platform. These major announcements from Apple always come with a healthy mix of tantalizing allure for the possible, and sobering reminders that Apple defines the constraints in which we must operate. The lack of web views on Apple TV was not a constraint I imagine most developers were anticipating. I hope that it does achieve the laudable goal of encouraging more developers to embrace native designs, but I also hope that Apple loosens up and finds a way to allow responsible developers to use a powerful set of technologies that we’ve grown accustomed to relying upon.

SiriScript

Today I faced a long list of alarms on my iPhone, and decided that I wanted to clean them out. The typical iOS “Edit” interface puts a red “delete” button next to each item, and upon tapping it you must then confirm it by tapping the explicit word “delete” at the other end of the item. Suffice to say: for a list of any significant size, this is very tedious.

On a whim, I decided to give Siri a shot at simplifying the process. I long-pressed the home button, and uttered: “delete all my alarms.”

NewImage

Well, isn’t that nice?

I realize that when I am faced with a problem on iOS or watchOS, for which I wish there were an automated, “power user” mechanism to simplify it, I reach for Siri and hope for the best.

In this respect Siri fills the gap that is left by the omission of an automating service such as AppleScript. On a Mac, when I’m faced with a problem like this, I look to Script Editor, and hope that the app is scriptable enough to get the job done. For example, if alarms were a service provided by my Mac (and why aren’t they!?), then I would expect a script like this to complete the task at hand:

tell application "Clock" to delete all alarms

Having AppleScript at my disposal is great, but I am also frustrated that Siri doesn’t live on my Mac. I should be able to invoke the dictation UI (fn-fn keystroke, by default) and ask Siri to “add to my reminders,” or to perform any of the other common tasks I can perform with my phone or watch.

Siri is more limiting than AppleScript, because it can only carry out tasks that Apple’s engineers have predicted that I will want to perform. But it’s also much easier than opening up Script Editor, scrutinizing a scripting dictionary, spending 10 years learning AppleScript, and then writing and running a script.

Ideally, I’d like to have the best of both worlds: the ease of asking Siri to perform complex procedures and the option of extending the catalog of procedures that it knows how to perform. And I’d like this perfect combination of ease and extensibility on all of Apple’s platforms.

Since the debut of the iPhone, people have speculated about whether we would ever see an official solution for automation, along the lines of AppleScript or Automator. I think we’ve actually been seeing it since Apple acquired and integrated Siri. I hope that one day this will culminate into the consistent, extensible solution for automation that I have imagined here.

Six In One

Craig Hockenberry’s “Half-Assed” calls out the disparity between Apple’s Mac and iOS App Stores with respect to app analytics, limiting customer reviews from beta OS releases, and support for beta testing with TestFlight:

Mac developers have never had access to TestFlight, either internally or externally. It’s “coming soon”, and until that day comes, there’s no way to test apps that use the iCloud servers. Which sucks for both the developer and the customer.

For years, I’ve harbored my own resentments about the way Apple seems to treat the Mac App Store as a second-class citizen. One point that has nagged at me since the Mac App Store launched five years ago is the lack of effort Apple makes in promoting these products through social networks. For years, the @AppStore account has been extremely active promoting iOS apps to its huge (now 3.8 Million people!) audience. It’s obviously a priority for Apple to promote the iOS App Store, and their Twitter account does a great job of it.

But there is no Twitter account for the Mac App Store, and the @AppStore account has nearly never mentioned Mac software. (Go ahead, do an advanced Twitter search for “from:AppStore mac“). Around four years ago at WWDC, I asked a group of App Store affiliated engineers what they made of this. They all looked at me blankly, paused, looked at each other blankly, paused, and then shrugged as if to say “Huh, I wonder why we don’t promote the Mac App Store?” I don’t know either! But they were all in a much better position than I to find out or push for a change. Evidently, that hasn’t happened.

The neglect makes sense on one hand: iOS and now watchOS are the new hotness, the platforms that represent the fastest and most culturally significant growth for Apple. They sell the most devices, generate the most revenue, and create the biggest headlines, worldwide. It still makes sense for Apple to prioritize the iOS App Store, but it’s a shame they haven’t done more over the past five years to integrate the systems that power the stores so that benefits to developers for one platform’s store would automatically benefit the developers for the other.

On the other hand, let’s acknowledge that the disparity is not all roses for iOS and weeds for the Mac. iOS developers continue to face obstacles for which we have long enjoyed simple solutions for on the Mac. As Craig points out, we can’t ship a useful beta testing app that fully exercises all of Apple’s locked down services such as iCloud, but what can we do? We can ship arbitrary binaries to an unlimited number of people, who can install and run those apps on whatever devices they choose. How do you like them, ahem, Apples?

And what about the absurd steps iOS developers must take in order to stay up to date with beta releases of the OS? Either they commit themselves to running guaranteed buggy and possibly unusable versions of the OS on their machine “machines,” or else they spend extra money on devices whose only purpose will be to act as testbeds for the risky new OS. Want to maintain backwards compatibility? Better keep multiple iPhones, iPod touches, and iPads, of varying generations handy, but be careful not to update them to a newer OS, as there’s no going back.

On the Mac, we enjoy the ability to erase and reinstall whatever version of the OS we choose, whenever we choose. Furthermore, we can maintain parallel installations of the same or different versions of the OS, on easily switchable partitions of the same disk. Even in the context of a single OS install, we enjoy the ability to test varying user scenarios by configuring test accounts and “Fast-User Switching” between them from the comfort of our Mac’s menu bar. Heck, we can even virtualize whole Macs thanks to VMware, Parallels and VirtualBox. When it comes to testing various configurations affordably and expeditiously, it’s the iOS developers who should be crying to Apple that their priorities are skewed.

I guess it’s lucky the Mac was around for so many years before the dawn of iOS, it’s had time to accumulate many developer-empowering features. Although Apple’s priorities with respect to development resources and marketing seem to be focused on iOS today, we enjoy many privileges on the Mac that I doubt iOS developers will ever see. And to top this off with a bit of true optimism for the future: the weird thing is, Apple keeps improving OS X. I’m sometimes surprised by the amount of attention Apple continues to give to the OS given its apparent relative lack of importance. But I guess Apple is well and truly stocked with a bunch of Mac softies, after all.

There’s a ton of totally vexing behavior that seems to be ill-spirited towards Mac developers, but also a ton that seems to hold iOS developers in low regard. I think this speaks to the likely truth that Apple is, more than anything, under-staffed and not well situated to deploy solutions to both platforms in tandem. It truly is a case of six in one, a half-dozen in the other. But wouldn’t it be great if iOS and Mac developers could each enjoy the benefits of all twelve? I’ll hold out hope that one day Apple will unlock the secret of organizing their efforts so that developers on all their platforms can benefit more or less equally from the technologies the company provides.

Apple News And The Open Web

People love to poke fun at Apple for its purported failure to achieve anything of lasting value in the realms of the cloud or social media. Essentially: anything that connects people to a centralized system for storing and sharing information with each other? Apple’s not good at that. Or at least that’s what people say.

Apple has fallen short or outright failed with many projects, including Mobile Me and Ping, which serve as poster children for people who claim they will remain forever helpless with this whole class of technologies. Personally when I hear this criticism, I’m inclined to remind people that for example the massive number of iOS and Mac users who communicate daily over iMessage are technically part of a massive social network that connects them through Apple’s centralized servers and permits the storage of, and sharing of, information between people. If you were to concede that iMessage is a social network, then it’s a pretty impressive one.

But I grant that in key ways, Apple falls short when compared to social giants such as Facebook or Twitter. These companies see value less in the types of private communications that take place via iMessage, and more in the public, or at least loosely bounded communications that take place between individuals and groups of followers. Subscribers, if you will. This massive quantity of communication, and the tendency towards sharing it publicly to potentially millions of viewers, seems well-suited to companies whose viability is rooted in advertising on a massive scale.

I’m a huge fan of Twitter, but one of the things that continues to bug me is that I don’t feel as though I own any of my content there. Sure, I can now request and download a complete archive of my Twitter posts, and a variety of solutions make it easy to automatically accumulate a copy, or even post live replicas of my posts to other services. But the canonical home for my posts to Twitter is … Twitter. When you multiply this fact out over the hundreds of millions of Twitter users, you have a situation that is very good for Twitter, but in my humble opinion, not so great for each and every one of us users.

As the developer of a popular blogging Application for the Mac, it should be obvious that I value blogging. I think there is something special about the ability we have gained as a global community to sit down at a computer, tablet, or phone, and peck out the words that attempt to express our thoughts, sharing them with the world through this gift (coincidence?) of history sometimes referred to as The Open Web. In a nutshell: the Open Web enables free distribution of content in a manner that can’t be completely curtailed by centralized authorities such as governments, militaries, or multi-national companies who happen to run social networks.

Twitter for example is as a company that controls the storage and distribution of each and every one of the messages we post to it. If they decided tomorrow that my use of the service does not meet their standards, my content could be eliminated from the system with the metaphorical flip of a switch. They also maintain tight control over access to the information they do distribute. Years ago, they famously clamped down on 3rd party developers, severely limiting the ways in which existing apps could connect end-users to the company’s services, all but eliminating the possibility that new “full service” Twitter clients would be developed.

What does all of this have to do with Apple and its famous inability to run a viable social network? At WWDC 2015, held last week in San Francisco, Apple announced the Apple News app for iOS 9: essentially an app that will make it easy for 3rd party content providers to serve rich “magazine style” content to all iOS users. Already they have a host of big publishing names on board including Condé Nast, the New York Times, and Bloomberg.

This all sounds great for big publishing, but how does this serve “the rest of us,” and what does it have to do with the “Open Web”? It will all come down to how stringently Apple limits access to small publishers who wish to get their content into the app. Judging from initial overtures, I’m inclined to think that most publishers will be welcome to participate. Currently, if you log in with your iCloud account and click through the sign-up process, it indicates that you can enroll as either a company or individual. I am tentatively optimistic that this blog, your blog, and the vast majority of blogs you read and enjoy will be welcome to publish content through Apple’s News app.

Great, another closed system over which a huge company lords absolute control, and can cut off access to unwanted content at the drop of a hat? No. Because the content doesn’t live on Apple’s servers. This is a key distinction in my mind. Apple’s News App serves primarily not as a source of information, but as an amplifier of it. Podcasting makes a great comparison, and is especially apt considering the extent to which Apple deserves credit for popularizing and faciliating the early growth of podcasting as a platform for free expression.

Approximately 0% of the podcasts available to the massive installed base of Apple’s customers are actually hosted on Apple’s servers. Yet a huge number of podcast content providers thrive because of the distribution mechanism, the amplifier, that Apple provides by way of the Podcasts section of its iTunes store, and the Podcasts app on its iOS devices. If Apple decides on a whim to rank a particular podcast lower in the charts, or even to outright remove it from the iTunes directory? It’s definitely bad news for the show, but it’s not a death knell. The content lives on, access to it remains unfettered for those who seek it, and alternative clients for accessing the content are not “permitted,” because they don’t need to be. They are allowed to exist by default, because of the very nature of the web.

I already said I’m moderately bummed out by my relationship to Twitter because of the sense of lost ownership of my content. That feeling is exacerbated by my knowledge that eschewing Twitter, publishing my shorter, quippy, conversational thoughts to a private server of my own devising, would result in connecting to fewer people. To me, that’s the point of tweeting, the point of blogging, and the point of podcasting: to connect with people.

People who used to write prolifically on long-form blogs are facing a similar conundrum with the rise of services such as Medium, which aim for and seem to deliver on the goal of connecting writers with larger audiences of people. Why keep writing for your own, completely owned and controlled site, if contributing your content to a centralized authority such as Medium will yield more feedback, gratitude, and criticism than publishing on your own site?

I’m optimistic that Apple’s News app will be a strike against centralized services such as Medium, Twitter, and Facebook. A strike against signing over content to a 3rd party mediator for the sake of a greater chance at connecting to an audience. Apple may not be the world’s best technology company when it comes to either storing data or building a social network around it, but they are damned good at building a captive audience of delighted users who trust the company to provide access to a variety of 3rd party content.

Whether it’s music, apps, podcasts, or, coming very soon, syndicated blog content, you’d have to be a fool not to try to get your work into their customer-facing channels. In the case of podcasts, and as it seems with “News,” doing so means providing a feed that points to content you own and which you store on your server. If Apple turns out to be a jerk about it? We can count on other apps and services rising to consume the content in a comparable or improved manner. That’s the way the web works.

OS X El Capitan

Thanks to a tweet from Michael Steeber, I learned that I have the dubious honor of having been the first person to tweet the literal phrase “OS X El Capitan”, which happens to be the name of of Apple’s forthcoming OS X 10.11 operating system.

I did some research of my own and believe this claim is true. I don’t think this is some great victory or proof of my insightfulness, but I do admit to thinking it’s at least moderately cool.

Out of curiosity, I used Twitter’s now-awesome advanced search to zero in on the day when I first tweeted the phrase, June 19, 2013. This must have been in the aftermath of WWDC 2013, shortly after Apple had debuted its new OS naming strategy, after places that are distinctly Californian. People were joking about future code names like OS X Sacramento, OS X Carmel, or gasp!, OS X San Jose. I thought these were all poor choices because they would not be evocative of the spirit of California in the same visceral way that Mavericks was:

I quickly followed with a quip about using OS X El Capitan:

Though to be honest I don’t remember exactly what grammatical pedantry I was alluding to. What’s (not really) important is that I was the first to use the phrase, two years before Apple announced the name of the OS.

And while I’m patting myself on the back, let me give a shout out to Mark Hachman, who while similarly throwing out possible names for future OS releases, managed to make the first ever reference to “OS X Yosemite”:

Those who can, do. Those who can’t, teach. Those who can’t teach, tweet early and often.

WWDC Video Downloader

It’s great that Apple has, for years now, made videos of most WWDC content available free of charge on the web. A problem arises though, when you realize that you want to quickly check the content of some specific session, only to realize you are either offline, on a slow internet connection, or just don’t have the time or patience to connect to Apple and download the video.

I’ve found it useful to use Olivier HO-A-CHUCK’s wwdc-downloader script, which he has recently updated for the 2015 URL conventions.

Essentially you just download the script to a disk with a ton of free space, run it, and you’re left with a permanent archive of all the videos and PDFs from a given year’s WWDC.

I’ll be waiting until I get home to run this script, since by then all of the videos should be available, and I’ll have easy access to that aforementioned big hard drive. It’s great though that he has updated it so promptly this year.

Keeping Up With WWDC

Each year, WWDC kicks off with a keynote address chock full of the company’s tentpole announcements for the coming year. I always find it difficult to keep in mind even these, ahem, key points. But it gets “worse” as the day goes on, and then as the week goes on, as nuanced announcements are indicated by revelations in the Platforms State of the Union, and the extensive, in-depth sessions that fill out the remaining days of the week.

It’s all too much. Exciting, but still, too much.

Fortunately, master information compilers like Michael Tsai swoop in to help organize links to the most significant download points and technical summaries, as well as pertinent pages from non-Apple sources such as one explaining the process for using VMware to create a standalone test version of OS X El Capitan.

Michael Tsai: WWDC 2015 Links.

Michael’s blog continues to serve as a great argument for the value of RSS and blogging. Subscribing to it is a great way to keep your finger on the pulse of a great number of pertinent issues to Mac and iOS developers, both during WWDC week and a throughout the year.

Whose Phone Is This?

On the latest episode of Core Intuition, my co-host Manton Reece described the experience his wife had of leaving her iPhone behind on an airplane, only to have the airline thankfully announce over the airport loudspeakers that the phone had been found.

When they returned to claim it, they asked how they had been able to determine the name of the owner from the locked phone? The answer? They “just asked Siri whose phone it was.”

Apparently this is common knowledge to the airline employees, and to no doubt countless iPhone users, but it was news to Manton and me. You can try it yourself: if you have an iPhone, and have set a contact card as “My Info” in Siri’s preferences, lock your phone and then ask Siri: “Whose phone is this?”

On the face of it, it seems like a great feature. Who wouldn’t want to empower the well-intentioned finder of one’s lost phone to make an effort of returning it?

The problem to my mind is not that Siri shares my name and contact information, but that it goes a step further, showing not only my main telephone number, but my physical address, all my telephone numbers, email addresses, as well as my AIM, Twitter, and Facebook accounts. It also happily provides my birthdate, the names of my wife, mom, dad, brother, heck, the names of any person I have assigned a relationship to.

When my friend Dan Moren gave me a ride to Çingleton last year, we killed time in the car playing with Siri’s abundant personalization features. Anybody with access to my locked phone will soon learn that Dan is in fact more than just a friend to me:

Screen capture showing personal details revealed via Siri

Of course, you don’t have to share all this information with whatever stranger manages to pick up your phone. Simply disable Siri access from the lock screen, and nobody will be able to access your private information using it. Of course, this means no airline employee who finds your phone tucked between the seats will be able to easily return your phone to you, either.

Alternatively, you could change the information on your “My Info” contact card. For example I could add an entry “Daniel Minimal” to my Contacts list, and only include a telephone number or email address. The problem here is much of Siri’s usefulness (as we discussed on the podcast) is rooted in it knowing specific details about you. Requests such as “give me directions home,” “call my mom,” or heck, “text my sweet, sweet ride to Montréal,” will fall upon deaf ears if you don’t include this information in the card that you associate with Siri’s “My Info.”

Depending on how paranoid you are about what happens when a stranger gets ahold of your phone, you might read this and decide to do nothing, to delete all the personal information from your “Me” contact card, or to forbid Siri from being accessed when the phone is locked. Personally, I don’t think any of these solutions is ideal. I’d like to be able to ask Siri to share some of my personal information from the lock screen, to increase the odds of my lost phone being returned. But I’d like to draw the line somewhere reasonable, without having to share every last detail about myself with the stranger who is holding the device.