This bug has already been made public and we have similar bugs on other Chrome variants that are public, but I'm marking as a security bug out of an abundance of caution. Technically this is high severity according to our guidelines.

cjgrant, is your URL elision work going in a direction where it could be re-used on Chrome Custom Tabs?

More than the eliding logic, it seems like LocationBarLayout.splitPathFromUrlDisplayText(String) is not working correctly which has been our shared code within Android for getting the domain for a while. So even if we did have enough space, we were going to show the wrong domain if I am understanding this correctly.

I would be happy to update it if we believe this is high severity, but I probably will need some direction on what logic to use.

Re #2: The text displayed in this scenario is part of the Hostname component of the URL; the path is not shown. 

The problem is that the Hostname component exceeds the width of the display area, allowing truncation of the displayed text to result in spoofing.

But the hostname should have included verifcheck.com right? What I mean is if we only change the eliding logic and not change how we get the hostname, it will still be incorrect.

Re #4: The hostname /does/ include the "-webapps.verifcheck.com" text, but that text isn't visible in portrait mode due to truncation. If the device is rotated to landscape mode (such that there's more horizontal display area) it is not truncated.

estark, to your question of whether reworked elision code could help here:

This field is Android UI, so AFAIK, its font rendering is Android-specific, and does not use gfx::RenderText (the mechanism elision uses to measure rendered text size).

In theory, and in *general*, Android Java code could call C++ eliding methods with a callback to some Android text measurement system, but that sounds like a long-shot.  In the Android omnibox case, I have no idea how much field/font/UI magic is going on behind the scenes.

cc'ing fgorski@, who may be able to expand on this.

Adding owners to CC: Ted and Theresa.

Had a quick look:

If I understand the code correctly, the URL is shortened in: 
UrlBar#limitDisplayableLenght()

If I understand that code correctly, we might have the following problems:
* We are eliding the text based on the length of char sequence, and not available display frame.
* allowed string size before we elide is pretty big: 1000 on low-end, 4000 elsewhere.
* We are eliding someplace the middle of allowed span, leaving around max length of characters (therefore no effect for the URL above).
* We are using custom code. :(

I think it should be possible to elide based on display frame size (at the cost of extra IPC), with elision span starting right after the https://, but that would still be custom code.

fgorski, separate from issues with the current custom code, there's the question of whether we can ultimately unify the elision code used here and elsewhere.

There's some work going on to make C++ elision code more generally usable.  If it were possible to have the Android omnibox call to C++ for URL shortening, one implementation could disappear.

When you said "extra IPC", were you referring to JNI calls, or something else unrelated?

I think Ted and the UI team is already planning to reuse as much of common C++ code and I would expect that applies to elision as well. It may take time. In any case Theresa and Ted are the best people to ask here.

RE: extra IPC. My comment is based on the View#getWindowVisibleDisplayFrame documentation:
...
This function requires an IPC back to the window manager to retrieve the requested information, so should not be used in performance critical code like drawing.

(This says don't do it, but it would be a trade-off between security and performance, and I think it could be done once and cached) 

https://developer.android.com/reference/android/view/View.html#getWindowVisibleDisplayFrame(android.graphics.Rect)

Also, that is the first idea that came to mind, so perhaps there is a better way of arriving that that information.

Custom Tabs and Chrome should both be calling UrlBar#scrollToTLD.  It seems like that isn't working reliably enough.  Tommy changed that most recently, so again, I'll defer to him initially.

tommycli: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

When I worked on scrollToTLD, it did seem kind of flaky sometimes. It's possible our efforts to fix the RTL hostname case made the base use case flakier.

This is a tough nut to crack.

tommycli: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I landed a fix for omnibox alignment on Android, which should fix this:
https://chromium-review.googlesource.com/c/chromium/src/+/677881

This bug requires manual review: M63 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

No merge needed.  My fix landed in 63.0.3223.0

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot