Good idea, but unfortunately I don’t see the option to change the title anywhere. I also can’t edit the original post. I probably lack the privileges.
I have unmarked the solution.
I have never used iNat without Tor, actually. The only problem I used to encounter was blocking of specific exit nodes by iNat itself, but switching the circuit small number of times always fixed that. Getting blocked by AWS – especially this often – is entirely new.
It’s not clear to me that this definitely is a bug - it sounds like this may be an intentionally chosen setting to cut down on abuse. I agree that the title of the Bug Report isn’t very descriptive and some of what is written, such as:
seems to be incorrect as that was marked as solved by the poster (who is free to do that) and there’s no indication that that bug had anything to do with the Tor browser (user noted that they are using Firefox).
Assuming it is a bug, I would suggest making a new Bug Report that condenses what is known about this issue into a single, coherent post along with any potentially useful speculation about fixes and links to potential solutions. Spending a lot of time addressing a fix for a browser used infrequently by iNat users (I can’t find any other Bug Reports for it on the forum) is probably not a great use of staff time, so making it as easy as possible for them to efficiently understand this would give the highest chance of it being addressed.
What kind of abuse? Requesting images? What a time to be alive where privacy-protecting software is considered abuse while AI scrapers are somehow legitimate.
The issue seemed identical when I created the post, which is why I wrote what I did. I would edit both if I could. Alas, it seems I don’t have the permissions to do that.
I can do that, sure. I assumed having yet another thread about this would not be welcome.
current Tor browser is built on top of firefox just like Microsoft edge builds on top of chromium, but this issue is related to Tor only.
well it depends on how one views it. obviously there is no contractual obligation on service guarantee but there is serious caveat here. A blanket abuse detection ended up preventing genuine logged in normal user from interacting with iNat service altogether (note its not just about browsing but uploading media to AWS that inat uses too to this user - aka preventing making CC observations too) and that looks as a bug or atleast highly anti-feature even though the original intention is genuine.
As an original intention of such intentional setting should not be like “lets block all abuse IPs no matter”, that is also absurd assumption as large set of modern Internet users in today’s world relies on IPs that are dynamic by ISPs, aka I have no control on what IP I am gonna get tomorrow, and it can just as well happen such random IP I get can probably be flagged by some abuse system historically.
The correct logic that is missing and which is why I call it gray area between bug-or-featurerequest is “ofc lets block abuse IPs but allow whitelist access to service for genuine logged-in users with credibility and no abuse” aka rely on user credibility first instead of unreliable and disconnected random IP historical credibility that is no where proof that this particular logged in user has abused service.
ofc this is all under assumption that TOR access failed from pure IP flagging.
maybe after u create a new thread with clear details and headline now, staff can probably split replies from this thread and merge to that new thread there and close this. so no issues.
You are of course right in theory, but even iNat blocks purely based on IP address. I had always assumed it is this way because the point of the block is to protect the backend from excessive load and doing it as you suggest would require access to the backend to validate that it’s an existing user. Thus it would still expose the site to potential DDoS. Sending a 403 Forbidden if IP matches some predefined list is obviously much quicker than querying the database for each request.
With all that said, this justification no longer holds because iNat recently started using Cloudflare as its DDoS protection. Despite this, some Tor exit nodes are still IP banned even when I have passed Cloudflare’s (invasive) bot challenge before using a different exit node.
Sorry for the delay, life got in the way. I’ve tested it again now and the amount of Tor blocking by AWS has dropped to ~50% of exits, which is quite workable and obviously massive improvement over the original ~95%. Therefore I am marking this as solved for now. If the issue returns close to its original magnitude I will start a new thread as suggested. It’s still broken.
@cthawley @einsum I started a new thread summarizing this one at https://forum.inaturalist.org/t/website-unusable-on-tor-due-to-aws/80037.
Marking this Bug Report as solved since another has been created for the same issue.