Farewell Automattic

After 9 years, 2 months, and 23 days, today is my last day at Automattic.

I owe a lot to WordPress, Automattic, VIP, and now WooCommerce. I initially learned PHP as a teenager by reading the WordPress source code and writing WordPress plugins and themes. Building websites was one of the very first things that got me interested in Computer Science.

I still have an email from Andy Skelton dated April 3, 2006. I was having problems with the new sidebar widgets feature and without knowing what else to do, emailed Matt for help. Andy replied with a patch that fixed the problem. I remember wanting to learn how to fix problems like that for myself. I was 15 at the time. A little over 14 years later, I ended up working on the same team as Andy when he switched to VIP Systems.

I applied to be an intern with (at the time) the WordPress.com VIP team after seeing Matt announce it on Twitter.

Sometimes I think about how big of an impact that moment had on my life. It’s hard to imagine how much different the last 10 years would have been for me otherwise.

It’s weird leaving a company after 10 years. I remember Matt telling me that I was the 200th person Automattic had hired. I think there were something like 180 full time employees back then. Now there are over 2,000 Automatticans. As I’ve been reflecting on some of the meetups and projects I’ve worked on over the years, some of those early memories feel like they’re from a different company.

On the other hand, it’s striking how similar the culture still is. We still use P2s (internal blogs) for communication. There’s still a small team of Systems Engineers running most of the infrastructure, including one of the fastest DNS hosts on the internet. One of the biggest changes (other than the number of people) is that most teams switched from IRC to Slack years ago. 🙂

Automattic is made up of tons of smart, fun, kind people who are trying to make the web a better place. I’m so happy to have been a part of it.

Wire 2.0

Wire started as a sabbatical project a little over three years ago. I wanted an RSS reader that didn’t require an account and displayed articles in web views instead of the traditional method of styling article content in a “reader” view. People spend a lot of time on their websites and I think reader apps should respect that.

Wire 2.0 is a complete rewrite using SwiftUI and an improved offline caching system. I’ve been using versions of this new app for quite a while, but until iOS 15 it wasn’t possible to build some of the features I wanted with SwiftUI.

Syncing between devices also works much better than before. I love being able to read articles on my phone and iPad and having that state all kept in sync. If you’re signed into your iCloud account, it just works.

If you try it, let me know what you think. And please rate and review the app on the App Store 🙃

Strong Password Enforcement

Modern web applications have a responsibility to prevent their users from using easily compromised passwords. I would also say that it’s in their best interest, although it’s certainly a trade off. Most people still don’t use password managers, so stricter requirements will lead to some people losing access to their accounts. Still though, forcing people to use even moderately strong passwords will help prevent account takeovers and all the headaches that go along with them.

I’ve compiled a list of some things I think all apps should do to enforce strong passwords. The thresholds you pick will depend on the security requirements for your system.

Rate Limits

Login attempts should be rate limited. While not strictly related to enforcing strong passwords, rate limits will enhance the effectiveness of the other techniques. Indeed, rate limiting is identified as an OWASP Top 10 security risk for APIs.

Minimum Length

Checking the password length is primarily an optimization for the next steps. I don’t believe in complex password rules, but it goes without saying that short passwords are easy to guess. Length is a cheap thing to check before we get into the more complex analysis.

Check Strength

Instead of complex password rules, we can use an algorithm like zxcvbn to evaluate the passwords. The idea here is to forgo annoying rules and instead focus on the complexity of the password itself. This has shown to be more user friendly and more secure at the same time.

Bonus: Pwned Passwords

Finally, you may want to block passwords that have been found in publicly exposed password lists. Troy Hunt’s Pwned Password API makes this very easy. There are some drawbacks of this that might be a none started for some applications — namely, your password change process now relies on a third party API. It’s also debatable whether globally blocking nearly a billion passwords is useful. Luckily, the API includes information about how many times a given password has been seen in breaches, so it’s possible to fine tune this as well.

Happy Birthday Frank

Our dog, Frank, is two years old today. According to Embark, Frank is a Lab, Catahoula, Fox Hound, Great Pyrenees, Boxer, Supermutt. We tell everyone he is a Lab-Catahoula because he is mostly a Lab, but looks and acts like a Catahoula Leopard Dog.

We adopted Frank in March of 2020 through Fetch Wisconsin Rescue when he was almost four months old. He weighed 25 pounds at the time. We don’t know very much about his first few months except that he was born in Louisiana and came to Wisconsin just under two week before we met him. (Now he’s 75 pounds and I try not to pick him up as much.)

His favorite things are going on adventures, being chased by other dog friends, and trying to steal sips of coffee.

We got Frank at the perfect time. Shortly after we adopted him, the rescue had to stop taking new applications because apparently everyone had the same idea back then. He’s been a great pandemic companion.

Automatically hide and show menu bar in full screen

I use full screen mode on my MacBook pretty frequently. Swiping back and forth between full screen apps has always been a workflow that just comes naturally to me. One downside is that I’ve always had to move my mouse to the top of the screen to show the menu bar in order to check the current time.

On the new MacBook Pros, full screen mode hides the notch by default. Where the menu bar would be is just black. You can have the menu bar show even in full screen mode though. I haven’t found a way to conditionally show the menu bar only on the MacBook display, but on my external displays there is enough screen real estate that I think I prefer having the menu bar always visible anyway.

From the command line:

defaults write NSGlobalDomain AppleMenuBarVisibleInFullscreen -int 1

Or from System Preferences, Dock → Menu Bar: