Allow insecure http for `@require` resources

[quoid]

Currently @require resources are fetched from the swift side and will get resources loaded from http, instead https is required.

The following resource can no be added to a userscript:
http://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js

The following resource CAN be added to a userscript:
https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js

This has caused issues for some users who are using userscripts that load resources from http. There's an Apple dev forum post here where an Apple employee describes the perfect scenario for arbitrarily allowing user defined http resources, which happens to fit well into this context.

For example, imagine you’re building a tool where the user can enter an arbitrary URL and you fetch that URL and display the returned headers. The user might enter any sort of URL, including an http URL, or one to a server whose TLS setup is broken, and you still need to work with it. That’s a perfect use case for NSAllowsArbitraryLoads.

Assuming, NSAllowsArbitraryLoads is still the "fix", it can be easily implemented. I'm ambivalent on this change. It rarely would affect me because I write most of my own userscripts and wouldn't want to use userscripts loading content from http. However, I can't expect every user of this app/extension to be as discerning. Related to this, GM.xmlHttpRequest and the GM_ counterpart both allow fetching from http. If http is disallowed for @require it should also probably be disallowed for those methods and vice versa.

If anyone has opinions on this, please do chime in.

[phw]

If http is disallowed for @require it should also probably be disallowed for those methods and vice versa.

Not sure about @require, I can see the benefit of only allowing HTTPS there, but also see why this is a compatibility concern and for some scripts it might not (yet) be possible to update them.

But I would like to preserve the capability to contact HTTP resources via GM.xmlHttpRequest. At the very minimum for localhost / 127.0.0.1. Local services often don't provide or need HTTPS, and if they do its not easy for the end user to setup access. See also my comment at #164 (comment)

[quoid]

But I would like to preserve the capability to contact HTTP resources via GM.xmlHttpRequest. At the very minimum for localhost / 127.0.0.1. Local services often don't provide or need HTTPS, and if they do its not easy for the end user to setup access.

That's a good point, I didn't think about that when making my comment above. Considering that, it sounds like limitations on XHRs isn't a good idea.

As far as @require goes, I did a quick update to attempt the fetch the resource from https if http is included, but haven't made any significant changes yet. From reading about NSAllowsArbitraryLoads it seems like there'd be additional scrutiny on the app during the review process which I didn't want for the first iOS version, so I am still unsure how it will be handled.

[phw]

From reading about NSAllowsArbitraryLoads it seems like there'd be additional scrutiny on the app during the review process which I didn't want for the first iOS version, so I am still unsure how it will be handled.

With the move towards HTTPS throughout the web your update to try the HTTP -> HTTPS upgrade is probably already allowing to run many user scripts that still define http resources.

For NSAllowsArbitraryLoads this would be clearly one of the use cases that Apple developer describes, where the app cannot be sure about the servers it accesses because they are user provided. But I'd actually try and see how far it gets with the HTTPS upgrade fix and which user scripts get reported for still not working.

The new 4.x version already should provide far better support for userscripts with the newly added GM.* API.

[quoid]

Closing this, if it comes up again will reconsider NSAllowsArbitraryLoads