Most maverick IDs of auto-obscured taxa should not change observation geoprivacy

Observation A:
ID1: SpeciesA, a species set to auto-obscure/private (maverick)
ID2: SpeciesB
ID3: SpeciesB
ID4: SpeciesB

Observation A is now automatically obscured or made private due to ID1. Examples:

Observation B:
On the other hand, a situation like Observation B should probably trigger obscuration:
ID1: SpeciesB
ID2: SpeciesB
ID3: SpeciesB
ID4: SpeciesA, a species that is set to auto-obscure (maverick)

Thoughts on this?

2 Likes

How do you stop someone from intentionally adding an incorrect ID to see the actual location ? If it changes, it should only be after it gets to Research Grade (ie more than 1 correcting ID has been entered)

1 Like

Doy. I did specify maverick, which would require multiple accounts by a bad actor(s) to overtake the community ID.

I guess it’s just a shame that these data are permanently obscured/private, especially if/when obscuration by day is implemented, since it would cascade to affecting other observations.

You just have to be careful there is no way for people to intentionally game the system to unobscure something. The odd obscured record of a common species may be worth accepting to prevent that.

2 Likes

the important thing is to stop observation by day from being implemented, or it’s kinda game over for iNat as a grassroots monitoring platform.

also… RAVENS are obscured somewhere? really>???

Yeah, or maybe some way for case by case assessment.

Some kind of an automated comment dumped onto the record telling the user that the obscuring can be turned off is a viable solution. It puts the control into the user and hopefully prevents any kind of intentional bad acting.

i think it could be OK in some settings, the most at risk species, and observations within the same obscuration block as that one only. As a blanket policy especially in Canada now it will literally break most small location bioblitzes and place lists, destroy the range maps, and lots more because so much data is driven by ‘power users’ who hit some random obscured thing during a given day.

I don’t get why they don’t just obscure date though. I know they need to mess with the links too but that seems a tiny price to pay considering the alternative.

I guess i should save most my my appeal for the dark day when/if it actually happens though.

2 Likes

I was responding to Chris.

sorry, i’m getting kinda mixed up here. i don’t pay much attention to the replied to on here becuase people seem to always hit it on accident. but, sorry if i derailed!

Definitely a tough situation you’ve outlined, because I generally do want to err on the side of caution.

I wonder if this is a case where curator intervention should be required to exempt from auto-obscure. Create a handy curator button to list observations whose auto-obscuration hinges on a maverick ID. (Or maybe we can already work URL magic to do that…)

One curator can flag for “exempt from auto-obscure”, and a second curator can agree or not. Would require a new (hidden) observation attribute to maintain.

We would also have to consider how subsequent ID activity would or would not reset the exemption.

Maybe I’m overthinking this here, but otherwise seems like a tough nut to crack.

1 Like

A and B should behave the same in terms of auto-obscuration. It shouldn’t matter whether the maverick auto-obscuring ID came at the beginning, the end, or the middle of a chain of other IDs. that said, i tend to agree with erring on the side of caution:

i think it might be nice to have pop up a little note to a person who makes an ID that triggers auto-obscuration that that ID will trigger auto-obscuration, just so they understand the consequences of their actions.

To achieve what end goal ? There is nothing they can do about it, they can’t turn it off.

i think just to let the system be the first thing that lets people – especially new people – know the observation is now auto-obscured. if then others then determine the maverick ID is bad and should be removed to de-obscure the observation, and if they ask the maverick to remove the ID for that reason, it won’t be the first time the maverick has heard about the consequences of the ID.

the problem is a lot of people just leave the site, and then there’s no way to remove it. I guess the observer could delete and re create the observation or copy it and delete the old one but that’s a pain

If auto-obscuration is determined by IUCN Red List threat status, then this will be a major pain in our part of the world where many of our data are threatened species. This will be extremely frustrating dealing with popups for simple identifications.

fair enough. what about the threatened status showing up on individual identifications, not just at the observation level?

3 Likes

in general if any repeated popups are put on the site, it needs to be possible to turn them off, once per account, and never see them again. Otherwise it will drive away more of the already too low number of people helping with species ID

1 Like

You might be on to something there. A visual cue without otherwise interrupting the ID workflow. I could get on board with that. There could be a place to hover for an explanation, for those not already familiar with what it means.

3 Likes

[off-topic] IUCN red list in Least Concern category: https://www.iucnredlist.org/species/22706068/113271893