Continuing the discussion from View true locations on maps for observations with trusted hidden coordinates
Here is a link to a tool I vibe-coded, allowing you to view the true locations for up to 10,000 observations at a time (yours or from observers who trust you):
https://jwidness.github.io/iNat_obscured_observation_viewer.html
If you have comments, please post them here rather than on the feature request.
Jane, this looks like it could be useful, and thanks for your efforts in making it available. I bring this up rather reluctantly, but I’m always wary of granting full account authorization to third-party apps. While I trust your intentions, I don’t know your programming and software auditing skills, and am concerned when you say “vibe-coded.” Even though i trust that you do not intentionally have anything but “GET” API calls, granting such authorization could conceivably, however unlikely, lead to completely wiping out a user’s iNaturalist account, and I couldn’t bring myself to try it. As it’s on github, I could do my own audit to make sure its safe, but I’m not sure I trust my own skills that much, either.
This really goes to a larger issue: The iNaturalist community is built largely on trust, and iNaturalist itself has lots of methods for supporting this trust (mostly via flags and curators for cases where that trust is violated either through bad intent or honest mistakes). However, for third-party software add-ons, how do we know what’s reliable and trustworthy? For simple query-based add-ons that provide alternative displays for public data, there are not big issues. But when we’re dealing with add-ons that require private (authorized) access, there can be severe consequences to programming errors (or even potentially malicious code). How do we decide what’s safe?
I said “vibe-coded” only to mean that I didn’t code it from scratch, not to mean that I let an AI run completely unsupervised. In fact I was very particular in the prompts I gave, and I paid very close attention to the output. The authorization flow is essentially the same as what pisum uses for https://jumear.github.io/stirfry/iNat_observations_updates, so if one is comfortable using that tool, this is no riskier.
If you want, you can see iNat’s recommendation for PCKE flow and compare that to what I’m using. And if you wanted to look at the code, you would also find one POST during the authorization process, and otherwise only GET calls.
I probably should have said something more neutral, like “I wrote this tool with AI assistance”.
I would also add that if you’re not comfortable running code written with AI assistance, then you should not use the iNat app, which has Copilot code in it.
Edit to add: and if people would like to continue a general conversation about either AI assisted code or third-party security, please do that in a linked topic.
for what it’s worth, just based on my cursory glance jwidness’s code as it currently exists, i don’t see anything that seems to pose an active security threat to your account. that’s not to say that there aren’t things that could make the code better and that’s not to say that the situation couldn’t change later to create a threat, but i guess it’s always going to be up to your own judgment at the end of the day whether the risk of using something outweighs the benefits.
for what it’s worth, an open-source page like this, since it allows folks to evaluate the code, should theoretically be less risky in the long run than something that is proprietary, or even something open-source where the deployment chain is less transparent.
and i have no reason to suspect that jwidness would intentionally deploy something malicious (i gave her contribute privileges to my own repo, after all), nor to suspect that the authors / deliverers of other code that jwidenss relies on would intentionally deploy anything malicious either.
A post was split to a new topic: AI assisted code and security issues
I’ve wanted this feature for like a decade, so thanks Jane for creating an easier workaround than the current options.
2 posts were split to a new topic: Feedback on moving a post to a new topic
Yes, I had assumed that’s what you meant. As I said, I was raising the issues reluctantly, because I would in general trust your skill levels. I have no problem with well-managed use of AI for coding, but it does require careful auditing of the output, and I don’t know you well enough to know that you are skilled at that. I have 50+ years of coding experience, but wouldn’t trust myself to thoroughly understand several hundred lines of AI-generated javascript (a language that I personally hate as poorly structured and difficult to read [says someone who’s first professional job was progamming in FORTRAN IV 
]).
Yes, but if iNat screws up the code, they have the ability (and responsibility) to restore any lost data.
Agree wholeheartedly!
I hope nothing I said could be construed to imply that anything malicious was going on here. I trust both you (@pisum) and @jwidness to write good, reliable code to support iNat users. But, because of the risk of unintended errors, I won’t use your code with with full account authorization. For situations where that’s needed, I write my own - then I have only myself to blame if something bad happens. For those who don’t have that ability, I think they need to consider the risks before agreeing to grant authorization, and I’m glad that the iNat authorization pop-up gives fair warning of the possible consequences.
After my own review of Jane’s code, I agree with your assessment. All of the PKCE authentication flow code is within the first 85 lines of the script, is straightforward to read and understand* and does not pose any threat to users.
* Admittedly requiring a bit of extra effort for a competent programmer not well-versed in Javascript to look up a few things - not a huge hurdle these days, given all of the good documentation we have at our fingertips online?
that’s fair. i generally don’t use browser extensions because of how much power they can potentially have. everyone has their own tolerance for risk.
folks who want to could adapt either my own or jwidness’s code as local html files that they can run without having to go through the PKCE flow that the pages use.
even then, you’d still need to check to makes sure there’s nothing else in the code that would open it up for attacks. for example, since observations can include user-generated content, you would want to make sure that the code you’re running either sanitizes the user-generated content or otherwise handles it in a way that can’t pose a threat to you.
and you’d also need to check any other code that your code calls, along with its delivery pipeline. (jwidness’s code uses some other code for the mapping framework, for example.)
and finally, you’d need to check to make sure the code itself isn’t making any dangerous calls.
my human eyes didn’t see any of those sorts of problems, or at least no combination of issues that poses a current threat.
This is an interesting and valuable conversation, and I think, while some of it focuses specifically on the app’s code here, the general aspects would be very helpful in the more general thread on
AI assisted code and security issues
that was split off from this one.
Hopefully, the rest of this thread can focus on feedback on the viewer app itself and how users use it rather than a general approach to code security and use of external apps/extensions.
This is awesome! Thanks for taking the time to do this, just tried it out and it’s a really helpfull tool. Kudos!