#125 What is a Sandbox?

In software, sandboxes are all about isolation. In this episode, we'll explain why isolation is important for security, privacy, and testing. Welcome to COPEC Explain Software, the podcast where we make computing intelligible.

This week we're talking about sandboxes. They're pretty common, right?

You use a sandbox every day, and you might not even realize it. When you open a web browser, you're in a sandboxed environment. When you use an app on your smartphone, you're in a sandboxed environment. And if you're a software developer, you probably do your testing in a sandboxed environment. We'll talk about sandboxes today from both a security perspective, a privacy perspective, and also a testing perspective.

So where should we start?

Well, I think it's worth mentioning that sandboxes are a relatively recent phenomenon, at least in the realm of personal computing. If you are using Windows 95 in the mid 1990s or macOS Eight, you were not in any kind of sandboxed environment when you were running an app. Instead, you were in the Wild West. One app could mess around with the resources of another app. One app could truly affect how another app appears. There were all kinds of cool modification type apps that could change the appearance of the whole system, make the Windows look different, make the widgets look different. That's not possible in a personal computing operating system today. So for the reasons that we're going to go into today, security and privacy, sandboxes have been implemented across modern Windows, macOS, iOS, Android, and many server operating systems as well.

Maybe we should start with a definition. What is a sandbox?

You'll find different definitions online, but I think the unifying factor is the idea of isolation. A sandboxed environment is isolated from the rest of the system so that the program that is running within the sandboxed environment cannot affect the other programs running on the system or their data.

So why is that good for security?

Let's say you have a program that has some kind of vulnerability. Perhaps there's a flaw that allows a hacker to gain access to the system. If the program is truly in an isolated environment, they're only going to get access to the resources in that isolated environment, such as active memory, such as disk. The file system. Maybe only a part of the file system is available to each isolated process, such as network traffic coming into the system. Only network traffic specifically relevant to the program in the isolated environment will be accessible, such as hardware. We don't want just any program to be able to use any piece of hardware. If a program has no reason to use your camera, should it even have access to the camera? Because then if it has a security vulnerability, the hacker is going to gain access to the camera as well, or the virus is going to gain access to the camera as well. So by keeping a process completely isolated, we limit the attack surface on the.

System so that sounds like a really good thing.

Yeah, and that's why sandboxes have become so ubiquitous. So sandboxes exist in every web app you use. Your web browser creates a little sandbox for each web app. A web app, by default, does not have the privilege to write anywhere in the file system. You can explicitly say, well, I want to download this file from this web app and put it into a specific part of the file system. But a web app cannot, on its own, just go and write to your Documents folder, for example. It can't on its own without your permission, and you giving it that privilege. Just access a certain piece of hardware, like your camera or your microphone. This is also true on both iOS and Android. When you download an app and you run it, it gets its own sandboxed environment, including its own part of the file system. So let's say you download a word processing app. It can't go and edit the files in your Notetaking app. They're in their own space. They have their own separate section of the file system and also their own separate set of privileges to all the different pieces of hardware network resources, memory, access as well. This also means that when we remove one app, we don't affect any of the other apps on the system. Isolation is a really powerful concept.

All right, so we know sandbox helps keeps us secure. What about how it protects our privacy?

The privacy really follows from the security by making sure that every resource that we want to access requires privileges. It enables us to, at a fine grained level, limit the ability for an app to go beyond its intended purpose. Let me give you an example. Perhaps you download a new social network and it wants to spread itself virally. Of course, the creators of that social network have an incentive to just go dig through your contacts and automatically send an invite to all of them by email or other means, or even just to harvest your contacts so that they know who your friends are that are already on the network. But maybe you don't want that. Because of the isolation of apps in modern sandboxes on modern smartphones, we don't give the app developer the ability to just automatically go and grab all your contacts. Believe it or not, we did in early versions of mobile operating systems. And while this might be troublesome for the app developer who wants to have their app go viral for you, it gives you peace of mind that you know, you will have had to specifically have allowed that app that access, because maybe you're just testing it out. Maybe you don't want all your friends to know that you're using that app. Maybe you want to just have some separation of your work life and your private life. Whatever the reason, it's the powers in your hands to keep that information private. Thanks to the isolation and the requirement of escalated privileges in order to utilize those additional resources on your device. So they really go hand in hand. They're not the same thing. Security and privacy are not the same thing, but they go hand in hand with one another. And without having these isolated sandbox environments for every app, we can't really have the fine grained control of what they can and can't access, and therefore when they can and can't invade your privacy.

