Open Bug 815329 Opened 8 years ago Updated 2 years ago
Mixed Content Blocker after all other Content Policies and after all internal redirects
That seems plausible to me, yes.
It seems like a hack to me :) This is one more example of why CSP might not be a good way to do content security state determination.
After I've read bug 782654 last comments, I think when this would rather be hardcoded (i.e. not added as a CSP listener) it would not be a hack. Also hardcoding this in the redirect callback of nsDocLoader (or nsDocShell? I don't recall) we may fix the https->http redirect too.
Basically, we cannot implement the mixed content blocker as an implementation of the current nsIContentPolicy, because of bug 838395 and redirect issues as described in comments in bug 456957 and bug 418354. We need to do mixed content blocking/logging much later than nsIContentPolicy allows, and we must be able to do so without having references to the actual DOM nodes. My plan is to hook the nsMixedContentPolicy logic directly into Necko. This will require that every channel (for web content) to be annotated with the nsContentPolicyType. I think Dev was working on that and I am planning to work with him on it. One great side-effect of this work is that mixed content blocker will become compatible with e10s and it will be enforced in the trusted (parent) process. It will also be easier to fix bug 418354 with this. After this is implemented, we can try to generalize this work into a new content policy API where CSP and other content policies can be enforced in the parent process in e10s, and which works correctly with redirects (both internal and external).
Assignee: nobody → bsmith
Summary: Call nsMixedContentBlocker after all other Content Policies → Call nsMixedContentBlocker after all other Content Policies and after all internal redirects
Target Milestone: --- → mozilla21
test_csp_bug768029.html should be fixed as part of this work. One of the patches in bug 834836 works around this bug (bug 815329) by disabling the mixed content blocker.
Is this bug the reason why Twitter goes into the mixed content state after a while without an obvious non-TLS request in the Network tab of dev tools?
(In reply to Henri Sivonen (:hsivonen) from comment #6) > Is this bug the reason why Twitter goes into the mixed content state after a > while without an obvious non-TLS request in the Network tab of dev tools? Maybe related to bug 947079?
Component: Security → DOM: Security
You need to log in before you can comment on or make changes to this bug.