But modern apps seem to prefer making everything an https: link. That way, if the user doesn't have the app installed on their phone, they get taken to a friendly landing page - rather than seeing an error message.

The Signal messaging app launched signal.me URls for this purpose back in 2021. It allows you to share a link like https://signal.me/#p/+447700900123 and have your signal client open up a chat with that person.

Then, towards the end of 2022 they added support for their own scheme! sgnl (although it doesn't appear to have been submitted as an IETF draft, and isn't listed on IANA).

It has exactly the same layout as it's https sibling: sgnl://signal.me/#p/+447700900123

Of course, not everyone has (or wants) a phone number. So Signal are adding support for usernames.

Sadly, they've taken the same xenophobic attitude as GitHub and insist that only good ol' American letters and numbers can be used. No fancy accents, right-to-left languages, or Korean Hangul.

Nevertheless, it will be interesting to see if this prompts a surge in Signal take-up. Especially important as Signal are dropping SMS support

The main point, I agree with. Citing a whole paper is a lossy process. Saying "Smith, J (1963) Practical Time Travel, Gallifrey Press" is basically fine but it doesn't tell you where in the publication the bit is you're citing.

Xiao & Ballou contend that the answer is to add a page number to every citation. I think that's a simple solution - but almost always the wrong way to solve the problem.

Firstly, page numbers aren't stable. If you've got the large-print version of a paper, it will have a different page numbers than the regular print edition. Paperbacks and hardbacks have different numbers. The paper copy might be formatted differently from the digital copy.

Secondly, most modern documents simply don't have pages. Anything published as HTML / ePub won't have a page number. Page numbers are a skeuomorph in those contexts.

Finally, even if there is a stable page number - is that precise enough? A page may have several hundred words in multiple sections. Page numbers aren't granular.

I've ranted before about I consider Quoting Page Numbers from eBooks is Considered Harmful.

So what's the solution?

URl fragments!

A properly formatted document should be accessible by sub-section. For example:

example.com/papers/time-travel.html#2.3.9-Eye-of-Harmony

That takes us to the paper we want, and straight to the anchor heading we're discussing. This also works with the obsolete PDF format.

Now, not all papers have the correct markup to do this. That's OK! We can cheat using Text Fragments. That allows us to link to the first instance of a specific string of text in a document. For example:

example.com/papers/time-travel.html#:~:text=Reverse the polarity of the neutron flow

I genuinely think both of those solutions make more sense than hoping that your reader has a copy of a paper in exactly the same format as you do.

One of the things I found most frustrating during my MSc was how... old fashioned academia was. PDFs with two column layouts, unreadable fonts, paywalled knowledge trapped in moribund formats. Let's try to drag it into the late 20th Century, eh?

Over time, the branding faded and GU.com became a URL shortening service. Tiny URls like gu.com/abc could be printed in papers, sent via SMS, or posted on Twitter. They made a huge fanfare about how it would help with analytics.

You can read some of the history of the shortner to understand why it was created.

Rev Dan Catt

@revdancatt

Niche twitter thread time. I'm raising a glass to the end of the @guardian's URL shortener gu.com, which is now on sale for £2.5 million.

Back when twitter was only 140 chars & didn't shrink url links itself, making short URLs a whole important thing.

1/8 pic.x.com/wu9joo3vkw

---

And now, for reasons best known to themselves, The Gaurdian have stopped the service and put GU.com up for sale.

The starting price is TWO AND HALF MILLION DOLLARS!

Look, if I had an asset that valuable and was looking at declining revenue, I'd sell it.

But breaking that URl comes with a problem. I've written before about why URl shortening is bad for users and bad for the web. I've even helped publish government guidance about it. But all of those were based on the premise that the shortener was a 3rd party service. I never thought someone would be as daft as to switch off their own service.

Here are some of the problems this sale causes.

Terence Eden is on Mastodon

@edent

Whoever buys the gu.com domain will effectively get to rewrite history.
They can redirect links like these - and change the nature of the content being commented on.

Joyce Alene

@JoyceWhiteVance

The Steele Dossier asserted Russian hacking of the DNC was "conducted with the full knowledge & support of Trump & senior members of his campaign.” Trump's war against the FBI & efforts to obstruct make sense if he thought they could prove it. gu.com/p/axa7k/stw

---

---

Is there a tweet somewhere of a future politician saying "I support this 100% GU.com/...."? Redirect that to something horrific and you have a potential scandal on your hand.

There are lots of academic papers with gu.com shortened links. Those are all now dead.

Millions of links around the web - including many on the Grauniad itself - are all now broken.

The Guarrdian could fix this by publishing a list of all the shortened URls. That wouldn't stop links breaking, but would make it possible for researchers to reconstruct the original destination.

For decades, we've tried to remind people that "Cool URls Don't Change". We'll just have to hope that the people of the future find a way to decipher all these obsolete links.

http://↑↑↓↓←→←→ba.tk/

Yup, copy and paste that into your browser and it will resolve. Update: The free .tk domain service no longer works.

