Whose bug is it anyway?

The bug is with whoever decided to use a (greedy) URL parser as a URL recognizer. Those are two different tasks — like facial recognition vs. facial identification. "Drawing a box" that separates a face/URL from the rest of the image/prose, vs. actually "understanding" that face/URL.

There should exist (and, I believe, do exist) algorithms specifically for segmenting micro-format data like URLs, phone numbers, etc., out of prose text. These algorithms are specifically tuned not just for the features of these micro-formats, but also for the features of prose text that might conflict with them (like trailing periods!) The output of such segmentation algorithms can then be fed to actual parser/scanner regexes, to validate and extract meaning from the microformats. (The segmentation algorithms don't always trigger only on valid instances of the micro-format, so you need a stricter check after.)

One might then say that, having such an algorithm in hand, it's the responsibility of any API of a rendering engine that knows it's going to be used for rendering mixed prose+URL content (where the URLs aren't marked up in any way to indicate them), to offer an API for such a URL-segmentation algorithm, and in its docs to mention that this API should be used in place of just throwing the lower-level URL scanner at the problem.

But that supposes that the implementers of such an API have such an algorithm in hand. Often they aren't even aware that such algorithms exist.

Really, I would say that this is a "tragedy of siloed development": if this were a FOSS rendering toolkit, probably someone who knows about the existence of this algorithm would have raised an issue within a relevant repo; and then the folks working on the project could have taken a look and realized it would be better to offer/implement that API, and document its use-case (and warn, in the lower-level API, that it shouldn't be being used for the higher-level use-case.) But because this is a big opaque-from-the-outside project, there's no clear way for a meeting-of-the-minds between "the person that notices the bug and knows that prose:URL segmentation algorithms exist" and "the team that could benefit from that information" to happen.

This is what bug bounty programs are for in security land—to provide a channel for this meeting-of-the-minds to happen. But there isn't really anything like this in UX land.

All of the involved parties should fix the problem on their own. Any single one of them fixing the issue won't prevent it from popping up again, since you can substitute or circumvent the fixed layer.

Signal should handle this case explicitly in the app, since it's a common frustration for their own users when typing dots, commas and parenthesis.

Android should maybe fix the library, but at the very least fix the documentation to mention that it is not intended to be used in context of prose. Android fixing their library is the least useful of all possible fixes, since it won't propagate to users of Android in any meaningful way for a decade.

The Virgin web team should see that there's elevated 404's, and configure their system to ignore trailing full-stops.

A company the size of Virgin probably already has a process to review marketing messages, but it's likely to be someone eyeballing it, and they should fix it to catch this automatically. They probably already use a marketing automation and scheduling system, that could fix it by verifying the links before pushing.

Among the ways in which the early web may have been an improvement upon its successors: https://www.w3.org/Addressing/URL/5.1_Wrappers.html

It's the media team. They created an ambiguous URL given the context. When you're making a web page you control the context and markup so you can make it unambiguous. If you don't, and you're putting a URL at the end of a proper sentence, it becomes ambiguous.

To avoid this issue when writing URLs in plaintext, I add a space at the end.

> Check out https://example.com/thing . They've got...

Let's say we were serious about solving this problem (without adopting a strategy like mine above). We would need a set of rules for plaintext-safe URLs. It would comprise:

- An extension to the URL syntax to specify the subset of URLs that are plaintext safe. It might be as simple as a list of punctuation characters that cannot appear at the end of a URL (unless they are percent encoded).

- Guidelines and test vectors for implementers of URL identification algorithms.

- Guidelines for content authors. E.g., "The only characters that may immediately follow a URL are..."

- A recommendation for web developers to ensure plaintext safefy when creating new URLs.

If we are considering URLs have entered the realm of regular content we produce/consume as text, then the bug should be fixed by the lowest layer in the stack (dunno if it's the URI library or the OS a browser app or whatever). We can't expect people to understand the concept of a hyperlink while we scold them for not adding a blank space after them (which is stupid, we don't do that in regular text) or something like that. We need to handle URLs gracefully. I have seen legal papers with URLs at the end of sentences multiple times with period marks right next to them because a text editor works like that. The user is not to blame here. In theory the person who sent the SMS is not to blame either, SMS is a text document.

"Virgin Media’s Marketing Team" for sure, because it's their responsibility to test if their message works. There always will be some buggy software around. It could be feature phone, iOS, Windows Phone (devices are still alive), some tablet with SIM or whatever. It is "Marketing Team"'s responsibility to test if their message can actually reach their customers. Everything should be tested. Always.

It doesn't really matter whose bug it is. If you're sending urls through a lossy medium, and you want them to work, your server needs to be accepting of trailing garbage and (where possible) truncation and case insensitive.

If you send a link via sms, some number of people are going to type it in a url bar while looking at their phone, that's a lossy process. In addition to whatever terrible things happened during sms transmission.

For me it's fairly clear that the only unambiguous way of delimiting a URL in the context of plain text is using whitespace. Only a space, tab or new line shouldn't be considered as part of the URL. This means virgin media are at fault and should put a space after the URL.

If the UA encounters a 404 it could offer to strip the ".", perhaps.

And this is why I always put space before the punctuation when sending a link to someone.

All of the above. Any of those layers could have fixed the problem, and should have.

The issue is sending a bare URL. They should have said, “To visit our support page, click here.” With “click here” being a link. If they’re concerned about people with email clients that don’t support HTML mail, they should also put on a line by itself the full bare URL. This is email communication 101.

The biggest problem here is that the company involved is ran by monkeys and there's no way to report this issue. In a proper company this would either not have happened (if competent people were behind the feature and would've tested this properly) or would've been resolved the same day as soon as a customer reported the problem.