We should replace the two FrameLoadDelegate mixed content warning callbacks: - (void)webViewDidDisplayInsecureContent:(WebView *)webView; - (void)webView:(WebView *)webView didRunInsecureContent:(WebSecurityOrigin *)origin; with a single one that notifies that a webView has become insecure. This put the origin tracking in WebKit instead of at the App level.
We can do that, but the app still needs to do the origin tracking work to understand certificate errors properly.
(In reply to comment #1) > We can do that, but the app still needs to do the origin tracking work to > understand certificate errors properly. Interesting. Can you elaborate briefly on this? Perhaps we should document what the app is expected to do with these delegate methods a little better.
(In reply to comment #2) > Interesting. Can you elaborate briefly on this? Sure. Suppose we have two tabs open to the same HTTPS site. In one tab, the user approves a certificate error and receives HTML over a broken certificate. Now, we need to remove the lock icon from the other tag because the attacker can inject script into the first tab. Similarly, suppose the user approves a certificate error for https://foo.com. Now, later, https://bar.com includes a <script src="https://foo.com/ttt"> and the browser loads the script over a broken HTTPS connection. Now, we need to remove the lock icon from that https://bar.com tab as well as all the others. It's possible the best thing to do is teach WebCore about certificate errors. That way, we can ask the WebKitClient whether to approve the bad certificate (instead of doing it via the back door in the network stack). If we do that, we can manage the cert error state and the mixed content state together in WebCore. > Perhaps we should document > what the app is expected to do with these delegate methods a little better. I can write up a short white paper about how all this stuff ought to work if that would be helpful.