Google to kill off URL shortener once and for all Google will soon make its own contribution to the problem of link rot by shutting down the Google URL Shortener service in 2025. The Google URL Shortener was launched in 2009 as an attempt to make lengthy links manageable by feeding them into Google's shortener, which spat out shorter ones in the form of https://goog.gl/*. …
URL shorteners are, and have always been, a snare and delusion. By definition, the poor sod clicking on one hasn't a clue where they will land up, so they're a primary vector for browser-based attacks. However they came about largely in response to the increasing use of such monstrosities as unreadable and untypeable 1k+ long hashes as URL parameters. Clearly, the primary purpose of the URL (to make links user-accessible) has long been forgotten.
Mike 137,
I'm unusre what to think on this. On the one hand, I'm like you and really hate link-shorteners. I know they're not all scams - but it's not easy to tell which. And a lot of them don't allow you to find out the full link you're being asked to click on - so you can work it out yourself.
On the other hand - how hard would it be for Google to just maintain this service? Like so many things with Google - they create a useful service, then just randomly kill it. It can't require that much resource for them to keep it going - given that they committed to do it. But then Google even do this for paid services - like that time they bought Nest and discontinued half the product range - and just shut the servers down on IoT kit that people had bought 3 months before.
I have memories of shortening services that did advertising redirects back around the mid to late 2k's.
One of them was a bee themed one? You got sent to an advert landing page, then clicked "continue on".
I also have a very small tingle of it paying a portion of profits to the people who created the links, based on click-through/impressions.
Very weird idea back then, still odd now.
It doesn't only seem to be Google though. It appears all over the place, within IT at least. It's not enough to deprecate or cease to promote a given service, but even when it wouldn't hurt to let it remain, once a company falls out of love with a product/method etc. they seem to feel the need to kill it off completely/
Equally there is so much shite out there now the Internet is becoming increasingly useless.
It is now common to have sites that take your search and simply aggregate a load of random links with key words, all bollocking. Then you have the sites that present a stack of generated answers carefully engineered to make it look like people posting questions when in fact it is just generated.
And my final bugbear on tech, utter morons who post helpful responses like:
Have you turning off and on
Defrayg the disk
Reinstall Windows (insert others as appropriate)
Factory reset.
I have that problem
Oh, it is fixed now...... no solution
Of course reinstalling the f*****g OS 99.9999% "fixed" it. As does the factory reset.
THEY ARE NOT FIXES. That is morons making the problem go away until it recurs.
Then all the shite with no date.....
Rant over, maybe I have just been around too long
Totally agree.
Management, marketing and Javascript have long conspired to ensure that the URL got perverted into the absolute filth of length that exists today.
And news sites are the first to blame, with their stupid insistance that they needed their articles to display in three columns, just like paper.
It's the web, stupid. You don't display like paper. But, instead of dealing with it, we had to wait for smartphones and adaptive HTML to get something akin to what the newsies could have understood thirty years ago.
Stop management from interfering in the Internet. That would be a good start to getting things working smoothly again.
There are times when a shortened link is either necessary altogether or necessary given the constraints of the control over the system. For instance, when someone has decreed the use of a certain CMS on a website which generates long links and might be changed in the future, but the link has to be read out and typed in manually because someone's going to mention it in a speech, video, or advertisement. However, my solution when this has proven necessary is to build my own link shortener. At least then, the domain name is the same and the user can know which organization created the link. It also makes them easier to maintain in the future because no external organization can shut them down and, if the destination moves, the shortened link can be updated.
> There are times when a shortened link is either necessary ... the link has to be read out and typed in manually because someone's going to mention it in a speech, video, or advertisement ... build my own link shortener.
99% agree.
The other 1% is because I'd try not to even think of it as a link shortener, but a link sensible namer. Shortening can lead to systems like - well, all of them I've seen used - where you end up giving out 9 chars max of gibberish, whilst a namer tells you to use a sensible name and have, ooh, two dozen chars if it is warranted. E.g. blogs.com/ads/fake-james-bond
As originally conceived, there was a distinction between a Uniform Resource Name (a canonical identifier for the resource) and a Uniform Resource Locator (which identified a means of retrieving the resource). As I recall, TBL originally envisaged hyperlinks as being bidirectional to avoid the "link rot" problem.
Unfortunately, URNs ultimately require a directory provider (and agreed metadata and searching criteria) to find the associated URL(s) and bidirectional hyperlinks are largely impractical as it would be impossible to make a link without the consent of both "ends" not only to their creation but subsequent maintenance.
Instead of a URN directory, we first got the much simpler, but monolithic, search engine (the Internet has really struggled with distributed supplementary services - the fact that domain names are monetizable mean that DNS and TLS certificates are viable, but they're exceptions). These "solve" the problem of resource discovery in a different way: instead of looking for a specific resource, they attempt to identify available resources that may be relevant even if they're not the specific one you're looking for. They worked reasonably well in the past - at the cost of creating monopolies in information discovery - but are breaking down as it becomes harder to distinguish between authoritative content and spam.
Where information quality is important, you generally need something better. The Universities at Bath and Bristol - among many others - have been working on Resource Discovery Networks for years, but the issue is that human assessment of information quality is still the most effective.
I think there is a potential role for something between a link shortener and a URN: a service owned by an identifiable authority, with established criteria for cataloguing resources that could issue permanent "handles" for resources whose actual target could be transparently changed to match their present physical location. Those wouldn't just be academic authorities - you could have a service that accepted any resource if was offered, but it would be much easier to attribute a reliability score to the catalogue provider than to the individual documents. There could even be a delegation of authority similar to the X.509 chain of trust in security certificates.
I think there is possibly a financially-sustainable model in there somewhere, but the issues of finding and identifying resources, assessing their quality and capturing ephemera are all related and increasingly intractable problems to which better solutions are overdue.
I think there are several more problems with bidirectional links and they basically only worked in TBL's internal data system which had a, compared to the internet, very small scope of data to be catalogued. With anything too large, links tend to make sense only in one direction. If my project links to a library I used, that makes sense, because someone modifying my project might want to find the canonical source of the component. If the library links back to my project, it makes much less sense, because that library does not use my project, so at best it can be an example of something you can do with their library and it might not be a good one.
"I think there is a potential role for something between a link shortener and a URN: a service owned by an identifiable authority, with established criteria for cataloguing resources that could issue permanent "handles" for resources whose actual target could be transparently changed to match their present physical location."
I'm not sure when that would be more useful than a more efficient alternative. For instance, we could do that for scientific journal articles, which are relatively easy to name uniquely, and the trusted authority could index them and keep a database of the URLs where you can find the paper. Fine, but nothing prevents someone who operates the server it's pointing to from accidentally shutting it down and disconnecting access. Presumably, the cataloguing authority has to detect that and get the server to come back or find another source. In comparison, if they just copied the thing, then they just have to keep some disk space around and stay online themselves. Less administrative effort and therefore expense means they're more likely to do something like that. That applies as well, if not better, to something that's less organized than scientific papers, because unless the files are very big, the administrative effort of keeping track of their locations is likely higher than the disk space needed to store them.
I detest those fucking things. I teach people to HOVER over links before clicking and those URL obfuscating services make a mockery of it.
Probably the most ominous thing about them is, neither you nor whatever site or service you posted the link on, have control over what that link may redirect to in the future.
Do many people still use them? Or even know such a thing exists?
They have their uses, I suppose - say, for posting a link into an IM or email - but I'm always extra wary of them. I can't imagine that many people will have used them as internal links within their sites, but maybe on social media profiles, or as links to shared documents etc. Could be a real pain tracking them all down, though I'd suggest that if you rely on anything made by Google you probably deserve the pain, and maybe even enjoy it :)
a number of websites fail to maintain their own internal links. I clicked on a link on the Tefal site the other day to check out one of their products, but the link went nowhere, instead I got a message saying the page did not exist. Duh, bit of spring cleaning due?
Did the picture change?
Is currently a graphic of the Grim Reaper (makes sense, Google is killing a "feature")
The figure on the Argus Cover looks more like a Greek Hoplite (am going more by the spear and cloak, although the helmet looks more Roman (gladiatorial, not the horsehair style), maybe?).
Just curious.
As you illustrate, anyone using a Google product does so voluntarily (or they are volunteered by PHB).
It is just that they offered things that many people decided to use - and nobody had paid for an SLA. Which means Google can do whatever it wants with all its kit, just like you do whatever you want with yours.
The meat of TFA is really that people are now going to reap the rewards of not bothering to buy a product: maybe target your anger towards all those people who let the situation come into being and who are the ones that will suffer (and their clients/customers as well, of course).
Then you can use your words productively and point out when those people just go and make the same mistake with another "free" service.
MS seem to have made a virtue out of this. Practically everytime I click on a link to some help topic within W10 or Office, I discover the page “cannot be found” and I’m presented with some generic Microsoft webpage extolling the virtues of the product I’m using or its successor and nothing actually helpful.
The older the product the worse it gets. I expect within a month of W10 going Eo next year, all the W10 related links will start to fail.
It is a cunning ploy on their part. I used to copy MS URLs into my notes and docs, expecting to find them again in a week's time. But they have now hidden Product 2009 and any attempt to search for it on their site only returns Product 2023 (or Product 365). Eventually, you give up as it is cheaper to just buy the new damn Product.
I am less gullible now, and make heavy use of the Print Edit WE add-on, or similar, to store a local copy and put a link to *that* in my docs.
My impression is that Microsoft might be addressing that problem. Most likely in the near future instead of page cannot be found you'll get some AI generated WAG as to what it might have contained.
User: "Hey Clippy, how do I print this thing, there's no Print Button"
Windows: "To print, mix 15g or eye of newt with 7g of frog toe. Add 20g of bat wool and ..."
Aiieee! You scared me silly about this. Even after checking a bit I don't know that I'm not nervous.
I just generated such a URL from Google maps and it looks like
https://maps.app.goo.gl/YBAJQeF5....
so indeed does have goo.gl in the URL
But it also has "maps.app." in the hostname, so not strictly the shortened URL format?
Then found in Google's notice that they explicitly say:
"Any developers using links built with the Google URL Shortener in the form https://goo.gl/* will be impacted, and these URLs will no longer return a response after August 25th, 2025."
So (whew!) Google maps derived links will continue to work. Well, until....
Hello,
I have read this on Mastodon, "Archive Team" is an organization who tries to save the data with grid of computers (like seti@home). The documentation/setup instructions are here:
https://wiki.archiveteam.org/index.php/ArchiveTeam_Warrior
I have a very weird issue with this excellent idea, people in oppressed countries may end up "browsing" regime oppositions blogs/pages and may get logged with RL consequences.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
