RFC: Add profile field "emergency contact" or such like as

[jdporter]

It has happened from time to time that some monks have expressed concern over the unexpected and prolonged absense of another monk. In at least one case, a monk contacted the gods to see if a reachout could be done. Unfortunately, we had to say no, because the contact information stored in the user profile consists only of an email address, and our policies explicitly state this this email address "is used only to send you your password". I believe that this creates — correctly — a strong expectation of privacy around this personal information.

Therefore, I would like to propose the addition of an "emergency contact" field, which would probably normally be an email address, but with a different expectation as to its potential usage. The use of this field would be strictly optional. That is, as a user, you wouldn't have to put anything in it unless you want to.

Alternatively, we could add a checkbox which, when checked, indicates that you are OK with site administrators using the existing email for "emergency contact" purposes, in addition to its current purposes (i.e. password recovery).

Any thoughts?

"such like as" is my homage to blazar.

[LanX]

> "is used only to send you your password"

I understand this as a guaranty, that it's not used for spamming. (See also update (3) )

And I don't expect many would object about an extra mail every x years.

Additionally I seem to remember - maybe incorrectly - that these emails were used for sending warnings after PM was hacked.(?)

My suggestion

Just amend the policy with a phrase° that the email can be used for exceptional personal emergency contacts by the admins, but never for any kind of advertising.

Reasoning:

• no code required
• any technical solution will need an explanation anyway
• any technical solution will only effect new-commers
• it's a social, not a technical problem
• techs tend to try to solve social problems with technical approaches
• emergency contacts are affected by the same rot like normal contacts (5)

Concerning monks who haven't seen the policy change, because they were away in the meantime:

• "It's easier to ask forgiveness than it is to get permission"

just do it till someone objects, and if this really happens, add him/her to a manual exception list (which will be very short)

Updates

°) I leave the wording to native speakers and victims experts of US I-will-sue-you culture*. ;)

*) LOL , that's an epic boomerang 😂

3) from Create A New User

Please note:

We are not going to send you junk email "member updates", sell your address to spammers, or display your email address for people to see. This email exists so that you can receive your password, and/or retrieve it if you forget. There may be future email functionality, which you will have the option to turn on from your user settings page.

4) your mother is doing fine ;)

5) but are rarely updated. I personally know a case of an emergency last will written in WW2, leaving everything to a long forgotten former wife not seen for 40 years.

[jdporter]

I seem to remember - maybe incorrectly - that these emails were used for sending warnings after PM was hacked

Your memory is good! Status of Recent User Information Leak

[cavac]

To me, it makes sense to have an "emergency contact" field (only visible to site admins) that a user can fill in. I don't think the field should have special semantics ("email address"), some people like me don't read their emails on a perfectly regular basis.

In this day and age, an emergency contact might also be a phone number or even, say, a link to their social media site that permits private messaging. I mean, after all, if the person you are trying to contact would look into their email accounts, there's already a good chance that they would have seen emails sent to whatever address they used on PAUSE or similar.

Plus, an "emergency contact" sort of implies that this could be an emergency that needs to be dealt with as-soon-as-possible. In my mind at least, that could include things like "PM has a very big security problem, it's all hands on deck for gods, site admins and pmdevs". I'm not sure Email has the right reaction time for this sort of thing.

As for dealing with long absence (possible illness or death) of a monk, at least for me it's more likely that some family member or friend would take over my phone to deal with things than it would be for them to find a way to access my email accounts (which run on my own server, shielded by strong passwords). On the other hand, cell phone providers usually have procedures available to take over a dead relatives phone number (call forwarding, etc).

[jdporter]

I don't think the field should have special semantics ("email address") ...

I quite agree. The instructions for the field would be very open-ended. It could even include brief instructions, multiple avenues to try, etc.

"emergency contact" sort of implies that this could be an emergency that needs to be dealt with as-soon-as-possible

I've been putting "emergency contact" in quotes because I don't actually envision an actual emergency use case, like "this monk is going into anaphylactic shock". What this data element shares with an actual emergency contact is that it could be someone other than yourself we should contact, in the event that you seem to have fallen off the face of the earth.

"PM has a very big security problem, it's all hands on deck for gods, site admins and pmdevs"

Well, the gods would be leading that, and they already have each other's contact info outside of PerlMonks.

As for dealing with long absence . . .

Obviously, we can't assume that your next of kin will log into your PerlMonks account and let us know what's happened.

[bliako]

Obviously, we can't assume that your next of kin will log into your PerlMonks account and let us know what's happened.

Perhaps the next-of-kin can even volunteer to take absent Monk's place and continue the divine work? Jokingly...

[kcott]

G'day jdporter,

I'm against this idea.

There are plenty of entities (work, doctor, etc.) that hold "next of kin" (or equivalent "emergency contact") information. I do not see this as a role for PM or any other internet forum (or similar group).

[hippo]

Then don't fill in the field (or check the checkbox). If it's optional, as proposed, where's the harm?

[kcott]

++ Thanks for your reply.

If there's no field/checkbox/whatever then there's no issue at all.

I often encourage people to register on the basis that it's very simple and asks for minimal information. In my opinion, this just muddies the waters by (optionally) requesting information that PM shouldn't hold in the first place.

My opinion could be swayed if presented with a scenario where this information would be essential. From the OP (my emphasis):

"I has happened from time to time that some monks have expressed concern over the unexpected and prolonged absense of another monk. In at least one case, a monk contacted the gods to see if a reachout could be done."

I don't consider that to be sufficient reason to implement this change.

I'm more than happy to discuss this further. :-)

[Polyglot]

...our policies explicitly state this this email address "is used only to send you your password".

This policy needs to change posthaste--yesterday, if not sooner!

I would rather know that my password is not stored anywhere in plain text, and that it could only be reset, not resent!

I do NOT want my password sent to me...ever! Whomever has set the system up this way should be rather ashamed. This is exactly why a few years ago the site had a major issue with a hacking event that compromised everyone's passwords. It sounds, by this "policy" talk, as if no lesson was learned at all!

I'm a simple monk, with inferior coding skills by comparison with most here--yet even I do not store anyone's password in plain text on my servers. Tools like crypt are super easy to use, and waaaaaay more secure than plain text!

[jdporter]

Whomever has set the system up this way should be rather ashamed.

That would be vroom. Or possibly even CmdrTaco.

The problem is, it is not easy to change. It is very far from trivial to change. Everything about this system is hard to change. But we've had this conversation many, many times already. No point in going around it yet again.

[Polyglot]

Perhaps I'm oblivious to what has gone round the rugged rock so many times as you say, but usually the hardest things to change are those that buck the social current or that simply have to pass a large committee. If so many of us (virtually unanimous I would hope) agree that this change would be a positive thing, why then is it difficult? If the platform is at all based on Perl, it should be cinch, right?

I don't mean to cause everyone to rehash old stuff, but if there's a link to catch me up to speed on the past conversation, I'd take a look at it.

[Anonymous Monk]

Don't feed the trolls!