Category Archives: Apple

Log Littering

Apple has dramatically revamped its standard logging mechanism. Unified Logging, available in macOS 10.12 and iOS 10, replaces various file-based logging approaches with a centralized, database-backed repository for log information of all levels of interest.

The big win, both for developers and for users, is performance. Where the simple act of logging some debugging information used to have enough of a cost to dissuade rampant use, the new system makes it so cheap that developers inside Apple and out are being encouraged to “log like the dickens” in the name of generating more evidence for posthumous debugging. The new system also offer impressive data mining abilities, making it far easier to filter for what you’re looking for and to track logging information across specific activities, even if the activity spans multiple processes.

The two big losses, in my opinion, are that the sheer size, number, and variety of logging messages makes it impractical for users to skim the console for “real problems,” and that the resulting logging archives are so large that it’s impractical to casually include them with bug reports to Apple or 3rd party developers.

The WWDC session on the topic goes into detail on these points, but perhaps most useful for framing my complaints here are Apple’s stated goals for the revamp:

  • One common, efficient logging mechanism for both user and kernel mode
  • Maximize information collected while minimizing observer effect [the phenomenon that enabling or adding logging changes the behavior of the system you are trying to understand]
  • We want as much logging on all the time as possible
  • Design privacy into the system

Two of the stated goals, “maximizing information collection,” and “as much logging on all the time as possible,” exacerbate the problems of there being so much log data that it’s both difficult to skim, and cumbersome to share.

Imagine a society in which all packaging has been transformed into fast-composting, biodegradable materials. Your soda bottles, snack wrappers, cigarette packages, etc., all biodegrade to dirt within 48 hours of use. What a boon for the world: the major, global problem of trash accumulating in our towns and environment would be gone. Poof!

Or would it? When “littering has no cost,” I suspect that we’d face a new problem: far more people would litter. Why bother finding a place to throw out that bottle, when nature will take care of it in within 48 hours? Multiply this attitude out over even a small portion of the world’s billions of people, and we’d be guaranteed to be buried in trash. All trash that will be gone in 48 hours, mind you, but constantly replenished with a fresh supply.

I think this metaphor points to a similar problem with unified logging: the sudden onslaught of “low cost logging” has left our developer society unprepared in some specific ways to deal with the consequences of the new reality.

So, how can we, and Apple fix this? We need specific solutions that make skimming for problems, and sharing pertinent log data easier, yet don’t impact the very positive goals outlined by Apple above. Here is my advice:

  1. Don’t litter the logs. Just because you can log it, and just because doing so is cheap, doesn’t mean there isn’t a cost. Some of the recurring log messages littering my Console arrive at a rate of thousands per minute. There may be good arguments that certain subsystems, in certain states, should log this extensively if the resulting data will justify easier diagnosis of problems, but much of the junk I see are redundant reiterations of relatively useless information:
Not switching as we're not in ~/Library/Keychains...
...
CSSM Exception:...
...
Etc. Etc. Etc.

