Stop using window.postMessage for API calls

[quoid]

Since the API calls only now going between the background and content scripts, instead of using window.postMessage, use browser.runtime.sendMessage.

Ref: https://github.com/quoid/userscripts/issues/265#issuecomment-1241377290

[ACTCD]

browser.runtime.onMessage in background.js should check whether the sender @grant has the corresponding API, to avoid userscript bypassing @grant to directly construct browser.runtime.sendMessage to call NOT @grant API.

[quoid]

@ACTCD

browser.runtime.onMessage in background.js should check whether the sender @grant has the corresponding API, to avoid userscript bypassing @grant to directly construct browser.runtime.sendMessage to call NOT @grant API.

Do you have any ideas for the implementation?

I haven't thoroughly thought about this, but without such a "protection" is a userscript author wants to directly calls the API method, by looking at the source code and finding the correct message name, they could circumvent @grant. Or they could simply just add the value to @grant. The obvious downside of this is that userscript authors could use privileged methods without first declaring it in a @grant value. At a glance it can make it harder to see what APIs an author is using.

Again, I haven't thought of a strategy to counter this thoroughly so this is all basically off the top of my head... That being said, I am not sure a good way to counter this in the content or userscript itself without storing which userscripts have access to which api methods within the background script itself. This is something I hope not to have to do.

Blocking access to these methods from the page is the biggest concern. If userscript authors want to do bad things, they will do bad things. Calling non-granted API methods by constructing your own messages is just one way. There are others an author can do that I'd rather not list out here, but fall into the same "category". The entire browser object is available to authors who are executing in the content script scope.

I am not downplaying the concern just talking about the reality that locking down the browser and it's associated methods is a big hill to climb. However, I am very open to PRs and suggestions. Feel free to email them as well.

[ACTCD]

@quoid

I have thought about this issue, whether it is necessary to strictly grant user scripts, it is true that if it is a script written or reviewed by the user, there is no significant difference, but from the original design of @grantmetadata, and considering the script of most users is Installed from the script market, it is still necessary to strictly adhere to @grant, it can intuitively know and easily change the permissions granted to the script, which is beneficial to the user.

I'm mentioning this question because it's closely related to the one I've mentioned before, for which I've thought about solutions, and yes, I've figured out a possible implementation, but I'm not sure if correct and comprehensive, I'm not as familiar with browser extensions as I am with user script, so I'm trying to read and study it, without directly suggesting how to implement it, I'll do those things later. I will communicate with you further by email later.