Six WebView setups call setMixedContentMode(MIXED_CONTENT_ALWAYS_ALLOW), including the payment form

[jim-daf]

Six WebView setups in TMessagesProj use:

webView.getSettings().setMixedContentMode(WebSettings.MIXED_CONTENT_ALWAYS_ALLOW);

Call sites:

• org/telegram/ui/ArticleViewer.java (Instant View renderer)
• org/telegram/ui/PaymentFormActivity.java (two WebViews: payment form and 3DS step)
• org/telegram/ui/WebviewActivity.java (in-app link WebView)
• org/telegram/ui/Components/EmbedBottomSheet.java (iframe embeds)
• org/telegram/ui/Components/PhotoViewerWebView.java (YouTube and similar embeds)

MIXED_CONTENT_ALWAYS_ALLOW lets an https page in the WebView load every kind of http sub-resource, including remote scripts. The WebSettings javadoc treats it as the strictly less safe choice. CWE-319 is the closest mapping.

PaymentFormActivity is the most sensitive of these. Its WebView renders the payment provider HTML and the 3DS challenge. Allowing any http sub-resource over an https payment form is a downgrade that the payment-provider page itself almost never asks for and that a network attacker could exploit to swap cards / inject form-stealers if they can reach a captive intermediary.

The other four (ArticleViewer, WebviewActivity, EmbedBottomSheet, PhotoViewerWebView) render Telegram Instant View articles, link previews and iframe embeds. These can legitimately reference http images on https pages, which is what COMPATIBILITY_MODE handles correctly.

Suggested fix:

Replace MIXED_CONTENT_ALWAYS_ALLOW with MIXED_CONTENT_COMPATIBILITY_MODE on all six call sites. COMPATIBILITY_MODE keeps passive sub-resources (images, fonts) loading on https pages while blocking active mixed content like remote scripts, matching how Chrome treats mixed content in the address bar.

A PR is open at #450. It is a single-token swap per call site and does not touch any other WebView setting.