Live data from Hacker News

Transitioning Google URL Shortener to Firebase Dynamic Links

developers.googleblog.com

41–50 of 59 posts

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#41

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

Probably because there is one Firebase team and one Google Cloud Other Stuff team and the teams just make different things.

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#42

Probably a good chance to inject this here: You can build your own private URL shortener with AWS Lambda, for a dozen cents a month [0]. I've made some modification to it so that it supports customized short name, but the changes are trivial to implement. You could (should?) also probably consider a short domain name to pair with it, but those are also cheap ($10/yr, perhaps depend on the TLD). [0]: https://aws.amazo…

Do u the source for custom-short-name on GitHub somewhere?

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#43
post #37

Probably a good chance to inject this here: You can build your own private URL shortener with AWS Lambda, for a dozen cents a month [0]. I've made some modification to it so that it supports customized short name, but the changes are trivial to implement. You could (should?) also probably consider a short domain name to pair with it, but those are also cheap ($10/yr, perhaps depend on the TLD). [0]: https://aws.amazo…

Talk about over engineering: spin up your own URL shortener using Lambda.

It’s really just a few clicks with CloudFormation

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#44
post #34

Earlier quoted context omitted.

The things they're announcing here are a turndown of support for creating new goo.gl links and a more flexible but slightly differently focused replacement, both without breaking existing links. Your comment is a general one that, while entirely valid, applies to all URL shorteners. How is that somehow different in the case of Google's shortener or this transition?

Because it’s a different domain. I expect google app links to go to something that looks like google (or goo.gl, etc), not something totally different that I am not knowledgeable is part of google.

This change isn't about what Google apps do. Indeed I wouldn't be at all surprised if Google Photos sharing continues to use photos.app.goo.gl following this change as it does now.

This is about turning down a service that formerly allowed arbitrary third parties unaffiliated with Google to make goo.gl links going to whichever destinations they wanted, and allows those third parties to track certain usage data like bit.ly also allows.

Google is simply removing that third party offering. I think that aligns very well with what you'd prefer, if I'm understanding you correctly.

It wouldn't surprise me if reducing user confusion is even part of their internal rationale for the turndown, though I don't actually know. I haven't been privy to such details since I left Google roughly 3 years ago.

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#45
post #35

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.

See my post a couple minutes ago - it routes to a completely different domain that, until I read this article, had no idea was related to google. I don’t expect that from a major provider like google or Apple, Microsoft, etc.

It's the same domain. The only difference is the subdomain partitioning by app.

Original: https://goo.gl/abcde

New: https://yourname.app.goo.gl/abcde

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#46

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?

They're still shorter, and less likely to line-wrap and break older clients. They also help to obfuscate certain tracking info and/or protect them from tampering.

Also you can set a custom shortname in almost all of them, if it's available.

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#47

Earlier quoted context omitted.

> Being security conscious, I hovered over the link and suspected a phishing attack. > Given I work in finance, this was the only prudent move I felt I had. At my place of employment, we are instructed to "hover to uncover" every link in an e-mail. Yet every link I get from virtually any automated source reads something like this: "To accomplish the task you need to accomplish, simply visit us at h t t p s: / / examp…

You've just given me an interesting idea for an extension to HTML itself - an anchor tag / link type where the text displayed can and must only be equal to the href value of the link. Additionally, any rendering client could render such a link with a special visual cue, perhaps, to help the user understand that the visible link text should equal the link href value and only the link href value. Could just be, maybe y…

What is the point of that? The vast majority of people don't care about URLs, which is why they don't check it when browsing and why we have links and buttons in the first place. That also doesn't solve anything regarding URL redirects.

It seems you're attempting to solve a spam/security issue through a presentation layer, which really works, especially when it's opt-in to a new HTML standard.

All major client clients already do some form of link scanning, including robots to visit the links themselves. This also feeds into their spam scores and can retroactively block certain links when wrapping it in their own redirects.

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#49
post #11

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

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”

Re: Transitioning Google URL Shortener to Firebase Dynamic Links

#50

Probably a good chance to inject this here: You can build your own private URL shortener with AWS Lambda, for a dozen cents a month [0]. I've made some modification to it so that it supports customized short name, but the changes are trivial to implement. You could (should?) also probably consider a short domain name to pair with it, but those are also cheap ($10/yr, perhaps depend on the TLD). [0]: https://aws.amazo…

URL Shorteners break the Internet[0] (2009) With Google Or Twitter, at least, they have some semblance of permanence, but with everyone hosting their own private shortener, will just lead to madness. [0]: https://blog.codinghorror.com/url-shorteners-destroying-the-...

Since then, URLs have even less to do with any real underlying directory structure.

What's another level of indirection between the browser and your CDN, your reverse proxy, your cache and your web framework?

Post reply on HN