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

Issue 453093 link

Starred by 63 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug
Team-Security-UX



Sign in to add a comment

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

Reported by kalman@chromium.org, Jan 28 2015

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 https://developer.chrome.com/extensions/omnibox

Peter, Ryan, thoughts?
 
good-url.png
13.8 KB View Download
bad-url.png
11.0 KB View Download

Comment 1 by kalman@chromium.org, Jan 28 2015

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

Comment 2 by kalman@chromium.org, Jan 28 2015

Cc: mea...@chromium.org
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.
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.
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.
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 kalman@chromium.org, 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 mea...@chromium.org, 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.
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.
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 https://drive.google.com/drive/u/0/my-drive and https://docs.google.com/document/u/0/ 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 f...@chromium.org, 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.
Cc: f...@chromium.org
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 f...@chromium.org, 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?
When you use the omnibox API we render a chip in the omnibox, albeit transitively.
s/transitively/transiently/

Comment 16 by f...@chromium.org, Jan 29 2015

I see, I've never seen this. what's the omnibox API? do you have a screenshot?
The mock I put up the top is stolen from the omnibox API, but there's a non-lie version of that at https://developer.chrome.com/extensions/omnibox
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. :)
Selection_164.png
23.5 KB View Download
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 f...@chromium.org, 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.
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.
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.
Cc: ainslie@chromium.org
Ok, <global colour> chip it is. I filed but 455422 to change it. Also, adding UI team person.
 bug 455422 .
Cc: sgabr...@chromium.org
Cc: jliebrand@chromium.org
I'd actually like to get QO's opinion on this. The QO URLs are pretty ugly.
Cc: hlo@chromium.org respino@chromium.org raymes@chromium.org
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:
http://some.server.com/whatever.docx

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
Sounds like QO is more interested in Rob Wu's omnibox spoofing proposal, which is somewhat orthogonal to this bug.
(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)
Cc: kavvaru@chromium.org
 Issue 488087  has been merged into this issue.
Owner: rdevlin....@chromium.org
Status: Untriaged
Owner: juncai@chromium.org
Status: Assigned
Mass triage! Please close, find an owner, or assign back to me. Thank you!
Owner: sgabr...@chromium.org

Comment 34 by f...@chromium.org, Dec 7 2015

Owner: maxwalker@chromium.org

Comment 35 by thex...@gmail.com, Jan 16 2016

This probably should be added sooner than later. Someone used a "chrome-extension.pw" domain to fake an LastPass' login page. Details here: https://www.seancassidy.me/lostpass.html

Comment 36 by lstor...@opera.com, 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 "chrome-extension.pw" to fool users.
Lastpass login in opera.png
13.5 KB View Download

Comment 37 by thex...@gmail.com, 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.
Cc: rsch...@chromium.org
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. 


Any updates here? Is the work on new omnibox security states help with this issue?
Cc: emilyschechter@chromium.org
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.
Cc: -kavvaru@chromium.org maxwalker@chromium.org
Owner: mea...@chromium.org
Status: Started (was: Assigned)
Assigning to myself. For the implementation, I'm using the EV bubble, with custom colors as pointed in the specs.
Cc: -rdevlin....@chromium.org kavvaru@chromium.org
(sorry, accidentally dropped a CC)
Cc: -mea...@chromium.org rdevlin....@chromium.org
Passed this by ui-review as well (meacer, just added you to the thread)
emilyschechter: Thanks!
Labels: ConnectionInfo
Components: -Security>UX UI>Browser>Omnibox>SecurityIndicators
Labels: -ConnectionInfo
Project Member

Comment 52 by bugdroid1@chromium.org, Dec 22 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/172e00cdced29d37051bd7fc8faaeedb7416653c

commit 172e00cdced29d37051bd7fc8faaeedb7416653c
Author: meacer <meacer@chromium.org>
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.

Screenshot: https://drive.google.com/file/d/0B9q2eN9gDoUIelprUjk0dXlINHc/view?usp=sharing

BUG= 453093 

Review-Url: https://codereview.chromium.org/2555063003
Cr-Commit-Position: refs/heads/master@{#440298}

[modify] https://crrev.com/172e00cdced29d37051bd7fc8faaeedb7416653c/chrome/browser/ui/cocoa/location_bar/location_bar_view_mac.h
[modify] https://crrev.com/172e00cdced29d37051bd7fc8faaeedb7416653c/chrome/browser/ui/cocoa/location_bar/location_bar_view_mac.mm
[modify] https://crrev.com/172e00cdced29d37051bd7fc8faaeedb7416653c/chrome/browser/ui/location_bar/location_bar.cc
[modify] https://crrev.com/172e00cdced29d37051bd7fc8faaeedb7416653c/chrome/browser/ui/location_bar/location_bar.h
[modify] https://crrev.com/172e00cdced29d37051bd7fc8faaeedb7416653c/chrome/browser/ui/views/location_bar/location_bar_view.cc
[modify] https://crrev.com/172e00cdced29d37051bd7fc8faaeedb7416653c/chrome/browser/ui/views/location_bar/location_bar_view.h
[modify] https://crrev.com/172e00cdced29d37051bd7fc8faaeedb7416653c/chrome/browser/ui/views/location_bar/location_icon_view.cc
[modify] https://crrev.com/172e00cdced29d37051bd7fc8faaeedb7416653c/chrome/browser/ui/views/location_bar/location_icon_view.h
[modify] https://crrev.com/172e00cdced29d37051bd7fc8faaeedb7416653c/chrome/test/data/extensions/api_test/window_update/resize/test.js
[modify] https://crrev.com/172e00cdced29d37051bd7fc8faaeedb7416653c/components/toolbar/toolbar_model_impl.cc

Status: Fixed (was: Started)
Preeeeetty.

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
More interesting would be an extension named "https://www.bank.com/" or the like.
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.
That's fine with me.
Cc: mea...@chromium.org
 Issue 634076  has been merged into this issue.

Sign in to add a comment