`GM.info` / `GM_info` not working in the page context

[wolfissimo]

According to documentation, GM.info / GM_info should be available without having to @grant it. In version 1.5.0/4.5.0 this is no longer the case, which is bad because using @grant leads to other issues. Please fix this.

[ACTCD]

Please provide more information or further proof. After testing, the issue you described cannot be reproduced.

[ACTCD]

I see that the problem is that now GM.info is no longer available when @inject-into page, which is indeed a different behavior than before.

But I think this is working as expected, all privileged APIs should only be available when @inject-into content.

Leaking GM.info into the page context tends to lead to privacy risks such as user fingerprinting.

I'm not sure we'll get that behavior back.

[ACTCD]

So, it fits the documentation's description that you can use GM.info / GM_info without @grant them in the content script context.

For reference, could you describe your use cases in detail and the reasons you think it's required to use them in the page context?

For the record, the change was introduced in the refactoring of #560.

[scholtzm]

Just ran into this sudden breaking change.

What's the recommended way to access GM_info now in scripts that run via @inject-into page?

[wolfissimo]

So, it fits the documentation's description that you can use GM.info / GM_info without @grant them in the content script context.

I think, documentation is not absolutely consistent in this point:

• in "Metadata" it says "GM apis are only available when using content"
• in "API" it says "GM.info && GM_info ... is available without needing to add it to @grant" The latter was the case until the recent update.

For reference, could you describe your use cases in detail and the reasons you think it's required to use them in the page context?

1. My script uses a XHR proxy, which only works in page context. As soon as I add a @grant, it stops working.
2. The page my script is for is updated every few days, so I also need to update may script very often. So users should always see which script version they are running, for which I use GM.info / GM_info. So at least GM.info.script.version and GM.info.script.name should be available without@grant.

[ACTCD]

Just ran into this sudden breaking change.

What's the recommended way to access GM_info now in scripts that run via @inject-into page?

@scholtzm I am sorry you guys are having issues for this, but as I said before, I don't think this is a "breaking change", it's more like fixing a previous accidental leak.

So, the best way is to describe your use case in detail to help evaluate its necessity.

I think, documentation is not absolutely consistent in this point...

@wolfissimo As I've already explained, it's not a contradiction, you don't need to "grant" this API in the "content script context", it's always available.

As for your use case, I don't understand it. Could you please add more details?

If you mean that you show the version of the script on the page by reading GM.info, I think you can do that by updating the variables in the code at the same time as you update the script, reading through GM.info isn't necessary is it? Example:

// ==UserScript==
// @name        NewScript-j2qot9yz
// @version     1.0.0
// @description This is your new file, start writing code
// @inject-into page
// @match       *://example.com/*
// ==/UserScript==

(function () {
	const version = "1.0.0";
	// do whatever...
})();

[scholtzm]

My use case is simple, I display script version and icon (URL) from GM_info in the UI elements added by the script.

[ACTCD]

@scholtzm Then consistent with the example I made above, you could just add a variable to the code and update them at the same time as you update the script.

I know this may be a bit repetitive and redundant, but considering the security of the page context, it's worth it.

[scholtzm]

It that's what it takes, I will remove the usage of GM_info.

I am sorry you guys are having issues for this, but as I said before, I don't think this is a "breaking change", it's more like fixing a previous accidental leak.

Agree to disagree here. Just using the API as documented in the README. This is a breaking change and the API should have been properly deprecated for use in page context.

Keep in mind this change might have broken hundreds of scripts that worked previously.

[wolfissimo]

If you mean that you show the version of the script on the page by reading GM.info, I think you can do that by updating the variables in the code at the same time as you update the script, reading through GM.info isn't necessary is it?

Yes, thats my use case (I show version and also the script's name). But updating those values manually can easily be forgotten, and I think that is the main reason why GM.info.script.version and GM.info.script.name exist.

[ACTCD]

@scholtzm The reason I say that is because it's not inconsistent with the documentation.

When using API methods, it's only possible to inject into the content script scope due to security concerns.

This is clearly documented in the README.

But I also acknowledged earlier that it does behave differently than it has in the past.

So I'd like to get more feedback on the necessary use cases to better evaluate this change.

But as of now I don't see that.

And if that's breaking the wrong use case for the sake of better security, I think it's worth an opportunity for people to relearn and reconsider about the security model.

and I think that is the main reason why GM.info.script.version and GM.info.script.name exist

@wolfissimo No, the GM APIs are designed to be used in a "content script context", not for "page script".

[wolfissimo]

@scholtzm

It that's what it takes, I will remove the usage of GM_info.

Well, I inserted the following into my script, so that users of other browsers/operating systems still enjoy the benefits of GM_info:

if (typeof GM_info !== 'undefined') {
    // code using GM_info ...
}

[scholtzm]

@wolfissimo I'm using webpack to build the script so I just adjusted the config to use DefinePlugin and replaced all GM_info references. 👍

[ACTCD]

Convenience comes with privacy risks, and reducing unnecessary leakage points and better protecting users' privacy is the real benefit for everyone, developers and users alike.

I apologize that this unrecognized change in the refactoring has caused some inconvenience to you guys, but unless I can see the necessary use cases, I think maintaining the security model and providing a better security and privacy experience is something the project has always strived for.

We never tried to be compatible with more marketplace scripts, we always insisting that security comes first and that users deserve better quality user scripts that also value security and privacy.

[ACTCD]

So far, no effective use case feedback has been seen.

I will close this issue and will reopen it if there is new feedback.