For now, it just redirects to a Wikipedia article. If you can think of a better use for it, please let me know. I wonder how mail clients do at sending emails to it?

Interestingly, Chrome sometimes throws up a warning that this is a "Fake Site" saying "Attackers sometimes mimic sites by making small, hard-to-see changes to the URL." I suspect that's because of the mixture of English characters and symbols.

I was inspired by the (slightly weird) http://↓.tk website.

Facebook rewrite URLs with Unicode in the path - this is not best practice and could be dangerous.

It is possible to create a URL like http://bit.ly/😀 - the Unicode characters are valid in the path.

The URL Encoded representation is :

bit.ly/%F0%9F%98%80

Facebook mangles these URLs in such a way that it might be possible to redirect a user to a malicious site.

Here's what's happening. When Facebook sees the "😀" character in text, it rewrites it to the "󾰀" character (󾰀). That's a "private use character". This means Facebook can replace the user's computer's default smiley with a Facebook supplied image or font glyph - if it wants.

In normal text - such as "I passed my exams 😀" - changing the smiley is doesn't present a problem, but Facebook also replaces the text in a URL!

So, the URL :

bit.ly/%F0%9F%98%80%F0%9F%98%80

Will point to a Facebook security page.

Facebook changes the URL to :

bit.ly/%F3%BE%B0%80%F3%BE%B0%80

Which points elsewhere - bit.ly/󾰀󾰀.

I performed a couple of quick experiments. It is sometimes possible to post a link which displays a preview of a "good" site, but when clicked on leads to a bad site.

The chances of this being used as a successful attack vector are slim. Tricking the user into clicking on a link which subsequently steals their password is made marginally easier if the link and link preview don't match - but I'm sure there are easier ways of deceiving the user.

The real issue here is that Facebook is altering the text that you write - and that can have unexpected consequences.

We live in a non-ASCII world now. A URL like https://莎士比亚.org/奥瑟罗 is perfectly valid. Facebook - and other sites - should not be confused by non-Latin characters.

Take this recent example from Vodafone.

Aside from the obvious downsides (user doesn't know where the link will take them, if it's compatible, link looks like gobbledegook, etc) there is a rather more interesting issue.

Goo.gl - along with many other URL shortners - give everyone access to your statistics.

Visiting http://goo.gl/NdVGI+ will let you see everything.

I don't know how many messages were sent out, so it's hard to calculate a response rate.

From the map, I can see the two target areas were UK and (unsurprisingly) Greece. There are a few hits in other countries - that could just be people connecting via WiFi networks routed through that country.

There are also a few hits from iPhones - suggesting either the targeting wasn't accurate, or people are spoofing the iOS user agent.

Still, it's an interesting insight into Vodafone's marketing.

So, hurrah for LongURLPlease - a service which takes those horrid little links and turns them in to full sized URLs.

Here's the basic code in PHP to use the service.

function long_url($shortURL)
{
 //Use the LongURLPlease API
 $url = "http://www.longurlplease.com/api/v1.1?q=" . $shortURL;

 //Set up CURL
 $curl_handle=curl_init();
 curl_setopt($curl_handle,CURLOPT_RETURNTRANSFER,1);
 curl_setopt($curl_handle,CURLOPT_URL,$url);

 //Get the JSON response
 $url_json = curl_exec($curl_handle);

 //Close the connection
 curl_close($curl_handle);

 //Decode the JSON
 $url_array = json_decode($url_json,true);

 //Get the Long URL out of the array
 $url_long = $url_array["$shortURL"];

 if ($url_long == null) //The service couldn't find a long URL
 {
 return $shortURL;
 }

 return $url_long;
}

So, how should this be displayed to the user in Dabr?

There are three possibilities.

Display

<a href="short.url/foo">VeryVeryLong.Url/Bar</a>

This keeps the redirect, but it displays the full URL for the user.

Pros.

• Get to see what the content is.
• Allows the short URL service to record hits etc.

Cons.

• Won't highlight if you've already visited it.
• May cause problems if the VeryLong.Url is too long for the screen.

All Change

<a href="VeryVeryLong.Url/Bar">VeryVeryLong.Url/Bar</a> This completely replaces the short URL.

Pros.

• Hurrah! No more silly URLs.
• Will highlight if you've already visited it.
• You can seen what you're about to click on.

Cons.

• Breaks any statistics management the short URL service was performing (is this a con? Surely the receiving website should be recording such details?)
• May cause problems if the VeryLong.Url is too long for the screen.

Background

<a href="VeryVeryLong.Url/Bar">short.url/foo</a>

Pros.

• Will highlight if you've already visited it.
• You can seen what you're about to click on if you hover over the URL.
• Won't cause problems if the URL is too long for the screen.

Cons.

• Breaks any statistics management the short URL service was performing (is this a con? Surely the receiving website should be recording such details?)
• User can't immediately see what they're about to click on.

Conclusions

I prefer replacing the URL completely.  I see no value in the various short URL services.  The stats that they gather don't seem any better that those your webserver can provide.

However, long URLs can be messy - especially on small screened devices.

Long URLs on a BlackBerry

So, which do you prefer?