31–40 of 59 posts
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 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…
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-...
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…
This has been poorly handled. 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.
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?
This has been poorly handled. 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.
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.
I don’t expect that from a major provider like google or Apple, Microsoft, etc.
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…
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?
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…
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…
Earlier quoted context omitted.
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 if the page tries to position another element over the link? If you just say that the safe-link has the highest z-index, then you'll have plenty of awkward cases where it shows through stuff like sticky navbars/headings or dropdowns that happen to be opened over them. And what would the browsers do to show those links specially? Could a webpage do the same around their own links?
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) -> " rel="nofollow">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.