Thanks, Anne! On Fri, Mar 6, 2015 at 9:11 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Fri, Mar 6, 2015 at 8:51 AM, Mike West <mkwst@google.com> wrote: > > https://w3c.github.io/webappsec/specs/upgrade/ > > In the section on "return=secure-representation" it might be nice to > direct readers to the wonders of HSTS. (Section 7.2 does not seem to > address the relationship to this request header.) > Good idea! I hope https://github.com/w3c/webappsec/commit/2e3c42c0fcd320cd4e39a54ebe66d9eed9ae508c addresses this. > Should the section on "Policy Inheritance" address workers? > Theoretically you can instantiate a worker from another worker though > I've forgotten to what extent that is implemented. (The API you can > make downgrade fetches with would be fetch(). Of course, it's somewhat > questionable that any of that would be legacy content...) > Yes, it should. And now it does: https://github.com/w3c/webappsec/commit/48d670bfc6ab4ed41211d88d92c68276fbecfa9d Possibly even correctly! > In "Fetching algorithm" (section 5) you want a lowercase "f". > And elsewhere as well: https://github.com/w3c/webappsec/commit/d8bb40bc6812a7a5f77f2d79a4c8e284544d3b01 > > The only issue noted in the document is > > https://github.com/w3c/webappsec/issues/184, which suggests changing > from a > > value-less directive to a whitelist of hosts. I can see how that would be > > valuable, but it seems like a complicated thing to add if we don't > actually > > need it. Do folks here think it is necessary? > > I would prefer to start with the simplest possible thing. This > directive is primarily about dealing with mixed content URLs in legacy > content. And avoiding mixed content requires no http URLs. > Right. I agree. The potential value I see is in allowing sites to continue serving optionally blockable content (images, media) from an insecure source, as that might be the only source they have available. Something like `upgrade-insecure-requests 'self' my-awesome-cdn.info` might make sense. It's not clear to me that that's _necessary_ but I can certainly see it as nice to have. (Note that adding such a thing in the future could be trivial; similar to `sandbox`, we could simply map an empty `upgrade-insecure-requests` to the most secure variant (`upgrade-insecure-requests *`), and allow developers to layer something more granular from there.) -- 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 Friday, 6 March 2015 09:15:46 UTC