- From: Jim Manico <jim.manico@owasp.org>
- Date: Mon, 2 Feb 2015 07:48:05 -0800
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Mike West <mkwst@google.com>, WebAppSec WG <public-webappsec@w3.org>
This proposal has a good chance of "breaking" sites or harming functionality without messaging the user since this proposal effects both same domain and different domain URI's. Perhaps add a alert or some kind of warning if the "switched" URI's hit a site that does not properly support HTTPS? -- Jim Manico @Manicode (808) 652-3805 > On Feb 2, 2015, at 7:41 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > >> On Mon, Feb 2, 2015 at 4:35 PM, Mike West <mkwst@google.com> wrote: >> Would the effect of the header be equivalent to running `s/http:/https:/g` >> on the HTML? That is, at parse time, we would transparently replace >> `http://example.com/test.png` twith`https://example.com/test.png`? > > Equivalent, but not identical. My proposal would be to upgrade in > Fetch similar to HSTS so that any scripts are not affected by URLs > changing. > > >> Or would this be similar to strict mixed content checking mode, blocking the >> requests without degrading the UI? > > It would not be similar as we would attempt to fetch these resources > over TLS. Having said that, I don't understand why strict mixed > content would result in UI degradation. If we don't actually do > something that causes harm to the user (such as fetching mixed content > images), we shouldn't alert them about it. > > > -- > https://annevankesteren.nl/ >
Received on Monday, 2 February 2015 15:48:33 UTC