Firefox prevented this page from automatically redirecting...

[king-daddy]

How can I see the destination url?

Use of this 'feature' seems to be exploding.

Carl

[VanguardLH]

king-daddy wrote:

> How can I see the destination url?

Mozilla has never deemed it necessary to show to where a redirection
points. To know there a redirect means knowing to where the redirection
points but Mozilla won't give you that info. You'll want to look at an
add-on. I tried a couple and they *do* tell you to where the redirect
points. I tried Redirect Control but sometimes it got too much in the
way (https://addons.mozilla.org/en-US/firefox/addon/redirect-control/):
it would block hyperlinks pointing to another site (different domain).
Most of the research I do has articles that point elsewhere for their
references and I had to keep telling this add-on that type of
redirection (which few users call redirection since this is behavior
expected of a hyperlink) was okay. If it merely blocked an interstitial
page used at the deliberately chosen redirect for they hyperlink then
that would be okay.

Even Firefox's own redirect blocking will trigger when visiting
Mozilla's add-ons page (addons.mozilla.org), selecting an add-on to
review, and clicking on a hyperlink taking you to the author's support
or home site. For example, look at the abandoned Redirect Remover
(https://addons.mozilla.org/en-US/firefox/addon/redirect-remover/) and
click on the "Support site" link (which is a dead community there).

Firefox's redirection block is not very robust. It catches redirects
using the meta-refresh attribute in HTML. It will not detect redirects
using Javascript. So while you might be encountering nuisances now,
sites are using more methods for redirection than Firefox will alert.

[king-daddy]

Thanks for all your elaboration. It's helpful.
The example you provided, I can see the target on the status bar. If it is hidden, I will not click it.

Sometimes I can view page source and find something helpful.

Sadly, I still exploit the HOSTS file but it's not perfect either. Some of the ads, and other requesters, need a
response, but the timeout delay is not as bad as enduring the target execution.

Carl

[Wolf K.]

On 2015-11-25 16:49, VanguardLH wrote:
> king-daddy wrote:
>
>> >How can I see the destination url?
> Mozilla has never deemed it necessary to show to where a redirection points.

[snip tech stuff]

As the snipped comments indicate, blocking/allowing a redirect is a
filter problem. No filter will ever be perfect.

That being said, I'd prefer to see the URL, then the user becomes the
filter. But you'll find that you often haven't a clue to what that URL
hides. Same as when you use a site-rating add-on, sometimes you'll
disagree with the ratings. So just use your best guess, and go!

You can't win.



--
Best,
Wolf K.
kirkwood40.blogspot.ca

[VanguardLH]

king-daddy wrote:

> The example you provided, I can see the target on the status bar. If
> it is hidden, I will not click it.

In that example, the the target site is short so it can be all displayed
in that infobar at the bottom. Actually, for this example, you can look
at the address bar to see the redirection was:

http://outgoing.mozilla.org/v1/807c0735a823579bb2737c4200ad1dd05a389bdd6c443959e628cbdad72b1e60/http%3A//getsatisfaction.com/betterbrowser/products/betterbrowser_firefox_redirect_remover

Apparently Mozilla's parser uses the last part of the URL string for the
target URL (after Mozilla's unique ID - the long hex number which is
their tracking ID when you click on their link). Because a colon is not
valid in the URL (after the URL protocol specifier), they use the ISO
entity for it (%3A).

Used to be the online search engines use redirection. They redirected a
search result's link to their server (so they could track how often that
result got selected to record relevancy ranking) and then their server
took you to the actual target site. Now they show the target site in
the <A> tag (the href attribute) but put the hyperlink inside a <DIV>
that has a unique ID so which link you click can still be tracked.
They're getting trickier to track you. This way you see the href shown
in the <A> tag in the infobar displayed by the web browser (instead of
using https://<google>/parms&url=<ISOentityURL>). There are add-ons
that specify attempt to remove this type of redirection (e.g., they look
for a URL as an argument's value, strip off the prior part of the URL
and any args afterward and convert ISO entities to regular chars and
then take you directly to the target site). That eliminate tracking so
Google and others had to get smarter.

Mozilla is doing the same. If you right-click on the "Support site"
link in the add-ons page, Firefox shows you the simple <A> tag's href
value (where the anchor points). So it looks like a simple hyperlink
rather than a tracking URL. Yet when you click on that link, you do not
got directly to the target site.

Both Google and Mozilla are being somewhat nice in providing an <A> tag
to show you where they will redirect you. Firefox and other web
browsers will show the href value when you hover over the link as though
that is where the link will take you, but you've already seen that is
NOT where you get taken. That's why I don't trust the on-hover infobar
for where it says is the destination of a link when hovering over it
since the site can fake out the web browser as to where the link really
goes.

I'm not sure what any web browser will show in their target URL infobar
when Javascript is used. The URL is not built (does not yet exist)
until you click on the link. Another obfuscation is to reference a
server-side ID to go to the target site: the server dynamically builds a
table of IDs that the page script uses to ID a link to the server which
knows the actual target returned to the script in the page to then go to
the target.

> Sometimes I can view page source and find something helpful.

I often right-click on a link to Inspect Element. In this case, you
will see Firefox highlight the <A> tag with the href value that Firefox
will show in its URL infobar - but that's not where you go when you
click on that link! I don't know if a parent script uses the unique ID
in the <DIV> in which that link is encompassed or some other trick. If
I disable Javascript when at that add-ons page, and scroll down to find
the "Support site" link, it still works but with the redirection. So
Javascript isn't needed here but Mozilla is still getting tricky in
showing you one URL when you hover the mouse over the link versus to
where the link actually goes.

Despite Firefox, Chrome, or IE (or any web browser) showing you the href
value in an <A> tag, that is not necessary where you are taken when
clicking on a hyperlink. That is, the href value shown in the web
browser when hovering over a hyperlink may not be its actual
destination. At the add-ons page and its "Support Site" link, hover
over it. Where did it point?

getsatisfaction.com/betterbrowser/products/betterbrowser_firefox_redirect_remover

Firefox didn't show the URL protocol specifier of http. When you click
on it, where were you actually taken? When clicked, you went to:

http://outgoing.mozilla.org/v1/807c0735a823579bb2737c4200ad1dd05a389bdd6c443959e628cbdad72b1e60/http%3A//getsatisfaction.com/betterbrowser/products/betterbrowser_firefox_redirect_remover

Well, that's not what Firefox told you was the link's destination, was
it?

I've yet to see just exactly what criteria Firefox uses to determine
there will be a redirection at a level that triggers that criteria.
Even a hyperlink on a page that takes you to a different domain is a
redirection but you intended to trigger that redirection without
interference by the web browser. I know Firefox will trigger on an
auto-refresh that points to a different domain. I'd have to test if you
could detect the simple case of the target attribute in an <A> tag
pointing at a different domain. It managed to detect the redirection
that Mozilla uses which does not involve Javascript but must see
something in HTML, like maybe the unique IDs in the <DIV> tag
encompassing the <A> tag. Mozilla probably doesn't want to divulge
their criteria that will trigger their redirect infobar although it is
open source for any programmer to delve into (which is why some sites
have figured out how to get around Mozilla's criteria so Firefox won't
sometime trigger on a redirect).

The fact that search results at Google and Bing open in a new tab/window
rather than in the same tab for an <A> tag with no target specified
indicates they are doing something tricky with their URLs. Without a
target attribute, clicking on a hyperlink should open the new doc inside
the same tab/window as where you clicked the link. However, search hits
at Bing and Google will open in a new tab/window when you click on them.

http://www.w3schools.com/tags/att_a_target.asp

_self (same window) is the default target if the target attribute is
missing. Using Inspect Element on a search hit hyperlink shows a simple
<A> tag with no target attribute. Yet clicking on the link opens a new
tab or window. So much for web browsers using the href attribute to
indicate to where a hyperlink actually points.

> Sadly, I still exploit the HOSTS file but it's not perfect either.
> Some of the ads, and other requesters, need a response, but the
> timeout delay is not as bad as enduring the target execution.

Alas, I don't know of an add-on for any web browser that lets you
instantly disable the 'hosts' file (so you can past its blocking when
needed). You would have to use an external script, like a batch (.bat)
file, to rename the 'hosts' file to, say, 'hosts.OLD' so Windows
couldn't find it on the next DNS lookup (for hosts not still in its
positive hit local cache assuming you haven't disabled the local DNS
Client) and another batch file to rename 'hosts.OLD' back to 'hosts'
(unless you get tricky in the script to check the filename and toggle it
so a single batch file could be used to simply toggle the filename).
With ad-blockers, typically they give you a disable option to get them
completely out of the way when you want. No such feature for the
'hosts' file.