Password AutoFill suggests credentials for a messagefilter: associated domain (FB25326312)

Privacy & Security General
Aravind_Vaidhyanathan OP
Created
Replies 3
Boosts 0
Views 255
Participants 2

The issue below affects every partner app embedding our SDK, so we'd appreciate DTS taking a deeper look. We're happy to open a code-level support request and provide screen recordings and a sysdiagnose. Details are in FB25326312.

We ship an SMS filtering SDK (a Message Filter app extension) that partner apps embed. Password AutoFill is treating the SDK's messagefilter: associated domain as a credential domain for the host app, so unrelated saved logins appear on the partner app's sign-in screen.

Configuration

Apple validates Message Filter network deferral against the containing app (an unauthorized containing app gets ILMessageFilterError.Code.networkURLUnauthorized), so the entitlement must be declared on each host app, not the extension:

messagefilter:messagefilter.example.com
  • The AASA file at messagefilter.example.com lists the host app IDs under messagefilter only. It has no webcredentials key.
  • Network deferral works as expected.

(The real domain is in FB25326312.)

Observed behavior

On the host app's sign-in screen, saved logins for the SDK provider's domain (example.com) are suggested in the QuickType bar and the QuickType suggestions list:

  • No webcredentials: domain: only example.com logins are suggested.
  • App's own webcredentials: domain added (valid AASA entry): the app's logins appear, but example.com logins are still suggested alongside them.

Password managers

Reproduces with Apple Passwords and third-party password managers (tested with 1Password, Dashlane, and Norton Password Manager):

  • Credential providers appear to receive the messagefilter domain in the serviceIdentifiers array passed to prepareCredentialList(for:). Some use only the first identifier, others use all of them.
  • QuickType suggestions come from iOS itself, so the unrelated credentials appear regardless of which password manager is used.

Seen on iOS 26 and iOS 27 in a production partner app.

Questions

  1. Is it intended that a messagefilter: domain contributes to Password AutoFill credential matching?
  2. Is there a supported way to exclude it from AutoFill without breaking Message Filter network deferral?
Replies  3
Boosts 0
Views  255
Participants  2
DTS Engineer OP
Apple

Thanks for the post and the bug filed.

This is not intended behavior. Password AutoFill is designed to strictly look for the webcredentials: service type in the app's AASA file to determine credential sharing. The fact that iOS is passing the messagefilter: domain into the serviceIdentifiers array for Credential Providers could be a bug? Good idea on filing that bug.

I suggest a possible workaround right now to host the Message Filter API and its AASA file on a completely separate, dedicated domain that has no user-facing logins associated with it? This ensures that even if AutoFill incorrectly picks up the domain,

You can see the status of your feedback in
Feedback Assistant.
There, you can track if the report is still being investigated,
has a potential identified fix, or has been resolved in another way.
The status appears beside the label "Resolution."
We're unable to share any updates on specific reports on the forums.

For more details on when you'll see updates to your report, please see
What to expect after submission.

Albert  WWDR
Aravind_Vaidhyanathan OP

Thanks, Albert. It's helpful to have confirmation that this isn't intended behavior.

Moving the Message Filter endpoint to a dedicated domain is something we've already been considering and discussing internally. It isn't a quick or simple change for us, though:

  • New domain and AASA: we'd need to set up and maintain a new domain with its own AASA file listing every partner's app ID under messagefilter.
  • SDK update: the extension's ILMessageFilterExtensionNetworkURL would change, so we'd have to ship a new SDK version.
  • Partner releases: every partner would need to update their Associated Domains entitlement, integrate the new SDK, and ship an App Store update. Until each partner does, their users remain affected.

With several partners already shipping our SDK and more lined up, the rollout would take considerable time across all of them.

Also, a dedicated domain stops existing logins from surfacing, but in apps without their own webcredentials: domain, the save-password flow during autofill by the Passwords app or any 3rd party Password Manager app would still suggest or populate the website/domain field with the messagefilter domain. Passwords saved this way would then be suggested in every partner app sharing it, so users of one partner could see another partner's logins. That's why we feel a system-level fix is still needed.

Given the privacy implications (another website's saved credentials being offered on a partner's sign-in screen) and the poor user experience this causes, is there any way FB25326312 could be prioritized or the fix expedited?

We understand you can't share updates on specific reports here, but anything you can do to flag its severity internally would be greatly appreciated.

DTS Engineer OP
Apple

Thanks for the reply, routed the bug to the correct component and added the link to this thread for them to have some context. Let's see what they come out with, thanks for your patience on this one.

Albert  WWDR