upgrade-insecure-requests is a great way for sites to upgrade their subresources to https without having to change hardcoded http links. upgrade-insecure-requests provides a guarantee that no mixed content will load and degrade the security UI of a site. In cases where an http subresource cannot be loaded over https, the subresource will simply fail to load and any functionality that it provided will be broken. Some sites may appreciate this property and want assurances that third party content can't degrade the security of their site. Others may feel that they can't afford to have potentially broken functionality. Or they may know of a single, important subresource that isn't available over https and not want to spend the time and effort to upgrade the rest of their http links to https. This would prevent those sites from using upgrade-insecure-requests. I propose we add an upgrade-insecure-request-with-fallback option for sites and services that can't afford to break functionality but want the potential for increased security. This fallback option can be either a separate directive or an attribute on upgrade-insecure-request. We will have to be careful to ensure that we don't break backwards compatibility with sites that already set upgrade-insecure-requests and expect it not to fallback. Sites and services that opt into upgrade-insecure-request-with-fallback should be aware that they may have slightly decreased performance, because in the fallback case there will be two roundtrips for the same subresource. Thoughts? ~TanviReceived on Wednesday, 1 June 2016 21:57:10 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC