4 ms·
Chrome 64 now trims messy links when you share them
- dhritzkiv 9y agoThis 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.
- Osiris 9y agoExactly. 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.
- labster 9y agoActually your process seems pretty easy to automate. Reload a page until you get the minimum set needed to reproduce the current DOM.
- ikeboy 9y agoExcept many pages have unique data on each load
- Osiris 9y agoIf that's what Chrome is doing, verifying that the shortened URL produces the same DOM, then I wouldn't have a problem with that.
- dullgiulio 9y agoThat 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).
- bluepnume 9y agoShould 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.
- labster 9y agoCompared 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.
- yjftsjthsd-h 9y agoWith JavaScript in play, even reloading the exact same page might yield a different DOM
- colejohnson66 9y agoOr corporate websites where something as simple as looking at my schedule has a “query run” time
- illnewsthat 9y agoI do the same thing. That being said, a huge majority of users wouldn't take these extra steps.
- koboll 9y agoAgreed. 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.
- kodablah 9y agoAfter 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
- skymt 9y agoI can confirm this after a look at the source. https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/exported/WebDocument.cpp?l=286 https://cs.chromium.org/chromium/src/third_party/WebKit/Sour...
- kevin_b_er 9y agoWill 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 9y agoI 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.
- deleted 9y ago[deleted]
- dal 9y agoGreat 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.
- thestephen 9y agoAlmost right! Imagine if Chrome also trimmed away all the AMP mess when sharing a link.
- gpvos 9y agoIt 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.
- kodablah 9y agoYour links are broken. Regardless, do a view-source and look for `<link rel="canonical` and I believe that is what is being used.
- gpvos 9y agoNot broken, but "of the form", with dots where variant stuff goes. (Edit: okay, HN mangled them a bit; I changed them a little.)
- reificator 9y agoOr 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 9y agoI totally forgot that there could be a canonical link in the head of a page. Apologies for that.
- DvdGiessen 9y agoI 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/
- lazycouchpotato 9y agoDoes this work for links from a Google search result too?