Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google shifts goo.gl policy: Inactive links deactivated, active links preserved

blog.google

Post reply on HN
Print view View original

121–130 of 194 posts

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#121

Post by rany_ »

quesera wrote: post #113
rany_ wrote: post #109

Earlier quoted context omitted.

I really doubt it was about security/maintenance burdens. Under the hood, goo.gl just uses Firebase Dynamic Links which is still supported by Google. Edit: nevermind, I had no idea Dynamic Links is deprecated and will be shutting down.

Firebase Dynamic Links is shutting down at the end of August 2025.

I had no idea. It's too late to delete my comment now.

It's a really ridiculous decision though. There's not a lot that goes into a link redirection service.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#122

Post by sumeno »

cogman10 wrote: post #67
Aurornis wrote: post #41

Earlier quoted context omitted.

The Google URL shortener stopped accepting new links around 2018. It has been deprecated for a long time. I doubt it was a cost-driven decision on the basis of running the servers. My guess would be that it was a security and maintenance burden that nobody wanted. They also might have wanted to use the domain for something else.

How much of a burden could this really be? The nature of something like this is that the cost to run it naturally goes down over time. Old links get clicked less so the hardware costs would be basically nothing. As for the actual software security, it's a URL shortener. They could rewrite the entire thing in almost no time with just a single dev. Especially since it's strictly hosting static links at this point. It p…

> How much of a burden could this really be?

You know how Google deprecating stuff externally is a (deserved) meme? Things get deprecated internally even more frequently and someone has to migrate to the new thing. It's a huge pain in the ass to keep up with for teams that are fully funded. If something doesn't have a team dedicated to it eventually someone will decide it's no longer worth that burden and shut it down instead.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#123

Post by observationist »

borg16 wrote: post #18
jasonpeacock wrote: post #7

What amazes me is that this wasn't the original plan. What product manager thinks "the best thing for our customers is to delete their data!". > We understand these links are embedded in countless documents, videos, posts and more, and we appreciate the input received. How did they think the links were being used?

i read in an earlier thread for this on HN - "this is a classic example of data driven product decision" aka we can reduce costs by $x if we just stopped goo.gl links. Instead of actually wondering how this would impact the customers. Also helps that they are in a culture which does not mind killing services on a whim.

At this point, anyone depending on Google for anything deserves to get burned. I don't know how much more clearly they could tell their users that Google has absolutely no respect for users without drone shipping boxes of excrement.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#124

Post by mbac32768 »

chrisjj wrote: post #114
simonw wrote: post #92

Earlier quoted context omitted.

"How much of a burden could this really be?" My understanding from conversations I've seen about Google Reader is that the problem with Google is that every few years they have a new wave of infrastructure, which necessitates upgrading a bunch of things about all of their products. I guess that might be things like some new version of BigTable or whatever coming along, so you need to migrate everything from the previ…

> I guess that might be things like some new version of BigTable or whatever coming along, so you need to migrate everything from the previous versions. Arrival of new does not neccessitate migration. Only departure of old does.

They deprecate internal infrastructure stuff zealously and tell teams they need to be off of such and such by this date.

But it's worse than that because they'll bring up whole new datacenters without ever bringing the deprecated service up, and they also retire datacenters with some regularity. So if you run a service that depends on deprecated services you could quickly find yourself in a situation where you have to migrate to maintain N+2 redundancy but there's hardly any datacenter with capacity available in the deprecated service you depend on.

Also, how many man years of engineering do you want to spend on keeping goo.gl running. If you were an engineer would you want to be assigned this project? What are you going to put in your perf packet? "Spent 6 months of my time and also bothered engineers in other teams to keep this service that makes us no money running"?

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#125

Post by lokar »

chrisjj wrote: post #114
simonw wrote: post #92

Earlier quoted context omitted.

"How much of a burden could this really be?" My understanding from conversations I've seen about Google Reader is that the problem with Google is that every few years they have a new wave of infrastructure, which necessitates upgrading a bunch of things about all of their products. I guess that might be things like some new version of BigTable or whatever coming along, so you need to migrate everything from the previ…

