webpage or its components should not attempt to message an extension directly

[edeykholt]

In the requestAutoSignin implementation in polaris-web (used by https://github.com/WebOfTrust/signify-browser-extension/blob/909803e6ad0a1038aa8d4ffea914767d98ea2894/example-web/my-app/src/App.js#L74),

polaris-web/index.js

Line 81 in 697eb6a

const requestAutoSignin = async (rurl) => {

,
it attempts to contact the extension directly via chrome.runtime.sendMessage(). It should always communicate via the extension's ContentScript. The webpage and a compliant ContentScript should have a "contract" of message types. The ContentScript and its Extension (service-worker) must have a completely independent contract of message types and ways of communicating. The web page and polaris-web should know nothing about the latter. For example, in the case of KERI Auth extension, it will use chrome ports, not messages, and will ignore all messages.

[rodolfomiranda]

why not have both options? the direct way of communication may be more performance for some use cases.

[edeykholt]

The performance overhead of forwarding a message is negligible, right? If an extension service-worker is required to listen to messages from anywhere, it wouldn't know which sources to trust. The service-worker should only be required to listen to messages from its own ContentScript (and the extension's other app content). The design of an extension shouldn't be otherwise constrained. The protocol and messages between a page and an extension should only concern the messages (and maybe other content but hopefully not) between the page and the ContentScript.

[rodolfomiranda]

I'm not sure that the performance is negligible and you get the benefit of inline response. The service worker only needs to listen to trusted web pages that were authorized by the users. I still don't get your point of restricting messages only from content script. I think that content script exists primarily to allow the service worker to directly interact with the DOM of the web page.

[edeykholt]

Well, I've stated most of my case already. Among other things, my implementation for KERI Auth doesn't use messaging, but uses ports, so that means I'd need to change that or not implement AutoSignin until needed.
It is also confusing to me why this interaction for handleRequestAutoSignin is gated depending on result of canCallAsync, which returns true for Brave or Chrome. So, that means another execution path for others like Firefox. You mentioned "why not have both options?" By that did you mean based on browser type, or a configuration?

[rodolfomiranda]

that's because chrome implements the externally_connectable feature that allow the service worker to receive messages in a specific listener chrome.runtime.onMessageExternal.addListener

[edeykholt]

Does that imply for the extension to use the Auto SignIn feature ( handleRequestAutoSignin on chrome or brave) that its manifest needs add the "externally_connectable" section and declare the sites it trusts? Hmm.

[rodolfomiranda]

The ideal case is that the user grant permission at runtime as with optional_permissions

[edeykholt]

This is related to WebOfTrust/signify-browser-extension#159

[edeykholt]

See refactoring proposal at #31