Deeplink URLs are stripped from GitHub Markdown

A lot of softwares by now support deeplinking right from a web app into an application installed on a machine. Deeplinks usually have the form of custom-protocol://some-payload or com.my.protocol:payload.

These are very useful, but it seems that they currently can’t be included e.g. in Readme’s or any markdown displayed on GitHub.com - they’re stripped away on link generation.

The following are all valid deeplinks that work when included from a website, but are stripped away both from the [link](link) and <a href= syntax on GitHub Markdown.

Open Slack: slack://open
Install Unity 2021: unityhub://2021.1.19f1/5f5eb8bbdc25
Open the AssetStore in Unity: com.unity3d.kharma:content/163802

See for reference e.g. Reference: Deep linking into Slack | Slack

Well, that was a fun :rabbit::hole:.

The scheme limitations don’t appear to be documented anywhere.

Certainly, I couldn’t find anything from here:

Nor in the GFM spec, nor in github’s gfm markdown fork, although I found an issue that complained about it:

You could file a bug. There are two places to consider filing it:

https://support.github.com

The former might give you a response explaining something (or not).

For the latter, you could ask them to document what they’re doing (personally, this seems like a perfectly reasonable request).

Alternatively, you could just use html or use your own markdown parser instead of GitHub’s.

1 Like

Thanks for the follow-up!
I’ve reported a bug to GitHub Support now (and also to Slack and Discord, where these links are also not properly kept).

1 Like

So for Slack, I’d argue in favor of not allowing such things since such links are a security risk. (The same actually applies in most places.)

What bothers me is the lack of documentation in each instance.

Speaking as someone who worked on browser security including URL handling. URL schemes are fun, and shiny, and oh-so-chock-full-of-exploitability. And also speaking as someone who produces and consumes documentation.