
Chrome 64 now trims messy links when you share them - StanAngeloff
https://www.theverge.com/2018/2/19/17029162/google-chrome-64-link-trim-feature
======
dhritzkiv
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.

~~~
kodablah
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](https://support.google.com/webmasters/answer/139066?hl=en)

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

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

------
DvdGiessen
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/](https://addons.mozilla.org/en-US/firefox/addon/pure-url/)

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

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

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

------
gpvos
It appears to rewrite a URL of the form
[https://www.amazon.com/s/browse/...](https://www.amazon.com/s/browse/...). to
[https://www.amazon.com/b?...](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.

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

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

