RFE: Forbid redirect from trusted sites, too

[Tom T.]

http://forums.informaction.com/viewtopi ... 752#p11752

Noticed that yahoo.com was not whitelisted, only mail.yahoo.com, https://login.yahoo.com, https://edit.yahoo.com (for preferences/password changes? I think) and akamai.net. This had always been enough before, and prevents annoyances when redirected to yahoo home page after logging out of mail.

I suggest that Advanced > Trusted include the option to forbid META redirection at trusted sites as well. The above quote was in regard to a problem at Yahoo Mail, but it got me thinking: Why do I have to be taken to Yahoo's home page when I'm through with their mail? (*They* want me there, of course.)

FWIW, after logging out of Mail, a page will flash for a split-second, blank except "If you are seeing this page, your browser settings prevent you from being redirected to a new page. Click here to continue." After a split-second, it continues to Yahoo home. Actually, that blank page would suit me fine as a logout page. Then I could go wherever I wanted without having to be taken to Yahoo home.

Note that since the required scripting from mail.yahoo.com is allowed, the site mail.yahoo is regarded by NS as Trusted. May we have the option to prevent these redirects as well? Thanks.

[therube]

Note that NoScript does not block all META redirects - only those inside <NOSCRIPT> elements.
Also note that some sites will code for both circumstances - when JavaScript is enabled, & when it is not.

So would it help in this situation? Thinking not. Cause if you disable yahoo.com ...


Now (if I recall correctly) FF itself (but maybe not in 2.0) does have a more generalized redirect catcher (though it is not effectual in SeaMonkey 2 ) that may already do what you are looking for.

(FF) Bug 83265 - UAAG: Add a way to disable HTTP-EQUIV=refresh (block automatic meta redirection, lock on current page)

(SeaMonkey) Bug 465303 - UAAG: Add a way to disable HTTP-EQUIV=refresh (block automatic meta redirection, lock on current page)


That said, I am not against the RFE.

[Tom T.]

So would it help in this situation? Thinking not. Cause if you disable yahoo.com ...

