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.