How does the navigation bringing back the URL mitigate the issue? Wouldn't it be trivial for a page to just intercept a link click and not trigger an actual navigation but pop in a fake omnibox today?

Only an HTTPS page could.

In today's Stable Chrome, only an HTTPS page could intercept a link click and show a fake omnibox?

No, that's what the suggested mitigation for #3 would provide.

Ah I see. I'd be hesitant to try to mitigate HTTP sites pretending to be HTTPS sites by always showing the URL bar as this would represent a significant usability regression for HTTP sites, e.g. articles. For smaller phones, this could reduce the available viewport substantially.

In any case - this issue is applicable to both Chrome and non-Chrome-Home right?

There are some issues now (e.g. using fullscreen to spoofing), and Chrome Home doesn't affect them much.

However, I have one specific scenario in my mind:

- The user navigates from https://trusted.com to http://unencrypted.com
- unencrypted.com shows a fave omnibox at the top of the screen, spoofing https://secure.com. Since the user is familiar with an omnibox at the top (either from other browsers, or from experience with older Chrome versions), they don't notice the real omnibox at the bottom (perhaps they clicked a link near the top of the screen, and their hand is covering the real omnibox).
- The users scrolls around a bit and the real omnibox moves out of view.
- Now unencrypted.com can capture scroll events and spoof any site it wants, as long as it wants.

In *addition*, since unencrypted.com uses HTTP, anyone on the same network also has the same power.

If the omnibox is always shown, then the site will have to distract the user from the real omnibox 100% of the time, not just at initial load. Enforcing this for HTTP takes the new spoofing power away from local attackers.

I was hopeful that Bijou would obviate origin display problems [1] by showing a separate and/or persistent URL bar, like Safari does now (see safari-minimal.jpg), but it seems we're not going in that direction.

[1] Also see Issue 454529 (Origin in omnibox on iOS can be extremely small).

Deleted: safari-normal.jpg 90.7 KB

	safari-normal.jpg 90.7 KB View Download

Deleted: safari-minimal.jpg 83.0 KB

	safari-minimal.jpg 83.0 KB View Download

Here's how it looks.

Deleted: top-omnibox-spoof-720p.mov 25.8 MB

top-omnibox-spoof-720p.mov 25.8 MB Download

Lucas, I'm trying to understand what it is about Chrome Home that makes this spoof possible. Is there a change in when the omnibox is visible, or is the difference just that the omnibox is less noticeable because it's covered by one's hand?

Thanks for the demo. To clarify, Chrome Home makes the risk of faking the omnibox slightly larger though the risk has always been present, correct?

For example, in today's Chrome:
- The user navigates from https://trusted.com to http://unencrypted.com
- unencrypted.com points the user to content below the fold
- user scrolls down and real omnibox moves out of view
- Now unencrypted.com can capture scroll events and spoof any site it wants, as long as it wants.

> is the difference just that the omnibox is less noticeable because it's covered by one's hand?

Just this part (combined with a long transition period where it will still look natural for users to see an omnibox at the top).


To continue here instead of the email thread:
Stepping back a little from this specific bug, it's not that the state before Bijou was perfectly acceptable and that Bijou crossed some unreasonable threshold.

However, we've known for a long time about issues with the mobile omnibox: it's easy to spoof in certain situations [1], and it can sometimes be extremely narrow [2]. palmer@ and I have pointed to Safari's approach as a pretty good solution. As described by palmer@ in [2], this is what Safari does:

> I am happy to be of help in finding a solution! FWIW I quite like Safari's behavior on iOS:
> 
> * Portrait Mode: Normal view, with toolbar/location bar, editable location
> 
> * Portrait Mode after scrolling down: half-size, non-editable origin display (incl. tiny security lock for HTTPS); tap to show full-size editable location bar
> 
> * Landscape Mode: No toolbar/location bar; content gets full screen
> 
> * Landscape Mode after scrolling up to top: Normal view with toolbar/location bar, editable location

However, all our bugs/threads about this were basically answered with "let's not address this individually,lpeople are working on a big redesign to re-imagine Chrome's mobile UI" – which is what became Bijou.

Some explorations of Bijou experimented with a more Safari-like design [3]. However, it seems that none of Enamel's long-standing concerns with the mobile omnibox were addressed in the final version of Bijou. And if Bijou launches without them, I worry there will be pushback to address these issues with with any additional UI layout changes in the next few years.


[1] Issue 640641
[2] Issue 454529
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=640641#c12

Thanks for the additional context.

I don't think the notion of a URL mini-bar at the top has been dropped entirely. We are still considering it and we can take your points into account as well.

Ah, that's interesting to hear! What's the timeline for Bijou experimentation?

Another way this manifests itself: I'm used to scrolling the page to the top, and then tapping the thing that looks like an omnibox at the top. For google.com, the top of the page *is a search bar*. I'm finding myself accidentally trying to use it to enter a URL I want to navigate to. :-(

Anecdata, for what it's worth, I've had this experiment enabled for a week and I'm still looking to the top for the omnibox. I worry that this might end up my experiments with Dvorak keyboard layouts-- prone to failure because I can't enable the change across all of my devices.

We're enabled for Googlers currently and we plan on doing experimentation in M60.

Is the bottom URL bar still under experimentation? Otherwise seems this bug is no longer applicable and should be WontFix-ed

@27 No, Chrome Home is being turned down. Marking WontFix.