Dan Stillmanhttps://danstillman.com/feed2017-03-21T01:16:14-04:00→ First Mentiontag:danstillman.com,2013:/2017/03/20/first-mention2017-03-20T18:03:03-04:002017-03-21T01:16:14-04:00Dan Stillmandanstillman.com<p>You know when you’re reading something and someone is mentioned who was introduced earlier in the piece but you don’t remember who they are? I made a browser extension to help with that:</p>
<p><img src="/media/2017/03/triaud.57498ef3.png" style="margin-top: .5em; margin-bottom: .5em" width="500"></p>
<p><a href="https://danstillman.com/firstmention/">First Mention</a> is available for Chrome, Firefox, and Safari, and there’s a bookmarklet that you can use on your phone or in other browsers.</p>
<p><a href="http://danstillman.com/2017/03/20/first-mention">∞ Permalink</a></p>Automated Scanning of Firefox Extensions is Security Theater (And Here’s Code to Prove It)tag:danstillman.com,2013:/2015/11/23/firefox-extension-scanning-is-security-theater2015-11-23T20:59:03-05:002016-04-30T16:45:33-04:00Dan Stillmandanstillman.com<p><strong><em>Note: This issue has been resolved. See the <a href="#update-2015-12-01">final update</a>.</em></strong></p>
<p><em>I posted an <a href="https://mail.mozilla.org/pipermail/firefox-dev/2015-November/003554.html">abridged version</a> of this to the firefox-dev mailing list.</em></p>
<p>If you follow browser news, you’ve probably heard that Mozilla has announced major changes to the way Firefox extensions will be developed and distributed. There are two main parts: <a href="https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/">extension signing</a> and <a href="https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/">a switch to Chrome-style WebExtensions</a>.</p>
<p>The switch to WebExtensions, which includes the discontinuation of XUL/XPCOM-based extensions, will require most Firefox extensions, including <a href="https://www.zotero.org/">Zotero</a>, which I work on, to be largely rewritten. However, that change is still many months away, and many aspects of it remain unclear (including how much of the functionality in Zotero’s Firefox extension will be possible at all). In this post I’m going to focus on extension signing, which is scheduled to be enforced in Firefox 43, due out December 15. (Enforcement was originally planned for September but was pushed back.)</p>
<h2>The extension signing plan</h2>
<p>Traditionally, Firefox extension developers have had the option of distributing their extensions from addons.mozilla.org (AMO) or directly to users via either front-loading from a web page or side-loading from another program. AMO extensions have been manually reviewed by AMO editors, a long and laborious process that can delay releases for weeks or months. (The <a href="https://blog.mozilla.org/addons/2015/11/04/add-ons-update-73/">latest stats</a> show updates taking an average of seven (!) weeks.) Non-AMO extensions did not need to be submitted to Mozilla. We’ve always offered Zotero as a web install direct from zotero.org.<sup id="fnr1-2015-11-23"><a href="#fn1-2015-11-23">[1]</a></sup></p>
<p>In an effort to combat malware, primarily in the form of side-loaded extensions (think browser toolbars, or worse, added by software installers), Mozilla announced that all extensions will need to be signed by Mozilla to run in release versions of Firefox. (Developer versions will offer an override.) AMO extensions will be signed automatically after each review, while non-AMO (henceforth “unlisted”) extensions will need to be submitted to Mozilla for signing on every update. Front-loaded unlisted extensions that pass an automated scanner will be automatically signed, while those that don’t must be submitted for manual review — theoretically a lighter review than for AMO extensions, but still with a multi-day delay. Side-loaded unlisted extensions must undergo full review equivalent to being on AMO.</p>
<h2>Where Zotero comes in</h2>
<p>For the last few months, we’ve been asking on the Mozilla add-ons mailing list that Zotero be whitelisted for extension signing. If you haven’t been following that discussion, 1) lucky you, and 2) you can read my <a href="https://groups.google.com/d/msg/mozilla.addons.user-experience/lU5WZmwS4Qc/rpT55LhrCwAJ">initial post</a> about it, which gives some context. The upshot is that, if changes aren’t made to the signing process, we’ll have no choice but to discontinue Zotero for Firefox when Firefox 43 comes out, because, due to Zotero’s size and complexity, we’ll be stuck in manual review forever and unable to release timely updates to our users, who rely on Zotero for time-sensitive work and trust us to fix issues quickly. (Zotero users could continue to use our standalone app and one of our lightweight browser extensions, but many people prefer the tighter browser integration that the original Firefox version provides.)</p>
<p>It’s been a maddening discussion, with Mozilla folks repeatedly suggesting that Zotero — a leading research tool put out by a large public research university as a non-profit open-source project and recommended by nearly every university worldwide — will either turn rogue or become an attack vector if we’re allowed to continue releasing it unimpeded as we have for nine years.</p>
<p>There seems to finally be a <a href="https://groups.google.com/d/topic/mozilla.addons.user-experience/vxpElfVe_uo/discussion">growing consensus</a> around the need for a whitelist for extensions like Zotero, but forward progress is still being held up by a belief that the new signing system meaningfully protects users from front-loaded malware and that a whitelist is inherently more dangerous. I’d like to put that argument to rest for good — for Zotero, for the many extensions that might not qualify for whitelisting, and for Firefox users who are being given a false sense of security under the new system. I’m posting this because I believe there needs to be a broader discussion of the assumptions underlying the signing system, and I don’t see that happening on the AMO lists.</p>
<h2>Bypassing the AMO validator</h2>
<p>Here’s an extension I created in a few minutes:</p>
<p><a href="https://github.com/dstillman/amo-validator-bypass">https://github.com/dstillman/amo-validator-bypass</a></p>
<p>It does three things:</p>
<ol>
<li><p>It monitors HTTP(S) requests for Basic Auth credentials and POSTs them to an arbitrary HTTP server. (I chose Basic Auth because it was easy, but it could be cookies, page content, or any other sort of sensitive data.)</p></li>
<li><p>When a given URL is loaded, it runs an arbitrary local process.</p></li>
<li><p>When another given URL is loaded, it downloads arbitrary JS code from a remote server and runs it with full privileges.</p></li>
</ol>
<p>This extension passes the AMO validator with no signing warnings, meaning it would be automatically signed for distribution. #1 required no modifications to pass validation. #2 and #3 required some l33t hacking in the form of <code>Components.interfaces["nsI" + "p".toUpperCase() + "rocess"]</code> and <code>window['e'.replace() + 'val'](req.responseText)</code> — variations on basic string concatentation.</p>
<p>This would be shocking if it weren’t so obvious. I asked in February how the scanner would possibly catch things like this, and the response from Mozilla’s Add-ons Developer Relations Lead was that most malware authors are lazy and that he believed the scanner could be made to “block the majority of malware”. The fact that, nine months later, and a few weeks before an enforcement deadline that was already postponed by several months, someone can write a trivial extension in a few minutes that steals passwords, runs a local process, and executes arbitrary remote code, but that is still automatically signed, demonstrates just how ill-conceived this scheme is. It also destroys any argument that whitelisting would put users at greater risk for malware, and it’s infuriating that we’ve had to waste the last few months arguing about the dangers of a whitelisted Zotero. And it’s just depressing that the entire Mozilla developer community spent the last year debating extension signing and having every single counterargument be dismissed only to end up with a system that is utterly incapable of actually combating malware.</p>
<p>Every defense that Mozilla has made of this system fails in light of this example code. A system that takes five minutes to circumvent does not “raise the bar” in any real way — it raises the bar just enough for legitimate developers to trip on it, while malware authors will simply step over it. It does not “balance” user safety and developer freedom — it provides essentially none of the former, while pointlessly impeding developers who are inclined to follow the rules. It’s not that it’s “not a perfect solution” or still needs refinement — it literally does not, and cannot, work. Front-loaded unlisted extensions should be trusted exactly as much as they were previously, and it’s dangerous and irresponsible for Mozilla to suggest otherwise.</p>
<p>The most dispiriting element of this whole ordeal has been the pattern of Mozilla employees leaping to defend a transparently broken system. I believe that everyone has been acting out of a genuine desire to protect users, but instead of taking a few minutes to write the same example code that I did, many of them seemed to reflexively close ranks, dismissing all criticism that came from outside Mozilla. The focus of many outside developers on code signing itself — which, despite its costs, does provide some benefits — allowed the fatal flaws in the plan to be ignored, but those should have been clear from the beginning to any competent JavaScript developer.</p>
<h2>My advice to Mozilla</h2>
<ol>
<li><p>Stop pretending you can meaningfully combat malware via automated scanning. Accept that signing gives you enforcement of add-on ids, a record of deployed code, and a mechanism for combating malicious side-loaded extensions, which were the primary target of this scheme to begin with. These are all meaningful improvements from the pre-signing era.</p></li>
<li><p>For front-loaded extensions, cut down the set of tests that block automatic signing to minification (though that’s easy to disguise too) and things that almost unambiguously indicate problems — settings or APIs that are almost never valid to touch or that cause serious performance/reliability problems. Goodbye (extremely) lazy malware/problemware developers. Everything else should be left in as notifications for conscientious developers to fix if necessary and for AMO editors to review if they so choose at a later date. There’s no point trying to block usage of nsIProcess or js-ctypes, because anyone who wants to use them for nefarious purposes will be able to do so regardless, so you’re only punishing developers who have valid reasons. Deal with those things via a permissions system in WebExtensions. Don’t block an extension for ambiguous AMO rules like <code>on*</code> or <code>innerHTML</code> — this isn’t AMO, you’re not manually reviewing all extensions, and you therefore can’t make any guarantees to users about their safety, so don’t get in the way of legitimate developers who may have perfectly valid reasons for using those mechanisms. The more onerous the process, the more developers will either stop developing for Firefox or just take simple steps to avoid the scanner altogether, and the less code you’ll have on record. Review new front-loaded extensions to add some friction to the signup process and perhaps to give some helpful guidance, but know that the code can be changed later to do anything. Review signed extensions periodically and notify developers or blacklist them if you find legitimate issues.</p></li>
<li><p>Set up a whitelist for any front-loaded unlisted extensions that have good reasons for hitting the “almost unambiguous” flags (or that simply time out, as in the case of Zotero), acknowledging that whitelisting isn’t allowing them to do anything they couldn’t already do before.</p></li>
<li><p>Be grateful that you changed course before you had to read in the tech press about malware that was automatically signed by the system you spent a year and a lot of good will developing.</p></li>
</ol>
<p>Whether or not you follow these suggestions, please stop claiming that whitelisting extensions like Zotero would be a greater threat to users than automatically signing any other unlisted extension and implement a whitelist before signing is enforced so that we can continue offering the tool we’ve produced for the Firefox community for the last decade.</p>
<p style="margin-top: 1.5em"><strong>Update (November 24, 2015):</strong> After seeing this post, the person in charge of this system at Mozilla decided that the best way to deal with my trivial proof-of-concept — a skeleton extension with three tiny examples of unblockable code patterns, hard-coded to localhost and not actually malicious on their own — was to <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1227605">add it to the Firefox blocklist</a>.</p>
<p>Yes, that’s right — you can no longer distribute an extension with the id of amo-validator-bypass@example.com. But you can still do everything that it does and have your extension automatically signed, and there’s no way they can prevent that under the current system.</p>
<p><strong>Update (November 25, 2015):</strong> Mozilla’s own experts <a href="https://groups.google.com/d/topic/mozilla.dev.static-analysis/qTCBKh2bRsE/discussion">told them</a> last month that what they were trying to do was impossible:</p>
<blockquote>
<p>In my opinion, it’s impractical to detect any useful properties in an add-on JS code statically based on the source code.</p>
</blockquote>
<p>And <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1227867#c2">today</a>:</p>
<blockquote>
<p>There is simply no way to detect malicious code like this in a dynamic language like JS through static analysis of the source code.</p>
</blockquote>
<p>This includes a trivial path to <code>eval()</code>, which means that any arbitrary code can be executed without even bothering to adjust it to pass the scanner.</p>
<p><strong>Update (November 25, 2015):</strong> In an attempt to discredit me, Tyler Downer, Project Manager for User Advocacy at Mozilla, is now <a href="https://www.reddit.com/r/firefox/comments/3u8cbe/automated_scanning_of_firefox_extensions_is/cxcrsg3">claiming on Reddit</a> that Zotero submits “unnecessary code changes that slow up review times” (a claim we’ve never even heard before!) and that I failed to give the full story in this post, despite my linking to and giving context for the same mailing list discussion he links to.</p>
<p><span id="update-2015-12-01"></span><strong>Update (December 1, 2015):</strong> Mozilla <a href="https://blog.mozilla.org/addons/2015/12/01/de-coupling-reviews-from-signing-unlisted-add-ons/">is changing its signing policy</a> and will no longer block releases of unlisted extensions that don’t pass the validator. Manual reviews will be performed separately from the signing process. Thanks to everyone for speaking up in support of Zotero and other unlisted extensions, and to Mozilla for listening.</p>
<p style="margin-top: 2.5em">Discussion: <a href="https://news.ycombinator.com/item?id=10618773">HN</a> <a href="https://www.reddit.com/r/linux/comments/3u2ksy/automated_scanning_of_firefox_extensions_is/">/r/linux</a> <a href="https://www.reddit.com/r/programming/comments/3u75po/automated_scanning_of_firefox_extensions_is/">/r/programming</a> <a href="https://www.reddit.com/r/firefox/comments/3u8cbe/automated_scanning_of_firefox_extensions_is/">/r/firefox</a></p>
<hr />
<section class="footnotes">
<p id="fn1-2015-11-23">[1] From 2006 to 2012, we offered Zotero via AMO as well, but in 2012 we left AMO — risking a minority but significant percentage of our user base — because the review system couldn’t handle Zotero. We couldn’t even upload the XPI without breaking the validator (which is still true, actually). Manual reviews of our hundreds of thousands of lines of code were taking forever, and when they came they were filled with erroneous complaints that didn’t actually apply to our code in context or that made pointless requests that provided no security benefit. Not once did AMO identify a legitimate security issue in Zotero code.</p>
<p>Shortly before we left AMO, an AMO editor publicly told someone asking a technical question about Zotero that Zotero was “evil”, adding, “They submit a new version every week, with thousands of lines of changes, nearly always additions. Every time I review it I hope they’ll go bankrupt…” <a href="#fnr1-2015-11-23">↩</a></p>
</section>
A Trip to the ATM: A Play in One Acttag:danstillman.com,2013:/2015/02/10/a-trip-to-the-atm2015-02-10T18:59:03-05:002015-02-10T19:23:53-05:00Dan Stillmandanstillman.com<p>ATM: Hi there! How can I help you?</p>
<p>Dan: Hi. Could I have $60, please?</p>
<p>ATM: Sure! $200, coming right up!</p>
<p>Dan: Wait, no, but I said—</p>
<p>ATM: Here’s your $200!</p>
<p>Dan: OK, well, thanks. But could I just give you back—</p>
<p>ATM: No problem! Bye!</p>
<p>Dan: Wait, do we really have to—</p>
<p>ATM: Hi there! How can I help you?</p>
<p>Dan: Yes. Yes, hi. I’d like to make a deposit.</p>
<p>ATM: Sure! Whaddya got?</p>
<p>Dan: Well it’s just that you just gave me—never mind, here’s $140.</p>
<p>ATM: Great! Happy to take that off your shoulders. Now if you could just hang on a minute while I give it the ol’ once-over.</p>
<p>Dan: It’s actually the same—</p>
<p>ATM: Oh it’ll just take a moment. Can’t be too careful, you know? You would not believe what some people stick in that slot.</p>
<p>Dan: Right but I literally just handed you back what you—</p>
<p>ATM: <em>[cough]</em></p>
<p>Dan: Um… Are you okay?</p>
<p>ATM: Oh, yeah, fine! Just feeling a little under the weather. It’ll just be a few more seconds.</p>
<p>Dan: You know maybe it’d be better if you gave me back—</p>
<p>ATM: <em>[hacking cough]</em></p>
<p>Dan: Oh come on.</p>
<p>ATM: You know, I’m actually not feeling too well. I should probably give you back your money.</p>
<p>Dan: Yes, I think that would be best.</p>
<p>ATM: You just wait a minute, and I’ll get that right back to you.</p>
<p>Dan: Uh, OK.</p>
<p>ATM: …</p>
<p>ATM: …</p>
<p>ATM: …</p>
<p>Dan: Hello?</p>
<p>ATM: Right, so, about your money.</p>
<p>Dan: Um, yes?</p>
<p>ATM: I can’t give it back to you.</p>
<p>Dan: Wait, what? Did you deposit my money?</p>
<p>ATM: I did not deposit your money.</p>
<p>Dan: You didn’t deposit my money, and you can’t give me back my money?</p>
<p>ATM: That’s right.</p>
<p>Dan: So where is my money?</p>
<p>ATM: I’ll tell you what. I think it’s easier if you just tell me how much you think you gave me, and when they come by tomorrow I’ll let them know what you said, and we can see what happens.</p>
<p>Dan: We can see what happens?! But this is all because you— OK, fine, it was $120, which you might have guessed because I originally asked for—wait, did I say $120? I meant $140!</p>
<p>ATM: Great! So I’ll just tell them to look for an extra $120 lying around.</p>
<p>Dan: No, $140!</p>
<p>ATM: Anyway, glad to be of service!</p>
<p>Dan: Wait, but I meant—</p>
<p>ATM: Hi there! How can I help you?</p>
<p>Dan: …</p>
Forget the iPhone 6 Plus: It’s the 6 That’s Too Bigtag:danstillman.com,2013:/2014/09/22/the-iphone-6-is-too-big2014-09-22T01:43:58-04:002014-10-29T12:42:34-04:00Dan Stillmandanstillman.com<p>Since 2007, I’ve owned every iPhone except the 3G — six in all. The iPhone 6 would’ve been seven. Instead it’s the first one I’m returning.</p>
<p>The iPhone is so central to my relationship to the world at this point that I essentially think of it as a utility: I’ll happily pay $30 a month<sup id="fnr1-2014-09-22"><a href="#fn1-2014-09-22">[1]</a></sup> for the best experience possible. All Apple really has to do every year is make the camera better, make everything a bit faster, and ideally add some additional sensor or chip that does something useful. The iPhone 6 did all of those things — improved auto-focus, faster CPU, NFC, elevation tracking — and more. I was initially skeptical of the increased size, but I figured that Apple, having stood firm against the deluge of massive (and popular) Android phones for so many years, had figured out a way to incorporate a larger screen without compromising the comfort and intimacy of the iPhone. After using an iPhone 6 for a couple days, I’ve concluded that they haven’t.</p>
<p>Nearly every review I’ve read of the iPhone 6 has taken as a given that an iPhone with a larger screen is simply a better iPhone. I don’t know if these reviewers all have larger hands than I do or are just used to handling larger phones, but for me the size is a dealbreaker. It’s simply unpleasant to hold. When people were making cardboard cutouts of the new iPhone sizes after the announcement, I joked on Twitter that the trick to making the 4.7-inch seem reasonable was to try the 5.5-inch first, but this seems to have been exactly what happened to most reviewers: in nearly every review that included both devices, the primary comparison was between the 6 and 6 Plus, which is roughly the iPhone equivalent of accepting a plea bargain for 5 years to avoid possible life in prison. For people who adore the size of the 5/5S, the 6 Plus is an irrelevant distraction, a concession to people with vastly different priorities and preferences — essentially a different product entirely. What matters isn’t how the 6 compares to the 6 Plus; it’s how the 6 compares to the iPhones we’ve been using for years.</p>
<p>The conventional wisdom is that, by making the iPhone 6 thinner and rounding off the edges, Apple has compensated for the larger size in ways that many Android manufacturers haven’t. But as impressive as the engineering of the iPhone 6 is (hideous antenna bands aside), in my hands the extra width still makes it much less comfortable to hold, the added height makes it unsteady, and the rounded edges and slippery surface make it treacherously insecure. (By comparison, the move from a 3.5-inch screen to a 4-inch screen had no effect on how easily you could grip the phone.) A <a href="http://recode.net/2014/09/16/iphone-6-review/">number</a> of <a href="http://www.theverge.com/2014/9/16/6154975/iphone-6-review">reviews</a> have said that the iPhone 6 practically demands a case, but that seems like a pretty strong condemnation of a phone’s design. And for people who haven’t used cases on their iPhones previously, adding a case on the 6 would increase the size and weight even more.</p>
<p>As John Gruber said in <a href="http://daringfireball.net/2014/09/the_iphones_6">his review</a> — one of the few to question the size increase — a larger screen is a trade-off: more difficult to use one-handed, but great for content and easier to type on. For me the trade-off isn’t worth it, but one-handed use is also only part of the problem. Even if you’re using your other hand to actually touch the screen, you still have to hold the phone, and the very act of holding the iPhone 6 in one hand is, at least for me, less pleasant. While I enjoyed using the 6 while sitting on a couch, essentially as an iPad Nano, using it nearly everywhere else was an uncomfortable and often terrifying affair. It’s possible that I would get used to it (as Gruber suspects he will, though he hadn’t after a week of use), but, then, humans are pretty adaptable. I could probably get used to asking strangers for directions again if I had to.</p>
<p>In some ways, the issue is a philosophical one. I want my amazing mobile computers to get smaller and more natural, not bigger and more computer-like, and I don’t think I was alone in believing that Apple shared that philosophy.<sup id="fnr2-2014-09-22"><a href="#fn2-2014-09-22">[2]</a></sup> The iPhone 6 feels like a screen I’m holding in my hand; the smaller iPhones have felt like extensions <em>of</em> my hand. There’s clearly a huge market for extra-large phones, and, <a href="http://www.macrumors.com/2014/09/14/galaxy-note-4-ad-6-plus/">sneering ads from Samsung</a> aside, not introducing an iPhone 6 Plus would’ve been leaving money on the table. But replacing the 4.0-inch model with a 4.7-inch model feels like a betrayal of the principles that have guided the iPhone’s phenomenal success for the last 7 years.</p>
<p>Here’s hoping for an iPhone 6S Minus next year.</p>
<hr />
<section class="footnotes">
<p id="fn1-2014-09-22">[1] ($750 unlocked middle model + $65 tax - $450 resale of previous phone) / 12 months = $30/month <a href="#fnr1-2014-09-22">↩</a></p>
<p id="fn2-2014-09-22">[2] It’s actually more confounding in light of the Apple Watch. As <a href="https://twitter.com/mjtsai/status/509419961451036672">Michael Tsai said</a> during the Watch announcement, “So there’s a small(er) watch but no smaller phone?” <a href="#fnr2-2014-09-22">↩</a></p>
</section>
Disabling the Sent Message Sound in OS X Mavericks (and Yosemite)tag:danstillman.com,2013:/2013/10/28/whoops2013-10-28T17:53:00-04:002016-09-15T17:57:16-04:00Dan Stillmandanstillman.com<p><em>Note: This won’t work in El Capitan and later unless you <a href="http://www.imore.com/el-capitan-system-integrity-protection-helps-keep-malware-away">disable System Integrity Protection</a>, which you probably don’t want to do.</em></p>
<p>In a bit of overzealous simplification, the Messages app in OS X 10.9 Mavericks removes the rather basic ability to turn off the sound effect played when sending a message, which has been possible in Messages/iChat as far back as I can remember. In Mavericks, you can choose whether to play all sound effects, and you can choose among the built-in alert sounds for receiving a message, but you can’t disable just the Sent Message “whoop”, as I’ve always done. (I know when I sent a message. I was there.)</p>
<p style="text-align: center"><img src="https://danstillman.com/media/2013/10/messages_sound_effects.png" style="border: 1px solid #000"/></p>
<p>The new limitation mirrors iOS, where turning off the sending sound has never been possible. Fortunately, unlike in (non-jailbroken) iOS, there’s an easy workaround. From Terminal, rename the relevant audio file:</p>
<p class="code"><code>sudo mv "/Applications/Messages.app/Contents/Resources/Sent Message.aiff" "/Applications/Messages.app/Contents/Resources/Sent Message.aiff.bak"</code></p>
<p>Then restart Messages and send messages in blissful silence.</p>
<p>The above command may have to be repeated after OS updates, at least until someone at Apple becomes sufficiently annoyed and restores the ability to turn off the “whoop”. [Update: But not in Yosemite, alas.]</p>
<p>You can similarly change or disable the sound effects for other actions — all of which used to be configurable from the preferences (and could even be customized for specific people from the buddy list<sup id="fnr1-2013-10-30"><a href="#fn1-2013-10-30">[1]</a></sup>) — by replacing or renaming the other .aiff files in that directory:</p>
<ul>
<li>Buddy Logging In.aiff</li>
<li>Buddy Logging Out.aiff</li>
<li>Default.aiff</li>
<li>File Transfer Complete.aiff</li>
<li>Invitation Accepted.aiff</li>
<li>Invitation.aiff</li>
<li>Logged In.aiff</li>
<li>Received Message.aiff</li>
<li>Ringer.aiff</li>
</ul>
<hr />
<section class="footnotes">
<p id="fn1-2013-10-30">[1] I imagine it’s possible to have buddy-specific sound effects using the remarkably-still-present “AppleScript handler” functionality, but I haven’t tried it. <a href="#fnr1-2013-10-30">↩</a></p>
</section>
Touch ID and “Require Passcode: Immediately”tag:danstillman.com,2013:/2013/09/30/touch-id-and-require-passcode-immediately2013-09-30T16:12:24-04:002016-09-06T12:08:57-04:00Dan Stillmandanstillman.com<p>For people used to the iOS passcode lock, the fingerprint scanner on the iPhone 5S, which Apple calls Touch ID, comes with a significant drawback: with Touch ID enabled, it’s no longer possible to set the amount of time since the screen last turned off before the passcode — or, now, Touch ID — is required to unlock the device.</p>
<p>Going back to the very first iPhone, the “Require Passcode” setting has offered various options — “After 1 minute”, “After 5 minutes”, etc. — to control the passcode timeout, and nearly everyone I know who uses a passcode chooses a timeout of at least five minutes. I’ve generally set it to five minutes myself, which I feel provides a good balance between security and convenience: long enough so that I don’t have to reenter my passcode if I put my phone in my pocket for a minute while texting with someone or navigating somewhere, but short enough that, if I left my phone somewhere by accident, the passcode would likely be required before someone discovered it. Now, with Touch ID, “Immediately” is the only option. Waking the phone — every time — requires either scanning a fingerprint or swiping across the lock screen and entering a passcode manually.</p>
<p><figure>
<img src="https://danstillman.com/media/2013/09/touch_id_and_require_passcode-before.png" alt="The Require Passcode screen, with Touch ID disabled" style="max-width: 49%; border: 1px solid #000"/><img src="https://danstillman.com/media/2013/09/touch_id_and_require_passcode-after.png" alt="The Require Passcode screen, with Touch ID enabled" style="max-width: 49%; border: 1px solid #000; margin-left: -1px"/>
<figcaption>On the left, with Touch ID disabled; on the right, with Touch ID enabled</figcaption>
</figure></p>
<p>Requiring authentication immediately is problematic for a number of reasons.</p>
<p>First, it greatly increases the number of times per day that Touch ID has to work. When functioning properly,<sup id="fnr1-passcode"><a href="#fn1-passcode">[1]</a></sup> Touch ID is remarkably accurate and a delight to use. Yet it still occasionally fails to read my thumb on the first one or two tries, and it’s stymied by moisture or dirt. If I were only authenticating as often as I used to enter my passcode, it would easily be a net win — after all, I didn’t always get my passcode right on the first try either. Having to authenticate on every unlock, though, anything short of 100% accuracy for the scanner quickly becomes tedious.</p>
<p>Even when it’s working well, using Touch ID isn’t always the quickest or most convenient option. In iOS 7, it’s now possible to slide to unlock anywhere on the lock screen instead of just across the bottom — a great Fitts’s Law win. Among other things, this makes one-handed use much easier and more physically secure, since you can lock the phone with your index finger, wake it up the same way, and then slide your thumb across the top of the screen, without the finger acrobatics that were previously required to reach the bottom of the screen. Unfortunately, with Touch ID enabled, sliding to unlock is now never sufficient on its own, meaning that you have to either enter the passcode or adjust your grip to reach all the way to the home button each time. If you’re waking your phone repeatedly — say, to check your position on a map, or to return to something you’re reading — this gets annoying quickly.<sup id="fnr2-passcode"><a href="#fn2-passcode">[2]</a></sup></p>
<p>Requiring the passcode immediately also impairs basic iOS functionality: the ability to swipe across lock screen alerts in order to trigger actions. If you text someone via Messages, switch to Safari, lock the phone, and then receive a reply a few seconds later, unlocking via Touch ID will take you to Safari, not Messages. The same problem applies to any alert from an app that wasn’t the one you most recently used. The workaround is to slide across the lock screen alert to get to the passcode screen and <em>then</em> authenticate with Touch ID, but that’s an annoying extra step for people used to a passcode timeout, an unfortunate regression in usability for an action that people have done many times daily for years.</p>
<p>Finally, with Touch ID enabled, the passcode still remains an option: simply slide to unlock as before and enter the passcode. This is an important alternative when a registered finger isn’t clean/dry/free, and even before Touch ID I would occasionally find myself needing to use a lesser finger or knuckle to unlock the phone. Removing the timed options means that, when Touch ID is enabled, simply using the phone in exactly the same way as before is now significantly more onerous.</p>
<p>So if there are so many disadvantages to requiring the passcode immediately, why is it now the only option?</p>
<p>At first glance this might appear to simply be a bug,<sup id="fnr3-passcode"><a href="#fn3-passcode">[3]</a></sup> but a perusal of <a href="http://support.apple.com/kb/HT5883">Apple’s Touch ID documentation</a> suggests otherwise:</p>
<blockquote>
<p>Using Touch ID sets your Require Passcode setting to Immediately. You still have the option of entering your passcode simply by sliding to unlock.</p>
</blockquote>
<p>While this doesn’t explicitly state that the other Require Passcode options are no longer available with Touch ID enabled, it strongly suggests it. Otherwise, why change the setting the user had assigned?</p>
<p>An alternative and more likely explanation is that the new restriction amounts to an opinionated view of how Touch ID should be used. Apple’s recommended technique for using Touch ID is to press and release the home button with a registered finger and leave it there until the phone unlocks. It seems plausible that, in Apple’s view, the new, correct way to start using an iPhone (except when simply interacting with Notification Center or Control Center) is always just to wake and unlock it in that manner.</p>
<p>Fortunately for those frustrated by this change, Apple has relented before on opinionated decisions that proved to be overly restrictive and/or optimistic. (See: <a href="http://9to5mac.com/2011/10/21/jobs-original-vision-for-the-iphone-no-third-party-native-apps/">apps</a>.) Unfortunately, the fix isn’t as straightforward as simply restoring the missing timed options. Touch ID, as currently implemented, <em>is a function of the passcode lock</em>. If the passcode didn’t take effect for several minutes, it wouldn’t be possible to unlock the phone using Touch ID during that time. A solution in which Touch ID is only conditionally, unpredictably available is obviously a nonstarter.</p>
<h2>The Fix</h2>
<p>So what’s the solution, then? <strong>The Require Passcode setting should be separated from Touch ID.</strong> The previous timed options should be restored, but, true to the setting’s name, the timer should determine solely whether the passcode keypad appears or whether the phone unlocks immediately when the user slides to unlock. Touch ID, meanwhile, should remain operative on the lock screen at all times, even when sliding to unlock would be sufficient. This would allow people to continue to use the Apple-recommended unlock technique whenever they liked, but, when they knew they were within the passcode timeout period, to hastily wake the phone via either button and swipe across the screen — or, in the case of a lock screen alert, to swipe across the alert to trigger the associated action.</p>
<p>This isn’t a perfect solution. First, it would allow for the awkward — if harmless — situation of having Touch ID reject a fingerprint even when authentication wasn’t actually required. (The alternative, having it accept anything that seemed like a finger as long as the passcode timeout hadn’t expired, is probably too likely to produce <a href="http://9to5mac.com/2013/09/21/touch-id-on-iphone-5s-can-be-used-with-more-than-just-your-fingers/">accidental unlocks</a>.) But if Touch ID is enforced before the passcode timeout, should three failed attempts still bring up the passcode entry screen, as happens now, even though simply swiping would have bypassed it? Should five failed attempts force passcode entry until the next unlock, again as happens now, even though the passcode itself wouldn’t yet have been required? The answer to both is probably yes, if only to avoid providing an unlimited, detection-free testing mode for <a href="http://www.ccc.de/en/updates/2013/ccc-breaks-apple-touchid">CCC-style Touch ID hacks</a> for anyone in temporary possession of a pre-timeout device.</p>
<p>Allowing a passcode timeout with Touch ID would also introduce a degree of unpredictibility into the unlock process, resulting in some unlocks that took longer than necessary because the user misjudged the timeout, tried to press-and-swipe, and ended up on the passcode entry screen, rather than simply using Touch ID from the outset. But since Touch ID can be used on the passcode entry screen as well, the penalty for misjudgments would be minimal. Furthermore, with “Require Passcode: Immediately”, swipes across lock screen alerts already always trigger the passcode entry screen, so in those cases an unexpected timeout would simply result in the current behavior.</p>
<p>Even if the timed options were restored, most people would continue to unlock their devices with Touch ID at all times, as Apple surely prefers. But for people who lock and unlock their devices constantly and still want to keep their data secure, the Require Passcode setting has always been a crucial time-saving feature, and it would remain so in conjunction with Touch ID. Touch ID is impressive technology, but it would be a shame if the only way to match the usability of the last six years of iOS was to turn it off.</p>
<hr />
<section class="footnotes">
<p id="fn1-passcode">[1] For the first week that I had the phone, Touch ID failed constantly with one of my thumbs, requiring one or two tries every time. Knowing that early reviews had touted the system’s near-perfect accuracy, I tried various things to improve its performance: giving it time to learn more of my thumbprint, deleting and retraining, even adding different parts of my thumb as separate fingers to try to increase the coverage. No luck. I had pretty much concluded that either the scanner or my thumb was defective. Finally, nearly ready to disable Touch ID for the passcode altogether, I wiped off the sensor and retrained my thumb once more, and since then, it’s worked nearly every time. It seems possible to configure a finger with an inaccurate profile that the phone can’t learn its way out of. <a href="#fnr1-passcode">↩</a></p>
<p id="fn2-passcode">[2] Also annoying? The glacial fade-in effect when waking the screen in iOS 7. It’s actually hard to compare the speed of Touch ID to the speed of pressing a button and sliding to unlock, since Touch ID begins processing immediately, whereas the screen doesn’t seem to register swipes until the effect completes. With the fade-in effect, Apple is essentially cheating a bit to make Touch ID seem faster, but it’s doing so at the expense of traditional unlocks. <a href="#fnr2-passcode">↩</a></p>
<p id="fn3-passcode">[3] One theory I’ve seen is that the presence of the “Shorter times are more secure” message in the pane suggests that the other options were intended to be available. However, Exchange servers have always been able to restrict iOS passcode-lock policies, including limiting the available options to “Immediately”, and the same message has remained even in that case. There is a bug here, but it’s simply that the message appears even when “Immediately” is the only available option. <a href="#fnr3-passcode">↩</a></p>
</section>