Clean URL display

[vesta0]

User Story

As a user, I want to see the top-level domain of a site when I look at the address bar without having to tap or scroll, so I easily and quickly know that I am on the site I want to be on.

Acceptance Criteria

• I don't see the scheme (https, http, www) part of the URL until I tap on it
• Users don't lose any security-relevant cues/information (run this by sec-review team)

┆Issue is synchronized with this Jira Task

[vesta0]

We will postpone this work until we have time to think through different use cases and scenarios to make sure we don't create any security risks.

First step would be to discuss with the security team.

[severinrudie]

Chromium has a really good document that covers some best practices for URL elision.

[brampitoyo]

In many ways, Chrome’s approach was inspired by Firefox desktop’s eTLD+1 approach:

The part that’s highlighted in white on desktop, is possibly the only part that we should display on mobile.

[AmyYLee]

@topotropic since she's on search

[dveditz]

The part that’s highlighted in white on desktop, is possibly the only part that we should display on mobile.

Please don't hide significant subdomain labels. Highlighting the "registered domain" (eTLD+1, if you can get that out of Gecko or have a front-end copy of the Public Suffix List) can be helpful drawing attention past spoofy first bits, but the first bits are still significant. mail.google.com is not at all the same origin as docs.google.com. Google is trying to hide "www." and "m." prefixes (jury is out on whether folks will accept that) which might be acceptable, but don't hide anything else.

Your picture shows the full mail.google.com so maybe I took your wording too literally. If so I apologize.

Ambiguous from the picture, but if there is a non-default port you need to show that, too. If a URL has been canonicalized by Gecko then any port that remains will be a non-default one and should be shown. And please show the current Fenix slashed-lock icon (or some equivalent) for any scheme that is not https:.

Another tricky case (but common on mobile) is when the origin is too long for the space. In that case show as much of the "end" of the origin as you can. …aspoof.google.com. If bits get truncated indicate that with ellipses or arrows or even a fade-in. Watch our for RTL languages: "end", not "rightmost". This might be easier to do if you're only showing the origin as you proposed instead of having to line-up the post-host slash.

[brampitoyo]

Hi @dveditz, apologies for not clarifying. I typed the wrong thing.

I totally agree with you that we should never skip showing significant subdomains. The mail in mail.google.com is important. We can argue that hiding “www” may be ok to Google, but “m” or “mobile” I would still consider significant (especially if we’re on a mobile browser).

I showed that in the mobile example – second screenshot – but wrote incorrectly that we should take the desktop approach wholesale. Sorry about that!

Yes, I didn’t show non-https schemes. I agree, in those cases, that a crossed-out lock icon should be shown – which has a red slash to help signify potential danger.

The “origin too long” problem is interesting, and isn’t something I’ve thought of. It will become an issue on our devices, particularly in portrait orientation. I’m happy to take your advise on that.

I am probably still missing a lot of use cases. Can you think of more?

[dveditz]

Ah yes, the second picture looks fine for what it represents in the "normal" case, so let's worry about edge cases.

1. Hiding: personally I don't like hiding any subdomains, even "www", but I don't have a super-strong security argument if it's limited to ONLY "www". We can probably get away with it since Google's doing it. However it will sometimes lead to someone getting a certificate error that says "... not valid for www.foo.com" and the user would then look at the bar and say "but I'm not ON 'www' anything". That will be rare. Chrome users likely wouldn't hit that case because Chrome seems to do some sneaky auto-redirecting when they see a cert that's valid for the form with or without the "www" and they assume you wanted the one with the working cert at the same IP address. I don't see us adding that to Gecko any time soon. Hiding "www" is OK if product folks insist on it.

2. The picture doesn't show a port. They're rare so the example is fine as an example (better, even, for most uses without esoteric edge-case clutter), but I can't tell if you do or don't show ports when they come up. I know I said this earlier but taking the opportunity to reiterate that if the origin has a (non-default) port it MUST be shown.

3. The lock/slashed-lock is fine for hiding https/http. If we ever have to support other schemes you may need to be flexible, especially since many don't have "hosts" you can pull out.

