Live data from Hacker News

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

blog.google

111–120 of 194 posts

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

#111
post #18

Earlier quoted context omitted.

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.

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.

> 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.

Yeah I can't imagine it being a huge cost saver? But guessing that the people who developed it long moved on, and it stopped being a cool project. And depending on the culture inside Google it just doesn't pay career-wise to maintain someone else's project.

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

#112

Earlier quoted context omitted.

It's not useful if the resulting URL is too long. It defeats the purpose of a URL shortener. The source URL can just be used then.

Yes I did address that part but honestly I can use the time of when it was sent into blockchain / transaction id which is generally really short as I said in the comment. I will hack a prototype tomorrow.

It is the long URL that also needs to be stored, not just the short URL.

If you want to use blockchain for this, I advise properly using a dedicated new blockchain, not spamming the Nano network.

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

#113
post #109

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.

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.

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

#114
post #92

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…

> 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.

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

#115

Earlier quoted context omitted.

Honestly, that's a great question I think I might be doing a self plug here, so pardon me but I am pretty sure that I can create something like a link shortener which can last essentially permanent, it has to do with crypto (I don't adore it as an investment, I must make it absolutely clear) But basically I have created nanotimestamps which can embed some data in nano blockchain and that data could theoretically be a…

You can't address the risk that whoever owns the domain will stop renewing it, or otherwise stop making the web gateway available. Best-case scenario is that it becomes possible to find out what URL a shortened link used to point to, for as long as the underlying blockchain lasts, but if a regular user clicks on a link after the web gateway shuts down then they'll get an error message or end up on a domain squatting…

These days one can register a domain for ten years, and have it auto-renew with prefunded payments that are already sitting in the account. This is what I did for the URL shortener I am developing.

The same would have to be done for the node running the service, and it too has been prefunded with a sitting balance.

Granted, there still exist failure modes, and so the bus factor needs to be more than one, but the above setup can in all probability easily ride out a few decades with the original person forgetting about it. In principle, a prefunded LLM with access to appropriate tooling and a headless browser can even be put in charge to address common administrative concerns.

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

#117

Earlier quoted context omitted.

The key difference is share.google, as you mentioned, is for Google controlled properties whereas goo.gl allowed shortening any arbitrary user provided URL. Which opened up a giant can of worms with Google implicitly lending its brand credibility to any URL used by a scammer, phisher or attacker.

You can generate share.google links on chrome for any arbitrary url.

How? I just tried each of the Share options for this thread in the desktop Share menu, and they all used the full URL. Including the QR code which I verified by saving as a PNG and scanning it outside of any Google app. I also haven't found any Share option in the iOS app either that doesn't use the full URL. But harder to test on mobile given the various permutations of sharing between random apps.

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

#119
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.

But if you don't downgrade the old, then you're endlessly supporting systems, forever. At some point, it does become cheaper to migrate everything to the new.

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

#120
post #70
post #18

Earlier quoted context omitted.

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.

Goo.gl didn't have customers, it had users. Customers pay , either with money or their personal data, now or the future. Goo.gl did not make any money or have a plan to do so in the future.

I always figured most of the real value of these url hashing services was as an marketing tracking metric. That is, sort of equivalent to the "share with" widgets provided that conveniently also dump tons of analytics to the services.

I will be honest I was never in an environment that would benefit from link shortening, so I don't really know if any end users actually wanted them (my guess twitter mainly) and always viewed these hashed links with extreme suspicion.

Post reply on HN