Since the only way to sign into some (even paid) products is via a web auth flow, this means that e.g. in iOS native apps when SFSafariViewController is used, most of WAF blocks are not recoverable from the error message, and especially privacy–conscious VPN customers may already have existing privacy features on system level that can get blocked by the WAF during the signon.
| SFSafariViewController |
Mozilla VPN login |
| Contrary to other WebView types, that e.g. do not have iCloud+ Private Relay available at all, SFSafariViewController uses the system–level Safari setting, incl. any iCloud+ Private Relay settings, ending up using their (partners') MASQUE datacenter–based nodes for this WebView — if the embedded FxA signin flow gets blocked by WAF, there's usually nothing actionable the end user can do. While the error page suggests checking JS, adblocker etc., none of that is relevant inside the webview that a) lacks such controls, b) is not adjustable in any way by the end user. |
 |
According to https://developer.apple.com/icloud/prepare-your-network-for-icloud-private-relay/ the iCloud+ Private Relay has some tokens to identify real users, not sure how these should be honored by the CDN?
┆Issue is synchronized with this Jira Task
Since the only way to sign into some (even paid) products is via a web auth flow, this means that e.g. in iOS native apps when SFSafariViewController is used, most of WAF blocks are not recoverable from the error message, and especially privacy–conscious VPN customers may already have existing privacy features on system level that can get blocked by the WAF during the signon.
According to https://developer.apple.com/icloud/prepare-your-network-for-icloud-private-relay/ the iCloud+ Private Relay has some tokens to identify real users, not sure how these should be honored by the CDN?
┆Issue is synchronized with this Jira Task