Coding in a Walled Garden: Adjusting to a More Secure Work Environment

Every quarter, I change how I work. I look at my daily driver tools and find alternatives. 

Since I write a lot of code, that means swapping editors and terminals constantly. I’ve burned through most of the JetBrains options. I’ve coded in Visual Studio, Cloud 9 and even Vim (that one, years ago, required me to read several books in advance). For shells, I’ve rotated between options like bash, zsh and (recently) Cloud Shell. 

“Intelligence is the ability to adapt to change.” – Stephan Hawking‍

Every quarter, it’s painful. I uninstall what I had - forgetting all the keyboard shortcuts that made work comfortable - and start over. But what I gain is an understanding of how tools work. I get to experience good UX vs bad; good architectural decisions vs bad. I even get to change my habits, which forces me back to the primitives of what I’m trying to accomplish. There is no slipping into bad habits when there is no time to build them in the first place. 

Everything becomes about impact.

For years, I wanted to switch my computer out altogether for a “secure device”. As a security professional, especially one coming from the offensive side, it has been apparent that mobile devices are more secure by design. The sandboxing of applications, absence of software from unapproved vendors and the general reduction in surface area means less avenues for attackers.

In fact, CISA offers the following guidance to small businesses:

‍While all operating system vendors work to continuously improve the security of their products, two stand out as being “secure by design,” specifically, Chromebooks and iOS devices like iPads.

‍Some organizations have migrated some or all their staff to use Chromebooks and iPads. As a result, they have removed a great deal of “attack surface,” which in turn makes it much harder for attackers to get a foothold. Even if an attacker were able to find a foothold on those systems as part of a ransomware attack, the data primarily lives in a secure cloud service, reducing the severity of the attack.

With significant advancements in tablet technology happening in 2022, I decided I would trade my MacBook Air (latest M2 model) for an iPad Pro 11 (also M2). This story describes how I went about the switch, what worked vs what didn’t and most importantly – how it is changing my approach to work.

The Prelude

I decided to start my challenge on a Monday. I would give myself a full week to continue using my laptop but switch to only cloud-based applications. This would be a nice practice run for working full-time on an iPad while maintaining the safety net of a full computer. If I can master the SaaS tools while on a familiar device, switching hardware later should have less friction.

I started by removing my desktop code editors (JetBrains and Visual Studio) and enabling Codespaces in my GitHub account. This will probably cost $20-$30 a month for my level of usage. It is tough to estimate though, so I’ll need to keep an eye on that.

Codespaces seems intuitive enough. Creating a new “space” required me to select an existing repository and a few settings, then a container spun up and looked a lot like the Visual Studio I had on my desktop.

It was my first time using the tool, so I took a few hours to familiarize myself with the knobs and levers. Nothing jumped out as particularly good or bad.

In another tab, I launched AWS Cloud Shell and went through the same rounds. This is a pretty handy tool, as it was preconfigured with my credentials and provided me with a 1GB cache per region - along with full encapsulation of my work in the region. After a few hours - and a Safari Books tutorial on Cloud Shell - I now think it’s one of the most underused AWS utilities.

I tend to live inside code editors and terminals on my Air so I have no other daily drivers to practice on this week.

Day 1: Prep

Six days later, it was time to start. It was a Saturday when I shut down my laptop and fired up an 11 inch iPad Pro (M2, running iPad OS 16.4). Those were the minimum specs I thought I could get away with, so I could use Stage Manager with the new “more space” zoom option. 

Stage Manager is what makes this all possible. Before iPad version 16, you could plug into a larger monitor but the scaling was absurdly off. It would vary monitor-to-monitor but in my experience you’d either have to accept a very zoomed-in view or that your monitor wouldn’t use the full screen. Switching to the “more space” option in the display settings will auto-configure the correct resolution.

After turning the iPad on, I spent the first hour syncing it to my Apple account, doing a system update and playing with the display settings when plugged in or out of my 32-inch Samsung monitor. Everything looked as it did on my Air. There is one extra perk: the face unlock of the iPad had noticeably less friction than the fingerprint scanner before (I had to reach across my desk).

In my pre-planning, I noticed that the MacBook Air M2 has a 17 hour battery life and the iPad Pro only 10 hours. This worried me a bit because I like making it a full day on a single charge - something I’ve gotten used to on the Air.

To combat this, I flipped the battery to “low power usage” and turned off “find my device” (the latter being a known battery drain). One initial finding is that I could greatly dim my iPad screen while plugged into an external monitor, which I anticipated would increase my battery time as well. 

I wrapped up my day by attaching my Logitech Master Keys (keyboard) and MX mouse via bluetooth and configuring the mouse speed. I opted to use these peripherals because the magic keyboard options at the Apple store all felt too constricted. I know this will hurt my ability to code on airplanes but I’ll tackle that challenge later.

Day 2: Coding