Would you mind finishing that sentence, please? (It's already disabled.)

Now (if I recall correctly) FF itself (but maybe not in 2.0) does have a more generalized redirect catcher (though it is not effectual in SeaMonkey 2 ) that may already do what you are looking for.

(FF) Bug 83265 - UAAG: Add a way to disable HTTP-EQUIV=refresh (block automatic meta redirection, lock on current page)

Without looking at the link, the name of the link scares me. I don't want to "lock on the current page". When I log out, I'd like to be taken to a logout page, as my banks do. The blank page that's mentioned in the OP would suit me fine as a logout page.

Or am I misreading this, and I need to go and look at the link? Guess I'd better. Thanks.

Edit: Looked at the link. That's a humumgous bunch of code that presumably was added, date being 2007, so it should be in F2. Is there an about:config pref for this?

[therube]

Hmmm. What happened? Thought I updated the post with just that information.

Oh well, here again:

Code: Select all

In Firefox 3.0.x and above: Tools -> Options -> Advanced -> General -> "Warn me
when web sites try to redirect or reload the page"

(It's probably sitting in a wrong post somewhere. Anyhow, looks like FF2 is out.)

Anyhow, I found the earlier thread related to this topic, Meta refresh.

[Tom T.]

Hmmm. What happened? Thought I updated the post with just that information.

Oh well, here again:

Code: Select all

In Firefox 3.0.x and above: Tools -> Options -> Advanced -> General -> "Warn me
when web sites try to redirect or reload the page"

(It's probably sitting in a wrong post somewhere. Anyhow, looks like FF2 is out.)

Anyhow, I found the earlier thread related to this topic, Meta refresh.

Correct, no such option in F2 UI.
However, the link to the meta thread was very useful. Giorgio said you could block them with ABE if you knew the destination in advance. Since I do (yahoo.com), I asked him for that rule to add to ABE.

Still would like the feature in general, but that would solve the immediate annoyance. Thanks much.

[Tom T.]

Code: Select all

In Firefox 3.0.x and above: Tools -> Options -> Advanced -> General -> "Warn me
when web sites try to redirect or reload the page"

Hmmm, not what I expected.... I set 3.5.3 as above. It said it prevented a reload of the Yahoo mail log in page, and also prevented this forum from taking me to the Board Index automatically after logging in. But still got sent to Yahoo home page after logging out of Mail. Any ideas?

Edit: Plus, after submitting this post, it wouldn't show me the submitted post unless I clicked "Allow". Might be more of a nuisance overall than the benefit of avoiding the Yahoo annoyance, if it did, which it doesn't.

[Giorgio Maone]

https://addons.mozilla.org/en-US/firefox/addon/992

[Tom T.]

https://addons.mozilla.org/en-US/firefox/addon/992

Thanks, will have a look.

Note: This extension does not block JavaScript-based and HTTP-based redirects. If you know a way how to do this, please let me know.

Perhaps you should let Herr Fuchslocher know that you do indeed know of a way to prevent Javascript-based redirects?

[GµårÐïåñ]

This is currently not in the NS model other than to block what is in the <NOSCRIPT> tag but it can be added I suppose. It is just that the feature in 3.x (I know doesn't help you) and the countless addons for this purpose sort of make it moot. I suppose under GPL/OS, Giorgio can just grab the code, give some credit or modify it enough not to and include it but that would increase the overhead on the addon without the added benefit given its practically obsolete to need to do that. I am on the fence on this, I am sorry. If the feature is included, I will dump my other tools, disable the built-in function and use it and be happy but I am not in a rush to see Giorgio pile this on top of more pressing features, I am sorry.

@Giorgio, you think you can make this happen without too much infrastructure change or overflow? Maybe put it on the to-do for when you are in a mood to punch out a feature in an hour? It won't really hurt us right?

[Tom T.]

The RefreshBlocker extension as recommended by Giorgio seems to be designed to do this and more, and is only 37 k.

However, although it worked at first, at the moment it is *not* blocking the redirects from mail.yahoo to yahoo. Will have to play around with it a bit more.
It appears to fill the purpose (if I get it working right; a "compatibility update" was just applied), and if so, then I imagine that there would be less need for this RFE.

What seemed inconsistent to me was that while mail.yahoo.com was a trusted site, yahoo.com was untrusted. So, allowing a trusted site to land you on an untrusted site, by default and with no configurability, seemed inconsistent.

[GµårÐïåñ]

That tool has come a long way. At first it was simply a straight blocker until Fx team just jacked it and put it as a permanent feature of 3.x at which time the developer didn't just abandon it, he updated it to include a few more useful options that did not come with the hijack. It is a finicky tool and I am sorry to say it takes some tweaking and getting use to before it functions exactly as you need it. Don't give up but remember depending on the model used for the redirect, it might not catch it based on the infrastructure.

[Tom T.]

What seemed inconsistent to me [[ABOUT NOSCRIPT]] was that while mail.yahoo.com was a trusted site, yahoo.com was untrusted. So, allowing a trusted site to land you on an untrusted site, by default and with no configurability, seemed inconsistent.

Still seems like an issue.

[GµårÐïåñ]

Yeah, its a scratcher.

[Tom T.]

For the record, Fx 3.5.3's native refresh blocker isn't blocking this redirect, either. And right now, I can't get Refresh Blocker to stop it, either, even though it did the first time I installed it.

[GµårÐïåñ]

See, for client side refresh, you can use the built in meta, or you can use js. With js, since you have site allowed, it will go through and nothing you can do and nothing will catch this type of refresh to the best of my knowledge because it is since an http/https request which is obviously allowed (as if you typed the address or clicked on a link) and not as a meta refresh so it wouldn't be intercepted by anyone. With js disabled, the system sniffer will have the page default to the meta (its what I would do, cover my bases) and in that case both Fx built-in and Refresh Blocker should be able to catch it, no problems, hands down. Now the only other thing I can think of, is to write up a quick js and run it using GreaseMonkey to parse the code and remove refresh or redirect references; however the downside to that is that it may not be able to properly distinguish between a real refresh or a valid link or http request. There seems to be no full proof method short of finding which js module on their site controls this and explicitly block its path or if they are blending it with their code, find out what the syntax is and use a GM script to strip it. To make matters worst, if they are using server side refresh, there is absolutely not a single hell of a thing we can do on the user side to stop that unless you can find a way to inject a script into the data being processed which is nearly impossible short of a memory location hack.