Apple Touch ID is dangerous.

Many iOS apps, including Apple secure Notes and banking apps and 1Password.app and Apple Pay provide an option to use Touch ID for authentication. Apple makes much of the security advantages of Touch ID.

Sometimes Touch ID fails to recognize your finger. That’s no problem, you can repeat that finger recording, or you can add another one. All you need to know is your iPhone’s unlock code.

All anyone needs to know is your iPhone’s unlock code. With it can add their own finger, and unlock anything that was Touch ID enabled. In my testing on Apple’s secure Notes a fingerprint added after a Note was created opens the Note.

So Touch ID is only as secure as your iPhone’s unlock code. Which, even with Touch ID enabled, you have to enter too often. So you probably make it short and tappable so you can do that.

Yeah, once you enable Touch ID on your bank account, you’ve basically changed its password to your iPhone’s conveniently short and tappable unlock code.

Touch ID is dangerous.

Force Mac Chrome to open for a specific user profile - as of April 2016

I’ve been trying to get Chrome to open in one of my 15 user profiles since at least 2012. I have visited an open SuperUser question on this topic for four years. Today I added a method that work — for this moment:

As of April 2016 on Yosemite I was able to locate Google Apps for all of my 15 Google Profiles (yes, 15). Some were in ~/Applications/Chrome Apps, though we have been told these are going away [1].

To find all of them however I had to do this:

Go to ~/Library/Application Support/Google/Chrome.
In Spotlight search on kind:app
Find 300kb "Applications" with names like Gmail (username).
Copy the ones you want and rename them, then put in your Applications folder of choice.

All victory is transient, but Sisyphus is ahead most of the time.

Scrivener - the book compiler. Review.

I'm using Scrivener to write Smartphones for All - Using iPhone and Android to build independence for atypical minds.

It’s brilliant software. On my Mac it uses the same text editing engine as TextEdit, including the same RTF format. So, like the Nisus Writer I once used, my writing is indexable by Spotlight and almost as future-proof as plaintext. (I thought RTF was dead. Guess not.)

Apple’s text engine has its share of bugs and limitations, but for basic text work it’s good enough. The primary weakness is table layout, but so far I’ve worked around that.  Scrivener manages the tasks TextEdit can’t do, like page references, footnotes, internal links, document structure and the like.

The real brilliance though is how Scrivener merges concepts of software code management with the traditional word processor. It treats text blocks as though they were blocks of code, including simple version management and “compiling” to multiple output formats (PDF, EPUB, etc). Rather than use some horrid database store, Scrivener leverages native Mac file structures to manage its data. Extra brilliance points for that.

On this compile framework Scrivener layers a rich set of power user features. The latter, I admit, can be overwhelming. I recommend learning the basics from the initial tutorial, then start writing and learn additional features over time.

All software dies. One day Scrivener will die too. But with the ability to complete to multiple formats, and the use of native file system semantics and RTF data, Scrivener is as future proof as any power tool can be [1].

[1] Scrivener’s design is a guide to how photo management software should be built. Please, someone do this.

The new and old and obsolete and confusing ways Mac OS X starts code running.

Windows added uninstallers at least 15 years ago. MacClassic OS didn’t need them, but Mac OS X sadly does. Indeed, it needs them more as MacOS gets more complex and less well documented:

… The difference between an agent and a daemon is that an agent can display GUI if it wants to, while a daemon can’t. The difference between an agent and a regular application is that an agent typically displays no GUI (or a very limited GUI).

… Agents run in a user context; daemons are userless and purely background, without any access to a window server or other user state. That’s why the daemon vs agent distinction in the Library folder names …

… once comprehensive daemon/agent doc was last updated in 10.5 after initial authoring for 10.4

Without an uninstaller we end up doing a hunting expedition when weird things happen. Code that starts automatically is particularly hard to track down. I wrote this post as a reference for me, drawing from a few Super User and other posts:

• Common Mac OS folders/settings to check (when trying to get rid of a pesky self-launching app) - Super User
• Track down all startup & login script and application launches in Mac OS X
• osx - Run command on startup / login (Mac OS X) - Super User
• osx - removing startup item from com.apple.launchd - Super User
• @inadarei: Various Ways Something Can Load On Startup in Mac OS-X
• OS X Tips – System Startup – launchd, launch daemons, startup items, launch agents and login items | DGKApps
• All start up items exist in OS X (Lion) | MacRumors Forums

 This list of places to look comes from the above, some of these are extremely obscure and some may not longer be used.

