Bug 219396

Summary:	[WPE][GTK] Deprecate insecure-content-detected signals
Product:	WebKit	Reporter:	Michael Catanzaro <mcatanzaro>
Component:	WebCore Misc.	Assignee:	Michael Catanzaro <mcatanzaro>
Status:	RESOLVED FIXED
Severity:	Normal	CC:	annevk, fran, kaiykay768, mcatanzaro, m_finkel, nekohayo, smoley
Priority:	P2	Keywords:	DoNotImportToRadar
Version:	WebKit Nightly Build
Hardware:	PC
OS:	Linux
See Also:	https://bugs.webkit.org/show_bug.cgi?id=246606
Bug Depends on:	247197
Bug Blocks:	140625

Description Michael Catanzaro 2020-12-01 06:19:47 PST

Nowadays, Chrome has started blocking all mixed content unconditionally (except form targets, but it will block those too very soon), per https://www.feistyduck.com/bulletproof-tls-newsletter/issue_70_chrome_developers_want_to_eliminate_mixed_content. If we were to implement that, then we could deprecate the insecure-content-detected WPE/GTK API signal and remove the API tests for it. The relevant internal APIs can be removed, and the corresponding Cocoa API can also be deprecated.

To make this work, we need to automatically rewrite insecure URLs to https:// (or wss://), and allow the content to fail to load if that doesn't work. An exception would be in place for loopback.

This will obsolete bug #142469 and some (but not all) of the other bugs blocking bug #140625. We just need to make sure all the various types of resource loads are properly upgraded.

Comment 1 Michael Catanzaro 2021-09-27 13:57:41 PDT

There is a spec developing somewhat differently: https://w3c.github.io/webappsec-mixed-content/

We probably want to match the spec.

Comment 2 Michael Catanzaro 2022-07-19 15:06:01 PDT

Basically we want to:

 * Upgrade any mixed content that we do not block today, block if secure connection is unavailable
 * Continue blocking everything that we block today (unchanged) (unless upgrade-insecure-requests CSP is used, unchanged)
 * Make sure to block mixed downloads

The spec offers the possibility of an option to disable all of this and just load mixed content, but WebKit should not allow that. We can also remove preferences for AllowDisplayOfInsecureContent and AllowDisplayAndRunningOfInsecureContent.

Comment 4 Michael Catanzaro 2024-02-16 15:31:41 PST

I think this is now implemented after bug #268823, albeit only conditionally, behind a runtime preference. This makes it unclear what we should do with the various insecure content detected APIs. The various layers of signals still exist, but are generally unused now.

I'm inclined to deprecate the GTK/WPE API simply to avoid confusion from having API that doesn't do anything anymore. Not sure about the cross-platform bits, though. They're still theoretically useful if you change the runtime setting. And the GTK/WPE ports do allow this via the WebKitFeature API, so in theory, they could still be fired. In practice, though, we can still safely deprecate them; no developers are likely to ever do that, and even if so, it's OK to tell developers "don't do that."

Comment 5 Michael Catanzaro 2024-02-19 13:42:04 PST

Pull request: https://github.com/WebKit/WebKit/pull/24770

Comment 6 EWS 2024-02-20 10:58:10 PST

Committed 275056@main (9cf4048416d8): <https://commits.webkit.org/275056@main>

Reviewed commits have been landed. Closing PR #24770 and removing active labels.