Transitioning Google URL Shortener to Firebase Dynamic Links(developers.googleblog.com) |
Transitioning Google URL Shortener to Firebase Dynamic Links(developers.googleblog.com) |
Reminds me of Microsoft reusing "Surface", or prepending "Live" to everything once upon a time...
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.
or am i thinking of totally different things? I feel like there are other google products that end with “Base”
A Google branding is closely associated with Android.
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.
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.amazon.com/blogs/compute/build-a-serverless-priv...
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-...
What's another level of indirection between the browser and your CDN, your reverse proxy, your cache and your web framework?
1) User clicking on a URL: the latency of this action is mostly determined by the latency of cloudfront, which is pretty fast [1]. (Except in the case of a first-click when cloudfront has to do a pull from S3, which is also not bad [1])
2) Creation of a new short URL: this action is the execution of a lambda function, which in my experience is ~1s in cold-start scenarios, and near instant otherwise.
[0]: https://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-...
[1]: https://www.quora.com/What-are-typical-latencies-for-static-...
[1] https://firebase.google.com/docs/dynamic-links/create-manual...
examples of g.co urls: http://g.co/payhelp http://g.co/recover http://g.co/allo
I got an email for my company yesterday with one of these links.
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.
Google is going to see a lot of that over the coming weeks if they can’t improve their communication on this.
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 more purposeful destination forwarding.
[1] https://firebase.google.com/docs/dynamic-links/use-cases/
Once the service is locked and statistics are off (ie mid-2019) the entire site could be replaced with an exported set of static files.
Presumably that will go away at some point. Ain't nothing free.
> 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: / / example dot com / some / simple.url.html"
Yet the ACTUAL link is: "h t t p : / / linktracker9 . unrelatedentity4 . subdomain . example dot io / asdflkjawsfq3894gfjwerfgouiewjngwskuvhawesri7gfhwe4i7fghwefv / qwerog9f8weh8w4fhw98ry2938hwf?utm_lol=hahaha&utm_more=roflcopter&utm_howabsolutelylongcanwemakethislink=shadyb1zn3zz&phishing=no&itscool=thisis_definitely_not_phishing&utm_feed=buzz"
I understand, but do not accept, why every link sending program on the planet insists on doing this. It is broken and wrong.
Could just be, maybe you could make an anchor tag which is like, <a href="http://www.google.com"> without a closing tag, and browsers know to render that where the text displayed equals the value of the href. Additionally, clients could detect such links and give them a visual cue to indicate they are "safe(r)" relatively speaking?
Just an idea that popped in when you said this.
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?
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?
I don’t expect that from a major provider like google or Apple, Microsoft, etc.
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.
Original: https://goo.gl/abcde
Also you can set a custom shortname in almost all of them, if it's available.
They allow tracking.
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.
I guess I was thinking, browser vendors and clients that care are already taking measures to inform users if the URL they are browsing is safe / secure (HTTPS enabled UI for example) - I was just trying to think of some way for the HTML source itself to indicate "hey, the value of the href of this link should be exactly 'X', and a user can see that relatively easily, and if for any reason it is NOT 'X' then the link should not be trusted". I mean, the clients could also take active measures to block such links as well... if the "href" is not the same as the expected value for the href (or if it changes), then the client disables the link automatically.
I don't think one would use the "safe-links" I described everywhere (like, not in places where they would bleed through). I think they might be a special use case, maybe for emails and clients that are rendering more document oriented HTML as opposed to web-site/web application type HTML, although browsers could certainly render them.
Of course, those clients would have to be trustworthy too.
I suppose rather than showing any visual cues that the link is enabled, clients could just validate that... if they see a link like this (without text or an ending anchor tag) -> <a href="http://www.google.com"> then the one and ONLY action the link can take is to navigate to the precise href specified, and it would only render the text of the href as the content of the anchor tag.
So maybe a visual cue is not even needed - just enforcement by trustworthy clients.