Transitioning Google URL Shortener to Firebase Dynamic Links • Hacker News Board

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#51

Post by manquer » Sat, Mar 31, 2018, 7:36 AM UTC

dingaling wrote: post #27

manigandham wrote: post #23

Earlier quoted context omitted.

What is poorly handled and what should've been different? The security issue seems to be the obfuscation that is offered by all URL shortners and redirects, and most email links usually have several layers of them.

Which raises the question of the purpose of link shorteners anyway. They are usually so obscure and jumbled that reading them out loud to someone would be slow and awkward ( "that's goo dot gl, no e" ). So what is the use-case?

SMS is one case where we use them. Shorter links mean we could fit notifications into typical 140 characters limit for single sms

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#52

Post by manquer » Sat, Mar 31, 2018, 7:39 AM UTC

duskwuff wrote: post #38

niftich wrote: post #8

Earlier quoted context omitted.

Continuing to honor existing redirects is a relatively simple gesture of goodwill -- it's absolutely what customers expect, it's good for the web, and doesn't need a lot of ongoing effort. Rather, it looks like they're driving people to a different product intended for a different set of usecases [1]. They want to get out of the generic, commodity web URL shortener business, and drive more of their customers towards…

Crucially, the new product is unlikely to be available through a web interface (at least, without an account), so Google no longer has to deal with their link shortener being used for spam and fraud.

Spammers would not be dettered by the need to use an API. Besides anyone could build a frontend for accessing the API

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#53

Post by traek » Sat, Mar 31, 2018, 10:00 AM UTC

AznHisoka wrote: post #49

niftich wrote: post #11

Earlier quoted context omitted.

Firebase is their Mobile-Backend-as-a-Service brand. The product they're driving customers to, Firebase Dynamic Links, is not really a web URL shortener, but more of a bridge between URLs and in-app links. In this light, it makes sense.

I thought it was their repo of entities that was used for displaying Google Knowledge results? Or the ecommerce product repo... or am i thinking of totally different things? I feel like there are other google products that end with “Base”

That was Freebase, which was acquired by Google for use in their Knowledge Graph.

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#54

Post by sethammons » Sat, Mar 31, 2018, 1:10 PM UTC

In regards to the shortener replacement, it might be nice for app developers, but as a user, I loathe when a link that can go to a website tries to bring me to the app install. I don't want to install your likely crappy, less featurefull app.

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#55

Post by DigitalSea » Sat, Mar 31, 2018, 1:23 PM UTC

russellbeattie wrote: post #5

I wonder why Google is reusing the Firebase brand so much? It doesn't really fit with messaging (GCM -> FCM) or links, among other functions. Seems like an odd choice, even if the backend infrastructure/team is the same. Reminds me of Microsoft reusing "Surface", or prepending "Live" to everything once upon a time...

As someone who is a heavy Firebase user and a huge fan, it reassures me that Google has so much confidence in the Firebase platform. When you think about it, Firebase is just a friendly wrapper around Google Cloud, pretty much every Firebase feature is just UI sugar over Google Cloud Functions, Google Cloud Hosting and so on.

While Google pushes its mobile functionality and features first and foremost, Firebase is an invaluable web platform for both native and web, sans a couple of features like Remote Config.

I think Firebase is one of the best things to happen to my development workflow in a long time, invaluable for things like MVP's, etc.

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#56

Post by johan_larson » Sat, Mar 31, 2018, 1:33 PM UTC

kirubakaran wrote: post #3

Since they will be continuing to honor existing redirects, do they gain anything by disallowing new redirects? If it is engineering effort they want to save, they can just stop developing new features, right?

I'm a bit surprised they are planning to continue to support existing short urls indefinitely.

Presumably that will go away at some point. Ain't nothing free.

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#57

Post by smarx007 » Sat, Mar 31, 2018, 10:54 PM UTC

Google should give the whole dump of the redirects to the Internet Archive (or at least stop banning their crawlers) https://archive.org/details/301works

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#58

Post by SeanKilleen » Sun, Apr 01, 2018, 3:09 AM UTC

If you want a free OSS URL shortener for your own domain name, I built a simple one at http://xluh.co/repo. Will be expanding on it in the future.

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#59

Post by anarazel » Sun, Apr 01, 2018, 5:02 PM UTC

dingaling wrote: post #27

manigandham wrote: post #23

Earlier quoted context omitted.

What is poorly handled and what should've been different? The security issue seems to be the obfuscation that is offered by all URL shortners and redirects, and most email links usually have several layers of them.

Which raises the question of the purpose of link shorteners anyway. They are usually so obscure and jumbled that reading them out loud to someone would be slow and awkward ( "that's goo dot gl, no e" ). So what is the use-case?

> So what is the use-case?

They allow tracking.