Some of these seem to be well and truly noise, but some of them, even if they seem highly redundant and noisy to me, could in fact represent useful logging if you happened to, for example, be tracking down a subtle bug in Apple’s security libraries. That’s fine, I’ll accept that some amount of log diarrhea in the name of better software, but only if the following accommodation is made…

  • Annotate high-frequency logs for easier filtering. The logging system offers a variety of tools for annotating log messages, but even internal Apple groups do not seem to use these extensively or appropriately. The system supports the notion of three levels of log message: default, info, and debug. Only the “default” level messages are displayed by default in the Console app, yet all of the above-described garbage is displayed in that default mode. The Console will become significantly more useful when the worst offenders have marked their messages for severity, subsystem, and category so that they can be effectively omitted from the default view, and so that they can be mined later for use by folks who can actually make sense of them.

  • Generate context-specific sysdiagnoses. One of the worst practical outcomes of unified logging is that capturing a “sysdiagnose” on my Mac now generates a compressed archive that is still larger than 400MB. These archives are typically requested by most groups at Apple in response to bug reports, regardless of how severe the bug is or how readily reproducable it appears to be. In the world of Apple bug reports, sysdiagnoses are treated like lightweight bits of information that should be appended to every issue, except they’re now anything but lightweight.

    All the annotation work advised above should really pay off when Apple provides a streamlined mechanism for capturing sysdiagnose information pertinent to a specific subsystem or product. The company already offers product-specific advice for capturing log information, sometimes requiring the installation of custom profiles and other shenanigans. The lightweight unified logging system empowers Apple to both require that internal groups properly annotate their log messages and to facilitate smarter gathering of that data.

    Currently if you want to capture a sysdiagnose at any time a Mac, you simply press Ctrl-Opt-Cmd-Shift-Period. On an iOS device it’s done by holding both volume keys and the power key, but you have to enable logging first with a custom profile. This shortcut will generate one of those mondo 400MB style sysdiagnose archives, which you can upload to attach to your bug reports in your copious spare time.

    I envision a prompt that appears after invoking the existing shortcut, or else a new shortcut for “interactive sysdiagnose” where you could specify the category of bug you are reporting. The prompt would list categories correlating to groups at Apple who had done the work of providing streamlined log filtering data that will effectively strip out all the useless (to that group) noise from your log data.

    In fact, sysdiagnose already takes a “process” parameter when invoked from the command line, and my understanding is that this enables it to capture data that is pertinent to the target process. The unified logging system seems to provide the infrastructure for even smarter capturing along these lines.

    I realize that in this time of flux, where much log data is not properly annotated, there is still an incentive for many groups to capture as much as possible and sort it out on Apple’s end. These groups should know, however, that the larger the sysdiagnose archive you ask users to upload, the lower the chances they will bother actually following through on filing the bug or on providing the pertinent information you have requested.

  • Annotate specifically for user-concerning issues. Power users on the Mac have, for years, counted on being able to skim the console log for information that might explain a slow Mac, persistent crashes, or other inexplicable behavior. Given the huge increase in number of log message and the lackluster annotation of these messages by Apple, the Console app is effectively useless to users for this purpose.

    On top of getting the annotation right in general, I think a new special level of log message should be created, indicating particular concern to end-users. These would identify log messages that developers specifically think users should take notice of and follow up about. I mentioned there are three basic levels of log message: default, info, and debug. On top of that, there are two special levels called “fault” and “error”, which can be filtered on in the Console, and which receive special treatment from the logging system.

    These special levels seem close to what users might find interest in, but they’re not quite right either.

    A “user interest” level of logging message would facilitate the kind of high level skimming that seems impossible in Sierra today. These log messages would convey information that a user might gain some insight from. They would stand in stark contrast to the noise of messages like these, from the filecoordinationd process:

    Claim D32EDEBE-C702-4638-800C-E4BAB9B767F3 granted in server

    Nobody knows what a claim is, or cares whether it was “granted in server” … unless they are actively debugging filecoordinationd. On the other hand, a message indicating the failure to grant a claim “because the disk is full,” could be very useful to users indeed.

    I realize the line could be difficult to draw in some circumstances, but a huge number of messages currently being logged are obviously not of user interest. Perhaps then, the opposite approach could be taken, and log messages could be annotated as being specifically useful for posthumous, internal debugging by developers.

I tell you, things are bleak. We’re swimming in a morass of useless console noise, and there is little we can do about it. There is room for optimism however, as the logging infrastructure is good, and seems to support many thoughtful measures that could attenuate the problems and make the system more useful and less cumbersome to developers, end-users, and well-meaning bug reporters.

The console is littered with trash. Sure, it will biodegrade in 48 hours, but that doesn’t mean we shouldn’t be concerned with cleaning it up. A combination of more thoughtful logging, proper annotation, and appropriate filtering will get us out of this mess.

App Store Maturity

Apple announced that they will be taking steps to improve the quality of apps available in the App Store:

We are implementing an ongoing process of evaluating apps, removing apps that no longer function as intended, don’t follow current review guidelines, or are outdated.

Developers have known since early in the App Store’s history that Apple may retroactively decide that a particular app no longer merits inclusion in the store. Because of the large number of apps in the store, it has widely been thought that such reconsideration would only occur when and if a new version of an app is submitted, and thus reviewed again. This announcement, however, hints at a much larger-scale procedure, that would potentially cull thousands of products from the store.

Several months ago, developers noticed that the average review time for apps had dropped dramatically. Instead of taking several days, sometimes a week, or more, it is now common for apps to be reviewed in only one or two days. Many wondered whether some technical breakthrough made it easier to blaze through reviews. For example, improved static analysis, an automated fuzz-testing suite, or some combination of these and other techniques could reduce the need for stringent human involvement in some aspects of the review process.

