Not necessarily "evil," but potentially fragile.
You say "...He considered it a quick hack, and it worked perfectly for quite some time." Presumably, it worked until something about the environment changed - maybe an upgrade to a newer version of vBulletin? I was trying to say that, in a situation like this, I would want a solution that was robust enough to be well-integrated and reusable, not something that the author considered "a quick hack."
My intent was (is) to provide a helpful response to your post. No "puffing" was intended. I am not concerned with being laughed at, nor envious of your understanding of computer science or the human mind, nor particularly interested in how bored you are. Since you asked the question, I assumed you wanted an answer. I gave the answer I considered most appropriate and useful: not functional code that does what you describe, but an assessment of the underlying concept.
If you are interested in considering constructive input, please allow me to start again.
I think that you may have overlooked, or misunderstood, this concern with your approach.
From your first post:
I wish the user to be prompted to verify that they are willingly sending an insecure message.
your most recent post:
The idea is for the web server to examine the text, locate the desired ---BEGIN PGP MESSAGE--- then allow the transaction.
Your posts seem to indicate that you want the user to be aware of the risk before it's too late (which would make sense).
At the same time, you don't seem to recognize (or acknowledge) that, if PHP does the warning, then it's already too late.
The transaction has already been allowed to begin, and the security of the message has already been left to chance at least once. Asking the user to "verify" a choice implies that it's not too late to reconsider - and therefore, that the user is still "safe," which is not true at all. This is the "false" sense of security I was concerned about.
I understand that in the particular situation, security is not a critical issue. But what happens when someone does need to send a secure message? You've trained them to click "Send Message" first, and then think about security.
This is the outcome I had in mind when I said you'd be better off doing "nothing at all": at least the user might stop and think that, since they're doing something they don't normally do, they might need to take a different approach. Instead, they may recall that their "normal" approach already accounts for security (but in actuality, only appears to).
You say, "real security exists much more in our behavior than in our technology." I completely agree. Therefore, ineffective (because it's too late for correction) or superficial (because you don't actually check that the message is encoded) behaviors are not desirable.