• User Login Items (~/Library/Preferences/com.apple.loginitems.plist)
• ~/Library/LaunchDaemons
• ~/Library/LaunchAgents
• ~/.bash_profile
• /Library/LaunchDaemons
• /Library/LaunchAgents
• /Library/StartupItems
• /System/Library/LaunchDaemons/
• /System/Library/LaunchAgents
• /System/Library/StartupItems
• /Library/Preferences/loginwindow.plist can have Login Items that apply to all users
• /etc/profile
• /etc/mach_init.d/
• /etc/rc/ and /etc/rc.local - totally unsupported, and not created by default (but probably still work)
• Network/Library/LaunchDaemons, but I don’t know)?
• /etc/mach_init_per_login_session.d/ and /etc/mach_init_per_user.d/
• cron launched @reboot items (yes, cron is still there), this might even work for everyone’s crontabs
• /Library/Security/SecurityAgentPlugins that have been loaded by being listed in the proper spots in /etc/authorization
• /private/var/root/Library/Preferences/com.apple.loginwindow.plist, in the LoginHook key (runs as root, passed the username)MCX (WorkgroupManager) login hooks (runs as root, but passed the username) note: below this network home directories are more reliably available, as is a connection to the WindowsServer
• MenuBar items from ~/Library/Preferences/com.apple.systemuiserver.plist and /Library/Preferences/com.apple.systemuiserver.plist (+MXC added items)
• /Library/Preferences/loginwindow.plist, in the key (array of paths) AutoLaunchedApplicationDictionary (everyone gets this launched at login, runs as user) (+MXC added items)
• LoginItems (generally GUI items) ~/Library/Preferences/com.apple.loginitems.plist and possibly /Library/Preferences/com.apple.loginitems.plist (have not tried) (+MXC added items)

Some terminal commands can help figure out what’s running:

launchctl list
…

2BUA8C4S2C.com.agilebits.onepassword4-helper
ch.tripmode.TripMode.169864
com.bombich.cccuseragent.132660
com.google.Chrome.44620
com.google.GoogleDrive.49732
com.google.keystone.system.agent
com.red-sweater.crashreporter.63648
com.red-sweater.marsedit.6280
com.synology.CloudStation
com.synology.CloudStationDrive
org.openbsd.ssh-agent
ws.agile.1PasswordAgent

When I edited my ~/Library/Preferences/com.apple.loginitems.plist I found references to 4 3 apps and a server, including one I removed 7-8 years and 3 machines ago:

• LaunchBar.app
• /Volumes/Molly_Internal
• /Applications/Dropbox.app
• MagicPrefs.app

I doubt they did anything, but I edited them out anyway.

Software ages like people, with increasing mutations and unhelpful complexity. OS X is late middle age, it’s been through many handoffs, each taking its toll …

See also: 

• Gordon’s Laws for software and service use 4/2010. I’m very cautious about trying new software. Perhaps great apps don’t need an uninstaller, but these days absence of an uninstaller is worrisome.

Mac thunderbolt 2 drive dropping -- remember ScanSnap AOUMonitor and don't touch Amazon Cloud Drive.

After months of reliable use my Elgato Thunderbolt 2 hub is dropping my USB3 external SSD; just like the OWC T2 hub did in my initial testing.

We know Yosemite (and El Capitan) have issues with Thunderbolt hubs; there’s something frail in Apple’s infrastructure [1]. But it had been working… So after power cycling everything [3] it’s time to look for things that have changed recently.

The first place to look is my Login items. I find something called “Mountain”. It’s missing though. Weird. Part of something I’d tried then removed. Deleted that.

I also find AOUMonitor. That would be related to my recent ScanSnap update. Sounds familiar, so I use my Google Custom Search for everything I’ve published. I find Managing unwanted Mac startup apps: ScanSnap’s AOUMonitor and Citrix Receiver. Bang. AOUMonitor is a known bad actor. Delete it.

