Support for unsafeWindow

[Hakorr]

Unless Safari has a restriction on this, Userscripts should support the unsafeWindow grant. Injecting into page is not good enough as it disables all GM functions and makes the userscript vulnerable to CSP blocking (and just vulnerable in general). So that is simply not an option.

unsafeWindow is not that unsafe and not supporting it limits the functionality of userscripts a lot. Saying it's unsafe is like saying riding a bike without training wheels is unsafe to a biker hobbyist, who can clearly ride a bicycle. Forcing the training wheels just disallows them to go around corners as well and just limits their potential.

The most popular userscript managers support it, so why couldn't this?

[Hakorr]

In fact, I don't think properly designed scripts should use unsafeWindow, its use case should be very rare. If I'm right, then I see no reason for an extension to have an unsafe implementation to be compatible with some ill-designed user script.

Rare? Yeah, but there are valid reasons for it. There is no "safer" way to get the same functionality. Not supporting it just makes this userscript manager weak.

[ACTCD]

Rare? Yeah, but there are valid reasons for it. There is no "safer" way to get the same functionality. Not supporting it just makes this userscript manager weak.

I mean that the use cases that really need it should be rare, not how common it is actually abused.
And I'm interested in knowing what the situation is when it has to be used, if you could provide some.

The main reason for not supporting it was the inability to implement it in Safari, and it still is, as I'm sure has been clearly and repeatedly stated in previous issues.

[ACTCD]

Like what I commented in the issue:

For the reasons above, I will close this issue unless we have the correct way to implement it and the necessary use cases, at which time we will reopen it.

Whether it is "widely" used or supported by other script managers is not a reason we have to support it.

If you think it should be implemented, describe a reasonable use case and a way to implement it correctly in Safari.

[ACTCD]

Injecting into page is not good enough as it disables all GM functions and makes the userscript vulnerable to CSP blocking (and just vulnerable in general). So that is simply not an option.

#252 (comment)

I've explicitly given a safer way to use them at the same time, and I've given a sample script.
So that's not the reason to have to implement it.

[Hakorr]

The main reason for not supporting it was the inability to implement it in Safari, and it still is, as I'm sure has been clearly and repeatedly stated in previous issues.

If it's actually not possible to implement then it is what it is I guess. Stay for Safari supports it somehow while also injected into content (not page, which is great), but I am not familiar with Safari myself so I am not sure how they do that, probably via some hacky method.

Your points are valid. My userscript exposes GM functions to its GUI which exists on a static website, but I could possibly update it to use the safer method you suggested (non-direct functions via events). That will probably make the methods async which is a bit of a pain due to my large existing codebase, but no pain to gain, eh?

---

If I can use this same issue to ask, do you know how this extension handles GM storage (.setValue, .getValue, .listValues) on two active tabs running the same userscript. My userscript does cross-window communication via GM storage, so both of the tabs need to be able to access the same storage. For example, do GM.setValue('hello', 123); on Tab 1, after that, GM.getValue('hello'); should return 123 on Tab 2 without having to refresh the page.

[Hakorr]

So yeah I was wrong, you're right that there are safer ways to do the same things. The methods to do that are quite complex though so I still enjoy having unsafeWindow, but understand not having it especially if Safari doesn't literally allow you to do that without hacky methods.

[ACTCD]

If it's actually not possible to implement then it is what it is I guess. Stay for Safari supports it somehow while also injected into content (not page, which is great), but I am not familiar with Safari myself so I am not sure how they do that, probably via some hacky method.

That's why I've been emphasizing the "correct" way, rather than sacrificing security for compatibility.

In fact, there were similar security risks in this extension in the early days, and the GM API was exposed to the page context. But we fixed it afterward. In the choice between compatibility and security we stick to the latter.

In fact even using the methods I've provided, there are still developers implementing them in ways that are not secure enough, bridging and exposing GM APIs to the page context and putting users at risk just for the sake of development convenience.

Using randomized event names and filtering the data correctly are both issues that developers need to be aware of.

If I can use this same issue to ask, do you know how this extension handles GM storage (.setValue, .getValue, .listValues) on two active tabs running the same userscript. My userscript does cross-window communication via GM storage, so both of the tabs need to be able to access the same storage. For example, do GM.setValue('hello', 123); on Tab 1, after that, GM.getValue('hello'); should return 123 on Tab 2 without having to refresh the page.

I think for the same user script, it shares the same stored data regardless of the tab.

But there also other options for communicating between tabs.