[MR4D]

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.

[techsupporter]

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

[snuxoll]

I can't even see the real link because our anti-spam software rewrites every single one (so they all look like https://somesubdomain.mimecast.com/linkcheck?something=as8fg...). Even more annoying it loads the URL before you even get to it, so single use URL's like Salesforce password resets get burned before you can use them (we finally got this fixed with our old Proofpoint setup that did the same nonsense, I haven't pestered them to fix it with Mimecast yet).

[sixdimensional]

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

[manigandham]

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.

[AgentME]

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?

[sixdimensional]

Yeah, those are legitimate problems, I agree.

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.

[exikyut]

This resonates strongly, I reckon. I really like this idea.

[jkaplowitz]

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?

[MR4D]

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.

[jkaplowitz]

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.

[manigandham]

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.

[dingaling]

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?

[manigandham]

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.

[manquer]

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

[anarazel]

> So what is the use-case?

They allow tracking.

[MR4D]

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.

[manigandham]

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