Next is Google Drive. It’s known to cause problems, but I’m still hooked on it and it’s an old-timer. Despite Google’s decreasing interest in iOS and OS X [2] I have to leave it.

But where’s Amazon Cloud Drive? It’s a newbie that’s also launching automatically. The fact that it’s absent from Login Items tells me it’s poorly written. Over to LaunchDaemons.

System Library\LaunchDaemons looks all Apple — as it should be.

Users\Library\LaunchDaemons has CCC (ok), Office (licensing and update, ugh), Skype (huh? - deleted!), Google keystone (old, part of their update infrastructure I think), TripMode (? delete for now), Barebones (trustworthy).

Users\me\Library is a bit odd.  Instead of LaunchDaemons we have LaunchAgents (really Apple?) [4] and no Startup Items. In LaunchAgents I find simple plists for Synology CloudStation (yeah, I’m suspicious of that one, but need it for now), 1Password (need it), Safari (ok I guess) and com.imobiesilentcleanserver.plist. The last was probably left over from testing imobie’s iOS cache cleaner (didn’t work), so I deleted it.

Alas, I still can’t figure out how Amazon Cloud Drive is starting up. Now I really want to kill it. Google is no help (which is another bad sign). Looking at Log files it looks like ACD is using some .NET infrastructure and it’s generated about 15 Console crash logs. 

Amazon Cloud Drive is a bugger to purge. EasyFind finds a folder in .local/share — yeah, a hidden directory. There’s app.com.amazon.clouddrive.mac.installer.playlist in friggin’ /private/var/db/BootCaches/2B1FD298-BBE8-4207-B1B0-ED420A2DAD74. There’s crap in Application Scripts, Application Support, and too many to mention. Try searching on “Amazon Cloud Drive”, “amazon.clouddrive” and so on. Take your time. 

Really, don’t touch Amazon Cloud Drive. Now I’m getting DOS TSR flashbacks in addition to my SCSI flashbacks.

Lastly, a safe boot to clear caches and then a restart. Now we’ll see what happens. I never did find what was launching Amazon Cloud Drive, but my Console isn’t showing any “Amazon” messages.

- fn -

[1] I’m getting PTSD flashbacks to MacOS Classic and SCSI chains.
[2] Apple is not doing well. 
[3] I’m going to start routinely power cycling my peripherals — they can go weeks without cycling whereas my Air gets cycled every week or two. 
[4] Update: jws explained -  "The difference between an agent and a daemon is that an agent can display GUI if it wants to, while a daemon can't. The difference between an agent and a regular application is that an agent typically displays no GUI (or a very limited GUI)… Agents run in a user context; daemons are userless and purely background, without any access to a window server or other user state. That’s why the daemon vs agent distinction in the Library folder names…

iOS 9.x spotlight bug explained: It's the RAM.

Spotlight has been failing for me since I updated to iOS 9 - no results appear. It got much worse with 9.3. Force-quitting background apps, especially Reeder.app,  helps. It acts like a limited RAM bug, but I think there are ways Spotlight may fail.

From Apple Discussions it doesn’t hit devices with 2GB of RAM, it’s a problem for 1GB devices with lots of indexed content and/or memory hogging apps.

Jason Heiser has figured out what’s wrong (emphases mine). It’s a capacity/RAM problem:

Apple discussions April 5, 2016

My iPhone 6 updated to iOS 9.3.1 an hour ago and Spotlight Search is still broken for me.

I downloaded iOS Console and looked at the console output when trying to perform a Spotlight Search. Here is what I saw:

Apr 5 15:42:18 jPhone searchd[286] : (Error) IndexGeneral in si_playBackMobileRecords:2343: played back 0 records
Apr 5 15:42:19 jPhone searchd[286] : (Error) IndexGeneral in si_playBackMobileRecords:2343: played back 0 records
Apr 5 15:42:19 jPhone diagnosticd[83] : unable to find offset 0x81448aac in shared cache for arch 'arm64'
Apr 5 15:42:19 jPhone diagnosticd[83] : unable to find offset 0x814467cc in shared cache for arch 'arm64'
Apr 5 15:42:19 jPhone diagnosticd[83] : unable to find offset 0x81649da8 in shared cache for arch 'arm64'
Apr 5 15:42:19 jPhone diagnosticd[83] : Invalid offset 2170854824 into shared cache for arch 'arm64'
Apr 5 15:42:19 jPhone ReportCrash[288] : platform_task_update_threads failed 1
Apr 5 15:42:19 jPhone ReportCrash[288] : Formulating report for process[286] searchd
Apr 5 15:42:19 jPhone ReportCrash[288] : report not saved because it is non-actionable
Apr 5 15:42:21 jPhone UserEventAgent[26] : jetsam: kernel termination snapshot being created
Apr 5 15:42:21 jPhone ReportCrash[289] : Saved type '298(298)' report (2 of max 25) at /var/mobile/Library/Logs/CrashReporter/JetsamEvent-2016-04-05-154221.ips

