Re: Viewing anyone's options w/o a password
On Wed, 23 Jun, Rob Francis wrote:
It seems kind of odd to me that if I know someone's email address on a list that I can go to the Info page and enter their email address, and then w/o a password see what options they have set. Granted, I can't change the options, but why even let someone get to see the options a person has selected?
Just wondering if this was a decision made on purpose, or perhaps an oversight.
I'd actually say it's somewhere in between.
Originally all the settings pages - admin and admindb, as well as the user options pages - were like the user options pages, not hidden behind a password. The others were moved behind the cookie wall, and i expect it would have been easy enough to hide the user options page, too, except that then you'd prevent users missing their password from getting at the "send me my password" option! Kinda defeats the purpose. The proper answer would be to make the user options page two tier, with the "send me my password" button in front of the cookie password, and the rest behind. Evidentally this extra elaboration was high enough effort to exceed the attention threshold available for the cookie-protection switchover, and nobody's revisited it since. And in truth, most of the telling information about the options is revealed on the roster page - the membership on the list, whether or not they're digest subscribers, and whether or not their delivery is disabled.
There are many such rough edges - some for simple expediency, and some that would require more infrastructure to be properly addressed. (An example of the latter is holding messages for approval directly in the config.db - we should have at least a basic catalog mechanism in which the mailing lists can store and retrieve such messages. This would take yet more overhead effort than the simple accommodation we could make for cookies around the user options page...)
Ken Manheimer klm@digicool.com
There are many such rough edges - some for simple expediency, and some that would require more infrastructure to be properly addressed. (An example of the latter is holding messages for approval directly in the config.db - we should have at least a basic catalog mechanism in which the mailing lists can store and retrieve such messages. This would take yet more overhead effort than the simple accommodation we could make for cookies around the user options page...)
I kind of figured that was the case. Thanks for the very informative reply. I figured I'd at least get a vote in for moving all option type stuff behind a password.
Seems to make sense to me, but hindsight, as they say, is 20/20.
Thanks again,
-rob
participants (2)
-
Ken Manheimer
-
Rob Francis