To prevent misunderstandings, I've written the original post in Japanese.
If you feel some questions, translate/read the original.

First, I write the dead line I cannot compromise.
The privacy of XOOPS_TRUST_PATH is notr a target to effeort but a spec

Certainly, some hosting services disallow directory outside of DocumentRoot.(A)
And some hosting services ignores .htaccess just under XOOPS_TRUST_PATH.(B)

But, you have to understand this thesis must be false.
"Existence of servers with (A) AND (B) makes a WebApplications which need private area vulnerable".

If it is true, almost all WebApplications might be vulnerable.
eg) Cake, Ethna and almost all frame works need private folders.


And you should learn the news entry itself is logicaly wrong.
Because, it is far from a problem of Protector but a problem with missing cares about XOOPS_TRUST_PATH.

If you have to alert, the target must be installer or documents.


And the patch for Protector you made looks stupid.
Why do you insert "SANITIZE"?

Though this stupid code using heavy preg_replace() is out of debate of course, the code like
cannot be granted for me.

Because inserting such a code will be a falseness for skilled developpers can understand the necessity of private area and agree with XOOPS_TRUST_PATH.

If Protector is corrupted by such codes, the other D3 modules should be corrupted also.
And inside XOOPS_TRUST_PATH, there are a lot of libraries, caches, uploaded files, logs, and sessions. All of them are out of assuiming direct accesses then they should be placed private area.
Do you have any ideas for (A) AND (B) servers?
I can even proof XOOPS cannot be secure with "(A) AND (B) server".


And I don't know servers with (A) AND (B) at all.
If it exists really, all developpers just say "cancel the server right now".


I've just released Protector-3.22 with a checker XOOPS_TRUST_PATH is private or public.
And I rejected mamba's wonderful patches.

This is my final answer.