1767292 - HTTP Auth Dialog doesn't show Scheme

Status: RESOLVED FIXED

(Core :: Networking: HTTP, enhancement, P2)

Description

[Tom Ritter [:tjr]]

Copy/paste login.mozilla.com or type it into the address bar in Firefox and Chrome. Chrome shows you the scheme (it redirects to HTTPS) whereas Firefox does not. Because the address bar doesn't show the URL yet, it would be very nice to show the scheme so one is not left wondering "So... am I on HTTPS or not?"

Comment 1

[Valentin Gosu [:valentin] (he/him)]

Still happens:
https://httpbin.org/basic-auth/user/pass

Comment 2

[Sean Kim]

Attachment: Bug 1767292 - Show scheme for Auth Dialog if HTTP r=Gijs

Comment 3

[Sean Kim]

Seems like a relatively easy fix.

Comment 4

[:Gijs (he/him)]

IIRC the intent was for us to show no scheme but to show the insecure icon for http (indicate insecurity instead of "security") and not train people to rely on https being present (plus the dialog title is shorter and arguably easier for Normal People to follow without the scheme).

I'd sooner fix that if it's not working. Looks like maybe https://searchfox.org/mozilla-central/rev/7e0ae4372c52b8183d1178132dd6493edb576738/toolkit/components/prompts/content/commonDialog.js#82 doesn't get applied for toplevel loads? Seems pretty safe to apply that more widely.

Also, if we want to start showing the scheme then we have to fix the fading for when the origin is too long to display within the bounds of the dialog - right now IIRC we fade-from-start (implementation in adjustableTitle.js), which would end up omitting the scheme still. So in an adversarial situation the patch here would not work well.

Curious what other people think.

Comment 5

[Valentin Gosu [:valentin] (he/him)]