• data: although we don't allow top-level navigation to data: users can still type it in (or on mobile, more likely use a bookmark)
• blob: these come up. The current syntax has an embedded origin (including https vs http) so if you can parse that out it's not terrible to just show the embedded origin as the actual origin. But if you don't do that then blob: URLs will look like they have no "host" so what do you show?
• file: The web can't navigate to a file: URL, and I think currently Fenix doesn't accept external file: url intents, but there will probably be pressure to support displaying local content from other apps. Like blob there's no syntactic host in the URL; unlike blob there's no way to fake one either. What will you do?
• about: we've got a bunch of these we show at various times. Sometimes they're short and showing the whole thing is fine (about:config) and sometimes they have extraneous parameters that make them a mess (about:config?filter=dom.ipc.processPriorityManager.backgroundPerceivableGracePeriodMS)
• moz-extension extensions have their own pages. Probably best to show the name of the WebExtension instead. Caution: prefix "Extension: " before the name so an extension doesn't give itself a name like "mail.google.com"! (you can see this in action on Desktop Firefox with extension pages.)
• resource: and chrome: Perhaps unlikely now that we have WebExtensions rather than legacy extensions, but devs might use them for things from bookmarks so you'll have to handle it one way or another.

I could go on, we will invent new ones in the future, and we're even proposing to allow WebExtensions to be able to add their own handlers (to support dWeb). Most won't have a "host" you can fake--you'll need a plan for these. And for many of them the oddball scheme is actually important and shouldn't be hidden behind a slashed lock that implies "http:". Easiest is perhaps to just show the whole URL if the scheme is not one of a list you have special handling for.

4. We will definitely get URLs that are too long, whether because some domains really are long (https://llanfairpwllgwyngyllgogerychwyrndrobwyll-llantysiliogogogoch.info/ -- yes, it's real!) or because it's a phishing attempt. The best thing is to put the end of the host/port in the end of the display area and truncate from the front. We MUST indicate that bits were truncated. Typically browsers have used ellipsis ('…' character or literal 3 periods) and more recently fadeouts seem to be popular. I suspect fadeouts are bad for accessibility (screenreaders or folks with poor contrast vision), but you could ask the a11y team about that.

5. Watch out for RTL languages, especially when labels are mixed (foo. or .com, or crazier mixing). Since you're not displaying the scheme, path, or other parts of the URL this eliminates many avenues for spoofing. If the host has been canonicalized by Gecko then you should be in reasonable shape. Truncate from the beginning of the string (if necessary) and wrap the whole host in a LTR block per spec.

[kglazko]

For the first PR towards this isse, we are only hiding 'https/http' and 'www' and not shortening/abbreviating any part of the string with ellipses. When testing, please verify that.

[sv-ohorvath]

For the first PR towards this isse, we are only hiding 'https/http' and 'www' and not shortening/abbreviating any part of the string with ellipses. When testing, please verify that.

Verified this is fixed in Beta 4.2.

[Madis0]

How can an user disable this? Setting browser.urlbar.trimURLs to false did nothing.

Lack of the protocol is minor as the security state indicates it more accurately, but lack of www is prone to creating real confusion as the address bar does not indicate the real host the user is on.

[andreicristianpetcu]

Is there a site where www and non-www offer different pages? Is this a purely theoretical situation or do you have a concrete example? @Madis0

[Madis0]

Some school and legacy sites don't work (or redirect) without www.

[blunden]

I also have some personal and test sites that proxy to different locations with and without www. This should absolutely be an option (it's pretty clear from Chrome's change that a sizeable part of the user base hates it). Chrome's similar change is making me strongly consider moving to Firefox (currently evaluating it on the different platforms I use) now that they have removed the option to re-enable it.

[mymedia2]

@andreicristianpetcu

Is there a site where www and non-www offer different pages? Is this a purely theoretical situation or do you have a concrete example?

There is a quite popular OpenNET portal that has different pages www.opennet.ru and opennet.ru.