On Wed, Feb 11, 2015 at 8:52 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > This seems like it might introduce more problems on the server side than > it solves. I think I agree with Jacob's analysis: 1. This isn't a problem for browsers that support upgrade, as they'd never have made the insecure subresource request in the first place. 2. Moreover, there's no harm in redirecting _all_ non-HTML/non-Worker requests to HTTPS, is there? That would simplify server-side logic. :) > Does CSP itself offer any feature-detection capabilities? No. Working on a JavaScript API for CSP3, and we send a `CSP: 1` header in order to mitigate the risk of leakage (as described in https://w3c.github.io/webappsec/specs/content-security-policy/#csp-request-header). We could certainly expand that header in various ways to advertise capabilities. I don't think that addresses Anne's central point about header bloat, but it's not clear to me what kind of advertisement mechanism we can use that doesn't fall into that trap. Client hint-style opt-in from the server side might be interesting ( http://igrigorik.github.io/http-client-hints/#rfc.section.2.2.1), but it leaves the first request in an indeterminate state. That might or might not be ok. -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 Thursday, 12 February 2015 06:52:31 UTC