I made a suggestion a while back that got one positive response, but then seemingly ignored. That there should be a “strict” mode e.g. for banks that want absolutely all traffic encrypted, and a “slack” mode e.g. for mashup web sites that want to encrypt all of their own content, but not that coming from some other web sites that they are pulling from. The doc proposes 3 modes: · “Enforced upgrade”: this is pretty much exactly what I meant by “strict” · “Monitored upgrade”: I didn’t address this ☺ · No upgrade: seemingly implicit in the absence of directives. I suggest adding a 4th mode: · “Local upgrade”: upgrade all content coming from this origin/server, and don’t attempt to upgrade stuff coming from other servers Local is basically saying “upgrade stuff that can be upgraded, but explicitly tolerate mixed content.” Clearly that is less secure. But it is more secure than no upgrade, which is where people using mixed-source content will be forced to go. From: Mike West [mailto:mkwst@google.com] Sent: Tuesday, February 10, 2015 4:28 AM To: public-webappsec@w3.org Cc: Brad Hill; Dan Veditz; Wendy Seltzer; Peter Eckersley; yan zhu Subject: Re: CfC to publish FPWD of "Upgrade Insecure Resources"; Deadline Feb 17th. On Tue, Feb 10, 2015 at 1:19 PM, Mike West <mkwst@google.com<mailto:mkwst@google.com>> wrote: This is a call for consensus to publish* the following draft of "Upgrade Insecure Resources" as a First Public Working Draft: https://w3c.github.io/webappsec/specs/upgrade/published/2015-02-FPWD.html Er. I meant "Update Insecure Requests", of course. Sorry about that. :/ -mike -- Mike West <mkwst@google.com<mailto: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 Tuesday, 10 February 2015 18:11:03 UTC