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.

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.

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

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

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.

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.

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.

Except many pages have unique data on each load

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.