Markdown hyperlink URIs do not accept non-HTTP(S) schemas.

[RokeJulianLockhart]

Markdown hyperlinks do not accept URIs whose schemas are not HTTP or HTTPS: [`startx`](file:///usr/bin/startx) becomes [`startx`](http://file:///usr/bin/startx).

[jdevfullstack]

yup that's right, if, say, you want to upload an image, in the latest update, you simply copy and paste it at the GitHub Markdown, unlike in the past you need to upload it first to get the valid URL

[RokeJulianLockhart]

https://github.com/orgs/community/discussions/27857#discussioncomment-3295974

@jdevstatic, that is actually entirely irrelevant to this, because the method by which the media that GitHub hosts does not ever cause the markdown to not utilize HTTPS. However, I am thankful.

[jdevfullstack]

which the media that GitHub hosts does not ever cause the markdown to not utilize HTTPS

can you explain that ? I'd been into network programming in the past, I might help regarding this

[RokeJulianLockhart]

https://github.com/orgs/community/discussions/27857#discussioncomment-3299854

@jdevstatic, GitHub's implementation of Markdown formats hyperlinks as [text](URI), which are converted into [text](https://example.com). However, this solely operates correctly via GitHub if what is contained by “()” is preceded by http(s):// (of any capitalization, as the relevant Requests For Comments mandate) rather than alternative but valid Uniform Resource Identifier schemes, of which file:// is one.

[jdevfullstack]

there was one similar situation in the past, which a URL from Linux is not working, other than that there are Markdown browser extensions that can access local resources exactly that "file://" protocol that you are mentioning but you need to allow it first because without that, it can be abused when someone's code can access local files through Markdown

[RokeJulianLockhart]

https://github.com/orgs/community/discussions/27857#discussioncomment-3300340

@jdevstatic, https://github.com/orgs/community/discussions/27857#discussioncomment-3312082:~:text=Allowing%20random%20URLs,is%20an%20opportunity

[airtower-luna]

Allowing random URLs would be potentially dangerous. A file: URL is simply useless outside of a computer with a similar enough filesystem layout (but that also means there isn't much point in rendering it on a website). But depending on the browser, OS, and their configuration random schemes might be connected to random software that then gets run with parameters from the URL. This has been used for attacks in the past, and probably still is where there is an opportunity.

Of course if the browser or whatever else is handling a well-known scheme has an exploitable bug those URLs might also be abused, but at least the attack surface is much better known. 😅

[RokeJulianLockhart]

https://github.com/orgs/community/discussions/27857#discussioncomment-3300405

@airtower-luna, sending a user to a malicious URI is always dangerous, obviously. HTTP and HTTPS do not somehow prevent this. If that were a consideration, no URI would be instantly clickable, not that that would do anything but waste time, however.

Regarding that, I remain able to post custom hyperlinks that contain alternative URIs obviously, but they are merely not clickable. That is mere security theatre, since invoking them is as easy as copy-and-paste into the browser's URL-bar.

[Thaina]

Unity and vscode has its own url scheme that would be very useful with button to interact from web page. To limit md only https is hindrance to development