W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: CfC to publish FPWD of "Upgrade Insecure Resources"; Deadline Feb 17th.

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Wed, 11 Feb 2015 11:29:38 -0500
To: Mike West <mkwst@google.com>, Tanvi Vyas <tanvi@mozilla.com>
Cc: Jim Manico <jim.manico@owasp.org>, Crispin Cowan <crispin@microsoft.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>, Peter Eckersley <pde@eff.org>, yan zhu <yan@mit.edu>
Message-ID: <874mqspg25.fsf@alice.fifthhorseman.net>
On Wed 2015-02-11 08:25:18 -0500, Mike West wrote:
> As we've discussed in other threads, I think user agents can and
> should experiment with automagically upgrading insecure blockable
> content, quite apart from whatever behavior we allow sites to
> opt-into. Those pages are already broken, so breaking them in a
> different way isn't particularly risky.

I agree with this.  If the practice of auto-upgrading blockable content
becomes common (either de facto or via MIX2, should that happen), then
being able to use CSP reporting is still a good reason for this feature.

Perhaps something could be said in this draft about the interaction
between CSP reporting and automatic upgrades of blockable content?

Alternately, we could use this draft to specify three possible values
for upgrade-insecure-requests:

 none - no automatic upgrades
 blockable - automatic upgrades of blockable mixed content
 all - automatic upgrades of all mixed content

and set blockable to be the default.  This would allow sites that want
to avoid these upgrades (why?  i don't know) to do so by issuing a CSP
with upgrade-insecure-requests=none.


Received on Wednesday, 11 February 2015 16:30:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC