BBEdit 12.6 to Return to the Mac App Store
Bare Bones Software (tweet, MacRumors):
BBEdit is now a sandboxed application.
[…]
Without unrestricted access to your files and folders, many of BBEdit’s most useful features, from the basic to the most powerful, won’t work at all; or they may misbehave in unexpected ways. At the very least, this hinders your ability to work done.
In order to resolve this fundamental conflict between security and usability, we have devised a solution in which BBEdit requests that you permit it the same sort of access to your files and folders that would be available to a non-sandboxed version.
For this reason, the first time you start BBEdit, it will prompt you to allow this access. The prompt will not be repeated; so if you decline to allow this access and later reconsider, go to the Application preferences, and click on the “Allow” button in the “Sandbox Access” section.
It saves a security-scoped bookmark that allows access to every volume on your Mac.
BBEdit being able to return to the Mac App Store is great news for customers (modulo bugs) and for Bare Bones, but I’m not sure what it means for the store in general. Although there has finally been some progress, this feels like Apple giving up. They can’t or don’t want to really fix the sandbox to work well with pro apps, but they do want them to be in the store, so they’ll just let them ask for blanket permissions. BBEdit gets to be in the store, and Apple gets to say that everything (except Xcode) is sandboxed, even though it’s kind of security theater.
This doesn’t bother me with respect to BBEdit. I’ve been running it unsandboxed for almost 25 years, so I trust the app, and this is not a decrease in security.
But what about other apps? Is any app now allowed to request persistent access to the entire file system? Technically, this has been possible since OS X 10.7, but few if any apps did it. I think everyone assumed it would lead to rejection. Has the policy changed? Or does App Review decide this on a case-by-case basis? How intrusive do the folder access prompts have to be before you can just get access to everything at once?
I don’t think users really understand that this is what clicking the button in an open panel is doing. And there’s no way to see which applications are maintaining access to which folders. It’s just not very clear what’s going on. Apple is kind of shifting the blame if anything bad happens. It can’t be their fault because the user “consented.”
More security-related changes:
When running on macOS 10.14.1 or later, BBEdit now uses built-in OS support for performing operations which require privilege escalation, namely authenticated saves and (if escalation is necessary) installation of the command-line tools.
[…]
AppleScripts are now run in a separate process, which means that any previous differences in scripting behavior as the result of running a script within BBEdit or from the Script Editor should be a thing of the past.
[…]
If BBEdit can’t send save or close notifications because you previously denied it permission to send Apple Events to the application which needs them (usually a file transfer client from which you used “Edit in BBEdit”), you’ll now get an alert to this effect; the help button in the alert takes you to a page which explains how to fix things.
My understanding is that “Edit in BBEdit” can no longer work with arbitrary apps, only those that have been pre-listed in BBEdit’s com.apple.security.temporary-exception.apple-events entitlement. Those are the only apps that it can send Apple events to. It’s kind of a drag. I once added “Edit in BBEdit” support to an app and didn’t need to get permission from anyone. (The app was Apple Mail, and said support has long since been broken by Mail’s sandboxing blocking Apple events.)
At first, I thought, I guess this does need to be clamped down. BBEdit has extensive AppleScript support, so if you give it full file access, then any FTP client or blog editor would also be able to get full access, just by asking BBEdit to do its bidding. But BBEdit’s sandboxing and entitlement aren’t actually protecting against that because any app can send events to BBEdit. That hasn’t changed. The real issue is that any sandboxed app that lists BBEdit in its com.apple.security.temporary-exception.apple-events can get full access. (I think; I haven’t tested this.) It’s obvious why you might not want to allow an app to script Finder or Terminal, but less so for a text editor. Is this an actual problem? I don’t know. These days I see a lot of people talking about theoretical Mac malware but not about problems it’s causing in the wild. And it’s no less secure than before, just more surpising because this can happen with two sandboxed apps from the store.
Previously:
- Transmit 5 on the Mac App Store
- Escaping the Sandbox – Microsoft Office
- Mac App Store Sandboxing, IAP Trials, Multiplatform Services
- BBEdit Leaving the Mac App Store
- Mojave Privacy Protection Aftermath
Update (2019-03-07): Tom Bridge:
Rich Siegel of Bare Bones software joins the pod this week to talk about BBEdit, TextWrangler’s departure, and life in the App Store World.
Update (2019-03-21): Bare Bones Software:
Non-App Store builds of BBEdit will no longer prompt for sandbox access at startup. However, it is still possible that sandbox access is required in order for certain behaviors to work correctly.
In particular, the OS will unilaterally decide to “quarantine” certain files when you ask BBEdit to open them from the command line; and there are likely to be other misbehaviors caused by assumptions that the OS makes when running a sandboxed application.
10 Comments RSS · Twitter
I think it might be presumptive to read too much into this change in BBEdit 12.6. Apple has long tried to sell sandboxing as something that Mac developers should use, not just for the Mac App Store. I don’t know what BBEdit has planned, but it seems logical (albeit perhaps misguided) that they are making these changes to avoid having two different builds. Maybe the code internally is using app sandboxing and a global bypass. The 12.6 update is free to pop-up any dialog it wants so it can avoid impacting existing customers. None of this should make anyone assume that Mac App Store policies have changed. Please don’t start submitting Mac apps with welcome screens asking for full access. You’ll be sorry! Apple has been pretty consistent with respect to this policy. Your app has to work and provide useful value. You can’t ask for root access. A user can provide it, but they have to go looking for it. You can’t ask, even nicely. I see no reason why BBEdit wouldn’t work fine without this bookmark. Some of the more obscure features might not work, but does everyone use those? If you are just editing files, it should work fine without a global bookmark.
> BBEdit has extensive AppleScript support, so if you give it full file access, then any FTP client or blog editor would also be able to get full access, just by asking BBEdit to do its bidding.
Whether you give it full access or not is irrelevant, though, because Apple events passing file objects have the same magic powers as Powerbox dialogs.
@Shane But without full access, and the other app sandboxed, neither app can (on its own) get an Apple event file object that references something outside the container. Right?
@Michael I'm not sure how far you mean with your "on its own". But it's trivial to run a script that includes "path to startup disk", which gives you a file object you can presumably send to any app you have permission to send events to.
@Share My understanding is that if an app has access to a file, it can pass that access along in the Apple event. But if it never had access to begin with, it’s like passing a bookmark that’s not security scoped. The path gets received, but it doesn't confer any access. Otherwise there would be a giant security hole, and any app could conjure access simply by constructing and running a script.
