The reason chrome.runtime is available everywhere is because the CryptoTokenExtension specifies <all_urls> in externally connectable.

https://chromium.googlesource.com/chromium/src/+/e3f445df632781fed7053789796e9dee14a4cc3c/chrome/browser/resources/cryptotoken/manifest.json#27

So any website can send a message to it.

juanlang@ (lucky cryptotoken OWNER), why does it need to be connectable by any site?

It's externally connectable to allow any 3rd party site to use U2F tokens. This capability is currently being used by Facebook, GitHub, and others.

At some point we intend to replace this approach with a real API, in particular the WebAuthn API currently being implemented by kpaulhamus@ and piperc@. That point isn't today, however. Until that time, chrome.runtime does indeed appear unconditionally.

Ah yes, I'm aware of the effort to replace the U2F stuff with a standardized API.  Blocking on that makes sense. Do you have an existing bug tracking removing the extension that we can block this on?

I don't have tracking bug, and I'm no longer working on this project. I could file one, but I'd have to assign it to someone else. Kim, Casey, do you have a bug to remove the cryptotoken extension perchance? What's the tracking bug for webauthn?

I'm not a good owner for this - is there someone on webauthn or cryptotoken that can own it?

Looks like  issue 664630  is the main webauthn bug.  Kim I'll assign this to you for now to track removing CryptoTokenExtension after webauthn ships.

Note that issue 665273 tracks the FeatureControl piece of this: validating that chrome.runtime isn't accidentally re-enabled by default in Chrome without getting blink API Owner approval like any other API we expose to all web pages (https://www.chromium.org/blink#new-features).

Yep, you found the right WebAuthN bug. Sg, I can hold this issue for now.

Passing to piperc@ to track while RPs are migrating from U2F to the now-available WebAuthn.