How to handle Redirects?

[sidki3003]

Right now interception of redirects is active in the config's Standard Mode and above. That is, redirects are turned into an option, by adding a "Redirect" (or similar) link to the page bottom.

"False redirect" killers are filters that kick in for image responses that turn out to be a CSS/JS/HTML document, which may or may not get parsed by the browser. Or for stylesheets/scripts that turn out to be something else, nonetheless always get parsed by the browser, taking CPU cycles, flooding the error console (if present).

Now and then i hear someone saying s/he isn't happy with that behavior. I have no idea what the majority of users prefers. So here is the chance to have your say.

Bypass keywords: "a_redir_f" for killing false redirects, "a_redir" for interception.

Affected filters:
"a_redir_f":
Header: 'Location: 2 Kill false Image/Favicon Redirects'
Header: 'Location: 3 Kill false CSS/JS Redirects'

"a_redir":
Header: 'Refresh: 1 To Link'
Web: 'JS "location.replace" to Link'
Web: '<script>: JS "location" to Link'
Web: '<meta> Block: Refresh to Link'

[ProxRocks]

how would you define a "false redirect" versus an "interception" ?

[sidki3003]

Sorry ProxRocks, i was still editing that post to get the explanation right, have a look again.

[ProxRocks]

hmm... tough call...
i mean, me personally, i don't want anything "redirecting" behing my back, but i acknowledge my paranoia level is higher than most (ie, you all know my take on disabling .js by default)...


but to answer the poll as more of an "objective populous", so to speak, let me ask this, would you classify a "false redirect" as a 'flag on the play', an attempt by script-kiddies to sneak in a .js by "falsely" calling it an 'image' or a .css instead... ie, the surfer has their browser (or Proxo) set to disable .js but allow .css and by using the "false redirect", did the script-kiddy web-designer find a way for our browser to "execute" a .js file that otherwise should not have been "executed" ???

edit: or is this a browser-specific question?

[lnminente]

I think killing these interceptions could break some pages, and going to the Config_Control.txt the definition of the level one says "Suited for new users", and the level two says "filters that are likely to confuse new users - e.g. require any sort of interaction - get bypassed."
I will not vote in the poll for respecting people wich use your config, but from here i would say "No, keep it as is."

[sidki3003]

Thanks for the input lnminente.


ProxRocks:
Almost all false redirects are "404 error" HTML documents.

As far as i can say, content-type exploiting attempts are negligible for favicon requests (i've only seen one), minimal for JS/CSS (except for CSS webbugs), above 0.1% (that's a lot!) for image requests.

The other "right to exist" of these filters is to save CPU (i.e. parsing) time.

[lnminente]

In that case i would say "Yes, for false redirect killers."

[sidki3003]

I suppose i still didn't get the wording right. Sorry again.

Right now, both, "killing" and "intercepting" is active for the out-of-box (i.e. "Standard") mode. My question is about removing either "killing" or "intercepting", or both, from the default mode, keeping it active only for advanced users (those who activate "Advanced Mode").

[ProxRocks]

okay, i believe i'm on the same page now...

to clarify my vote, i'm voting that "click on the redirect link within the footer be an advanced-mode only thing and that the lower, less intrusive modes redirect without any intervention required by the novice config user opting for those modes for more simplicity and therefore less intrusive surfing" BUT that those lower modes BLOCK the false redirects...

[lnminente]

No, sorry me, it was my bad english understanding too. I think you understood me, anyway i wanted to say if false redirects are 404 errors and favicons requests i would block them most of the time

[ProxRocks]

may i suggest altering the poll choices slightly?


"yes, limit listed filters to Advanced and above"
"yes, limit intercepting, but do not limit false redirects"
"yes, limit false redirects, but do not limit intercepting"
"do not limit, keep as is, Standard and above"
"i have no preference"

[sidki3003]

Thanks! So both of you have the same opinion.

ProxRocks, exactly, changed accordingly.

[eclipse]

I agree with ProxRocks and Inminente too.
I think it's better to leave the "legit" redirects alone in standard mode, but block the false ones.