RFC: Updating and Claiming Ownership of Nodes initially created by Anonymous Monk

[Perlbotics]

This RFC shall address the following two issues

1. edit/update nodes owned by Anonymous Monk (AM)
2. claim ownership of nodes initially generated by Anonymous Monk

using a simple unlock-phrase based and time-bound mechanism.

Current Situation

After hitting the create button, a node owned by AM cannot be updated anymore. This is obvious since several AMs cannot be distinguished from each other (AM#1 could edit node of AM#2).
A node created by AM cannot be claimed (automatically) by a regular registered user, though this can be useful. E.g., when forgetting to log-in, being at $work, etc. (Update) ... or other situations, see e.g. Can I adopt a node?.

Basic Approach

The basic idea is to present an unlock-phrase that can be used for a given node to editing and/or to claim ownership of this node. The unlock-phrase is presented after hitting the create-button. An AM who intents to update the given node or who later wants to claim ownership has to remember this unlock-phrase. Maybe the unlock-phrase can be saved as a cookie?

Usecase: Updating a Node owned by AM

When logged in as AM, presenting the unlock-phrase allows to edit the node. A new unlock-phrase is created after the update button has been hit. The option to edit a node owned by AM is time-restricted (e.g. 5 days). After this time, no further update is possible. The time window restriction makes it easy to protect old nodes owned by AM. Furthermore, it might reduce the PM servers load. Updating a node must not reset the time-window.

Usecase: Claiming Ownership of a Node owned by AM

During a time window of e.g. 5 days, a regular PM user, who is logged-in, sees an option to adopt a node that is currently owned by AM. Maybe this option can be switched on/off by means of CSS and/or Display Settings? If the user enters the correct unlock-phrase, the ownership is transferred. Since the node is now owned by someone else than AM, the option to transfer ownership vanishes.

Reputation and XP

I am not sure about that. Maybe reputation is transferred completely but not XP. So, XP changes while the node is being owned by AM goes to AMs account, while XP-changes after claiming the node go to the users account.

Implementation Considerations

It should be possible to implement this RFC without introducing changes to the database layout. The unlock-phrase could be created by hashing (e.g. MD5) a secret initial vector + the node-content + the node-ID + some other unique node-specific value. Then the digest is transformed into some human-readable unlock-phrase. Something along the idea implemented by Digest::BubbleBabble.
Since the node creation time is a known DB entry, the time-window can be computed/checked easily.

Update: I assumed, that the DB has no spare field left to store the hashed key-phrase. If it actually has, wonderful. Just generate a random unlock-phrase and store it's salted hash (e.g. bcrypt) for later validation.
In case there is no spare field left, the method above should work. Validating the unlock-phrase means re-calculating it and comparing it with the one presented by the user.

Drawback of this method: If the node is edited by a janitor, the unlock-phrase will change, making it impossible to edit/claim that node later on.

From a security point of view, the secret initial vector is the weak point (security by obscurity). If this is a constant value (e.g. hard-coded), an attacker that gets into possession of this value could hijack/modify every AM post within the time window. That could be alleviated by using a secret vector that changes daily (lookup-table or computed = f(creation time)). Ideally this vector would be an individual salt, but storing that would require an extra DB field.
Further conceivable counter-measures (unfortunately all of the security by obscurity kind): hash several rounds; get a seed from some internal DB fields (of given node) not visible outside; use a modified version of Digest::BubbleBabble; use another Digest::xxx; etc.
The point is to make it practically infeasible for an attacker to hijack an AM node.
An online brute-force attack seems unlikely taking the natural deliberate responsiveness of PM into account ... but adding a sleep 5; to the validation process should do no harm. Sure, an attacker could create a node and then try to reverse-engineer the process to generate an unlock-phrase using computational power available locally. So the process of generating the unlock-phrase should not be too obvious.

Time window (response to #919042): 5 days was a first guess, but I consider 5hours too short. If I come back one day later and want to update a node, than I need a bigger time window than 5 hours. In principle, it would be possible to have two time-restrictions: maybe 24 hours to claim a node and 48 hours to update a node?

[AM initial node] ---------(time window expired)--> [AM locked node ]
   |           |
   |         (valid unlock phrase to update node)
   |           |
   |           v
   |   [AM updated node] --(time window expired)--> [AM locked node ]
   |      |   |      ^
   |      |   v      |
   |      | (valid unlock phrase to update node)
   |      |
(valid unlock phrase to claim ownership)
   |
   v
[USER claimed node] (behaves like any regular user node)

Acknowledgments

This RFC has been refined during a short CB-discussion involving the feedback of tye and mr_mischief.

[tinita]

So there are two use cases where a registered user would post as AM, you say:

E.g., when forgetting to log-in

Just as an example, in some other forums you can and have to enter a guest nick name. If you are a registered user and your session timed out and you start a reply, you will be noticed that you are guest and have to enter a guest nick name. So it's impossible to "forget" to log in.

Maybe something similar could be introduced here, an extra checkbox and/or a clear "warning" that you are about to post as AM. This can be implemented probably very easily.

being at $work, etc.

Why would one not want to log in when being at work?

It should be possible to implement this RFC without introducing changes to the database layout. The unlock-phrase could be created by hashing (e.g. MD5) a secret initial vector + the node-content + the node-ID + some other unique node-specific value.

The node content, ID and creation date are public (*). Where does the secret initial vector come from? There has to be something secret in the database which you can compare to the unlock phrase. I don't know the db schema, so I'm interested in how one could do that without changing the schema.

(*) Well, the rendered node content is public; I don't know if there is an url to view the raw source of a node. In other forums you usually can get the source by replying with quoting (which I consider very useful, but I'm getting off topic).
update: the xml view seems to display the raw node content. update 2: without the newlines, though

update 3: the only use case I could think of is posting from a public, untrusted computer with a keylogger, and that's certainly an interesting one.

[JavaFan]

Games to be played once we have something like this:
• Vote for your own nodes! Create a post as an AM, log in, vote for the node, then claim it.
• Claim someone elses node. Find a place with lots of Perlmonks, a YAPC for instance. Snoop the local WiFi network. Intercept an unlock phrase. Claim ownership.
• Post a (potential) controversional node as an AM. See whether it gets support. Claim the node if it does get support, and don't if it doesn't.
• Create a whole thread of AMs replying to each other. Later decide which nodes to claim.
And that's with just half a minute of thinking. I'm sure people can come up with better games to play.

[davido]

In addition to the aforementioned abuses:

• Whine to the gods that you forgot to write down the passphrase.
• Complain to the gods that someone else claimed your node.
• Never post as yourself. Post all nodes anonymously and claim the good ones.
• And we're to believe that all these people who fail to heed all the many warnings about following Writeup Formatting Tips are going to suddenly notice the passphrase and keep track of it?
• Cite new-found precedence in people claiming Anonymous nodes as reason for expecting to be granted ownership of Swimsuit issue, exactly 390 bytes, etc. Why should it matter these high-ranking nodes were posted years ago? People are able to claim nodes now, and... yada yada yada.

No, the precedence is that AM-posted nodes remain anonymous. Each person who posts anonymously and then accepts the fate that the node shall remain anonymous takes the role of the next Dutch boy to walk along and save Holland. As soon as we let that little leak flow, a little problem will turn into a big ordeal, in my opinion.

The gods have resisted the temptation to attribute any anonymous node to any author because to do so would open the floodgates. Perhaps not the floodgates of permissiveness, but certainly the floodgates of whining, complaints, and hard feelings. No single schoolboy's attendance record is important enough to let Holland flood.

Heck, we even have very well known, very well respected (within the Perl community) contributors who upon losing their passwords without having an email address on record ended up losing their account.

This is supposed to be fun. Getting all caught up in "I posted that, you should give me credit." is taking it all too seriously.

I don't mind seeing new ideas tossed about, but unless they're well thought out, as well as being supported with voluntary labor, they're probably not going to make it past PerlMonks Discussion. It never hurts to discuss an issue and possible solutions. Change here in the Monastery, slow as it may seem, is the result of ideas filtering through the furnace of thoughtful consideration. Some big idea may have some small component of it that catches on. NASA's contribution to the Space Age didn't put colonies of Utopian suburbia on the moon. But it did bring us microwave ovens and velcro. (figuratively even if not specifically)

[tinita]

Snoop the local WiFi network.

A bit offtopic: It would be really nice if perlmonks was available via https. On http://www.perl-community.de/ we have https access. It's just a self signed cert, which is not perfect, but it's at least good enough to log in quite safely when being at a YAPC, and I don't wanna miss it anymore.

[Eliya]

2. claim ownership of nodes initially generated by Anonymous Monk

Personally, I would be more interested in having an option to claim/prove that I'm not some Anonymous Monk :)

More than once, when replying to anonymous nodes, I've found myself in the situation that - due to the specific context - it somehow felt as if I had created the node myself anonymously — such as you could in theory do in an attempt to gain XP (by posing the questions yourself for which you have good answers...), or to frontpage your own topic (posted anonymously), etc.

Sometimes, I'v even just not responded to anonymous nodes for that very reason.

[Perlbotics]

Identicon could give a visual hint, but would waste more PM bandwidth. Maybe a textual representation of an Identicon (displayed by title when hovering over user name) would be an option?
This would also allow to distinguish different AM participating in a discussion (in a single thread, not forever - and as long as no cookies are involved, only while the AM's IP does not change when adding new replies).

Anyway, someone able to conceive such an XP whore-crime would also be able to use post via different IPs...

Update: Just for fun ... Monk-Titles derived from IP.

My current IP would tag the Anonymous Monk title with
Sister Nonia of admiarable Revision Control ;-)

Read more... (4 kB)

[Anonymous Monk]

That sounds interesting

I have poor imagination, and claiming ownership of a node seems to be mainly related to XP game :)

How hard is it to notice when you're not logged in?

Perhaps a better option would be, for the preview/create mechanism, to notice, when a logged-in user becomes logged out, and warn/prompt for login, instead of creating a post as AM

[iguanodon]

How hard is it to notice when you're not logged in?

Not too hard if you use custom CSS.

[Anonymous Monk]

How hard is it to notice when you're not logged in?

In my case, several recent nodes poste by me came up as Anonymous because I'm working on an emacs mode for perlmonks and it was not logging me in prior to posting until I fixed a bug.

[Anonymous Monk]

During a time window of e.g. 5 days

5 days sounds like too much time, even 5 hours sounds too long :/