If you include a reference in a link (using this supported but uncommon syntax) ... ```markdown [target](@All) ``` ... the link _as a whole_ is removed **if** the target exists **and** you don't have permissions to view it. In this example, `@All` appears to be a valid, private namespace on GitLab.com. Render of the above Markdown: > [target](@All) Whereas if we try a different, non-existent target: ```markdown [target](@arcfqjrsheuokqjg) ``` > [target](@arcfqjrsheuokqjg) In other words, removal of the link signifies you have specified a valid target. For reference, here's what it looks like when it works: ```markdown [target](@kivikakk) ``` > [target](@kivikakk) Note the styles and popover-on-hover, like a regular `@`-mention. This works with other reference types, too. For example, `akhya/private-test` is a private repository in my personal GitLab account. I've created a single issue in it, so only the work item IID 1 is valid: ```markdown * [target 1](akhya/private-test#1) * [target 2](akhya/private-test#2) ``` Render: > * [target 1](akhya/private-test#1) > * [target 2](akhya/private-test#2) The first link is removed by the redaction process, while the second one never resolved and so is left as a relative link. You can discover the existence of the target repository, and enumerate work item IIDs. You can probably enumerate most objects on the system with this. Per the behaviour of `ReferenceRedactor` with non-link input, we should instead restore the link so that it behaves identically to an invalid target — both of the above should appear as relative links (that don't work). Discovered while fixing #415958+. <details> <summary>Render of the description for posterity</summary> {width=617 height=600} </details> <!-- template sourced from https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Default.md -->