New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 63 users

Issue metadata

Status: Fixed
Closed: Dec 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Issue 453093: Render chrome-extension:// page URLs similar to EV cert URLs + omnibox suggestions

Reported by, Jan 28 2015 Project Member

Issue description

What steps will reproduce the problem?
1. Install an extension
2. To to an extension's page; a good way to do this is to install linkclump then go to chrome-extension://lfpjkncokllnfokkgpkobnkbkmelfefj/pages/options.html

What is the expected output? What do you see instead?
There are trusted URLs since they're hosted locally, the packages are signed, etc. I don't see why they shouldn't effectively look like EV certs - and they'd look a lot better. That's mostly my motivation here.

I've attached a mock. The blue background is there to be consistent with how the extension omnibox API looks, see

Peter, Ryan, thoughts?
13.8 KB View Download
11.0 KB View Download

Comment 1 by, Jan 28 2015

(I faked the mock using the omnibox API + gimp, not intended to be pixel perfect)

Comment 2 by, Jan 28 2015


Comment 3 by, Jan 28 2015

I don't think the extension ID is meaningful, so I'd prefer to leave the whole extension URL grey.

I'm less certain what I think about the chip UI.  It seems like maybe a good thing, but what icon to use and what should happen when it's clicked are somewhat unclear.  I'd get the UI leads' input.

Comment 4 by, Jan 28 2015

Labels: Cr-Security-UX
EV certs are considered EV certs because they've gone through extensive vetting for every piece of information that is presented to the user. Reasonable people may disagree on how valuable that vetting is, but there is a tangible difference.

What information present in the origin chip has undergone any vetting? AIUI, the only information we vet re: Chrome Web Store is that the developer's email address is authorized. Plenty of extensions can claim to be the same extension (name), even if they have different IDs.

I don't think I'd be comfortable with this on principal that we're presenting as trustworthy information that's suspect.

Comment 5 by, Jan 28 2015

Just my $0.02, but I don't think these should be compared directly to EV certs (and don't think they should look like them).  In the mocks, they don't look overly like EV certs - they aren't green, they don't show the lock, etc.  I wouldn't want a change that decorated it with a trusted ev cert look - but adding the extension name, I think, is a positive.

Comment 6 by, Jan 28 2015

I'm more concerned how our users will perceive them. Showing such attributable information has generally been only when we've had high-confidence, and only when we include enough information to disambiguate (e.g. we show the company name, but ALSO the jurisdiction of incorporation to avoid PayPal [US] vs PayPal [GB] vs PayPal [ROU])

Comment 7 by, Jan 28 2015

> undergone any vetting

The vetting is indeed that the developer gives a name for their extension, and a registered domain for that extension, and users are expected to figure that out. The webstore doesn't do any kind of EV cert verification, so apart from the extra hoops, yes it's mostly equivalent to a normal cert.

Though, "vetting" could also be considered including our ability to reject and take down extensions which pretend to be what they're not.

And the fact that the user has a finite (presumably small) number of extensions that they've installed and therefore implicitly trust.

As Devlin said, perhaps EV cert was a bad place to start here - it's more about better attribution, we have more information here than just a URL.

> I don't think the extension ID is meaningful, so I'd prefer to leave the whole extension URL grey.

The ID is meaningful insofar as it defines the origin. On the web the origin is black and the path is grey, it would be consistent to have the ID black and the path grey for extensions.

Comment 8 by, Jan 28 2015

Well, we do show the extension name in a lot of places already today instead of the extension ID (e.g. AwesomeExtension wants to share your screen. Allow?), so there is certainly precedent for it.

Comment 9 by, Jan 28 2015

The only reason we have a black origin on the web is because it's useful information that people want to know at a glance.  That's not true of extension URL IDs, which is precisely why we (intentionally, after discussion with the security and UI leads) changed them from being highlighted the way you suggest to the all-grey version several years ago.

Comment 10 by, Jan 28 2015

Ok, that makes sense. My UI sensibilities tell me that while at a glance I don't care whether the ID is "aggdlhmifdpeipmoahelhnnpaacohacc" or "lfmojoalgoidelelengokdngcemhnael" it's still a nice separation between <entity> and <path within that entity>. That's always how I thought about the highlighting on the web.

