1607171 - Confusing combination of subdomain password suggestions in framed contexts

Status: RESOLVED WONTFIX

(Toolkit :: Password Manager, task)

Description

[Shane Selby]

Attachment: Incorrect-passwords.jpg

Hi

I'm concerned that you have a bug which means people could be submitting passwords from one website to another website. This could potentially mean a malicious website could store these log in details that were not meant for them once submitted.

I have attached a screenshot. You will see I am on the website https://support.jungledisk.com but it is giving me suggestions from paymentsense.zendesk.com

Comment 1

[:Gijs (he/him)]

If you right click the input box, you will see the context menu has a "this frame" entry. If you open that submenu and click "Show only this frame", you'll get jungledisk.zendesk.com opened in a new tab. The login experience (and I suspect, most of the site) is provided by zendesk. That's why other zendesk passwords are being suggested. There's no security hole here.

There clearly is some confusion, and we should look into what we can do about that, if anything...

Comment 2

[Shane Selby]

When I view the information for this frame it says the URL is:

https://jungledisk.zendesk.com/auth/v2/login/signin?return_to=https%3A%2F%2Fsupport.jungledisk.com%2Fhc%2Frequests&theme=hc&locale=en-us&brand_id=377894&auth_origin=377894%2Ctrue%2Ctrue

It seems to be making password suggestions from all subdomains of zendesk.com rather than that of just jungledisk.zendesk.com. It never used to do this. Has this been introduced in a new update?

Comment 3

[Adrian Florinescu [:aflorinescu]]

(In reply to Shane Selby from comment #2)

It seems to be making password suggestions from all subdomains of zendesk.com rather than that of just jungledisk.zendesk.com. It never used to do this. Has this been introduced in a new update?

Yes, check the blocking bug (bug 589628).
It won't hurt to double check if setting signon.includeOtherSubdomainsInLookup preference in about:config to false reverts to the old functionality showing only the jungledisk.zendesk.com credentials.

Comment 4

[Shane Selby]

Ok. I guess this can be marked as complete then. I think for your average non-technical user though this change is completely different to how browsers have worked in the past and could be confusing.

Comment 5

[Matthew N. [:MattN]]

Attachment: Screen Shot of same behaviour from Safari 13.0.4

(In reply to Shane Selby from comment #4)

Ok. I guess this can be marked as complete then. I think for your average non-technical user though this change is completely different to how browsers have worked in the past and could be confusing.

Actually this behaviour has been in Chrome and Safari for years, Firefox was just behind on implementing it.

Comment 6

[Matthew N. [:MattN]]

Attachment: Screen shot of same behaviour from Chrome 80.0.3987.16

Comment 7

[Matthew N. [:MattN]]

We are at parity with Chrome and Safari and I don't have any good ideas to address this that balances the convenience of access when it is appropriate to use the login from a subdomain. e.g. I don't think a modal confirmation dialog when using a login from a different subdomain is the right balance.

Zendesk could fix this themselves by adding zendesk.com to the Public Suffix List but there are other consequences to that.

Given that we are parity with other browsers and we don't have plans to address this, I will mark it as WONTFIX for now. We can re-open if someone makes a reasonable UX proposal.

Comment 8

[Daniel Veditz [:dveditz]]

Right, zendesk.com can't add itself to the PSL without messing up its own sites. They would have had to plan ahead to set up customer sites another subdomain deep or a completely different domain (like github.com has done with *.github.io)

Comment 9

[Shane Selby]

Ok. Thanks for your help, this clears things up.