The next day, Sunday, I settled into my new device. I rested my iPad on a WeatherTech tablet stand, plugged it into my external monitor and selected a JIRA ticket from the backlog.

I pulled up Codespaces in the browser and I started to write, debug and iterate like I usually do. Everything felt surprisingly normal. 

One oddity is the cursor, which looks like a big circle vs a clicker. Not a bad thing, just different. One pleasant surprise is Stage Manager, which offers what feels like a second dock (on the left side of the screen) for switching views on the fly.

After a few hours, the only con I’ve noticed is the Codespaces container I’m using requires a refresh - which takes 10 seconds - but only if I’ve spent more than a minute or so on another tab or inside another app. I think this is due to the background refresh being disabled while in low battery mode, so I re-enabled the regular setting and coded for a few more hours. Problem solved (I think). However, my battery drained faster in regular mode so I’ll need to consider how to balance this finding.

Doing all my normal “git work” - from creating new repositories to pushing branches - worked fine. Another finding I noticed is that the Codespaces “dotfiles” feature, which saves my configurations into the container when it spins up, is a must-have for me. 

While inside my container, I also installed packages (like Python 3.9) and deployed Lambda functions to AWS with no problems. This concept of ephemeral development containers with an embedded terminal is feeling quite natural.

‍Day 3: Work

So far, I’ve exercised my iPad heavily with code and infrastructure work (writing and deploying) but I haven’t done a normal work day. For me, a normal work day consists of coding (yea!), meetings on Zoom, heavy Slack chatter (plus ad-hoc huddles) and constant switching between documents, screen sharing and product demos.

Monday is typically my heaviest, so it should flush out any major concerns with my new iPad “workstation”. 

Taking my normal meetings, over Slack huddles (no video) and Zoom (video), I noticed the former worked out of box but the latter had no audio by default. I needed to hop into settings and tinker with the settings to enable this - forcing me to rejoin my first Zoom call. 

My first time screen sharing, I noticed the share request defaults to the iPad screen, which I’ll never want. You can switch share screens easily enough however. 

Bouncing between apps takes a little getting used to, as Stage Manager only displays one at a time - but this is just a habit for me to break. It is possible to show two apps at once but I think it’s better for my focus if I get used to seeing one thing at a time. Everything else is slick. 

The only con I’ve come across - that I haven’t solved for yet - is the screen dims too quickly. If I’m on battery-saving mode, the screen will dim after 30 seconds. If not, I can set the time to something longer. However, moving my mouse around the screen does not count as activity – I have to click on something for it to register as an action.

What I noticed by the end of the day, is I started allowing my screen to go dark during Slack huddles (Zoom video keeps the screen active). Talking to a dark monitor was different at first but again, I think this is a habit I can break and build back up.

I made it through a full 8 hour day before needing to recharge, which was pretty good for my first attempt. I think with some creative tinkering I can improve this number. I’ll likely aim to swap between battery-saver and regular mode on the regular.

Day 4: Travel

Here it was, my biggest obstacle. Traveling. 

I had a planned trip to HackSpaceCon - a first-of-its kind public conference about hacking, held at the Kennedy Space Center. This would require a trip from Maryland to Florida, midweek, requiring me to keep tabs on all things work as if I was still in the office.

I typically code heavily on airplanes, which is an immediate nonstarter because Codespaces requires a stable internet connection (and I’m usually too cheap to pay for WiFi). That’s ok, because I could swap to writing offline (Google Docs) documentation instead. 

Ergonomics turned out to be the biggest hitch in my plan. 

Practicing ahead of the trip, I undocked my iPad and wandered around my house, trying out different scenarios: iPad on my lap? Too unstable. Put it on a book for stability? Better, but I don’t want to lug an external keyboard, a stand and a book around. 

It became clear that I’m not going to break my habit of working in abnormal spaces, such as airplanes and couches - and laptops thrive in these environments.

I went to a local Apple store and toyed with the new magic keyboard, which has an Air-like feel. The keyboard had nice travel and, when paired with a 12.9 inch tablet, actually felt close to an Air - ergonomically speaking. It was a little top-heavy, in comparison, but the total weight felt about the same.

Summary

After a 2-week trial of prep and actual hands-on-iPad, I’ve concluded: it is possible, even desirable, for a software/security engineer like myself to work exclusively on a tablet.

There are a few habits to break, and you (or your company) must be willing to pay higher subscription fees for cloud services - but your net result will be a more secure workflow. 

From a single-device standpoint, the sandboxing of applications, blocking of arbitrary software installs and focus on cloud-only options makes the iPad a (close to) impenetrable option. Translating this to a full organization, the reduction in total surface area would be disruptive. IT costs would cut to a fraction (EDR, AV, ransomware protection, etc), time troubleshooting devices would slow to a trickle and fewer security incidents would occur.

What’s my takeaway? 

I’m now planning an overhaul of the internal security policies here at Prelude. Check back for updates on where we end up by the end of 2023. In the meantime, read up on our Verified Security Rules.