dreamwidth
add child safety restriction: no PMs between over-18 and under-18 accounts
It's becoming more common for social media sites with a PM/DM function to prevent people whose accounts are flagged as being under 18 from being contacted privately by people whose accounts have a birthdate making them over 18 or people whose accounts don't have a birthdate specified, for child safety purposes. This restriction does have some serious downsides, because there can be some legitimate reasons for that kind of contact (ie, queer/trans teenager living with unsympathetic/unsafe parents who can't have conversations publicly because that unsafe parent monitors their public posts/comments), but the legitimate reasons are outnumbered by the ways it can lead to bad things (and even the legitimate reasons can wind up in the bad place really easily: vulnerable teens can be taken advantage of really easily).
I've been taking a good hard look at our child safety features lately (because we've been taking such a stand in legal cases) and I think it's time to add this one.
- Someone whose init_bdate makes them over 18 should not be able to private message someone whose init_bdate makes them under 18. (Treat it exactly like PMs are off: grey out the link, and don't provide any clues that it's an age-related restriction, to avoid leaking information about age.)
- Someone whose init_bdate makes them over 18 should not be able to private message someone whose init_bdate makes them under 18. (Again, treat it exactly like PMs are off: grey out the link, and don't provide any clues that it's an age-related restriction, to avoid leaking information about age.)
- Two people whose init_bdate make them both under 18 should still be able to PM each other.
- If someone whose init_bdate used to make them under 18 turns 18, they should not be able to continue replying to any outstanding PM conversation. Ditto someone over 18 who had an outstanding PM conversation with someone under 18 prior to this feature going into place. Error message should be something non-leaky, along the lines of "Error: You cannot currently private message this account."
- This should only run on init_bdate: the birthdate provided on the profile should have nothing to do with it.
- This should not affect things like granting access, subscribing, or commenting to someone, just private messaging.
- There's probably something else I'm forgetting to add here.
Oh, I instantly remembered what I forgot: there are still a few accounts floating around from the days of pre-closed-beta that have an init_bdate of 0000-00-00. Because there definitely weren't any three-year-olds creating accounts in pre-closed-beta in 2008/2009 -- it was all folks who were working on the code -- just put in an exception for the purpose of this check that any account with an 0000-00-00 init_bdate should be considered over 18 (and thus not able to DM accounts with an init_bdate under 18).
Should someone over 18 be allowed to see (in their inbox) messages to and from someone under 18 exchanged before this change was pushed? Delete them? Should someone under 18 be allowed to see (in their inbox) messages to and from someone over 18 exchanged before this change was pushed? Delete them? (There may be reasons for the answers to these 2 questions and the 2 above to differ, eg for law enforcement purposes.) Should someone who turns 18 then be allowed to message someone already over 18? Since the init_bdate is only precise to the day and doesn't include a timezone, should 2 people born on the same date (whether in the same timezone or not) both treated the same on the day they turn 18, even though there may be almost 50 hours between their births, without it being possible to say who is older, or should that be disallowed to be on the safe side?
Should someone over 18 be allowed to see (in their inbox) messages to and from someone under 18 exchanged before this change was pushed? Delete them?
Leave already extant messages in the inbox, but make them unreplyable until both parties are over 18.
Should someone under 18 be allowed to see (in their inbox) messages to and from someone over 18 exchanged before this change was pushed? Delete them?
Yes, same as previous: leave already extant messages in the inbox, just make them unreplyable until both parties are over 18.
Should someone who turns 18 then be allowed to message someone already over 18?
Yes, once the init_bdate makes you over 18, you should be able to interact with people who are already over 18 -- this shouldn't be a permanent "you made your account while you were under 18, so your account will forever be limited", just a way of keeping people currently over 18 from private messaging people currently under 18 and vice versa.
Since the init_bdate is only precise to the day and doesn't include a timezone, should 2 people born on the same date (whether in the same timezone or not) both treated the same on the day they turn 18, even though there may be almost 50 hours between their births, without it being possible to say who is older, or should that be disallowed to be on the safe side?
We don't need to get that fine-grained about it -- a day or two on either side isn't an issue. (This isn't for compliance with a specific law yet -- all the ones that would introduce this as a legal requirement have been stayed on constitutional grounds -- just a way of bringing some of our features more up to parity with the current zeitgeist.) "is today equal to or greater than the init_bdate + 18 years by server time" is close enough for a check.
https://github.com/dreamwidth/dreamwidth/blob/main/cgi-bin/LJ/User/Message.pm#L300 (can_receive_message) https://github.com/dreamwidth/dreamwidth/blob/main/cgi-bin/LJ/User/Age.pm#L164 (init_age)
Also noting that the adult interstitial uses best_guess_age (init_age with fallback on age) instead, but the spec above precludes doing that.
We should be able to use that, just add the check for the few accounts that somehow managed to not get an init_bdate set. (Or I suppose I could get somebody to check on how many accounts were affected and contact them to set one if it's not that many.)
nod I think I'm going to write tests for can_receive_message as a first step. (Do you want that in a separate PR?)