Archive for May 12, 2016

Thursday, May 12, 2016 [Tweets] [Favorites]

Proposed Client-side Encryption in OmniFocus

Wim Lewis (via Ken Case):

Our main goal is to secure your data against a passive attacker: someone who can read the files on the server, intercept them on the network, look at old backup tapes, etc., but who cannot modify your files on the server. This describes a lot of real-world compromises. The passive attacker should be able to learn very little about your use of OmniFocus. They will, by definition, be able to tell when you’re making changes and syncing them, and they can tell if you’ve added an especially large attachment, for example, because of the increase in traffic. But they should not be able to read the contents of any of your tasks.


An OmniFocus sync database is a directory full of files which are read and written asynchronously by multiple clients that don’t have other ways to communicate.

An encrypted database has one extra file, the “encryption metadata” or key management file. Your passphrase decrypts this file, which contains one or more file-encryption subkeys, each with an identifying key index.



Long List of Ways Mac OS X Starts Code Running

John Gordon:

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[…]

Keir Thomas:

Moving beyond Gordon’s analysis, two free apps can help begin to sort out the mess and discover what apps are attempting to run in the background of your Mac:

  • KnockKnock: Malware installs itself persistently, to ensure it is automatically executed each time a computer is restarted. KnockKnock uncovers persistently installed software in order to generically reveal such malware.
  • Etrecheck: EtreCheck is a free tool that explains what is going on inside your Macintosh. It consolidates information from over 50 different diagnostics tasks and displays it all on one concise report.

Beware the UIKit Visitors

Rupert H:

My discovery for the day is iOS has an O(n^2) cost to add a subview so never have too many subviews on a view or performance goes to shit

Wooji Juice:

I’ve found that setting tintColor on the view manually before adding it to the hierarchy helps a lot.

Benjamin Encz:

This means, that as soon as a _UITintColorVisitor has an original visited view (which is true after it visited its first view), the outlined code checks if the subviews array of the originalVisitedView contains the currently visited view. This check scans the full array of subviews; in cases where the originalVisitedView is our root view, the cost of this operation grows linearly with the amount of added subviews.


Once we know the memory address offset we can create breakpoints in lldb based on addresses in Hopper.


With this approach I identified that with the current sample code, eax always refers to the root view. This means we are iterating over all subviews of the root view, N times for each subview that is added.

Update (2016-05-14): See also: Hacker News.

Compile Time vs. Run Time Type Checking in Swift

Benjamin Encz:

The dynamic type check in the above example actually works correctly. The body of the if let block is only executed for types that conform to our two expected protocols. However, we cannot convey this to the compiler. The compiler expects a concrete type (one that has a fully specified type at compile time) that conforms to HumanType and HasName. All we can offer is a dynamically verified type.


The solution of the “type erased” function that accept an Any argument isn’t really nice either; but in practice I have used similar approaches in cases where other code guarantees that the function will be called with the correct type, but there wasn’t a way of expressing that within Swift’s type system.

Update (2016-05-12): Joe Groff:

It is possible to “open” a protocol<> type into a concrete type via a protocol extension.