mousing over link shows different URL to where clicking it goes

[aspiers]

With the extension enabled, when mousing over a link, it shows the unstripped URL, yet clicking the link will navigate to the stripped version. I'm guessing the mouseover URL is unaffected because of the implementation only intercepting at click-time, not during page load / render:

The extension doesn't do any DOM parsing, but rather uses available APIs (webRequest.onBeforeRequest for navigation intercepts and contextMenu.create.onclick for right-clicks) to know about what the URL is.

I don't know how easy it would be to achieve, but I think it would definitely be less misleading if the mouseover URL was the exact URL which gets visited when the link is clicked. It's slightly scary to realise that a malware extension could hijack any innocent click and take the user somewhere they really don't want to go. So in the interests of keeping this benign extension as honest and transparent as possible, IMHO it would be worth fixing the mouseover, if that is technically feasible.

[aspiers]

#69 describes another scenario where the mismatch between mouse-over and click is still there but the opposite way around: only the mouse-over URL is stripped, not the one used for navigation.

[Letahl]

The extension cannot handle all possible redirects due to the format of the target URL (i.e. http://cj.dotomi.com/links-t/000000/type/dlg/sid/xxxxx/https://www.website.com/). I'm working on a way to handle some of these links with this style of URL.

It should be possible to have a feature where, if a redirect is not handled, it will parse that and determine that as the final URL to show upon mouseover (i.e. https://slickdeals.net/?tid=0000000 with tracking query strings removed, and then follow the redirects). Unfortunately, I'm not familiar with DOM parsing (the original developer might be, though) or how much of a performance hit it will take. If you have some suggestions as far as where to learn DOM, let me know.

[aspiers]

@cameronrcraig commented on 22 Aug 2018, 20:03 BST:

The extension cannot handle all possible redirects due to the format of the target URL (i.e. http://cj.dotomi.com/links-t/000000/type/dlg/sid/xxxxx/https://www.website.com). I'm working on a way to handle some of these links with this style of URL.

I don't understand. How is this style of URL any different to many of the redirect styles it already handles? For example, how is it different to the https://www.google.com/url?https://www.website.com style already handled here:

url-tracking-stripper/assets/js/redirects.js

Line 29 in d500b14

`${SCHEMA}www.google.com/url?`

It should be possible to have a feature where, if a redirect is not handled

What exactly do you mean by "not handled" in this context? I'm not sure I follow.

it will parse that and determine that as the final URL to show upon mouseover (i.e. slickdeals.net/?tid=0000000 with tracking query strings removed, and then follow the redirects).

Is that different from what I already proposed in this issue? If so, how?

Unfortunately, I'm not familiar with DOM parsing (the original developer might be, though) or how much of a performance hit it will take. If you have some suggestions as far as where to learn DOM, let me know.

The browser parses the DOM, but that's not relevant here as explained above in the issue description.

[Letahl]

I don't understand. How is this style of URL any different to many of the redirect styles it already handles? For example, how is it different to the https://www.google.com/url?https://www.website.com style already handled here:

"http://cj.dotomi.com/links-t/000000/type/dlg/sid/xxxxx/https://www.website.com" is a different URL because the extension functions by finding the first occurrence of "?" which indicates the start of the query string, and that is how nearly all URLs are formatted.

What exactly do you mean by "not handled" in this context? I'm not sure I follow.

Also, "not handled" in that context means that some target URLs cannot be fully extracted from the original URL, such as link shorteners like bit.ly. It would be detrimental to go through all of the redirects to find the final URL on each and every mouseover, especially if you did not intend to visit all of those links - the bit.ly link would have to do. But, that is not all cases!

Is that different from what I already proposed in this issue? If so, how?

It is somewhat different because the slickdeals.net/?tid=0000000 represents a case where the final URL cannot be extracted upon mouseover so I was giving an example. That link will redirect you to another site. If the final URL is able to be extracted, such as the gmail links, then the mouseover should show that final URL.

[newhouse]

Hi @aspiers thanks for the inquiry. As you already noticed, the extension does not go in an manipulate the hrefs/urls in the DOM itself. While it may seem scary to you that an extension may manipulate a URL you're navigating to in-flight, I think it's far scarier to imagine an extension reading and manipulating all of the HTML on all of the pages you go to (bank accounts, utilities, crypto, etc) in order to provide a smidgeon of privacy for the small % of times you happen to click a link with some UTM params. There is also no mouseover API in Chrome that I'm aware of that can handle only mouseover events from outside the page...but if you find one, please let me know!

Also, you're right to be a bit skeptical and there are indeed some bad people/companies out there and you should be cautious of what you install in Chrome. This extension mitigates that by being open-source for all to see, but Chrome extensions are notoriously dangerous things unfortunately.