On Wed, Feb 4, 2015 at 9:13 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > > I think there are three: > > 1. As is. Mixed Content is not touched. > > 2. Upgrade. Mixed Content URLs will be altered to use HTTP over TLS. > > 3. Block. All Mixed Content results in a network error. > > We recently added 3. We already have 1 (just do nothing). This adds 2. > We might want to make the syntax a bit more related, but I'll leave > that up to Mike. > For clarity, #3 is https://w3c.github.io/webappsec/specs/mixedcontent/#strict-checking. The expectation is that sites who do the work to migrate to HTTPS fully can lock in that behavior, and ensure that neither first- nor third-party content can screw it up. I suppose we could change the name from `upgrade-insecure-requests` to `upgrade-all-mixed-content`, but that would conceptually preclude using the directive on HTTP sites (as the content wouldn't actually be mixed). Perhaps that's not a bad thing, but since CSP itself works over HTTP, I don't think there's a good reason to deny this particular feature. (Non-form top-level navigation needs to be excluded as Mixed Content > does not touch that. Links would break.) > As I noted in another thread, I'm also worried about navigational upgrades. I think excluding them from the initial pass is the right thing to do. -mike -- Mike West <mkwst@google.com>, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Wednesday, 4 February 2015 08:21:26 UTC