Sadly, many of these are designed to be accessed by web contexts.  They are used to determine if hosted apps are installed or running.  There existence predates mine on the team, so I don't have much background, and, AFAIK, they've never really be documented.

I'd love to just kill these APIs (getIsInstalled, getDetails, runningState, isInstalled, installState), but we don't currently have metrics on their usage that I'm aware of.

Thanks Devlin! Perhaps we should convert them over to using WebIDL, and then add UseCounters like any other blink API?  The fact that (except for one) Edge has been successful (despite having a Chrome UserAgent string) without these suggests that at least some may be safe to remove.

Since this is about the same of our exposed web platform surface area, this might be something chasej@'s FeatureControl team could help with at some point. /cc Jason and Ian.

Re converting to WebIDL: That *almost* works for this very specific API (but wouldn't work in a general case for all extension APIs).  I say "almost" because without additional work, that would result in exposing these APIs to platform app contexts, where they don't currently exist (right now, they are exposed to web and extension contexts).  That's probably not a *huge* deal, since hopefully no platform apps are using these and we could have an ugly hack preventing them from doing anything, but it's still a behavior change that's worth taking into account.

At a higher level, I'd be much more interested in just figuring out if we could find a way to use blink UseCounters outside of blink.  It would be great to be able to use them for extension APIs and potentially other chrome concepts.  Is there any work towards that, and if not, is it worth investing in?

> I say "almost" because without additional work, that would result in exposing these APIs to platform app contexts, where they don't currently exist (right now, they are exposed to web and extension contexts).

That shouldn't be a problem. We have a number of mechanisms in WebIDL for exposing APIs in some contexts and not others (all owned by the FeatureControl team).  RuntimeEnabled is already probably adequate (https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/bindings/IDLExtendedAttributes.md#RuntimeEnabled_i_m_a_c), but we could also add something more specific.

> I'd be much more interested in just figuring out if we could find a way to use blink UseCounters outside of blink.  It would be great to be able to use them for extension APIs and potentially other chrome concepts.  Is there any work towards that, and if not, is it worth investing in?

There is!   Issue 716565  tracks moving UseCounters to the browser process, and with that I think it would be possible for code elsewhere in the browser process to use them.  Without WebIDL you wouldn't have the convenience of [Measure] just doing the right thing for you, but they're not too hard to use pragmatically (although most of the convenience functions would likely still live in blink code). 

Of course you can also just add your own UMA histograms completely separate from UseCounter if you like.

I don't think RuntimeEnabled is sufficient, but I could be wrong.  We need to be able to toggle availability based on specific v8::Context, such that two v8::Contexts in the same browser, during the same session, at the same URL, with the same installed extensions, can have different availabilities (as well as reaching out through //content to the //chrome or //extensions layer to determine the result).  Does RuntimeEnabled have enough frobs for that?

RuntimeEnabledFeatures doesn't quite have enough, but OriginTrials does, and we're hoping to be able to extend that mechanism to arbitrary features soon. (It's on the feature control draft OKRs for this quarter)

A good first step here, I believe, would be to include these APIs in webexposed tests, virtual/stable/webexposed/ in particular, so that we're not able to add to this set of APIs accidentally.

I will call that part a P2. chasej@, do you think that makes sense?