According to this, the searchd crash log is not being saved because it is "non-actionable." However, a log for "JetsamEvent" is being created at roughly the same time. I looked at this file on my iPhone and JetsamEvents appear to be a low-memory (RAM) issue. Here is the top portion of the crash report.

{"timestamp":"2016-04-05 15:42:21.21 -0500","bug_type":"298","os_version":"iPhone OS 9.3.1 (13E238)"}
{
"crashReporterKey" : "88540025a9600afa364c269a2c5bc8a91370b1ca",
"kernel" : "Darwin Kernel Version 15.4.0: Fri Feb 19 13:54:49 PST 2016; root:xnu-3248.41.4~28\/RELEASE_ARM64_T7000",
"product" : "iPhone7,2",
"incident" : "D0ED493F-7687-49D9-AFB9-BEE80BD93082",
"date" : "2016-04-05 15:42:21.21 -0500",
"build" : "iPhone OS 9.3.1 (13E238)",
"timeDelta" : 95,
"memoryStatus" : {
"compressorSize" : 50489,
"pageSize" : 4096,
"compressions" : 824422,
"memoryPages" : {
"active" : 101577,
"throttled" : 0,
"fileBacked" : 37711,
"wired" : 49311,
"anonymous" : 114469,
"purgeable" : 0,
"inactive" : 48272,
"free" : 2459,
"speculative" : 2331
},
"uncompressed" : 172172,
"decompressions" : 362924
},
"largestProcess" : "searchd",

According to this, the "largestProcess" was searchd when the crash report was generated. Further down in the crash report is searchd's information:

{
"rpages" : 129777,
"states" : [
"daemon"
],
"name" : "searchd",
"pid" : 286,
"reason" : "highwater",
"fds" : 100,
"uuid" : "7b301993-286d-3da5-a497-b729984d3229",
"purgeable" : 0,
"cpuTime" : 2.481274,
"lifetimeMax" : 84765
},

Apparently the maximum for searchd is "84,765" but it reached "129,777." The reason is "highwater" which I assume means searchd exceeded its RAM allotment. So maybe my Spotlight index is too large. Too many iMessages, too many songs, too many emails... Who knows.

The "report not saved because it is non-actionable" for searchd's crash report is worrisome. I fear this bug is nowhere on Apple's radar. We might be marginal outliers without recourse for a long time.

There are two workarounds for the bug:

1. Force-quit background apps — may help free RAM. Try again.
2. Siri works for launching apps even when spotlight fails.

I think setting all Spotlight indexing option to On helps — I have a feeling there’s a bug with rendering results that is worse if the rendering process has to manage exclusions. Restarting your phone daily probably helps too.

Update 7/30/2016

A correspondent who saw the same behavior as mine reported that Spotlight was working 8 days after he did a phone wipe and restore. I did the same and it’s working now 7 days later.  That doesn’t mean it will work forever, but 7 days is a long time. I’m now on iOS 9.3.3. I have seen a trustworthy report that the upgrade to 9.3.2 fixed the problem for some, for me it took the OS update and a wipe/restore.

 

iOS 9 secure notes with Touch ID are no more secure than your device passcode

If you enable Touch ID access to an iOS 9.3 Note.app Secure Note, the password on the note doesn’t matter. The note is no more secure than your device passcode.

Because if you know the device passcode, you can just add a new fingerprint to Touch ID. That will unlock the secure note.

So if you want to truly secure a Note with a strong password you can’t enable Touch ID access. Otherwise you might as well leave the note unsecured. You are better off using a strong password for your phone and using Touch ID for fast phone access.