This is a good point: reducing the impact of deleted accounts doesn’t do anything to address the root causes.
Thank you for your posts, which shed some light on the question of why a user might want to leave and choose to delete their IDs when they leave (as opposed to deleting IDs because iNat doesn’t offer any other options upon account deletion). Like many users, I’m an amateur, not a biologist in any capacity, so my experience of the site and its various frustrations is different in many respects from the experiences of those using it in a professional context.
I think it is important to try to figure out whether motivations for account deletion are mostly idiosyncratic and thus difficult to prevent, or whether there are recurring themes that can be traced back to structural or more systematic issues. I asked about whether staff solicit feedback upon account deletion, but actually this strikes me as rather too late – ideally what is needed is feedback from potential account deleters, before they have reached the point that they resolve to leave.
Indirectly I suppose some feedback already takes place, in the form of complaints and suggestions in the forum, for example, but only a small percentage of users post in the forum and these discussions don’t necessarily distinguish between the minor annoyances that we gripe about before getting back to our usual activities, and the major problems that substantially interfere with our ability to use the site effectively (i.e., “deal-breakers” that lead to account deletion). So this leaves me with the question: how do we figure out what these deep-seated concerns are and how can users be made to feel that their concerns are being heard and taken seriously? (Or from the standpoint of an ordinary user: how do we convey to staff that these concerns, rather than others, urgently need to be addressed.)
To say “where no white man has been before” is offensive when used in this context. The writer is clearly making a point that only white people can make progress in the endeavor of documenting biodiversity. Can a person native to the area not also get an education in biology and make a contribution in that region? Why would one need to specify one aspect of their morphology in this context. It’s the context that makes all the difference in the world.
Certainly one of the things that GDPR applies to is personally identifiable information (or PII in the industry jargon). I think it would be foolish to assume that’s the full extent of the scope of the right to be forgotten under GDPR or similar laws in other jurisdictions (Argentina, CCPA, etc.) You seem to be saying that none of the quite generally constructed terms in the myriad global privacy laws would have any relevance to a user’s iNat observations or identifications; I don’t think you’d get much support for that view from privacy professionals or lawyers. Anonymization is certainly one tool that can be used to ensure data doesn’t come within the scope of privacy protections, but it’s not a panacea.
Beyond the strict legal requirement, you also seem to want to ignore the desire of the iNaturalist team to create a community where people with widely differing preferences for privacy can confidently share their nature observations and contribute identifications. You and I might both be happy for our anonymized observations and identifications to remain on the platform in the event that we depart, but given that other users have chosen to delete their data on leaving, we can assume that they are not.
The challenge is to strike a balance that fully protects a departing user’s privacy (and intellectual property, where that is relevant) and then maximizes the preservation of scientific value within that context. I think there’s a good case for replacing IDs of departed users with a comment such as this.
This observation was identified as Genus specio on 9 January 2023 by a user who has since deleted their account.
Anything beyond that raises problems because it allows the departed user to be tracked in some way, or because it inserts “ghost” IDs into the Community Taxon logic. Fortunately, this approach seems like something you support, too, so perhaps we can persuade iNat staff to consider it in time.
I do appreciate @sedgequeen’s willingness to volunteer time to manually preserve anonymized ID content, but I’m pretty sure that the “convert ID to comment” approach outlined above would actually require less iNat staff time than supporting volunteer involvement, be more robust, and align better with the platform’s privacy guarantees.
Some solution other than volunteer help would certainly have advantages! I’m all for finding such a solution. But I want it found soon.
I think that replacing an ID with a comment is a poor solution because the observation still reverts to “Needs ID.” To me, the point of a solution is to keep the observations in RG or headed that way, not have them slide back a step. If there’s a way to just change the name of the IDer to “deleted account” or something like that but keep it as an ID, I think that’s good.
Not really. I was trying to deal specifically with iNat’s claim that because GDPR exists it means they must offer data deletion. I am saying that it doesn’t, and that with some work it is possible to ‘separate’ the personal data from the obs and id data such that the obs and ids can remain and not fall foul of these personal data laws.
My previous definition of PII was simplistic - the uncertainty is in how exactly ‘PII’ is defined - it’s rarely just a simple list of data items such as name, address, etc - it’s any data item or set of data items that can lead you to identify a real person, which makes it a challenge. Therefore it’s an area where proper analysis is important and which differs from system to system. The hard work comes in paring back the data so there are no breadcrumbs back to the person, but it is eminently do-able.
Do you have examples of where other laws include more than PII? Argentina’s recent bill was for personal data. CCPA is for personal data.
That’s because they can smell an opportunity for consulting fees from 2 miles distance.
Do you know of any we could ask? My legal teams have always signed off on our approaches to privacy adherence. I hope they’re not wrong!
The desire is laudable but I don’t believe bulk deletion of data contributes to that goal given iNat’s own API already allows data to be exported unobfuscated wholesale. Offering to delete the data from iNat’s servers when it’s already been downloaded by every Tom, Dick and Harry via the API seems like a token gesture.
Anyways, this is my final word on it. The dead horse has been well and truly flogged.
I believe these groups do export data but the account deletions described in this post seem to have happened without warning. Thus maybe all the exporting hasn’t happened.
I live in South Africa (born here, my heart is in Africa) I ID Unknowns across the Rest of Africa. That ‘no white man’ appals me.
No women scientists in his corner of the world either?
I think we’re getting at the same thing here. Even if a “data controller” scrubs all records of names, email addresses, etc. proper implementation of a right to be forgotten really requires that extra work to ensure there are no breadcrumbs.
It seems also that we agree that replacing each ID from the departed user with a comment noting the previous existence of such an ID would accomplish what we’re looking for in terms of preserving scientific value.
The need for iNat to delete data from its own servers when it likely has been downloaded and shared in other places is really tied to iNat’s being responsible for its own systems and not responsible for others’ use of that data. You make a case that iNat’s legal deletion responsibility may be more limited than reflected in current policy, and something like an anonymized identification could legally be retained. That’s probably also technically true for observations that have free licenses, so long as they are anonymized. I just can’t see iNat going there as it unnecessarily sets up the platform for conflict with departing users and might jeopardize trust more generally.
Anyhow, I imagine any change in this respect will need to wait until the problem becomes larger than the less controversial challenges of scaling performance, refactoring mobile apps, etc. Happy spider identification!
By the way, I personally don’t particularly want to be involved with stripping everything except ID’s out of accounts being deleted. However, we often hear variations of “Wish we could do that, but we don’t have the needed staffing.” I think, though, that we have nearly all the pieces we need to do this now. I’d like to see it done soon. Staffing needn’t be the a roadblock. (And I feel like saying “You should do this” without saying, “I would help!” is wrong. Inconsiderate.)
Having volunteers do the work is a kind of half-assed solution, true. It needn’t be more of a violation of privacy than having paid staff members do the work, though, if a few volunteers are chosen for the work, people who can be recommended by people who know the volunteer in real life.
I consider that replacing identifications of deleted users with comments fails to accomplish my goal – keeping the ID’s so observations are still RG or whatever status they have reached. The comment method would be a kind of quarter-assed, solution, one might say. However, it would be better than the current system, or non-system, so I would support that change, unhappily.
Should this become a reality, please don’t spend your time manually browsing the identifications of a former user and posting comments containing the former identifications. Both can be automated by software.
For whatever you would do repetitively, ask if a software could do it for you, and spare your time.
1) For grabbing all the identifications made for others by an identifier :
3) Both operations can be done using a single software, in a single run.
The only inputs would be the username of the former identifier and a token to push the comments on behalf of the volunteer.
Press ENTER and that’s it!
@sedgequeen I love your approach to say “I would help!” rather than just complaining. And I’m tempted by your vision of keeping IDs intact but with anonymized identifier names. But, whether implemented in code or via volunteers, it has two problems.
First, we already know with the problem where the >2/3 agreement principle means that to get an accurate ID for an observation requires support from three or five knowledgeable people because of conflicting IDs from one or two users who haven’t logged in for years. We’re going to experience that same problem with departed identifiers. Anonymized IDs for departed users are never going to be changed, and I suspect we’ll be a lot less keen on this approach after we create a permanent anonymous record of the first few departed-and-unreliable users.
Second, imagine that I want to leave iNat and delete my data because I’m afraid that someone is using my activity to stalk me. Maybe I already moved to a new location to try to avoid this person. I choose Delete My Account and my profile and observations are deleted, but the 200 IDs I made are all changed to Self-deleted-user2003-1-25-003. 150 are for observations around my old home address; 50 are for observations around my new address. Now I’m not really as anonymous as I hoped. That’s hypothetical and a bit contrived, but I think this type of scenario is why iNat cannot just substitute a single anonymized ID for the departed user’s ID. Using a unique ID for each observation would address this (but we would still have problem #1).
Hopefully, the number of prolific identifiers who choose to leave and delete their IDs will stay pretty low. And maybe we can find other ways to pitch in to help keep this a great community!
My conclusion is that the full-earase option will continue to exist, but at least one other option should be added, and hopefully some people will choose the new option(s)
Just a quick note that anonymization and pseudonymization have specific, distinct meanings and it woud be useful to distinguish them in the discussion. I’m not a lawyer, but in brief:
In data management contexts, anonymization refers to removing all directly and indirectly personally identifiable information in such a way that it is impossible to reconnect the data with a specific individual (for iNat, this would be equivalent to attributing any content from any deleted account to “deleted user”.)
Pseudonymization, by contrast, means that personally identifiable information is removed but the data is still associated with a specific individual, designated via a pseudonym (for iNat, this would be equivalent to assigning each deleted account a randomly generated identifier – e.g. deleteduser3cQ10). If there are privacy concerns connected with account deletion, this might not be felt to be sufficient. Many people are already using a pseudonym of sorts in the form of their username.
(There are some additional complexities connected with observations and other activities like projects, but I am focusing on IDs here.)
From what I understand of databases, the technical implementation of either is not the main hurdle. It can be automated relatively easily (this sort of task is what computers were designed to do) – no need for volunteers to de-personalize data.
But anonymization has certain additional tricky aspects that need to be considered. For example:
Should IDs by deleted accounts continue to count towards the community ID or not?
What happens if such a user later decides to return to iNat?
Part of the meaning of an ID comes from not just the label itself, but the assessment of who suggested it and why; this is no longer possible with anonymized IDs.
Apart from this, one specific problem that comes to mind is connected with the inability to re-associate data with a returning user if it has been anonymized on the backend (i.e., if iNat has removed any connections between the user and the data, rather than merely no longer displaying this connection). If previous IDs count as active and are no longer connected with a user, what prevents a person from re-IDing observations using a new account – thus inadvertantly or intentionally providing two IDs for the same observation?
Withdraw the ID from a departed user. Still visible to identifiers for the logic flow. NOT counting in the 2/3 argument. Not needing extra IDs to tip the balance.
Make it a Withdrawn ID with no identifier and no date, with an i to click for - from a departed identifier.
We keep the information, and the privacy.
Identifiers get a few more lurking in Needs ID, but the relevant taxon is visible to consider (and hopefully a quick and simple click to agree)