> I guess that might be things like some new version of BigTable or whatever coming along, so you need to migrate everything from the previous versions. Arrival of new does not neccessitate migration. Only departure of old does.

A lot of Google infra services are built around the understanding that clients will be re-built to pick up library changes pretty often, and that you can make breaking API changes from time to time (with lots of notice).

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#126

Post by [deleted] »

mbac32768 wrote: post #124
chrisjj wrote: post #114

Earlier quoted context omitted.

> I guess that might be things like some new version of BigTable or whatever coming along, so you need to migrate everything from the previous versions. Arrival of new does not neccessitate migration. Only departure of old does.

They deprecate internal infrastructure stuff zealously and tell teams they need to be off of such and such by this date. But it's worse than that because they'll bring up whole new datacenters without ever bringing the deprecated service up, and they also retire datacenters with some regularity. So if you run a service that depends on deprecated services you could quickly find yourself in a situation where you have t…

[deleted]

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#127

Post by onli »

wolrah wrote: post #71
progval wrote: post #68

Earlier quoted context omitted.

Hindsight is 20/20. Google was considered by geeks to be a very reliable company at some point.

Using a link shortener for any kind of long-term link, no matter who hosts it, has never been a good idea. They're for ephemeral links shared over limited mediums like SMS or where a human would have to manually copy the link from the medium to the browsing device like a TV ad. If you put one in a document intended for digital consumption you've already screwed up.

We knew that. But it is very useful in documents that would be printed, especially if the original url is complicated. That is why one would not use a random url shortener, but Google's. After all, Google would never destroy those URLs, and the company will likely outlive us.

I'm completely serious, and I have a PhD thesis with such links to back it up. Just in some foootnotes, but still.

Yes, maybe this shows how naive we were/I was. But it definitely also shows how deep Google has fallen, that it had so much trust and completely betrayed it.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#128

Post by ikiris »

mbac32768 wrote: post #124
chrisjj wrote: post #114

Earlier quoted context omitted.

> I guess that might be things like some new version of BigTable or whatever coming along, so you need to migrate everything from the previous versions. Arrival of new does not neccessitate migration. Only departure of old does.

They deprecate internal infrastructure stuff zealously and tell teams they need to be off of such and such by this date. But it's worse than that because they'll bring up whole new datacenters without ever bringing the deprecated service up, and they also retire datacenters with some regularity. So if you run a service that depends on deprecated services you could quickly find yourself in a situation where you have t…

Because it costs money to run things, and no one wants to pay for something that they aren't getting career value for.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#129

Post by 0cf8612b2e1e »

wolrah wrote: post #71
progval wrote: post #68

Earlier quoted context omitted.

Hindsight is 20/20. Google was considered by geeks to be a very reliable company at some point.

Using a link shortener for any kind of long-term link, no matter who hosts it, has never been a good idea. They're for ephemeral links shared over limited mediums like SMS or where a human would have to manually copy the link from the medium to the browsing device like a TV ad. If you put one in a document intended for digital consumption you've already screwed up.

I am constantly annoyed at O’Reilly and similar book vendors which seem to have a policy that all links should go through a shortener.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#130

Post by Polizeiposaune »

simonw wrote: post #92
cogman10 wrote: post #67

Earlier quoted context omitted.

How much of a burden could this really be? The nature of something like this is that the cost to run it naturally goes down over time. Old links get clicked less so the hardware costs would be basically nothing. As for the actual software security, it's a URL shortener. They could rewrite the entire thing in almost no time with just a single dev. Especially since it's strictly hosting static links at this point. It p…

"How much of a burden could this really be?" My understanding from conversations I've seen about Google Reader is that the problem with Google is that every few years they have a new wave of infrastructure, which necessitates upgrading a bunch of things about all of their products. I guess that might be things like some new version of BigTable or whatever coming along, so you need to migrate everything from the previ…

My understanding is that (at least at one point) binaries older than about six months were not allowed to run in production. But APIs are "evolving" irregularly so the longer you go between builds the more likely something is going to break. You really need a continuous build going to stay on top of it.

Best analogy I can think of is log-rolling (as in the lumberjack competition).

Post reply on HN