How to implement server-side authentication for text filtering requests??

If an app has a text filtering extension

Please clarify what you mean by “text filtering extension”. Are you referring to SMS and MMS Message Filtering?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes. Is there a way for the server to know the traffic has come from Apple and not a spoofer of Apple?

I saw somebody post a question in the past about using Shared Web Credentials to perform basic auth, is that possible?

My general advice on this front is to use App Attest, although I’m not sure how that’d work in a Message Filter app extension (I’m not the DTS primary on either of these technologies).

I’ve tweaked the tags of this post and I hope that’ll attract folks who know more about this stuff.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

AppAttest documentation says: "...Then you use the service to cryptographically sign server requests using the certified key."

With text filtering extensions, as the server request is coming from the OS, not from the app/extension, then the app/extension presumably won't be able to sign the server request?

If somebody reverse engineers the associated domain urls our of the app's info.plist or entitlement files and calls the server url directly, then how can the server detect this has occurred and the request is not coming from the iPhone OS of a handset on which the app is installed?

The basic security mechanism here is that the connection is secured using the web credentials you've provide, so all a user could do in the scenario above is report data as "themselves":

"If you have servers that can help your app extension determine how to handle a message, you must add the Associated Domains capability to your Xcode project and specify those domains. Then, you must set up shared credentials as described in Shared Web Credentials, substituting messagefilter for webcredentials throughout the steps. Lastly, you must specify the domains in your Info.plist file, which should look similar to the dictionary shown below."
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

@Kevin Elliott

A few of app extensions cannot make networks calls themselves, instead the OS makes the network call on behalf of the extension (such as the Message Filter Extension or Unwanted Communication extension).

As its not the extension itself making the network call in these situations, then does that affect the situation?

A few of app extensions cannot make networks calls themselves, instead the OS makes the network call on behalf of the extension (such as the Message Filter Extension or Unwanted Communication extension).

As its not the extension itself making the network call in these situations, then does that affect the situation?

No, at least not in this case. The credentials the system is using come from the system keychain and they were inserted there by your app, presumably as part of an in-app configuration process controlled by your app.

Note that while the documentation there is structured as "user name/password", that doesn't necessarily need to be the direct credentials the user would actually use to "login" to your service. Your service could also issue back extension specific login credentials after it authenticates the user through their normal credentials (or whatever mechanism you normally use). Note that many VPN services use an approach similar to this- the user has an "account" which is used to login to the VPN services management interface (website/app/etc). That account can then create additional "login users" (which are used to authenticate the actual VPN service), but the two different account types can only be used within their respective "areas".

Returning to the original question here:

In other words, how can the server verify that the request is valid and coming from the iPhone and not from some spoofer?

The connection is authenticated to a particular user, which is how you'd normally limit the impact of any spoofer. However, I'll also so that the login architecture I sketched out above also means that you could use App Attest to perform security checks before you issue an extension account to that device.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

@Kevin Elliott So the app would run code referenced in the documentation for App Attest, rather than the Message Filter Extension, however when the OS contacts the server its pulling stuff from the keychain which was set in the app?

There's a past question here about using (and failing) to use Web Credentials in the Message Filter Extension, should they have been calling that code from the app and not the extension?

https://developer.apple.com/forums/thread/758611

I'm not understanding how App Attest could be used in an app extension when the documentation for it states:

"Important. Most app extensions don’t support App Attest.....The only app extensions that support App Attest are watchOS extensions in watchOS 9 or later. " (https://developer.apple.com/documentation/devicecheck/establishing-your-app-s-integrity)

I don't understand therefore how its being suggested it could be used for a message filtering extension when its documentation says app extensions don't support it?

@Kevin Elliott So the app would run code referenced in the documentation for App Attest, rather than the Message Filter Extension, however when the OS contacts the server its pulling stuff from the keychain which was set in the app?

Correct. The app validates using App Attest, then adds the credential data into the keychain.

There's a past question here about using (and failing) to use Web Credentials in the Message Filter Extension, should they have been calling that code from the app and not the extension?

Yes, that's what I would recommend. To be honest, I haven't specifically looked at this particular detail of the filter extension in great detail, but the app is really the only place this makes sense to do. Two reasons:

1. The filer extension is going to run in a very broad set of circumstances, so you should try to keep it's implementation as simple as possible.

2. You need to validate the credential information before you use/set them and you need to do that in the app so that the user can fix anything that goes wrong (for example, password typos).

Basically, once you've validated them there isn't any reason NOT to complete the process by storing them into the web credential store.

I don't understand therefore how its being suggested it could be used for a message filtering extension when its documentation says app extensions don't support it?

Expanding on what I said above, the idea here is that you do all of your setup inside your app (including App Attest) and configure the filter extension until you've checked whatever you want to check.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware