Hmm. What is about the security issue? @atsampson, @ann0see, @gilgongo, @pljones What is your opinion on the security risk?

If you allow https://, I don't really see a problem with http:// (But I'm not an expert on this). Since there's a message asking the user if he really wants to open <url>, I don't see a big security issue.

I guess in so far as all security is a balance between utility and safety, we think the utility of having clickable links outweighs the possibly insecurity of clicking them.

Given this was previously specifically decided against, I'd expect there to be an overriding argument presented before changing anything that addresses the security concerns, rather than just "it's not nice".

https is supposed to help block (mitigate?) spoofing. In another thread, I was warned about jamulus.io.fakehost.com. My browsers default behavior is to block http. It is not a problem for me, but for the naive users I am onboarding, it would be good to eliminate the use of http. Fewer things to go wrong with naive users.

@gene96817 It seems pretty (probably increasingly) unlikely that people will legitimately post links to non-SSL sites. Almost to the point that if they do, then that's a marker for illegitimacy now?

Given this was previously specifically decided against, I'd expect there to be an overriding argument presented before changing anything that addresses the security concerns, rather than just "it's not nice".

It's a usability thing. I work with people who hardly know what a browser or what copy and paste is. They had someone else set up their machine and their Jamulus instance. For those people, it's way easier to have a clickable link. Would also be interesting to know what @AndyMcProducer's use case was (cf. #879).

I fully agree that https:// is better than http://. Browser vendors are pushing in that direction as well. However, let's take a common example for choirs: a huge public score collection such as cpdl.org. While the original site does provide https://, there are also lots of links to third-party websites which still support http:// only. When wanting to link to those, a usability hurdle appears: Either the users have to copy and paste the link into their browsers or some technically knowledgeable person has to download and re-upload this score to some https://-enabled website.

Regarding security, I think it would be important to understand what threat we are trying to mitigate:

• The original suggestion in Discussing potential security issues #314 (comment) was about practical vulnerabilities regarding the file:// protocol and maybe other protocols where their exploitability for malicious actions is not even known by now (with examples from Pidgin/Zoom). As far as I understand, this is about (pseudo-)protocols with unintended side-effects, i.e. especially those which are not typically opened by browsers. I fully agree that links with such protocols must be filtered and I think this issue is real because openURL() will apparently open/execute anything it is passed. I'm also fully in favor of the approach of @corrados who chose a whitelist-based approach instead of a blacklist-based one. This is basically about the threat of potential security vulnerabilities in Jamulus. I don' think that whitelisting http:// would change anything in this regard.
• There is a potential threat about leading unknowning users to bad websites (I think that's what @gene96817 meant and what @corrados hinted at in Discussing potential security issues #314 (comment)). I have too little experience to tell if this is a real problem on public Jamulus servers (i.e. bad users joining and posting bad URLs to the chat), but I am pretty confident that the decision about whitelisting http:// changes little to nothing in this regard. https:// (or TLS and its X.509 certificates) does not tell anything about the reputation of a website. Give me some minutes and I'll set up a fake jamulus.io.example.org website with or without https on some domain I actually own (no, I'm not intending to do that ;)). https:// solely ensures that the connection is authenticated and encrypted. Basically, it adds confidence that you are talking to the website you intended to visit.
• There is a potential threat about leading users to bad websites via phishing, i.e. via creating a link which displays as example.org/good.html but points to example.org/bad.html instead. Jamulus already protects against this issue by asking the user about the actual URL (and not the displayed text). This protection should work for both http:// and https:// (Security issues with the new "open external links" function in the chat window #620).

The only security argument which remains is: "people should only be using authenticated and encrypted communication". I generally like this sentiment. However, applying this argument in this http/https discussion sounds a bit strange to me, considering that Jamulus is supposed to be an open ecosystem with no authentication or encryption builtin.

Therefore, I do not see any specific security downsides with whitelisting http://. If you have some, I'm happy to hear about them.

For Jamulus, the main benefit of https is to ensure the user is connected to the site we intended.

I'd prefer it if Jamulus treated http: and https: links the same - the decision about whether to allow regular HTTP (or automatically upgrade it to HTTPS, in the cases where that's possible through HSTS or a plugin like HTTPS Everywhere) is one that the browser should make, not Jamulus.

Thanks for all your comments! I'll merge it now.

I'd have thought some where there would be a list of blacklisted sites or a way to check realtime.
Or allow the links but when clicked it passes through an online checker first which probs could be done with an url.