There are over 2 million apps in the App Store, and Apple has effectively announced that they are prepared to re-review all of them in the name of improving overall quality in the store. This hints strongly that there has been some systematic improvement to the review process. It boggles the mind to imagine that all 2 million of those apps were in fact reviewed by humans, but that happened over the course of almost 10 years. Whatever process Apple is gearing up to apply, they claim apps will start dropping from the store as early as September 7.

It’s interesting to me that Apple feels comfortable dropping a potentially massive number of apps from the store. They have never shied away from boasting about the impact of the App Store, often focusing on the sheer size of it. They make a point in every WWDC keynote to talk about the vast numbers of developers, apps, downloads, and yes, dollars flowing through the store. Yes, if they measured success purely by number of apps in the store, they would have made their review criteria much more lenient from the start. But if they cut the number of apps for sale by a significant degree, it will be the first time in the App Store era that I remember the company emphasizing “quality, not quantity.”

I see both the decision to ratchet up quality control, and the willingness to live with the consequences of smaller bragging numbers in the store, as signs of the App Store’s maturity. When Apple debuted the iOS App Store, one of its main challenges was in justifying the very idea of an app store. Every enthusiastic update on the number of apps or amount of revenue generated by them seemed almost paranoiacally intent on proving the concept of the App Store correct.

Apple’s willingness to now intentionally deflate those metrics strikes me as a sign of cool confidence. The App Store concept has been proven valid. It was proven valid years ago, but Apple’s famous paranoia may not have allowed the defensive posture to relax until now. I’m optimistic that this change is only the first of many, in which Apple will focus less on arguing that the idea of an App Store is good enough, and more on the possibility that such an App Store can be insanely great. Hey, a guy can dream, right?

The Apple

MacRumors pointed out that Apple seems to be dropping “Store” from its store branding. The new flagship store in San Francisco, for example, is “Apple Union Square.” This has led to some criticism and guffawing from friends who now jokingly refer to any Apple Store as simply “The Apple.”

John Gruber thinks it makes sense to drop “Store” from branding, and compares Apple with other major brands whose stores do sound ridiculous with the appendage:

The “Store” branding only made sense when the concept was novel. Now that Apple’s stores are well established, it makes sense to drop the “Store”.

And:

No one goes to the Tiffany Store or Gucci Store, they just go to Tiffany or Gucci. It’s not even just a premium thing — you say Target and Walmart, not Target Store and Walmart Store.

The difference between these brands and Apple is that Apple’s identity has long been independent from the notion of a store. Calling it the “Apple Store” was not only important because the stores were a novelty, but because Apple is a brand that transcends retail. This may be true as well for Tiffany or Gucci, but when you think about these brands, I suspect you think of them in their retail context. Target and Walmart? They’re stores to the core of their being, so of course it would sounds strange to brand them as such.

Apple is a company whose products, hardware and software, have historically been sold separately from its own retail presence. Going to “Apple” will never make sense the way it does to go to “Target” or even to “Tiffany’s.” Where “Store” has been dropped, it’s essential that some other qualifier takes it place. Going to “Apple Union Square” makes sense. Asking a hotel concierge whether there is “an Apple nearby” makes as much sense as asking where the nearest “Ford” or “Honda” is.

Of course, the vast majority of people will probably still refer to any of Apple’s stores as “the iPhone store.”

Not Perfected Here

Almost two years ago, Apple announced Swift, their next-generation language. Politically, it seems poised to imminently succeed Objective-C as the de facto standard language for Apple platforms. Practically, there are many questions.

Since the language’s debut, people have been pointing out the impedance mismatches between Swift, a type-safe and statically compiled language, and Objective-C, an unusually dynamic, almost “anything goes” language in which objects can be magically bound to do one another’s bidding at run time as opposed to compile time.

Brent Simmons recently ignited a round of (mostly) thoughtful analysis about the dynamic shortcomings of Swift, and whether Apple will eventually fill the dynamic void left by Swift, when they inevitably update their core frameworks to accommodate the new language.

Paul Kim, a long-time Mac developer, whose experience with AppKit goes back to the NeXT days, wrote a balanced defense of Objective-C’s dynamism. He concludes with an acknowledgement that many of the people who might contribute practical feedback to the Swift team about how it would best serve app developers, are too busy shipping apps:

