Note that the eTLD+1 may be off-screen until we fix Issue 527638 (Omnibox doesn't elide origin/host from the left on desktop).

I don't see anything here that really has to do with Safe Browsing; simplifying to a single component.
(Feel free to restore if there's a reason.)

yes, we need to elide properly as well. Let's do both -- I don't think they are dependent though.

One more suggestion: I do think the subdomain is useful for users in some cases. Maybe we could leave it black based on site engagement. e.g. I'd guess that many users would want to see these clearly differentiated: {calendar,contacts,photos,www,inbox}.google.com

Right, there's a ton of history here.  The fundamental reason we didn't do this before is cases like comment 4: users are actively confused by showing calendar versus mail as "google.com", because they don't think of those sites as the same, or either of them as the same as "google.com" itself.  But in other cases the subdomain is only about as worthwhile as the path.  We didn't have machinery that could distinguish, and we ended up deciding this was a usability-vs.-security tradeoff and went with usability.  Using site engagement to distinguish is possible; some sort of server-side signal might also be possible.  Of course, maybe distinguishing based on a heuristic is even more confusing and frustrating.

So when evaluating reversing this, you'd want to check whether this change hinders usability in any way or makes the browser feel buggier.  And of course things like the accessibility (contrast ratio) of your gray text, which I suspect is too low today for the path portion.

Note that Firefox already dims everything but the eTLD+1; we can try to learn from their experience.


The path (at least on my Mac) in non-incognito is #808080, which has a contrast ratio of 3.9:

https://leaverou.github.io/contrast-ratio/#white-on-%2380808

3 is the usual minimum recommendation, while 4.5 is good to aim for:
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html
So I would say our contrast is not too low, but definitely near the edge.

*puts on crazy idea hat*
What about making the eTLD+1 **bold** to make it stand out, instead of dimming the rest?

Deleted: regular.png 354 KB

	regular.png 354 KB View Download

Deleted: bold-domain.png 355 KB

	bold-domain.png 355 KB View Download

Deleted: dimmed-subdomain-bold-domain.png 354 KB

	dimmed-subdomain-bold-domain.png 354 KB View Download

Other browser vendors decided to make different tradeoffs here than we did -- our assertion at the time was that they were wrong, and we were right.  We may have been incorrect in that assertion.  I don't know that anyone has tweaked anything or the landscape has changed in the time since.

We are coming up with a research proposal now to test some of these ideas (does it make the domain less phishable), will share as soon as it's ready.

Google-internal doc: https://docs.google.com/document/d/1-73dBASs8leGj_59LgJVGFdBjSPUUXUvXo_Aa4xQrNM/edit# ("Hiding Path during High-Risk Moments
")

Preliminary results show that showing the eTLD+1 instead of the domain is not *more* meaningful users.

We may want to explore using it to save space for some surfaces in the future, but I think we should WontFix this once we have the full study data. Any objections?

martinshelton@: Is there something you can post here publicly about how this didn't pan out for us?

I'd like to share the eTLD+1 formatting results as part of a larger scale work in progress!

Setting to WontFix for now. If we find a format that seems to be a significant improvement in user studies, we can reopen and pursue an implementation.