It is also used for installing extensions. Extensions are not deprecated. It would be great to standardize a less vendor specific method nevertheless.

Oh interesting, thanks. Here's the documentation: https://developer.chrome.com/extensions/webstore

I agree we should think about standardizing something for this.  It looks like the 'url' is optional, so it would still be a win to have a single 'install extension' API developers could use, even if they still have to include separate <link rel> tags pointing to the different extensions they have for different browsers.

Maybe something for appiness team to think about, adding Blink>AppManifest (not quite right, but maybe the closest we have).

This is an extension API, and extensions are not standardized.  I personally don't see a reason that we'd standardize this API specifically (whether to standardize *all* extension APIs is a different question that has already been discussed).

#3 - it needs to be standardized because it is exposed to the open web and may be used for mis-detecting browsers, or relied on for other unrelated uses.

Just because it's exposed to the open web doesn't mean it needs to be standardized, AFAIK.  We expose more than just the webstore API on the chrome object - we also expose the runtime API and a few others, in addition to items that aren't extension-related.  Additionally, Chrome exposes a ton of webkit-related properties/functions/events/styles/etc to the web.  These can range in purpose from being initial implementations that will later be standardized (and hopefully removed) to things that have no plans to be standardized.

#5 - chrome.csi is on its way to be removed.
> Just because it's exposed to the open web doesn't mean it needs to be standardized, AFAIK.
I respectfully disagree. The general direction is to have every non-standard feature either removed, standardized, or at the very least fully specified and documented in a way that is implementable by others.
WebKit prefixed features are being standardized or removed (slowly, but they are). You can see a lot of "Standardize or remove Foo" issues in the issue tracker.
Unfortunately, you can already see some WebKit prefixed features in some specifications (directory upload), or in the web compatibility specification.

Proprietary/undocumented features hurt the web. This issue is one of the steps to mitigate that.

> Just because it's exposed to the open web doesn't mean it needs to be standardized, AFAIK.

Nope - we're working very hard to ensure every publicly exposed API is standardized and potentially interoperable.  From https://www.chromium.org/blink#new-features: "In practice, we strive to ensure that the features we ship by default have open standards."

The other remaining things on the chrome object are all on track to be removed.  See issue 113048 and issue 621512.

Hmm, okay, good to know.  I'm not sure if we can apply this logic to the runtime API, though, which is conditionally exposed to web pages.

By "runtime API" you mean the extensions API exposed to extension pages
etc? Or something else?  Certainly extensions aren't "the web" so this
policy and the blink launch process doesn't apply to them in any way.  It
just applies to pages that can be loaded in any browser (i.e. http).

TL;DR: We conditionally expose chrome.runtime to web pages.

The runtime API allows for sending messages to extensions from the extension itself, another extension, or trusted websites (sites specified in the extension's manifest).  So if I install an extension for example.com, example.com can use chrome.runtime.sendMessage(<extension id>, message).

See also https://developer.chrome.com/extensions/messaging#external-webpage

Looks like some of chrome.runtime (constants as well as connect and sendMessage) is exposed to any site, whether in incognito or normal mode, whether mentioned in the manifest or not.

A lot of things are...

> chrome
{app: {…}, webstore: {…}, runtime: {…}, loadTimes: ƒ, csi: ƒ}
app: {getIsInstalled: ƒ, getDetails: ƒ, runningState: ƒ, installState: ƒ}
csi: ƒ ()
loadTimes: ƒ ()
runtime: {PlatformOs: {…}, PlatformArch: {…}, PlatformNaclArch: {…}, RequestUpdateCheckStatus: {…}, OnInstalledReason: {…}, …}
webstore: {onInstallStageChanged: Event, onDownloadProgress: Event, install: ƒ}

@12 Yeah, I thought I had noticed that, too, but was wondering if it was one of the policy extensions I had, and hadn't had a chance to dive more deeply.  If it's everywhere, I wonder what's causing it.  It could be that there's a component extension with externally connectable specified as *://*/*, or there's a bug in the exposure code (though that code is pretty simple [1]).

I'll see if I can take a look on Tuesday.

[1] https://chromium.googlesource.com/chromium/src/+/413d7502992c9316ab84e63ec4be053af78fcb0d/extensions/renderer/extension_bindings_system.cc#22

Fascinating, thanks!  I filed issue 768486 to discuss what should be done about chrome.runtime.

I understand this is, fortunately, fixed after inline installation got removed?

Deleted: chrome-webstore.png 21.5 KB

	chrome-webstore.png 21.5 KB View Download

It is indeed!  (There are still other APIs that are exposed, but chrome.webstore is gone.)