yoink

It was a bug I’ve been carrying along for quite some time in Yoink. But I finally found the culprit: I’m looking at you, OS X sandbox.

Webarchive opened after bug occurredA webarchive created with Safari, after a security-scoped NSURL bookmark was created for it.

The Bug and its Detection

As it happens (sadly), not I discovered the bug, but a customer and user of my app Yoink encountered it. The reason being, I rarely handle .webarchive files (if at all) – webarchive files are created when saving a website in Safari, for example – but one of Yoink’s users, Christoph, appears to have to deal with them regularly.

The bug itself is described fairly easily. You have a .webarchive file you’d like to move using Yoink. So you drag it onto the app and then move it from Yoink to the actual destination. Business as usual.
Only that now, instead of opening the webarchive in your standard browser when double-clicked, above’s warning is shown.

There’s two baffling things about this warning:

  1. It looks like you’re trying to launch an application instead of just a file (“from an unidentified developer”)
  2. The creator of the file seems to have changed. Instead of Safari, it now says “BugReport-WebArchivesAndNSURLBookmarks” (the app I submitted to Apple to demonstrate this issue)

Highly concerning, to say the least. To some people, it might even look like something fishy is going on.

Hunting Down the Bug

Seeing as .webarchive files are binary property lists (thank you, Michael Tsai (@mjtsai on twitter) for the correction), I tried other property list files (for example, .plist files), but none exhibited the same behavior.

Reproducing it was fairly easy. There’s one pre-requisite for it to appear: that in System Preferences -> Security & Privacy -> Allow apps downloaded from, either ‘Mac App Store’ or ‘Mac App Store and identified developers’ be selected.
Otherwise, Gatekeeper isn’t active and doesn’t react to the issue.

System Preferences - Security and Privacy Settings

At first I thought it happened when moving the file out of Yoink, since that’s where Yoink actually does something to a file – it moves it from one location to another – who knows what goes on behind the scenes there.

Going through the move-code line by line, commenting out stuff I thought could cause this, made no difference what so ever. Create a new webarchive, move it using Yoink, and get the warning again. Rinse and repeat.
With stuff like this, I get annoyed easily, so my patience usually goes out the window after a couple of alterations to the code.

It was only after the billionth time that I considered it might happen when a file was added to Yoink, not moved from Yoink.

Going through the same process as before, I went through the code line by line, trying different things.

With a recent update to Yoink, the app knows when a file is renamed or deleted in Finder, using GCD (Grand Central Dispatch) and its dispatch sources.
I believed the issue lay there, but after commenting out all of that code as well, it became clear it wasn’t the culprit.

In a fit of anger and a severe feeling of incompetence, I randomly picked at the code (I know, highly professional. But I’m using version control – all is well, right?).

To my surprise, when I removed the code responsible for saving Yoinks files over relaunches of the app, the issue went away.

Security-Scoped NSURL Bookmarks

For a sandbox’ed app to keep a reference to a file added by the user beyond relaunches, it has to use what is called a security-scoped NSURL bookmark.

Sandbox entitlements necessary for security-scoped bookmarks

They can be used if the corresponding entitlement (see above) is added to the app’s sandbox entitlements file.

There are two ways a security-scoped bookmark can be created – either with read and write access, or read-access only (NSURLBookmarkCreationWithSecurityScope or it plus NSURLBookmarkCreationSecurityScopeAllowOnlyReadAccess).

I don’t know why this causes the issue, but changing the bookmark creation options from read and write access to read-access only fixed the issue (and moving the file is still possible with Yoink). It definitely looks like a sandbox bug to me.

Why should an app-internal bookmark (mind you, it’s only a reference to a file, not the file itself, created from an NSURL object) write to and change the webarchive’s file so that it a) can’t be opened anymore and b) shows the bookmark-creating-app as its creator?

Bug Reporting to Apple

