[Webkit-unassigned] [Bug 142469] ContentType::ActiveCanWarn should not allow bypassing allowDisplayOfInsecureContent setting

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=142469

--- Comment #3 from Michael Catanzaro <mcatanzaro at gnome.org> ---
Well, insecure content is no longer displayed, because you change loopback/localhost addresses to be trusted. So a test that ensures the insecure content warning is emitted when loading from loopback/localhost is expected to fail after your change. I think the only way to update the test would be to expose an API setting to toggle whether loopback/localhost addresses are trusted or not, as you've done for TestController. That would be overkill: it doesn't make sense to add public API solely for use by tests. So let's not do that. Alternativs:

 * Perhaps it might be possible to allow API tests to change TestController settings? I don't think any tests currently attempt this, and I'm not sure how hard it would be.
 * You could simply give up and remove the affected API test. But then we would have no tests for the insecure-content-detected signal.
 * Finally, the best option, but also the hardest option, would be to modernize how WebKit handles mixed content to match Chrome's current behavior, which is better than ours.

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 signal and remove the API tests for it. The modern behavior would be to automatically try to rewrite the URL to https://, and allow the content to fail to load if that doesn't work. (You could make exceptions for localhost and loopback.) Of course, that would be quite a bit of additional work, and would require rebaselining all the mixed content tests, but you would then be able to immediately close this bug, and probably many of the other bugs marked against bug #140625.

(Lastly, I'll mention that there's no longer much point in trying to fix this particular bug in 2020. It would be easier to implement Chrome's behavior.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201106/b42a115c/attachment-0001.htm>