My 3.1415 cents basically say CSP-based reporting is very helpful even with the noise. I always think there should be one single reporting mechanism for all the security headers, rather than asking developer to write code and detect the UI/Browser warning and find their code is causing trouble. And this needs to be outside of CSP, a superset reporting mechanism that CSP can forward to. I tend to think of it like shipping logs to logstash. This can be a whole different header... Now is auto-upgrading sub-resources a good security measure. I agree with some of the concerns raised in Devdatta's bugzilla report ( https://bugzilla.mozilla.org/show_bug.cgi?id=776278). I apologize if i am really shifting the main attention, and please excuse my inability to keep up with the latest development: Assuming there are 50/50 split of the world's legacy content now or will be served over http and https, or only http. The auto-upgrade will fail 50/50. Assuming there are 50/50 split of the world's legacy content now served over https with SHA1 or https with SHA2, the auto-upgrade will fail 50/50. Regardless, we have to deal with legacy clients, insecure and broken resources. But a page isn't make up of 1 third-party but dozens. As a browser user, and a developer, will auto-upgrade harm performance and user experience? Does auto-upgrade subresource offers better security than not when mixed content will eventually kick in if content is only http (or browser yells at SHA1-insecure cert, which I assume will then fail with mixed-content???). John On Fri, Feb 6, 2015 at 12:57 AM, Mike West <mkwst@google.com> wrote: > On Fri, Feb 6, 2015 at 6:39 AM, Devdatta Akhawe <dev.akhawe@gmail.com> > wrote: > >> 2) how to upgrade it to https (possibly via a directive >> > or via JS). I was focusing on the latter when talking about >> ServiceWorkers. I guess it doesn't help in cases where you don't >> actually support HTTPS in some obscure origin and thus can't upgrade >> automatically. >> > > We currently do mixed content (and CSP) checks before sending the request > to the Service Worker. I'm not sure it would be a good idea to restructure > that to wait for the SW to potentially rewrite the request. Also, the > timing seems problematic. You can't register a SW until you're on an HTTPS > page, at which point it't too late to start upgrading its requests. > > I think a CSP-based solution has some advantages here, but I guess I > wouldn't be opposed to explaining it in terms of service workers if there's > a good way of doing so. +Alex, who probably has opinions about SW's > applicability. > > -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 Friday, 6 February 2015 06:22:20 UTC