Added support for deleted users

[appurist]

Does not remove accounts, just remaps profile lookups if the customType is set to DELETED. Blocks logins by these deleted users, eliminates them from search, remaps their UUIDs on prims. Allows login of the substitute profile user account.

For GDPR support, this allows the right to be forgotten, even if viewers cache the UUID to name relationship, since this substitutes the deleted user's UUID with a dummy one for a substitute user account. It does not remove content tagged with the old user's UUID, however it remaps those IDs on region loading to refer to the substitute deleted account.

[mdickson]

https://gdpr.report/news/2017/09/28/data-masking-anonymization-pseudonymization/ https://en.wikipedia.org/wiki/Pseudonymization

[appurist]

@mdickson I'm not sure what point you're trying to make with those links. Are you suggesting that we don't need to support user account deletes at all? I'm aware of the pseudonymization and tokenization aspects of the GDPR and that helps with most of the data we maintain. Unfortunately it cannot be assumed that the user is using a pseudonym, and email addresses often reveal the RL identity.

This PR is the result of a discussion with Elenia where we came up with an approach to hide user accounts by substituting deleted ones with the identity of another account, without removing all traces of the old accounts (e.g. inventory), because other users may be using them (e.g. purchased or received inventory items from the deleted account). It is only the Halcyon half of the changes; the web interface to the db will obviously also need to support deletes and filtering on login, etc.

I'm aware of the pseudonymization and tokenization aspects of the GDPR. The UUIDs of users are good enough for pseudonymization but installed viewers keep a mapping of those UUIDs to names, so the simply removing the user definition will have almost no effect for anyone with a history of interaction with the deleted account. UUID substitution came up in the discussion with Elenia and does seem to resolve that nicely.

This PR may not go far enough with UUID substitution but I haven't been able to reproduce any cases where a viewer shows the old name, so I'll add to this with more remapping if we do encounter any such cases.

[mdickson]

Just providing some reference material on how the GDPR defines handling leaving data in place while "forgetting" a user. If the goal is to not delete the profile then this would be an acceptable alternative within the GDPR framwork.

YMMV

[appurist]

Ah yes, good. Yeah I think for the most part all of the data is either pseudonymized or tokenized, with the two possible exceptions of name (visible to others, and usually but not always already a pseudonym) and email address (not visible to other users). If a grid is getting an account delete request where GDPR actually applies, it is likely due to the user wanting non-editable fields on the profile to be forgotten. This is likely the avatar name. If we prevent anyone from seeing the profile at all, there are other places the name can still show up, such as user inventory properties, rezzed object properties etc.

In order to avoid breaking in-world content associated historically with the deleted user, we don't actually want to delete all traces of the user, thus the substitution approach. A grid can define a placeholder user account to replace "deleted" users and show where the deleted one would, thus eliminating the places where the profile of the deleted user would be referenced, or viewer name caches might present the deleted name.

Applying the substitution at the storage access level keeps the number of changes very small (i.e. we don't need to do a substitution everywhere a user's UUID is referenced). This is especially true given that deleted users will be blocked from logging in, further reducing the scope necessary to pull this off significantly.

This PR does not address inventory properties (both user inventory and task/prim inventory) but in my testing the substitution seemed to be applied universally. If I discover it isn't, I'll take care of that case as well with a further commit, now that the pattern has been applied in other code.

[appurist]

BTW, I'm trying to get the InWorldz beta grid updated with these changes for further real-world testing, but having build problems that prevent that. May be related to having only VS2015 on that machine, or there may be a build problem in the PR (even though AppVeyor had no trouble building it). I'm investigating.

[appurist]

I've fixed a copy/paste error in the code as well as one place where I was using VS2017-specific syntax ("=>" arrow syntax) which was the only thing preventing a build under VS2015 (on the IW build machine).

[appurist]

It's now running on the beta grid, there's a user "Jim Griefer" who has been marked with customType DELETED, he should not be searchable or show up in things. Instead, I've created "Mystery User" and all Jim Griefer references should get remapped to that account (on profile fetches, not Search).

However, I've created two large box prims on the "InWorldz Beta 8" region border with IB7, and they show with Jim Griefer remapped to Mystery User, but the Contents items show Jim Griefer's name, as I expected but could not reproduce in local testing. So I think I'd still need another update for User inventory / Task inventory items the way I did it for the prims. Other than that, it seems to be working. Jim Griefer cannot log in, Mystery User can (along with the other non-deleted accounts).

Not sure when I can get that followup commit posted, it may take a couple of days as I have other work to complete.

[appurist]

I'm going to close this PR until such time as it is complete and ready. It isn't yet.