Let's shift gears. As a developer, a sandbox is a really great tool for testing.

That's right. And it again comes down to isolation. When you're working on a new app, you often create two different environments a testing or development environment and a production environment. When you have a final version of an app that you're ready to release to the world, we say it goes into production. At that stage, you don't want anything you're still working on to possibly affect the production environment. Let's say that some new feature you're creating actually introduces some bugs until you've had a chance to iron them out, test out the new version, the new feature. You don't want that going and affecting your users. So it's very common for software developers to have two separate environments, one that actually touches end users and one that's only used internally or amongst alpha and beta testers. This isolation stops a lot of bugs during development from affecting end users. A lot of companies that provide APIs will also provide what's called a sandbox environment for their API. For example, if you've ever used Stripe to add financial transactions to your app, maybe you want to support credit card payments. They have a sandbox environment for when you're first testing. Why? When you're testing your app and developing it, you don't want to be doing transactions with real credit cards. What if you make a mistake and you're charged $1,000 instead of $100 or something like that? Right. Or if you just don't want to be using money when you're testing things out. So the testing environment, the sandbox environment, will be almost identical in functionality to the production environment, but it just will lack the use of real money that makes a lot of sense and reduces the surface area of errors going into actual financial transactions. If you've ever used Apple's inapp purchase system as a developer, same thing. You don't test out inapp purchases in the production environment where actual users and money could be utilized. Instead, you test it out in a testing sandbox where if anything goes wrong, it's not going to actually affect anyone's wallets nor their ability to utilize all the services in the app.

Sandboxes sound pretty great. Why wouldn't you use one?

They are pretty great, and there's a reason they've become so ubiquitous. They really are critical for privacy, security, and software development testing. But there are a couple situations where there can be some downsides. One is there are certain classes of apps that actually need a lot of the privileges that sandboxes sometimes restrict. Let me give you an example. There's an app that I use sometimes to record podcasts called Audio Hijack. It's a mac app. Apps that are distributed through Apple's Mac App Store are all sandboxed, and they don't have full privileges on the system in the way that an app that's distributed outside of the Mac App Store does. Audio Hijack needs to do some low level access. It needs to directly reroute audio at almost the driver level on your Mac. And so therefore it can't do that in a sandbox environment, because in the sandbox environment that Mac App Store apps have to run in, they can't actually get that low level access. So there are certain kinds of apps that won't run within a sandbox because they explicitly need that full access. The other reason sometimes folks run apps outside of a sandbox is for convenience. They just don't want to have to click a million permission dialogues every time they want to do something in an app. Unfortunately, that's not a great reason people still do it. Back in the older days, I used to see people regularly set themselves up as the super user on their system, whether that was an early version of macOS Ten or Linux. Users sometimes still do that, and that gives you absolute privileges and allows you to bypass any of the restrictions put in place for any app due to sandboxes. But at the same time, that escalation of privileges can be dangerous because now you can accidentally do literally anything on your system. And a lot of these restrictions are in place are actually to protect you or to protect you from malicious software that you might have accidentally installed. So the two reasons that we do sometimes go beyond sandboxes. One is because we have to to do the type of work that we want to do, the sandbox environment is too limited. And two, for convenience. But the second reason is not really a great one. On the other hand, there's a balance to be struck between how much we limit the user's freedom to do what they want and convenience, right? Nobody wants to be clicking through a million dialog boxes every time they use an app. So generally we relax some sandbox privileges after a user has said, hey, I explicitly, when I use this app, want to relax these privileges. And more recent versions of macOS and Windows are pretty good about that. Thanks for listening to us. We'll see you again in two weeks. Want to remind everybody to follow us on your podcast player of choice and also to leave us a review if you enjoy the podcast. And we always take suggestions about new episode ideas. We've actually been doing a bunch that our listeners have been recommending recently. Rebecca how can people get in touch with us on X?

We're at COPEC explains K-O-P-E-C-E-X-P-L-A-I-N-S.

Thanks for listening, and we'll see you in two weeks.

Bye. Close.