What I do see makes me worry that it’s not the experienced app-writers that are being heard. Unfortunately, many of us are too busy to sit in the various mailing lists and forums. Yes, ok, we lose. But we all lose if those creating the platform don’t draw from the experience of those who have built upon it successfully.

It would be OK that a majority of established 3rd party app developers can’t embrace and offer feedback about Swift, so long as Apple were buying into the language internally and ironing out all the kinks on their own. But how can they? Apple is in all likelihood the single largest owner of valuable, time-tested, customer-pleasing Objective-C code. Thus they face, as a company, the same challenges that Paul Kim and many other developers do: they can’t afford to put everything on the line, divert all their attention from Objective C, just to embrace a language that is not completely mature, and which doesn’t offer the same features as its predecessor.

If Apple’s long-time Mac and iOS developers, and the company’s own internal framework developers, are not yet empowered to dive head-long into Swift development, who is? Early adopters. Very early adopters. God bless them. Unfortunately, Swift’s early adopters will become experts in precisely the techniques that the language currently affords, as they aren’t motivated to push the language in the direction it needs to move to accommodate long-time Objective C developers, and … Apple itself.

I have to imagine Apple is stewing on this problem internally. Hopefully they have some brilliant thinking on the subject, some of which will come to light at WWDC in June. In the mean time, Apple faces an unenviable conundrum: the growing number of Swift experts in the world are predominantly neither employed by Apple, nor familiar with the design patterns that have set Apple’s frameworks apart from the competition for at least 15 years.

Swift is a fascinating, beautiful language. How will it evolve to prove superior, in the long-run to Objective-C? By providing a suite of impedance-matched frameworks that fulfill all the needs of current iOS and Mac developers. How will those frameworks come to be in an environment where Apple’s most experienced framework developers, and Apple’s most experienced 3rd-party developers are steeped in a tradition that favors patterns not supported by Swift? I’ll be very eager to see how that plays out.

Twenty Years

Ten years ago, I reflected on having been hired by Apple ten years before, when I was just twenty years old. “The Start Date“:

The day you start at Apple, be it as an administrative assistant or the CFO, you’re joining a proud legacy, and you know it. I still remember the thrill of receiving that offer letter. I grinned wide, stared down at the relatively meager salary I’d be earning, and signed away my agreement to start in two weeks.

That makes twenty years. Today, in fact.

Many of my colleagues from Apple in the mid-1990’s have moved on, as I did. But a very significant number of them remain. In a world where jumping from job to job has become expected of almost everybody, Apple maintains a curious lifelong employment appeal to many people.

Apple has always possessed ineffable uniqueness among its corporate peers. From the moment of its founding as a scrappy, barely funded home-made computer manufacturer, to forty years later when its value and influence are almost impossible to comprehend.

This year, many new young people will stare down at the relatively meager salary they’ll be earning, sign away their agreement to start in two weeks, and be in for the twenty-year ride of their lives.

When Worse Is Better

On the latest episode of John Gruber’s The Talk Show, guest Ben Thompson tries to identify the ways in which Amazon’s Alexa speech recognition is better than Apple’s Siri.

One of his key points was that Alexa, by being theoretically less capable than Siri, manages to avoid the heightened expectations and subsequent disappointment that users feel when Siri fails to listen as well as it promises to. It may be less competent overall, but what it does do it does predictably and well.

A comparison that came immediately to my mind was Apple’s mid-1990’s failure with the Newton handheld computer. The ambitious handwriting recognition was pure magic when it worked, but failed to work a significant amount of the time. Meanwhile, Palm took a more pragmatic approach with Graffiti, an overtly limited interpretation of the Roman alphabet, Arabic numerals, and a few other widely used symbols. By dramatically diminishing the magic of its handwriting recognition technology, Palm dramatically increased its reliability. Users seemed to appreciate this compromise, as Newton sputtered, and Palm Pilots went on to define the whole genre of hand-held digital assistants.

As much as I like this comparison, I don’t think Siri is doomed in the same way Newton was. Handwriting recognition was a primary interface on Newton, while with iOS devices it’s usually considered an augmenting interface. You can, and many people do, get plenty of use out of an iPhone without ever relying upon Siri. Siri is also nowhere near as unreliable, in my opinion, as Newton handwriting was. I use Siri on a daily basis and, perhaps because I’ve rarely tried anything better, I still find it an overall boon to productivity.