(In reply to :Gijs (he/him) from comment #4)

IIRC the intent was for us to show no scheme but to show the insecure icon for http (indicate insecurity instead of "security") and not train people to rely on https being present (plus the dialog title is shorter and arguably easier for Normal People to follow without the scheme).

I'd sooner fix that if it's not working. Looks like maybe https://searchfox.org/mozilla-central/rev/7e0ae4372c52b8183d1178132dd6493edb576738/toolkit/components/prompts/content/commonDialog.js#82 doesn't get applied for toplevel loads? Seems pretty safe to apply that more widely.

When navigating to from https://example.com to http://httpbin.org/basic-auth/user/pass it shows the scheme in the URL bar, but still a lock icon.

Also, if we want to start showing the scheme then we have to fix the fading for when the origin is too long to display within the bounds of the dialog - right now IIRC we fade-from-start (implementation in adjustableTitle.js), which would end up omitting the scheme still. So in an adversarial situation the patch here would not work well.

That's a fair point, though adding the scheme to the dialog doesn't make it so much worse.
In the end I think this is a minor change that improves the dialog regardless of whether the URL bar works correctly or not. We can make sure the lock icon appears correctly, but I think this patch might also be valuable.

Comment 6

[Valentin Gosu [:valentin] (he/him)]

Attachment: URL bar showing lock icon and http scheme

Comment 7

[:Gijs (he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #5)

(In reply to :Gijs (he/him) from comment #4)

IIRC the intent was for us to show no scheme but to show the insecure icon for http (indicate insecurity instead of "security") and not train people to rely on https being present (plus the dialog title is shorter and arguably easier for Normal People to follow without the scheme).

I'd sooner fix that if it's not working. Looks like maybe https://searchfox.org/mozilla-central/rev/7e0ae4372c52b8183d1178132dd6493edb576738/toolkit/components/prompts/content/commonDialog.js#82 doesn't get applied for toplevel loads? Seems pretty safe to apply that more widely.

When navigating to from https://example.com to http://httpbin.org/basic-auth/user/pass it shows the scheme in the URL bar, but still a lock icon.

You're talking about the identity block in the address bar, I was talking about the dialog itself, right next to where you're proposing we show the scheme. The identity block is bug 1809841, after bug 791594 covered updating the address bar (fixed after this bug got filed, as comment 0 indicates it wasn't updating at all).

I'm still a bit hesitant here because I was under the impression that longer term we're not that interested in showing "https://" in the address bar as a positive security indicator (ditto lock icon, as opposed to broken/slashed lock icon and/or "http"). Changing the dialog to always show the scheme would go in the opposite direction, and need changing again later (separate from the address bar).

The other thing to note is that we have a utility function we use for fxview and downloads, https://searchfox.org/mozilla-central/rev/f0b3dafb55f1e7904847f5dc889f131040789ba6/toolkit/modules/BrowserUtils.sys.mjs#220,234 , which can be called to include the http:// protocol but omit https, which may be a useful compromise.

Comment 8

[:Gijs (he/him)]

Attachment: Screenshot of insecure login dialog

This is what things look like for http subresource (iframe) requests today.

Comment 9

[Sean Kim]

In a user's point of view, I still think it would be great if there were a way to tell if it is http or https (directly), for example by hovering over the lock icon.

Comment 10

[Tom Ritter [:tjr]]

(In reply to :Gijs (he/him) from comment #8)

This is what things look like for http subresource (iframe) requests today.

This looks good, and I like it. I agree with Sean that hovering over the icon should have a tooltip saying something like "Insecure blah blah"

For what my opinion is worth anyway - I just wanted some way to know before I typed my password in. I don't like putting my finger on the scale of UI/UX decisions too much unless the people in charge of those areas explicitly ask me in a formal capacity :)

Comment 11

[Sean Kim]

Noticed an interesting behaviour. When I tried to run ./mach run http://httpbin.org/basic-auth/user/pass, I noticed that args.channel.URI.prePath is set to https://httpbin.org instead of http (url bar still says http://httpbin.org/basic-auth/user/pass). Is this an intended behaviour? If I try to visit http://httpbin.org/basic-auth/user/pass from anywhere else it is http.

Changing URI to originalURI seemed to fix this issue.

Comment 12

[:Gijs (he/him)]

(In reply to Sean Kim from comment #11)

Noticed an interesting behaviour. When I tried to run ./mach run http://httpbin.org/basic-auth/user/pass, I noticed that args.channel.URI.prePath is set to https://httpbin.org instead of http (url bar still says http://httpbin.org/basic-auth/user/pass). Is this an intended behaviour?

Is https-first/only definitely not turned on? This seems like a networking question, I don't really know what would cause the channel URI to be different from the URL bar here... if you "complete" the navigation by putting in a user/pass, do you end up on https or http, and does the URL bar update then?

Comment 13

[Sean Kim]

(In reply to :Gijs (he/him) from comment #12)

(In reply to Sean Kim from comment #11)

Noticed an interesting behaviour. When I tried to run ./mach run http://httpbin.org/basic-auth/user/pass, I noticed that args.channel.URI.prePath is set to https://httpbin.org instead of http (url bar still says http://httpbin.org/basic-auth/user/pass). Is this an intended behaviour?

Is https-first/only definitely not turned on? This seems like a networking question, I don't really know what would cause the channel URI to be different from the URL bar here... if you "complete" the navigation by putting in a user/pass, do you end up on https or http, and does the URL bar update then?

The issue I mentioned was due to system prefs, which I think was expected. If we navigate to http://httpbin.org/basic-auth/user/pass through the URL bar, it does show up the broken favicon. It should end up on https or http, depending on how URI's scheme (not originalURI), at least based on what I just tested.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c605e28269c2
Show scheme for Auth Dialog if HTTP r=Gijs

Comment 15

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/c605e28269c2

Comment 16

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/417a62178901
Backed out changeset c605e28269c2 for causing beta-sim failures CLOSED TREE

Comment 17

[Cristian Tuns]

Backed out as requested on Slack by Sean Kim
Backout link: https://hg.mozilla.org/integration/autoland/rev/417a62178901

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/11e6ace988c1
Show scheme for Auth Dialog if HTTP r=Gijs

Comment 19

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/11e6ace988c1