The browser.runtime's onConnectExternal/onMessageExternal API methods, besides being used to make a WebExtension "externally_connectable" from a different addon (which was already being discussed and tracked by Bug 1258360), can be used to make a WebExtension "externally_connectable" from a website. This issue will focus on the "externally_connectable from a website" part of onConnectExternal/onMessageExternal (evaluating what its behavior should be, discuss any concerns related to possible threats, and track its implementation).
It interesting to notice that being able to be "externally connectable from a website" seems to be much more requested and much more used by addon developers, probably one reason is that it would let them to integrate with a website without injecting a content script in every webpage of that website (or of any website, which means that the description of the addon permissions that is going to be presented to the user will not contain a "can read everything on websiteX", but something that is going to sound less scary, like "websites can send messages to this addon") For the same reason, it seems that an addon developer can prefer to let any website to be able to connect to their addon (which seems to not being currently possible in chrome: https://github.com/MetaMask/metamask-plugin/issues/813#issuecomment-261363677)
Some initial thoughts about some potential concerns/threats that we may want to discuss before providing this feature: - should/can we prevent the content script of a different addon from using the messaging API provided to the website from an "externally_connectable addon"? - should/can we prevent code that is running in the webpage but is not originated by the same origin (e.g. an injected script tag from a different domain) from using the messaging API provided to the webside from an "externally_connectable addon"?
Adding note to myself to find some numbers of how much this is used in Chrome add-ons to communicate from a webpage to an add-on.
A quick scan of 57804 Chrome extensions shows: 1837 externally_connectable // number of extensions with this manifest key 22 externally_connectable_accepts_tls_channel_id 1 externally_connectable_ids average // average number of ids per definition 114 externally_connectable_ids 75 externally_connectable_ids_* // number of extensions that use * 2 externally_connectable_matches average // average number of matches per definition 1812 externally_connectable_matches // extensions that define a 2 externally_connectable_matches_* // number of extensions that use <all_urls>
Hi There, sorry for not chiming in sooner, as the discussion was somewhat spurred by my web extension! (Thanks Luca! We've been busy, as I'm sure you have been!) We just finally started identifying our pain points with Chrome's Extension API, and started a discussion with them, and so it seemed like a good time to warm up the iron on this side too. I think Luca's security concerns are valid, but could be addressed with security policies, for example a safe and very restrictive policy might require that injected APIs of that type are not able to send messages on behalf of the page, or issue http/fetch requests from the site's origin domain, or maybe are only able receive function calls from the page, and can only communicate with their own Extension's context (although we extensions would love to talk to each other too). If our injected API was merely able to pass its messages to the content script or background script, and return the responses, that alone would be incredibly powerful, granting the ability to add new APIs to the browser via nothing but an extension. This is exactly what MetaMask is today, but it's not easy. We're injecting "web3", which is an immature, and very rough API for interacting with some peer-to-peer networks like the Ethereum blockchain. MetaMask is allowing developers to experiment with patterns of developing on these peer to peer networks, and the experience we've gotten from even our rough current version has spurred some great discussion & design around the next iteration of the API. Andy: If you wanted even more interesting numbers, check how many users each of those extensions has. Just out of curiosity, I don't actually think this is a very common pattern yet.
Andy: From your quick scan of the 1837 Google Chrome extensions that contains "externally_connectable", around 175 of those extensions are mine. As this is currently a P3, I'll assume this implementation will not land into 57 release and will follow something like this as an alternative : https://stackoverflow.com/questions/10526995/can-a-site-invoke-a-browser-extension/10527809#10527809
Update: since Andy posted comment 4 one year ago, the number of Chrome extensions that use externally_connectable has grown to 3,735 out of 82,659 extensions, or 4.52%, up from 3.18% in comment 4.
Severity: normal → enhancement
Adding to browser compatibility pages https://github.com/mdn/browser-compat-data/pull/2329
I am developing a website that communicates with an extension that is implemented to extend the functionality of this website. The website and the extension sometimes need to exchange sensitive data. Chrome extensions can be made 'externally_connectable'. Using this mechanism I can assure that from the point of view of my website I am communicating with the right extension by using the id of the extension. In Firefox however I need to fall back on CustomEvent or window.postMessage which technically works ok, but does not guarantee me that I am communicating with the right extension. By using CustomEvent or postMessage any other extension can possibly eavesdrop on the [website - extension] connection. I'd like to add to this discussion that adding the 'externally_connectable' feature is significantly adding to the secureness of this kind of extensions.
You need to log in before you can comment on or make changes to this bug.