I think we are still in the early days of speech recognition, which feels funny to write because back in the mid-1990’s when Apple was failing to perfect handwriting recognition, they were doing the very same thing with speech recognition. But as John and Ben said on the show, none of the existing technologies, whether from Apple, Amazon, Microsoft, Google, Nuance, or others, is even close to perfect. There is so much interest now in the technology, that it’s possible to at least imagine extremely fast, reliable, predictable speech recognition becoming the norm. Whether the standard ends up being a shorthand-based approach such as Amazon is taking with Alexa, or a more ambitious artificial intelligence, may depend on which company can close the gap faster using one approach or the other.

Paid App Store Search

Bloomberg set off a wave of fear, uncertainty, doubt, and skepticism with their report alleging Apple’s plans to offer paid placement in App Store search results:

Apple is considering paid search, a Google-like model in which companies would pay to have their app shown at the top of search results based on what a customer is seeking.

Putting aside the fact that such a move seems un-Apple-like, I don’t see how it would benefit Apple, either.

Google sells placement in search results because that is the core of their business model. When a user finds and clicks a non-sponsored link in search results, it may serve Google’s ambition to collect information about users, but it doesn’t earn them any money. Without paid placement in Google search results, Google probably wouldn’t exist.

Apple’s overall business model is selling hardware with high profit margins. The business justification for the App Store is multi-faceted: its purpose is first to enrich Apple’s hardware products with novel third-party functionality, and second to generate revenue in the form of that 30% cut that developers love to complain about.

To this end, it’s in Apple’s best interests to ensure that the intersection of the best and the most profitable software is presented to users in the App Store. This is probably why the tired old high-level charts are broken down by “Free,” “Top Paid,” and “Top Grossing.” Items that rise to the tops of of those categories are most likely to serve Apple’s business justification for the store.

Allowing third parties to pay for placement in the App Store would not contribute to Apple’s justifications for the App Store in any way. Who benefits from such a change? The businesses paying for the placement, presumably. It’s hard to see how paid placement would consistently benefit either Apple or its direct customers. It’s unlikely that paid listings would be used to highlight apps that are in line with Apple’s other goals for the store.

I hope that Bloomberg’s report indicates that Apple is indeed brainstorming many ideas for improving search and inventory presentation in the App Store, but count me among the very skeptical that paid placement will be among the ideas that the company actually follows through with.

Bad Preference Gatekeeper

With the release of OS X 10.11.4, developers of standalone preference panes face a new challenge with respect to users installing their software.

Apparently, the validation process that Apple applies to downloaded software, Gatekeeper, fails to validate OS X preference panes, even if they are signed with a legitimate Developer ID code signature.

The upshot of this is when users download a bona fide 3rd party preference pane such as Noodlesoft’s excellent Hazel, instead of having the software install as expected, a scary warning is displayed indicating the purported untrustworthiness of the software.

According to Paul Kim of Noodlesoft, the problem affects every preference pane he’s tested, including a freshly built, completely plain preference pane built with Apple’s latest tools. I put this to the test in Xcode 7.3, running on 10.11.4, by creating a new Preference Pane project from Apple’s template, setting it to sign with my Developer ID, and creating a release build of the project.

Running Apple’s “spctl” tool on a binary is a reasonably approximate way of determining whether Gatekeeper would reject the binary after downloading it from the web. Here’s the result for all the affected preference panes:

% spctl -av ./TestPanel.prefPane
./TestPanel.prefPane: rejected
source=obsolete resource envelope

Ah, that pesky “obsolete resource enveloped” message. Those of us who survived the transition from Version 1 to Version 2 code signing remember it well. But it’s not an accurate assessment in this case:

 % codesign -dv ./TestPanel.prefPane              
Executable=/Volumes/Data/daniel/Desktop/TestPanel 2016-03-31 14-03-51/Products/
[...]
Sealed Resources version=2 rules=12 files=2
Internal requirements count=1 size=220

The “version=2” indicates we are using an appropriate version for the signed resources. It would be hard, perhaps impossible, to do otherwise on a modern system with a modern Xcode toolchain.

The “spctl” tools supports a command line option to ask for more and more verbose results by adding “v”s to the command line. Unfortunately “spctl -avvvvvvv” doesn’t yield anything more informative than the seemingly inaccurate “obsolete resource envelope.”

