Closed Bug 1174361 Opened 6 years ago Closed 5 years ago

Return both HTTP and HTTPS logins for a domain

Categories

(Toolkit :: Password Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: tanvi, Unassigned)

References

Details

If a user visits a domain that has both HTTP and HTTPS records stored in the database, return both to the user.

In bug 667233 we do the following:
* Autofill HTTP on HTTPS if there is no HTTPS record:
If no HTTPS logins exist for an HTTPS page, see if any HTTP logins exist and return those.  If there is one login, it will be autofilled. If there are multiple logins the user can select one from the autocomplete drop down and then the password for that login will be filled.

* Autocomplete HTTPS on HTTP if there is no HTTP record:
If no HTTP logins exist for an HTTP page, see if any HTTPS logins exist.  If one or more HTTPS login does exist, allow the user to select one from the autocomplete drop down and then the password for that login will be filled.

This bug would improve upon that experience by returning both the HTTP and HTTPS logins (for autofill on an HTTPS page and autocomplete on an HTTP page) deduped.  So that means:
* On an HTTPS page, search for both HTTP and HTTPS logins.  If there are logins where the usernames match, define a heuristic to dedup them[1].  Return all the possible logins.  If there is one login returned, autofill it.  If there is more than one, allow the user to autocomplete the username and then automatically fill the password.
* On an HTTP page, search for both HTTP and HTTPS logins. If there are logins where the usernames match, define a heuristic to dedup them[1].  Return all the possible logins.  If there is only one login returned AND that login is associated with the HTTP login entry, autofill it.  Otherwise, allow the user to autocomplete the username from the login(s) provided and then automatically fill the password.

See more discussion on this in https://bugzilla.mozilla.org/show_bug.cgi?id=667233 comments 35, 36, 38, 39.

This would be an enhancement to the policy laid out in https://etherpad.mozilla.org/same-domain-http-https-passwords4

[1] How do we dedup if an HTTP entry and an HTTPS entry have the same username?  A few options:
* Choose the most recent entry and return that.
* Choose the entry associated with the scheme on the document.  So if the page is HTTP, return the HTTP entry.  If the page is HTTPS, return the HTTPS entry.
* Always prefer the HTTPS entry. (This doesn't work out so great if there is one HTTP entry and one HTTPS entry for the same username on an HTTP page.  We will end up going through the autocomplete experience when the user could have gone through the autofill experience with the HTTP password.)

Do we first see if the passwords match on both of login entries?  If they do, it doesn't matter which one we disregard.  Or do we perform the dedup'ing step regardless of the password value?
Some more thoughts on this from bug667233 comment 39
(In reply to Tanvi Vyas [:tanvi] from comment #39)
> Here are the cases to consider if we want to return both HTTP and HTTPS
> logins:
> 
> 1) Only HTTPS logins exist
> Easy, return all HTTPS logins (current patch does this)
> 2) Only HTTP logins exist
> Easy, return all HTTP logins (current patch does this)
> 
> 3) One HTTPS login exists and one HTTP login exists with the same username
> Return the HTTPS login
Or use most recently updated?  Or follow the scheme of the documentURI?  Depends on dedup'ing heuristic.
> 
> 4) One HTTPS login exists and one (or more) HTTP logins exist with a
> different username
> Undecided.  If we return the HTTP logins along with the one HTTPS login, the
> user will experience autocomplete instead of autofill.  So either
> i) Just return the HTTPS and user gets autofill
> ii) Return the HTTP and HTTPS logins deduped and user gets autocomplete
> 
> 5) More than one HTTPS login exists and one or more HTTP logins exist.
> Return the HTTP and HTTPS logins deduped and user gets autocomplete
> 
> I still think it makes more sense to handle the full policy and then dive
> deeper to further optimize.
Depends on: 1272507
(In reply to Tanvi Vyas - behind on reviews [:tanvi] from comment #0)
> * On an HTTP page, search for both HTTP and HTTPS logins. If there are
> logins where the usernames match, define a heuristic to dedup them[1]. 
> Return all the possible logins.  If there is only one login returned AND
> that login is associated with the HTTP login entry, autofill it.  Otherwise,
> allow the user to autocomplete the username from the login(s) provided and
> then automatically fill the password.

Hey Tanvi, I think this downgrade via autocomplete experience is the only part not implemented in bug 667233. Do we still want to do this given that Let's Encrypt has now launched and providing free TLS certificates?
Flags: needinfo?(tanvi)
(In reply to Matthew N. [:MattN] (behind on reviews) from comment #2)
> (In reply to Tanvi Vyas - behind on reviews [:tanvi] from comment #0)
> > * On an HTTP page, search for both HTTP and HTTPS logins. If there are
> > logins where the usernames match, define a heuristic to dedup them[1]. 
> > Return all the possible logins.  If there is only one login returned AND
> > that login is associated with the HTTP login entry, autofill it.  Otherwise,
> > allow the user to autocomplete the username from the login(s) provided and
> > then automatically fill the password.
> 
> Hey Tanvi, I think this downgrade via autocomplete experience is the only
> part not implemented in bug 667233. Do we still want to do this given that
> Let's Encrypt has now launched and providing free TLS certificates?

We don't want to downgrade.  If we have a saved login for HTTPS, we should not make it available in any form to the HTTP page.

If the user really wants to obtain the login information, they can go to the Password Manager Management interface and view it there.
Flags: needinfo?(tanvi)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.