1598175 - (urlbar-truncate-desktop) Potential origin spoofing because address bar truncates or elides parts of the domain (e.g. "facebook.com.evil.com" to "facebook.com..." instead of "...evil.com")

Status: NEW

(Firefox :: Address Bar, defect, P2)

Description

[Chris Peterson [:cpeterson]]

When the browser window is narrow, Firefox's address bar truncates "http://facebook.com.evil.com/" to look like "facebook.com..." instead of "...evil.com".

Chrome, Safari, Edge, and IE11 all have this same address bar behavior:

https://twitter.com/bcrypt/status/1197033834916630528

Comment 1

[Chris Peterson [:cpeterson]]

The URL standard says:

When the full host cannot be rendered, browsers should elide domain labels starting from the lowest-level domain label. For example, examplecorp.com.evil.com should be elided as ...com.evil.com, not examplecorp.com....

https://url.spec.whatwg.org/#url-rendering-elision

Comment 2

[Marco Bonardo [:mak] (Away 10-21 August)]

it's interesting that there's a standard on how to elide URLs, and you point out this affects every browser, so it must not be well known.
It may not be trivial to address this without breaking some things like drag-selecting a part of the url and avoiding too much url jumping-around on focus.
Bug 1598563 here could help a little bit, by making the urlbar be one of the last things shrinking. But obviously one could build a long enough sub domain to push things out of the view.
I also wonder if we could improve the tooltip when the url overflow, we currently show the full url, we could make it multi-line and show the origin too, or we could deemphasise the tooltip to make the origin more visible. It would only be visible when hovering it with the mouse though.

It sounds like this is an interesting problem, requiring also some UX evaluation.

Comment 3

[Chris Peterson [:cpeterson]]

I tested Fennec, Fenix, and Chrome on Android. Fennec and Chrome do the right thing (showing ...ook.com.facebook.com.evil.com and facebook.com.evil.com respectively), but Fenix does not (http://facebook.com.facebook...). I filed a new Fenix UI bug:

https://github.com/mozilla-mobile/fenix/issues/6762

Comment 10

[Stephanie Cunnane [:scunnane]]

We should add a test that covers the case illustrated by Daniel's example above.
We need some discussion with UX to elide the URL and see if the standard works well on the tested platform.

Comment 13

[Marco Bonardo [:mak] (Away 10-21 August)]

There's also RTL issues involved here. The problem is the visual representation of a bidi string may move the domain around depending on the presence of one or multiple strong directionality characters.
We have some code trying to predict the position of the domain (start or end), but it's not good enough, bidi rules are more complex (may indeed also end up in the middle).

To solve both problems we may try to use a SELECTION for the domain (pretty much inverting the current situation where we select all the rest to de-emphasize) and use/fix scrollSelectionIntoView of the editor to ensure it is visible.
We could also move the cursor position to the start of the domain, though currently some code (e.g. switching to a tab that had autofill in the urlbar) depends on us preserving the cursor position on blur.

Comment 20

[Marco Bonardo [:mak] (Away 10-21 August)]

note there is a patch improving this in Bug 1986161 (it just needs a fix for a rounding mistake, and maybe a followup to make the dissolving gradient smaller and more subtle so characters remain readable), before we move on here I'd like to know what's the plan of action.

Comment 21

[Daisuke Akatsuka (:daisuke)]

Oh, I see. Thank you for the information, Marco!
Since I have almost finished writing the patch, I will attach the patch later. I am glad if my patch will help bug 1986161.
(And I will clear this assignee later, after pushing my patch).

Comment 22

[Daisuke Akatsuka (:daisuke)]

This is the patch. https://phabricator.services.mozilla.com/D278419

Comment 23

[Daisuke Akatsuka (:daisuke)]

Attachment: WIP: Bug 1598175: Ensure to show the base domain

Comment 24

[Daisuke Akatsuka (:daisuke)]

Hi Marco!
How is bug 1986161?? If the bug can continue, I will unassign myself again from this.

Comment 25

[Marco Bonardo [:mak] (Away 10-21 August)]

(In reply to Daisuke Akatsuka (:daisuke) from comment #24)

Hi Marco!
How is bug 1986161?? If the bug can continue, I will unassign myself again from this.

if you have time to update the patch there (while maintaining the original author) to not fail the test, please do and land it. I think it's just a rounding issue. After that lands you can re-evaluate if there's parts of this still useful to land on top.

Comment 26

[Daisuke Akatsuka (:daisuke)]

Hi! I will take a look at bug 1986161.

Comment 27

[Marco Bonardo [:mak] (Away 10-21 August)]

Bug 1986161 landed, and afaict it fixed the most common cases, still TBD if it addressed all the edge cases with RTL (I couldn't find a broken case so far).