RESOLVED FIXED 219396
[WPE][GTK] Deprecate insecure-content-detected signals 
https://bugs.webkit.org/show_bug.cgi?id=219396
Summary [WPE][GTK] Deprecate insecure-content-detected signals
Michael Catanzaro
Reported 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.
Attachments
Add attachment proposed patch, testcase, etc.
Michael Catanzaro
Comment 1 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.
Michael Catanzaro
Comment 2 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.
Michael Catanzaro
Comment 4 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."
Michael Catanzaro
Comment 5 2024-02-19 13:42:04 PST
Pull request: https://github.com/WebKit/WebKit/pull/24770
EWS
Comment 6 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.
Note You need to log in before you can comment on or make changes to this bug.