E.g. I don't much care about the difference between and but it's still nice seeing the origin in black like that.

I can see this question coming back to one we've discussed before; whether the ID should simply be replaced by the extension's name, which has a different set of issues.

Comment 11 by, Jan 29 2015

I like the idea of showing the extension name, because it is more meaningful than the extension ID.

But I do not like the idea of showing it in a place that makes it seem like it is a trusted string (which it isn't). The origin is meant to be sacrosanct, and the EV name is supposed to be meaningful (albeit still imperfect).

I don't have any better suggestions for where to put it unfortunately.

Comment 12 by, Jan 29 2015

Maybe if I hadn't mentioned "EV cert" and instead mentioned "same rendering we use for the omnibox API attribution" (which is what I had in mind) - would that change things? The former is green, the latter blue, for what it's worth (and I actually think not-a-whole-lot without any context - but at least it's not totally wrong).

That said, I do actually think that the string could be considered trusted, just not by the same mechanism as EV certs, because it's what the user chose to install (and which we have the power to take down if it's found to be bad), it can't be anything else.

Comment 13 by, Jan 29 2015

AFAIK nothing else is put in a chip like that except EV certs and Chrome-trusted strings (for chrome://flags etc.).  are there others that i'm not aware of?

Comment 14 by, Jan 29 2015

When you use the omnibox API we render a chip in the omnibox, albeit transitively.

Comment 15 by, Jan 29 2015


Comment 16 by, Jan 29 2015

I see, I've never seen this. what's the omnibox API? do you have a screenshot?

Comment 17 by, Jan 29 2015

The mock I put up the top is stolen from the omnibox API, but there's a non-lie version of that at

Comment 18 by, Jan 29 2015

FYI, this is the same UI treatment we give search engines (and maybe other stuff?).  For instance, searching google.  Screenshot attached.  So, there _is_ precedent for things that aren't sacrosanct. :)
23.5 KB View Download

Comment 19 by, Jan 29 2015

Right, if you invoke tab-to-search we display a blue chip with the engine name.  The engine name for a particular site is set by the site's OSDD.

Comment 20 by, Feb 4 2015

Although it makes me a little sad, I do think it makes more sense than just showing the extension ID on its own. In the bad case: if the extension is screiwng around with its name, the user has almost certainly already been tricked by this point. In the good case: this will be helpful.

Comment 21 by, Feb 4 2015

I agree, though it doesn't make me sad.

Contrary to what I said earlier, I don't think a blue background is right, that implies search. A green background isn't right either since that implies EV cert. Therefore the color should be... well, I vote neutral.

Comment 22 by, Feb 4 2015

I don't think blue implies search.  Blue was picked because back in the day all of Chrome's chrome was blue-tinted.

I think we should change the existing blue chip to light grey and then use that.

Comment 23 by, Feb 4 2015

Ok, <global colour> chip it is. I filed but 455422 to change it. Also, adding UI team person.

Comment 24 by, Feb 4 2015

Comment 25 by, Feb 4 2015


Comment 26 by, Feb 23 2015

I'd actually like to get QO's opinion on this. The QO URLs are pretty ugly.

Comment 27 by, Feb 24 2015

For Quickoffice, the desire has actually always been to show the URL of the original file that I'm trying to open. Eg if there is a link to:

Then really *that* URL should show. The fact that the document happens to be rendered by an extension is somewhat irrelevant / implementation detail.

Note: I realise that this is specific to QO (and PDF viewer) whereas this bug is more generic about extension URLs and quirky IDs...

+raymes who has been working on making extensions render as browser plugins that would help achieve this.

And since I'm actually moving to a new project, I'm adding +hlo and +respino who are taking over the maintenance of Quickoffice

Comment 28 by, Feb 24 2015

Sounds like QO is more interested in Rob Wu's omnibox spoofing proposal, which is somewhat orthogonal to this bug.

Comment 29 by, Feb 24 2015

(ps. one reason why showing the original URL of the file that was opened would not be great, is that ultimately QO allows the user to edit the file. Basically the HTTP stream is saved in to a private file, which the user can edit and then SaveAs. Having the URL of the original file shown, makes handling a browser refresh much harder. Having the extensions URL shown, means that on a refresh we can reload the (potentially edited) private file)

Comment 30 by, May 15 2015

 Issue 488087  has been merged into this issue.

Comment 31 by, Oct 14 2015

Status: Untriaged

Comment 32 by, Dec 4 2015

Status: Assigned
Mass triage! Please close, find an owner, or assign back to me. Thank you!

Comment 33 by, Dec 5 2015


Comment 34 by, Dec 7 2015


Comment 35 by, Jan 16 2016

This probably should be added sooner than later. Someone used a "" domain to fake an LastPass' login page. Details here:

Comment 36 by, Jan 20 2016

One alternative is Opera's approach: keep the URL box clear and replace the icon with a puzzle piece to represent "extension". This makes it more difficult for "" to fool users.
Lastpass login in opera.png
13.5 KB View Download

Comment 37 by, Jan 20 2016

Keeping the address bar empty is not a great solution in my opinion. Personally I would like to see what page I am on.

Comment 38 by, Jan 20 2016

Yup. Definitely interested in getting away from the ultra-syntax-y approach we use today. 

Max, Devlin, Ryan and I met about this yesterday. We're going to tackle it as part of the broader omnibox design work happening this month since we're already rethinking parts of our origin/identity presentation. Our "verbose state" pattern should give us more flexibility.

Comment 40 by, Apr 22 2016

Any updates here? Is the work on new omnibox security states help with this issue?

Comment 41 by, Apr 22 2016


Comment 42 by, Jun 30 2016

ainslie, maxwalker: Any updates here? I'd really us to make some progress here, because this change will significantly help verify the identity of the page the user is at. 

There are also new API proposals to introduce UI that can be clearly attributable to extensions. Implementing this change will obviate the need for such custom UI, so it definitely seems worth the effort.

Comment 44 by, Aug 9 2016

Status: Started (was: Assigned)
Assigning to myself. For the implementation, I'm using the EV bubble, with custom colors as pointed in the specs.

Comment 45 by, Aug 9 2016

(sorry, accidentally dropped a CC)

Comment 46 by, Aug 9 2016


Comment 47 by, Aug 9 2016

Passed this by ui-review as well (meacer, just added you to the thread)

Comment 48 by, Aug 9 2016

emilyschechter: Thanks!

Comment 49 by, Sep 6 2016

Labels: ConnectionInfo

Comment 50 by, Nov 23 2016

Components: -Security>UX UI>Browser>Omnibox>SecurityIndicators

Comment 51 by, Nov 30 2016

Labels: -ConnectionInfo

Comment 52 by, Dec 22 2016

Project Member
The following revision refers to this bug:

commit 172e00cdced29d37051bd7fc8faaeedb7416653c
Author: meacer <>
Date: Thu Dec 22 01:24:44 2016

Render extension URLs with chips.

This CL reuses the security chip to display the extension name in the omnibox.


BUG= 453093 

Cr-Commit-Position: refs/heads/master@{#440298}


Comment 53 by, Dec 22 2016

Status: Fixed (was: Started)

Comment 54 by, Jan 6 2017


Athough... I have an extension called "HTTPS" that results in a somewhat questionable verbose state.
Screen Shot 2017-01-05 at 17.58.13.png
225 KB View Download
Screen Shot 2017-01-05 at 17.58.41.png
104 KB View Download

Comment 55 by, Jan 6 2017

More interesting would be an extension named "" or the like.

Comment 56 by, Jan 6 2017

The concerns about extension names are all valid. However, the confusion already exists in other UI surfaces where the extension name is used (e.g. permission dialogs, chrome://extension page etc).

I thought about displaying an "Extension:" or "App:" prefix in front of the extension name, but I couldn't convince myself that it would be extra useful. If we think this might still be worth doing, I can bring it up with the UI team (I wouldn't say there is a high probability of this happening though).

Otherwise we'll have to rely on the Webstore to perform checks on extension names and reject potentially confusing stuff like URLs. I'll give a heads up and work with them.

Comment 57 by, Jan 6 2017

That's fine with me.

Comment 58 by, Jan 26 2017

 Issue 634076  has been merged into this issue.

Sign in to add a comment