On 11/04/12 08:54, Jesse Ruderman wrote:
1) If a site sends an STS header, and the user has any data (cookies, passwords, etc) that are not https-only, immediately mark that data as https-only. (This helps if a site uses STS, but the user's privacy settings cause the password storage to outlive the STS storage.)
Sounds sensible.
2) When clearing history, retain the STS bit if any other data associated with the site is retained. For example, in the common case of clearing all history other than passwords, retain the STS bits for sites that have passwords stored. (This accomplishes roughly the same thing as #1.)
That too. If the aim of clearing history is to hide the fact that you've visited a site, then that fact is not hidden if you have a stored password for it. Given that, there is no additional privacy issue with retaining STS data also.
3) If you have a password stored for http, and you log into the same site using https, move the password to https-only. (This helps if a site moves from http to https, but does not set STS.)
I think this behaviour might lead to user confusion. It will look like "autofill stopped working on this site", whereas what actually happened is that, just once, they clicked on an HTTPS link to visit the site rather than HTTP.
5) If an identical password is stored for both any http site and any https site, and it is not used on the http site for 16 months, expire the http version. (This helps in cases where the hostname has changed, e.g. from mail.google.com to www.google.com, and the security level has also changed.)
I like that.
6) When connected to an untrusted wireless network, don't fill in passwords.
If only we could tell! :-) Can we? Gerv _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
