Safari 13 brings WebAuthn and drops legacy browser extensions

FIDO2 and WebAuthn finally go GA

First, let’s look at what I say is the most the positive addition, the ability to use FIDO2-compliant hardware security keys like the recently released Yubikey 5Ci. We’ve been waiting what feels like forever as this has been in preview a while. Now, if you use Safari, you can use hardware keys like the Yubikey or Titan Security Key as part of your organization’s MFA, or in some select cases (like Google accounts), make it the only authentication method. I tested it out and it works just like any other FIDO2-compliant browser, just know you still can’t use hardware keys with mobile Safari.

Meanwhile, WebAuthn is the credential management API developers can build into web applications that allows for users to authenticate with services without needing to save passwords on any server. The W3C made it an official web standard earlier this year.

Both features have already been part of the other major browsers, so it’s about time Safari started catching up.

Legacy extension deprecation

In 2018, Apple announced plans to deprecate legacy browser extensions. Legacy extensions allowed users to install scripts in Safari that added to the user experience, ranging from a wide variety of options, and were available from within Apple’s Extension Gallery and (for some of the time) from developer websites. Apple is replacing that with App Extensions (though this has been around for a while), which allow developers to enable an additional task from their app; it’s more limited and goes through the App Store.

Starting with iOS 12, users received messages informing them that their legacy extensions slowed down Safari (it’s questionable whether this was true), but they continued to work. In addition, Apple shuttered the Extension Gallery and developers had to create App Extensions now. As of Thursday, with the release of Safari 13, users cannot install legacy extensions anymore. 

The legacy browser extension deprecation impacts a wide variety of extensions, but ad blockers, VPNs, and other security-minded extensions are worse off, and this is due to having to work with the Content Blocker API. Instead of the extension blocking content itself, like previously, it sends a list of URLs that Safari 13 will handle the blocking of, instead. Apple has said that this change isolates Safari extensions and limits their access to data (which on the surface, is a good thing).

Now, the changes don’t mean an end to ad blockers, just a change in how they currently work. For example, uBlock Origin is likely done and others shut down ahead of this; some developers will not want to bother re-working their extension for the App Store. A few did make App Extensions that users can install—just make sure to research the ones that are available. The content blockers have limitations now and some might even allow “acceptable ads” (whether that’s OK is your decision to make).

Apple does what Google has threatened to do

Google has wanted to do this very same thing for a while now with Chrome. Developers noticed the planned deprecation of webRequest API and the introduction of the declarativeNetRequest API in manifest v3 Google Document. The changes amounted to the same as the Content Blocker API, requiring ad blockers to create a list that told Chrome what to block.

After a big outcry from developers and users alike, Google backed off and said the webRequest API wouldn’t be fully deprecated. No changes have been made as of yet.

Apple shows they prefer security to user choice

The updates outlined here show that Apple continues to lean into a more controlled, locked-down experience where they decide what’s best. I find myself a bit mixed on this. I like the addition of FIDO2 and WebAuthn—both are good specifications that provide users with more security—but am unsure about the move to ditch legacy extensions.

I have written a lot around the dangers of extensions; they have too much access to user data and browser permissions often don’t adequately spell out what that access is. Browser developers are working on reining things back in, but it’s slow going. However, some of the suggestions don’t seem especially well thought out, in this case, I’m speaking specifically about how Apple and Google ignore developers when it comes to extensions.

I’m fine with the browser deciding what to block as it means that an extension has less access to my data. But, neither vendor looks like they cared about the number of rule sets to allow, restricting to what sounds like a huge number but is actually limiting when it comes to content blocking. (50,000 sounded like a lot to me, but from reading complaints, it’s apparently not.)

At the same time, how many people does this really affect? Safari lags behind most other browsers in adoption, with NetMarketShare showing that only 3.63% use it. And, if the deprecation is a step too far from Apple, users and the enterprise can easily switch to another browser that hasn’t yet taken draconian steps.