in reply to On Chatterbox Echoes, and the Identification of Monks in the Wild

I like your first idea, however, I'm not sure sure about your second, for I see it as potentially risky for those monks who wish to protect their privacy.

While you cite a couple of potentially valid reasons for wanting to "automatically maintain the identities of the Monks," I know of at least a few monks that do not want their "real life" identity connected with their Monk tag. Each case you cite suggests some form of active participation on the part of the Monk you wish to confirm. That's fine and there are several mechanisms available for doing that.

However, if I'm reading your subtext properly, you want to ID Monks without their knowledge and that raises several concerns.

There is a great deal of information already available about our real lives on the Internet. Given that google logs the ChatterBox, there's a risk (however small) that the results of your automated process would eventually appear on standard search engines. As an example, note the first hit on my 'nym. While my actor's instincts are gratified by the top billing, my wife would be less than pleased if there were a connection from that to my RN. (She's been stalked and is very sensitive to public information of her name, address, or other vitals being readily available.)

Similarly, a certain monk maintains an gender-opposite online identity for reasons that have not been made public. There's a risk (however small) that an automated process would compromise this without that individual's knowledge.

I can think of (or know) several other reasons why certain monks have not publicized their real lives in various online communities.

You might believe that this information is useful in the right hands. That's true and it's also why I argue against this so strenuously. Automated processes do not question the validity of a request for information. Only people can determine whether those hands are the right ones or not.

If, for whatever reason, a monk has declined to provide details of their RL, then we should respect that choice.

If you absolutely must have some form of automated identification, I would only support it if a) there was a way to opt-out and b) that was the default. It's not that I don't trust you, per se, but I don't trust every member of our community. Some have demonstrated that they have little professional (or personal) courtesy and I would be extremely leery of any process that did not allow me to prevent those people from accessing more details of my life than I wish to publicize on my home node.

Should I wish, at some point, to provide services to PM, then I will happily submit to whatever verification that vroom deems appropriate. I might even be willing to provide that to people he trusts. However, I will not support any process that unfettered access to my RN, my personal email address, or other details I've chosen to keep private.

Sorry...

--f

Replies are listed 'Best First'.
Re: Please don't compromise my privacy
by Petruchio (Vicar) on Mar 06, 2001 at 00:43 UTC
    However, if I'm reading your subtext properly, you want to ID Monks without their knowledge and that raises several concerns.

    Happily, this is the only point I need to respond to. This is not at all what I mean. I would not support, much less suggest, anything which would compromise the privacy of people here... especially mine. ;-)

    What I mean is simply this: if each Monk had the option to specify a second, secret password, he could use that password to verify his identity outside the site, without giving up his primary password. That is all. There is no connection with anyone's real identity.

    So, for instance, I set up another website, Perlmonks' Bar & Grille. You wish to get in. You supply your normal username, footpad, and your secondary password. My login CGI sends the pair to a CGI on Perlmonks, recieves a "YES" back, and lets you in. Without your needing to divulge your real password, and compromise your PerlMonks account,

    It seems that the word "automatic" (and probably some unclarity on my part) gave you a different impression. I meant it in reference to the way authentication is implemented. By having set your secondary password, you now automatically have access to my web site. This scheme has various strengths and shortcomings (as do other schemes) but it is totally voluntary, and not at all injurious to personal privacy.

    Sorry if I mislead you.

[reply]
      This seems pretty limited to me. Once a monk has given you their ID and 2nd password, you could effectively imitate them anywhere outside the Monastery. This means that monks would have to be very careful with this second password, making it little more useful than the first for ID purposes.

      How about this: A person claims to be Petruchio, and wants an account on my site as such. I simply use the Monastery to /msg a monk of that name with a default password for his/her/its account on my site et voilą. No extra work for anyone, and the ID verification is as good as your primary password here. Even if someone who isn't a monk wanted to do verifications (seems unlikely ;-) they'd merely join the Monastery and they'd have the same ability. This also provides an automatic mechanism for a monk to know that someone is trying to impersonate them elsewhere ("/msg Albannach what the heck is this password for?").

      --
      I'd like to be able to assign to an luser

[reply]
        You're quite right, it is limited. On the other hand, it allows the user, and only the user, to change his password at any time also, so stealing the password will be of very limited value as well. And it seems a trivial limitation when real passwords could be harvested so easily around here.

        Your suggestion would also work, and is a bit more efficient than what tilly had suggested. Since under my scheme the user could be assigned, or forced to adopt, a new, local password upon first authentication, the only real difference is the level of automation.

        Also, with your scheme, there is extra work for someone... the person who must automate the /msg. If this seems trivial, then consider also the difficulty of adding a single textbox to a form, a single field to a database table, and what must be close to the simplest of all CGI programs.

        But yes, what I have suggested is quite limited, and what you have suggested is a very comparable scheme. Perhaps more interesting would be to consider the real objectives. A great scheme, as I think of it, would:

        1. Automatically allow access to a second site for anyone with a PerlMonks account, while maintaining the user's identity
        2. Allow this access in a way that was as transparent as possible to the user (ideally requiring no work on the user's part)
        3. Not give the proprietors of one external service any ability to masquerade as the user at another external service, and
        4. Be easily implemented, whether by vroom or someone else (more important if it's vroom).

        My suggestion achieves 1, 2 and 4, with the ability to change passwords limiting the problem of failing to achieve 3.Yours achieves 1, 3 and 4, and while it's less efficient on 2, it's not that bad on that account. I wonder whether we can come up with something which achieves all 4.

[reply]

In Section Perl Monks Discussion