If you organize your life with OmniFocus or OmniOutliner (or anything else from The Omni Group), you can take control of your data by syncing to your own WebDAV server.
Docker makes it easy and we’ll be done in about 5 minutes! You’ll have Traefik (a reverse proxy) sorting out SSL certificates for you, and Watchtower running every night to update your containers.
Cool.
Juli Clover (via Marco Arment):
Going forward, USB 3.1 Gen 1 (transfer speeds up to 5Gb/s), which used to be USB 3.0 prior to a separate rebranding, will be called USB 3.2 Gen 1, while USB 3.1 Gen 2 (transfer speeds up to 10Gb/s) will now be known as USB 3.2 Gen 2.
What used to be considered USB 3.2 will now be USB 3.2 Gen 2x2 because if offers twice the throughput speeds of USB 3.1 Gen 2, now USB 3.2 Gen 2. If that sounds confusing to you, you’re not alone.
What this branding meant is that many manufacturers say that a device supports “USB 3.1" even if it’s only a “USB 3.1 Gen 1" device running at 5Gb/s. Meanwhile, other manufacturers do the sensible thing: they use “USB 3.0" to denote 5Gb/s devices and reserve “USB 3.1" for 10Gb/s parts.
[…]
The good part of all this is that USB 3.2 could mean 5, 10, or 20Gbps. You can bet that there will be manufacturers who are going to exploit that confusion wherever and whenever they can.
Previously:
Hi, please preflight URLs with
UIApplicationOpenURLOptionUniversalLinksOnlybefore jamming them in aSFSafariViewController, thanks in advance
As per apple docs “When you include this key in the options dictionary of the
openURL:options:completionHandler:method, the method opens the URL only if the URL is a valid universal link and there is an installed app capable of opening that URL”
Robin Kunde shows how to do it in code.
See also: Allowing Apps and Websites to Link to Your Content.
As a user, I find Universal Links confusing because I don’t always know what’s going to happen when I tap a link, and I can’t seem override it to do what I want in a given situation.
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:
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.