I wondered if there was some magic flag that preference panes must now exhibit, or some new requirement that internals be signed in a different way than before. Surely, if anybody could get this right, it would be Apple! Their “Network Link Conditioner” is the only downloadable preference pane I could think of, and what do you know, it was updated as part of the Hardware I/O Tools for Xcode 7.3 download package, released on March 20. I downloaded a fresh copy to be sure I had the best that Apple could offer, located the preference pane, and double-clicked it.

Untrusted

You know it’s bad when even Apple’s own downloads are portrayed as untrustworthy.

This is a minor annoyance for folks trying to install an obscure development tool, but it’s a major issue for developers like Noodlesoft whose entire livelihood is built on the distribution of software packaged as a preference pane. The scary wording in the dialog casts doubt on the reputation of the developer, and for the more savvy, on the reputation of Apple’s ability to properly assess the trustworthiness of software that we download.

Let’s hope Apple can address this problem soon. Although it doesn’t pose a security risk, it seems appropriate that they could include this in a security update. After all, it has everything to do with preserving trust between users, developers, and Apple.

Update: According to Paul Kim, it’s not just preference panes that are affected, but any standalone non-app code bundle. So, for example, color palettes, screensaver modules, and, if anybody ever used them anymore, Dashboard widgets, are all affected. Pretty, pretty, pretty, pretty bad.

