- From: Michal Zalewski <lcamtuf@google.com>
- Date: Sun, 14 Dec 2014 12:07:25 -0800
- To: Igor Bukanov <igor@mir2.org>
- Cc: Chris Palmer <palmer@google.com>, Eduardo Robles Elvira <edulix@agoravoting.com>, "dev-security@lists.mozilla.org" <dev-security@lists.mozilla.org>, blink-dev <blink-dev@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, security-dev <security-dev@chromium.org>
> Then browser should show absolutely no indications of secure origin for > encrypted http://. The idea is that encrypted http:// experience would be > equivalent to the current http experience with no indications of security > and no warnings. However, encrypted http:// with insecure elements will > start to produce warnings in the same way a future browser will show > warnings for plain http. As mentioned in my previous response, this gets *really* hairy because the "has insecure elements" part is not a static property that can be determined up front; so, you end up with the problem of sudden and unexpected downgrades and notifying the user only after the confidentiality or integrity of the previously-stored data has been compromised. /mz
Received on Sunday, 14 December 2014 20:08:12 UTC