I don't know much about OOUI, but if we're just talking about urls that programmers can create (from like javascript), than I don't see why filtering the protocols is needed. If we're talking about things that users can create, I don't think we want them to be able to create arbitrary (even safe) urls, as then they can get around spam blacklists, etc.

Yes, it was added "just in case" (in 16eb98d463e486a4ee52423509c36d6c773653c1 per T75156: Security review of OOjs UI's PHP implementation). (Even that commit says, "I am not entirely sure about the last one; seems like this really should be the library's user's responsibility to validate. But it shouldn't hurt to have it.") I also think it would be okay to remove that check and just very explicitly document that unsafe URLs will be output as-is.

So, I think we should get rid of the filtering. Any objections? If there are none, I'll make this bug public and submit public patches for it.

In T107623#1758603, @matmarex wrote:

So, I think we should get rid of the filtering. Any objections? If there are none, I'll make this bug public and submit public patches for it.

I haven't been tracking this closely, but is your original,

I think we should give up on relative URLs and reject everything that doesn't start with a) a whitelisted protocol b) a slash.

what is happening now?

In general, I agree with bawolff's comment, except that I'm always nervous that someone is going to add a feature to pass through user controlled content into what we typically consider to be a programmer's interface. But if it's clearly documented, and there are no extensions doing something like that currently, then we can go ahead and do that.

That would be a breaking change now (some relative URLs that were previously accepted would now cause exceptions), and we'd presumably need a config option like allowUnsafeHref to accept them. Not sure how James feels about that.

On further thought, we should rather reject everything that doesn't start with a) a whitelisted protocol b) a slash / or c) a dot and a slash ./. It would still be a technically breaking change, but we wouldn't need any weird config options (relative URLs should just be prefixed with ./ to indicate they're safe, and make them definitely be so).

As far as I know this is not a security problem for anything right now, so I submitted a draft of the patch to Gerrit: https://gerrit.wikimedia.org/r/#/c/263534/ (drafts are not publicly visible, but not exactly safe either) and added everyone subscribed here as a reviewer.

https://gerrit.wikimedia.org/r/#/c/263534/ merged now. I really like the ./-prefixing solution, by the way.

In T107623#1925466, @matmarex wrote:

On further thought, we should rather reject everything that doesn't start with a) a whitelisted protocol b) a slash / or c) a dot and a slash ./. It would still be a technically breaking change, but we wouldn't need any weird config options (relative URLs should just be prefixed with ./ to indicate they're safe, and make them definitely be so).

It turned out that we have to also allow ? and # at the beginning. ./ does mean "current directory" and not "current file", after all, and prepending these with it would lose the current file name.