(Radar #25468728)

iPhone SE: No Room For Doubt

Last week, Apple announced the iPhone SE, a long-awaited update to the 4-inch class of iPhone. After the release of larger iPhone 6 and iPhone 6 Plus models, many fans of the smaller form factor worried that Apple might be abandoning it for good. Their fears have now been assuaged.

Even though I was worried and skeptical about the transition to iPhone 6, I have to admit I have mostly gotten used to it. I don’t know that I will return to the 4-inch sized phones, but the iPhone SE sure makes a compelling argument to do so.

What’s great about the iPhone SE isn’t just its smaller size. It’s great because it also lacks many of the design shortcomings, petty as they may be, that its grander siblings possess. The so-called “camera bump” that breaks the perfectly smooth surface of the iPhone 6? Not there on the SE. The reviled movement of the lock button to the side of the phone, where it’s easier to press accidentally? Not an issue. Even the fact that the SE allegedly has a slower touch ID processor will not be viewed as a flaw by people who are tired of accidentally unlocking their phones when they wake them to view their lock screens.

The iPhone SE is great because it doesn’t cast doubt on Apple’s design sense.

I am sure that all the design changes in iPhone 6 were done with good reason. The camera bump affords a higher-quality camera. Moving the lock switch may have been necessary to accommodate a slimmer profile. And the phone unlocking accidentally while you hold it is the tradeoff for the freaking amazing, gloriously fast intentional unlocking.

But the iPhone SE will be viewed by many as, and in fact it may be, a better phone. It’s great not because it’s as fast as, or can take as great pictures as, or can be unlocked as easily as the iPhone 6. It’s great because it leaves no room for doubt as to what it’s designed to do, and how it does it.

New Apple products never fail to offer enticing new functionality, but these amazing new features increasingly come with a “but.” Apple’s user base has grown accustomed over years to expect the great design. Design choices that have to be explained to be understood cannot be considered great. They are good, possibly even “best under the circumstances.” But a great design leaves no rough edge to be scrutinized, no accident-prone switch to be suffered, no “so good it hurts” performance optimization. Great design leaves no room for doubt that every detail was considered, and that every compromise was somehow, delightfully avoided.

iGotYourBack

I have been an ardent Apple fan since 1993, when I got my first Mac: a PowerBook Duo 210. From then, to the day I joined Apple in 1996, to the day I left in 2002, to present day, one thing has always been true about Apple: they are not a typical tech company. Pushing against the status quo has in many respects been a defining characteristic of the company, through down times and up times. Apple does what it thinks is right for itself, for its customers, and to some significant extent, for the world at large.

Tim Cook shared yesterday in A Message to Our Customers one example of Apple’s atypical attitude rearing its beautiful head. In response to the FBI’s demand that Apple supply custom software that would allow the agency to unlock an iPhone held as evidence, Apple tendered its refusal:

Up to this point, we have done everything that is both within our power and within the law to help them. But now the U.S. government has asked us for something we simply do not have, and something we consider too dangerous to create. They have asked us to build a backdoor to the iPhone.

The news has split public sentiment in predictable ways. There will always be a contingent that believes law enforcement should be aided in any feasible manner, regardless of long-term implications for individual privacy or civil liberties. And there will also be people so cynical about government and the police, that even Apple’s cooperation thus far, handing over information that it does possess, is viewed as a betrayal of customer rights. And of course, there is a massive group of folks in the middle, who aren’t sure where the line should be drawn.

Apple has a clear sense of where the line should be drawn, and they have stated it: they will not weaken the security of their products for the benefit of the FBI or (presumably) any other agency. Although the current request from the FBI only applies to an older iPhone model, whose security is easier to circumvent than later ones, the point Apple emphasizes is that complying with the order would be a terrible precedent for putting the needs of government ahead of the personal security of end-uers.

To my mind, this is a fine place for Apple to draw a line.

Other tech companies with huge investments in the consumer market should be lining up behind Apple in defiance of the FBI. To do otherwise, whether by explicitly defending the FBI’s demands, or by implicitly approving in silence, would be a betrayal of their own customers. It would be wrong both from an ethical perspective with respect to their duty to protect customer data, and from a PR perspective with respect to the public’s perception of their managing that duty.

If a couple other large companies, say Facebook and Google, come to Apple’s side, it will send a powerful message to the FBI and the rest of government. If a dozen large companies do, it will create a firewall that will be difficult for government to dismantle without very publicly reiterating and reaffirming its disdain for personal privacy.

I think it’s best for all parties if the “firewall” scenario comes to pass. The stage is set for a civil rights showdown, and while we need to speak out as individuals, we can also benefit enormously from the powerful voices of these tech giants.

But if other companies don’t step up, I’m not sure all is lost. Apple, as the largest American tech company, which also has the largest cash reserves, is well-suited on many fronts to fight this battle. Alone, if necessary.

People have criticized Apple for amassing a giant pile of money while never giving completely convincing explanations for what it plans to do with it. When your modus operandi is not only to push the leading edge of personal technology, but also to defend your customers’ personal data, and to possibly help establish the legal precedent that will defend the customers of all tech companies for decades to come, you never know when having $200B to “spare” might come in handy.

As a stockholder I don’t relish the idea of Apple burning through all that money just to defend their right to protect customer data. Although it’s arguable that it would be money well spent, it’s not an obvious, ideal use of shareholder equity in a public company. Luckily, I don’t think the cash will be spent. The $200B serves mainly to fortify Apple’s resolve in defying the FBI. Apple’s courage in the face of threats to its pro-consumer security policies is bolstered by the strength of those massive cash reserves.

Some may see this confrontation between Apple and the FBI as an industry vs. government dispute, but it’s far more than that. As personal technology and the internet permeate almost every aspect of wider society, the “tech industry” is indistinguishable from society as a whole. The right to defend our personal information, and the rights of companies to act on our behalf in that pursuit, are completely and inexorably tied to our rights as members of society. Eventually, we must win the right to protect our data from government. Apple, Google, Facebook, and other tech giants can step up to help us secure these rights today, or we’ll have a longer, harder fight ahead of us in years to come.

Hey Siri, Don’t Trivialize My Timer

Siri’s dictated timers are a feature I use all the time. Especially given my propensity to be distracted and lose track of short-term time commitments, the ability to blurt out in the kitchen: “Hey Siri, set a timer for one minute,” has saved many a pancake from being burned.

Something that has bothered me about this feature for a long time is the determination Siri has to be lighthearted and downright goofy when creating the timer, when the timer is for a specific time such as one or three minutes.

“Hey Siri, set a timer for three minutes.”

Siri's visual response when asked to set a three-minute timer.

Ha. Ha. Yeah, I’m always cooking an egg when I set a three-minute timer. By contrast, a request to set a two-minute timer is always met with a curt, yet still humanized, “Two minutes and counting.” If you set a timer for one minute? Whoo-ee, you’re in for some sass. Sometimes Siri just says “Your timer is set for one minute,” but more often you’ll hear a quip like “Remember, a watched iPhone never boils.”

I’ve been more irritated by this cuteness after years of using the feature and, I suppose, the frequency with which I set one and three-minute timers. It’s mostly a passing exasperation for me, but it strikes me as an example where emotionally charging a software interaction is a risky proposition.

My one-minute timers are usually for something trivial like pancakes, but what if I were using them in a more fraught scenario? What if one-minute timers play a serious role in the administration of care to a loved one? What if it’s a key interval in a CPR procedure? One of Siri’s cute quips is “The suspense is killing me.” What if the suspense really is killing somebody?

(Radar #23776483)