Chrome 64 now trims messy links when you share them | Hacker News Reader

Chrome 64 now trims messy links when you share them

theverge.com

28 pointsStanAngeloff25 comments

This seems like an odd feature, with more downsides than positives. Sure: long, messy URLs seem ugly; but, anchor tags and query parameters are often integral to display the desired state of a certain page. Anchor tags especially.

Also, how does it determine which parameters are critical to keep in? In the example, `ie` and `node` are retained, but `smid` is stripped. Obviously, `node` is important`, but `smid` may also be, whereas `ie` seems superfluous.

Exactly. When I share links, I always test a link (load the link in a private window) after stripping out the extra URL info before sharing it. I'm not sure how a browser would do that automatically.

Actually your process seems pretty easy to automate. Reload a page until you get the minimum set needed to reproduce the current DOM.

Except many pages have unique data on each load

If that's what Chrome is doing, verifying that the shortened URL produces the same DOM, then I wouldn't have a problem with that.

That has exponential complexity, is network-bound (slow) and still doesn't handle many cases (for example a "current DOM" where all relative links and images are broken).

Should be O(n) unless you're trying to optimize for every single permutation of query param, right? I'd assume the majority of the time the individual params would be independent from one another. Plus you'd only need to do it once in a while for any given base url and persist the result.

Compared to GGP's approach of having a human do it, this is still fast.

Also not sure why you'd want to share a link to a page where all the images and links are broken in the first place.

With JavaScript in play, even reloading the exact same page might yield a different DOM

Or corporate websites where something as simple as looking at my schedule has a “query run” time

I do the same thing.

That being said, a huge majority of users wouldn't take these extra steps.

Agreed. Why is this necessary?

The only possible endgame here seems like sites abandoning query params in favor of baking that information directly into the URL, which is a worse situation all around.

After some investigation, it appears to use the link rel=canonical head element that the search engine uses [0]. So it doesn't seem that nefarious since it's opt-in.

0 - https://support.google.com/webmasters/answer/139066?hl=en

I can confirm this after a look at the source.

https://cs.chromium.org/chromium/src/third_party/WebKit/Sour...

Will this mean the canonical links will start to disappear from pages? I doubt amazon, for one, will want to lose their tracking markers from pressing share.

I hope so. I don't appreciate that they were floated for SEO and are now used for an alternative purpose. They don't even mention it on the page I linked.

What I wonder is if the other forms of letting Google know the SEO-canonical URLs are also applied to Share-Link-canonical URLs (e.g. in the sitemap). I suspect not based on the sibling poster's source link. So the right answer seems to be not to use the head element if you don't want Google taking it off when sharing. All web devs know how to use JS to perform non-history-changing URL changes if we really wanted to cull the query parameters. We don't need their help.

I like the idea of sharing clean URL's. Actually, I use the Pure URL add-on[0] for Firefox which also removes garbage such as e-mail campaign tracking values, both for the purpose of sharing and since I prefer seeing/visiting clean URL's myself as well.

The Chrome implementation using the canonical URL has some edge cases which may be useful to handle, like adding the fragment which isn't part of the canonical URL for the resource yet can be useful to share. Given that this change is only for the share dialog and not for copying from the URL bar, that doesn't seem like a huge problem though.

[0]: https://addons.mozilla.org/en-US/firefox/addon/pure-url/

Almost right! Imagine if Chrome also trimmed away all the AMP mess when sharing a link.

Great for Google because they limit tracking for the sites it trims the links for. But Google can still see where it came from. Equals more profits.

Does this work for links from a Google search result too?

It appears to rewrite a URL of the form https://www.amazon.com/s/browse/.... to https://www.amazon.com/b?.... . This means it either has a (possibly huge) database of rewrite rules that needs to be kept up-to-date, or communicates with yet another Google API. Probably the latter, leaking even more of your browsing history to Google.

Your links are broken. Regardless, do a view-source and look for `<link rel="canonical` and I believe that is what is being used.

Not broken, but "of the form", with dots where variant stuff goes. (Edit: okay, HN mangled them a bit; I changed them a little.)

Or it could just as easily be using the canonical links in the head of the page.

Jumping straight to malice when the answer could be simple and benign is incredibly harmful. It undermines efforts to shine a light on truly malicious behavior.

I totally forgot that there could be a canonical link in the head of a page. Apologies for that.

Reply on news.ycombinator.com