I reported this bug to Apple (rdar://21765077) with an example project you can download here, if you’d like to see for yourself. Feel free to dupe the bug with Apple’s Bug Reporter Tool – I’d appreciate it 🙂

Now all that’s left to say is thank you for your patience, Christoph. You reported this issue at the beginning of March 2015 and had to wait until now for it to be fixed (and still a little longer because I have to submit the update to Apple for release on the Mac App Store as well). I really appreciate your continued feedback on the app!

Correction

Thanks to Michael Tsai for pointing out on his blog that .webarchive files aren’t bundles, as I falsely stated, but binary property lists.

Read more

Yoink for Mac Usage Tip #9

The following explains how send screenshots directly to Yoink.
For more Usage Tips like this, click here.

I recently had a very interesting conversation with a customer of Yoink, Bogdan V. He wanted to make Yoink detect screenshots he created so they would show up in Yoink’s window.

Automator to the Rescue

I had the idea of using Automatorto create the screenshot and send it to Yoink. After experimenting around a little bit, I sent Bogdan a very rudimentary workflow (that could, if saved as an OS X Service, also be launched with a keyboard shortcut) and he immediately turned it into something awesome.

The Automator Workflow

This is the script of the workflow Bogdan came up with:

Automator Workflow Screenshot

You can download the Automator Workflow here (~59KB) (tested on OS X Yosemite 10.10.1).

Setting up the Service

  1. Download the Automator Workflow
  2. Unzip it and double-click on the resulting screencapture.workflow file
  3. In the dialog, select Install (except if you’d like to edit the script, then click on Open with Automator)
  4. It will be installed in your ~/Library/Services/ folder: Automator Service Path
  5. To confirm installation, in Finder, click on Finder in your menu bar, select Services and find Capture Screenshot to Yoink in the list: Service in Menu
  6. In your ~/Documents/ folder, create a folder titled Yoink (where captured screenshots will reside)

You have now successfully installed the Service to capture screenshots to Yoink. What you can do now is create a keyboard shortcut for it so you can more easily access this

Create a Keyboard Shortcut

  1. Launch System Preferences
  2. Click on Keyboard -> Shortcuts -> Services
  3. Find Capture Screenshot to Yoink in the list, under General:Screenshot System Preferences Keyboard Shortcuts
  4. Click on add shortcut and enter the shortcut you’d like to use to activate the service.

That’s It

That’s all there is to it. Now you can create screenshots that are then immediately available in Yoink for you to drag around.
If you find it useful, be sure to let me know on twitter (@eternalstorms) or by eMail – I’d appreciate the feedback!
Take care!

Update (October 14, 2015)

I got a bit of feedback on this – especially feedback from Pietro S. and Jeremy M. pushed me to update this post with a bit more information.
  • To make the Automator Script capture the entire display instead of just a selected portion, replace the line ‘ do shell script “screencapture -i ” & filePath ‘ with ‘do shell script “screencapture “ & filePath ‘ (removing the -i option to cause the selection)
  • Jeremy was so kind to provide an updated Automator Workflow that appended a date and timestamp to the screenshot’s filename; add two actions before the actual script (“Get Value of Variable”) with the variables Date and Timestamp and import them into the script – as in this screenshot:
    Screenshot of Automator, appending date and time to the filename
  • To use this Automator Workflow with the standard keyboard shortcut command-shift-4, you first have to deactivate the standard action in System Preferences -> Keyboard -> Shortcuts -> Screen Shots, or assign it a different keyboard shortcut: Screenshot of System Preferences

A ‘thank you’ goes to Jeremy and Pietro for the updated workflows.

Read more

10904415 10205535099647537 6831010725206999453 o

Apple is currently featuring Yoink on the Mac App Store, in the category “New Year, New You”, and it’s in great company with the very popular apps MindNode Pro, 1Password, OmniFocus and Evernote.
I couldn’t be more proud and humbled.

This certainly wouldn’t have happened without all of you, so

Thank you!

—-
My name is Matt, I’m the developer of Eternal Storms Software. If you’d like to comment, you can catch me on twitter here: [twitter-follow screen_name=’eternalstorms’ show_count=’yes’] or by eMail.

Read more