This is not a matter about questions that I have for myself about what I understand or what I should do.

Perhaps I have been not direct enough in offering advice to the DNN Team. So my final remarks on this matter will be explicit advice to the DNN Team, and I will not respond further to any additional replies that continue to miss the point.

The DNN Team should understand that there are reasonably knowledgeable and experienced people out here, such as myself, who are not part of the DNN Team yet who nevertheless are capable of providing constructive feedback to the DNN Team.

Here I have attempted to remind the DNN Team of the following:

Keep your recommendations consistent with the public recommendations of Microsoft concerning important security matters.

If and when you deviate from the security recommendation publicized by Microsoft, explain in advance the reasons for the discrepancy.

Given the well known history of quality assurance problems with many DNN upgrade problems during the last calendar year 2010, when discrepancies arise between Microsoft announcements and DNN implementations, it only adds to the poor image of quality assurance. If you wish to improve the image of quality assurance for DNN, then make sure either that there are no discrepancies or else explain in advance the reasons for any discrepancies you choose to implement.

---

CT

In this follow up blog Scott GU make it clear that "remote only" is fine.
Then there is no discrepancy in this matter.
http://weblogs.asp.net/scottgu/archiv...

From the blog
"

# re: Frequently Asked Questions about the ASP.NET Security Vulnerability

@Jon,

>>>>>>>> Would using customErrors="RemoteOnly" instead of customErrors="On" work as well (to allow developers to more easily reproduce and diagnose errors when logged onto the same machine?  Or does customErrors explicitly have to be "On"?

Yes - you can use either RemoteOnly or On - both work fine.

Thanks,

Scott