Overriding Swift String’s Subscript Operator

With Swift 4, strings are once again a collection of characters. Maybe it’s my C++ upbringing, but an array of characters just feel right. Unfortunately, referencing a specific character in a Swift string isn’t as easy as using the subscript operator for an array. Instead of passing an integer into square brackets, iterating through the characters of a string requires the use of String.index. Simply writing myString[0] won’t work, we have to write:

let index = self.index(self.startIndex, offsetBy: (0))

I never remember this. Again, maybe it’s my C++ traumatized brain, but it just doesn’t sit right. So I made the equivalent of programatic comfort food with this little extension, overriding String’s subscript operator to accept a plain old Int:

extension String {
    subscript(i: Int) -> String {
        get {
            let index = self.index(self.startIndex, offsetBy: (i))
            return String(self[index])

And with that, myString[i] works and I don’t have to think too hard next time I reference a character.


I listen to a podcast about pens. A weekly podcast about pens. Yes, there really is enough pen related news to have a weekly podcast. So much stationery related content in fact, that there are dozens (dozens!) of websites and blogs dedicated to the wonderful world of pens, pencils, paper and ink! Over time, I’ve slowly branched out from a few core pen blogs to more than I can name off the top of my mind. I decided to make Nibbler, a free, little iOS app for aggregating pen and paper news.

Why make a pen news app? I could easily add all of these sites to an RSS reader, just like I do for all my tech news sites, but it just didn’t feel right to me. A lot of the posts from these pen blogs often feature well composed images of the shades of a new ink, the body of a fancy pen, etcetera. Most of the RSS readers I’ve had experience with on iOS don’t do a great job at showing off these pictures while browsing through posts. They also take out a lot of the stylized flair that gives the site its character. While browsing through the posts from dozens of pen blogs, Nibbler presents the leading image of each post. I’ve found some of the photos lead me to tap on posts I normally wouldn’t have an interest in (I might have a budding pencil attraction).

So, how does it work? At launch, Nibbler pulls in RSS feeds from two dozen pen, paper, and pencil blogs. Each of these RSS subscriptions can be toggled on or off, so if you are just sick and tired of looking at Ed Jelley’s beautiful photography (I do not think this is humanly possible), you don’t have to.

With all of the RSS posts loaded, a nice visual feeds shows off each post’s leading image and title. Tapping on a post opens up a full web view of the article, showing off the complete website. If the user prefers, Safari’s Reader Mode can be enabled, which simplifies the page, showing just the article text and allowing the user to set a preferred font and background color.

Apart from Reader View and subscription preferences, there are also themes and alternate app icons! Colorful, ink inspired themes and icons (a dark mode too)! I’m a big fan of apps with dark modes and the ability to make small tweaks. When making Nibbler, I knew there had to be a variety of themes and alternate icons to pick from. Also, as a pen person (dare I say addict?), I switch inks out of my pens depending other the weather, of course I’m going to want to change the way my app looks. The themes are based off of some of my favorite inks, and I will be adding more in the future. All current and future themes/icons are unlockable via the Nibbler’s only in-app purchase for $1.99 (I need a way to feed my habit, okay?)

I’m fairly new to iOS development and Nibbler is my first real app in the App Store. I’m a little nervous putting it out there. It’s something I’ve put dozens of hours into. I hope that people will like it and find it useful, discovering new pen blogs and enjoying the way the app works. I’ve loved working on this app, and could continue pushing out the release forever, continually adding new features, telling myself that it’s not quite ready yet, but I think it’s at a good state for a 1.0. If you find any issues, have an idea for a feature, or would like an additional blog added to the feed, send me an email or reach out to me on Twitter.

You can find Nibbler on the App Store.

Core ML and Vision for iOS

Apple showed off some spectacular tech demos throughout this year’s WWDC, particularly, those related to ARKit and it’s base framework Core ML. I’ve only dabbled with basic machine learning in the past (K Nearest Neighbor barely counts), and was intrigued at the amount of abstraction Apple provides in implementing computer vision, natural language processing, and working with custom models. After watching the Introducing Core ML session, I decided to get my hands dirty and create a little image recognition app fueled by machine learning.

Starting off was easy enough, after setting up a basic single page application with an UIImageView, a couple of labels, and a set of buttons, I picked a demo model (I went with Inception V3), and dragged it into Xcode 9. With the model in the project, all that was left was to reference the model, and have it make a prediction based on an image the user provides.

Once the model has been imported, clicking on the file in Xcode 9 will reveal details specific to the model, including what inputs and outputs. In the case of Inception V3, the model expects an image and will return a dictionary of labels and probabilities.

Using the model

let model = try VNCoreMLModel(for: Inceptionv3().model)
let request = VNCoreMLRequest(model: model, completionHandler: displayPredictions)
let handler = VNImageRequestHandler(cgImage: image.cgImage!)
try handler.perform([request])

These two code blocks are where the magic happens. Above, I referenced the model I imported, specify a completion handler, provide the image, and initiate the prediction.

Viewing predictions

func displayPredictions(request: VNRequest, error: Error?) {
   // Make sure we have a result
   guard let results = request.results as? [VNClassificationObservation]
   else { fatalError("Bad prediction") }

   // Sort results by confidence
   results.sorted(by: {$0.confidence > $1.confidence})

   // Show prediction results
   print("\(results[0].identifier) - \(results[0].confidence)%")
   print("\(results[1].identifier) - \(results[1].confidence)%")
   print("\(results[2].identifier) - \(results[2].confidence)%")

When the prediction request completes, the completion handler above is called, handling the results. I did a simple sort based on the confidence percentage provided by the model and displayed the top three results.

🤖 Success: 98.32451%

Pretty dang easy. If you’d like to take a look at my example project, head on on over to GitHub.

Pastebot Filters

On a recent episode of The Talk Show, John Gruber mentioned Pastebot, a clipboard manager from the good folks at Tapbots. I decided to give the app a try and have been impressed by both its ease of use and expandability. Not only does Pastebot maintain a history of your Mac’s clipboard, it also has a handy ‘Filters’ feature, allowing you modify text on the fly.

The clipboard

For a simple example, I have created a filter, that will convert a plaintext URL, https://austintooley.com into Markdown. All I need to do is copy a URL, and then invoke Pastebot (Shift + Cmd + V), select the filter icon next to the clipboard item, apply the correct filter, and voilà, [Link Text](https://austintooley.com).

A preview of how the filter effects the clipping

If you’re feeling really dangerous, Pastebot also allows Shell scripts to be run as a part of filters, allowing for powerful operations to be performed on paste. A great example of this is a default filter which uses a script to convert Markdown to HTML.

If you’re interested, I have made available a few simple Pastebot filters for creating Markdown content: lists, blockquotes, URL’s and images. You can find them here.

Passwords: The Single Point of Failure

Passwords are ubiquitous with the use of a computer. They are used to access the computer itself, to protect files, access bank accounts, social media, online shopping sites, and so much more. While passwords have been used in computer systems since at least 1961, they are prone to compromise. This paper will give a brief overview of the history surrounding passwords, their origins in computing, the differences between strong and weak passwords, as well as various technological and social attacks employed to obtain these ubiquitous credentials.


The use of passwords to hide or conceal information have been used long before the advent of computers. Indeed, passwords has been documented throughout the history of mankind. Dating back to 1,900 B.C., Egyptians engraved encrypted text on tombs, detailing the life of those who lied within.1 In Ancient Rome soldiers would use a watchword, which was used in the process of relieving a watchman from his duties. As a soldier was relieved of post, the new watch would handover a wooden tablet, on which the watchword would be inscribed. The relived soldier would deliver the engraved tablet to his superior, who would verify that each soldier was authentic and had completed his duty.2 The use of passwords was not limited to ancient armies. During World War II, American paratroopers used a password handshake to identify one-another as allies. As troops approached, the initial keyword of “flash” would be shouted. If the second party responded with the keyword “thunder”, it was assumed that the approaching party was friendly.3

The first documented use of passwords in a computer system was that of the Compatible Time Sharing System (CTSS) developed by MIT in 1961. The system was used to limit the amount of time each user could log on a computer per week. A year later, the first documented case of computer password theft occurred. Allan Scherr, a graduate student working on his PhD, desiring more than the allotted four hour weekly ration, located and printed the file containing all passwords for the system. Upon obtaining the list of passwords, Scherr was then able to log as much time he desired, using a new password every four hours.4

In the Digital Age, passwords are used by far more than just members of the military and academic researchers. With the advent of the internet the average citizen of the web has around 25 different accounts utilizing passwords.5 These passwords protect everything from public library access to credit card numbers, a persons geo-location, bank information, social influence, medical history, and personal media.

In Practice

The majority of modern password practices were established in 1985 by the Department of Defense (DoD). William Chiswick, a security researcher, comments that the advice given DoD document, Password Management Guideline, “was good at the time, and much of it still holds up, but many of our password aphorisms come from dated assumptions about threats and technology.”6 He notes that the guideline was created in a time when punchcards were still in popular use as well as remote serial terminals; the World Wide Web and the personal computer had not yet blossomed into the powerful forces they would become.

According to Chiswick, modern passwords are most vulnerable to compromise due to several central components of an authentication system as set fourth by the DoD. Firstly, “Passwords should be machine-generated rather than user-created.”7 The reasoning behind machine generated passwords (random character strings, example: “8uV^Qd)32l!”), is that they pose a much more difficult task to break, though not impossible (more on this further on). Pair difficult passwords with the additional advice that, “Users must remember their passwords,” and “A user’s password must be changed periodically.” While sound advice, Chiswick and others have come to the conclusion that this trio of constraints are near impossible for most human users to follow. This is especially true when applied to the modern user who maintains around 25 passwords, each of which should be unique. In a study held over 30 years ago, researchers Morris and Thompson confirmed that passwords were indeed a “weak point in information system’s security. They found out that majority of users’ passwords (87% of them) were short, contained only lowercase letters or digits or were easily found in dictionaries.”

While the problem of memorable unique difficult passwords is challenging, there are modern guides to assist in their creation. Before understanding what currently makes a “strong” password, it is necessary to understand which types passwords are classified as weak. Weak passwords are those that succumb to attacks most easily. These are passwords consisting dictionary words, phrases, or other common variants.8 Examples the most easily (and common) passwords are “password”, “123456”, “qwerty”, and “letmein”.9

In the past, advice has dictated that adding a suffix, prefix, or replacing alphabetic characters with numbers or symbols would substantially hinder a dictionary attack (such as “BandGeek321” or “p2$$w0rd”). Unfortunately, this hasn’t been effective for years as dictionaries containing common combinations and substitutions. The subsequent advice, popularly touted by XKCD and others was to string random words together, as detailed in the following comic:
XKCD Password Strength Comic

While more effective than the previous schema, this too is unfortunately no longer a good guide for the creation of a strong, memorable password. Attackers have been able to incorporate this method into their attacks tools. It also has been discovered “that passphrase users initially experienced a significantly higher number of login failures due to typographical errors.”

Currently, companies such as Microsoft and security experts such as Bruce Schneier recommend a password scheme which combines aspects of the two previous. The recommendation is to take a sentence or phrase and create an acronym from it, creating a string of text similar to a computer generated password.10 One example given by Microsoft is that the phrase “My son’s birthday is 12 December, 2004” could be transformed into “Msbi12/Dec,4”. An similar example by Schneier uses the phrase “this little piggy went to the market”, which could become “tlpWENT2m”.

Technology Attacks

The most common attack model used by password crackers happens offline, with a leaked password dump. These dumps are generally encrypted (in the form of hashed text), to which the attacker will seek to decrypt (to plaintext). This is done through either a brute force, dictionary, or hybrid attack. Though different in implementation, the success of each type of attack relies heavily on two factors: power and efficiency. Power, the amount of computations per second greatly determines the speed at which a cracking application can crunch through data. With the advent of multicore CPU’s and GPU’s, power has become a commodity in the cracking world. Efficiency on the other hand, is reliant on the creativity of the designer of the cracking program. Schneier explains that it is the ability to “guess cleverly”.

In the brute force method, an attacker would compute every possible permutation for each character of a password: upper and lower case letters, symbols, and numbers. “Whenever a computed hash, for which the attacker knows the input, matches one of the hashes in the stolen set, that user’s password is revealed. Clearly this approach requires abundant processing power and a lot of time.”11

The second, and more effective method, is the dictionary attack. In this technique, the attacker will again compute hashes to try and match those of the of the password dump, but bases the hashes off of lists of potential passwords. These lists may consist of English and foreign dictionaries, common passwords (such as “password”). According to security researcher Mark Burnett, a whopping 40% of all passwords appear in a list of the top 100 most common passwords. As expected, the dictionary attack is much more efficient than brute force and can be executed quickly.

The third attack, hybrid, is as the name denotes, a combination of both brute force and dictionary. “[The] hybrid approach involving permutations of dictionary words can crack passwords that meet the bare minimum of otherwise complex password policies. ‘password1’ or ‘letmein!’ and ‘s3cur3’ are such examples.”

As mentioned, both power and efficiency play a large role in the effectiveness of password cracking. The previously mentioned suggestion from the DoD to change a password periodically is to combat the possibility that if leaked, the password would be changed before a program could crack the encrypted credentials. Specifically, the goal was for a strong password (9 characters of only uppercase characters) to “resist a year’s worth of dictionary attacks with a cracking probability of 10-6.” If the same standard for a “strong” password were to be applied today, Cheswick claims that it would need to be changed every 31 milliseconds to resist compromise. It’s no surprise with current hardware that there have been reports of cracking software churning through 8 million password permutations per second.

Human Factor

Technical aspects aside, there is another vector of attack which has become more prominent with the advent of cloud services and social networks: social engineering. Through Google, Facebook, and several other services, attackers are able to gain a range of information on a target such as name, birthdate, birthplace, address, family member’s names, and so on. With this information, attackers can then proceed to use a service’s “forgot password” system to gain entry to a service. Alternatively, they may call a services customer support, acting as their target, gaming the system with the information gained from their digital sleuthing. For example, the only information necessary to gain access to an AOL account is the name and city where the target was born, which can be gained through Google or similar service.

The damage caused by such attacks can be devastating. Upon suffering an attack on several of his own cloud accounts, Mat Honan of Wired was able to contact and interview his attacker as well as several security experts. He was able to piece together the series of events which lead to his Amazon, Twitter, Gmail, and iCloud account being compromised within an hour:

“This summer, hackers destroyed my entire digital life in the span of an hour. My Apple, Twitter, and Gmail passwords were all robust—seven, 10, and 19 characters, respectively, all alphanumeric, some with symbols thrown in as well—but the three accounts were linked, so once the hackers had conned their way into one, they had them all. They really just wanted my Twitter handle: @mat. As a three-letter username, it’s considered prestigious. And to delay me from getting it back, they used my Apple account to wipe every one of my devices, my iPhone and iPad and MacBook, deleting all my messages and documents and every picture I’d ever taken of my 18-month-old daughter.”12


Passwords are as old as humanity and so is the art of cracking them. While they have had their place throughout history and especially throughout computer history, they were designed for different systems than those used today. There weakness lies mostly in users. It is difficult to remember complex, unique, ever changing passwords for dozens of services. The advance of computers has increased the speed at which passwords can be cracked or guessed via software. The rise of personal information on the web has given way to attackers finding alternate routes to gaining access to accounts. In his article on the need for an alternative, Honan suggests the following:
The ultimate problem with the password is that it’s a single point of failure, open to many avenues of attack. We can’t possibly have a password-based security system that’s memorable enough to allow mobile logins, nimble enough to vary from site to site, convenient enough to be easily reset, and yet also secure against brute-force hacking. But today that’s exactly what we’re banking on.”