|Security Improvements to Password Manager|
|Product manager||Lucas Adamski|
|Directly Responsible Individual||`|
|Security lead||Tanvi Vyas|
|Product marketing lead||`|
Stage 1: Definition
1. Feature overview
2. Users & use cases
- Do not autopopulate the username/password stored in password manager for http sites. Provide the multiuser experience seen here. (Note: this is also in the feature page for Highlight Cleartext Passwords.) - https://bugzilla.mozilla.org/show_bug.cgi?id=759860
- If a site is marked STS but a website (or by a user with ForceTLS), then there is no reason to have http data for that site. Hence, if a site sends an STS header, and the user has any data (cookies, passwords, etc) that are not https-only/secure, 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.)
- 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.)
- 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.)
- Don't autofill passwords within frames (similar to the Safari browser's password manager).
- Open Issue - what about third party widgets that allow users to login and post comments.
- If an identical password is stored for both any http site and any https site, prompt the user to redirect to the https site.
- If a password is stored in an http version of a site, see if the https version exists. If it does, prompt the user to redirect to the https version of the site and store their password there instead.
Stage 2: Design
5. Functional specification
6. User experience design
Stage 3: Planning
7. Implementation plan
Quality Assurance review
Stage 4: Development
Stage 5: Release
10. Landing criteria
|Theme / Goal||`|
Team status notes