historically, issues like this invariably can be traced to something on the user side. sometimes your ISP blocks or throttles particular origins, sometimes an ad blocker blocks stuff, etc.
it’s only interesting if those two users are using different setups. if you compare setups, then whatever is similar between the two could be sources of the issue. for example, if you both are using Tor, then probably there’s an issue related to that. if you’re saying that none of the exit nodes you tried work and you don’t think there’s anything else going on in the rest of the network, then maybe iNat has chosen to block them all, in which case that’s probably a choice, not a bug.
iNat does block some exit nodes regularly. When that happens, the entire site gives me 403 Forbidden. Switching Tor circuit until I find a node that hasn’t been blocked then resolves the issue.
In this case it’s different: the entire site works fine, while Amazon-hosted storage works nowhere. If it is indeed intentional, it seems unlikely the decision was made by iNat staff. In any case, blocking Tor users is discriminatory.
Yes, this is an AWS issue, I’ve said that already.
If slow typing speed is indeed related to the speed of my internet connection, that merely points to the forum having horrible design. No sane website would require communicating with the server in real time merely to type words into an input box. I wouldn’t be surprised, though – the sloppiness of some web developers nowadays is just awful.
inat uses Discourse for forums and continuous “draft saving” is a standard feature everywhere where discourse forums are used.
ironically, such draft saving is exactly an important usecase for other set of users facing such unreliable issues beyond network issues u had, be it tab crash/browser crash/multi device usage/… no one wants to be forced to retype 1000 words reply.
ideally I think this drafts should not hamper my typing speed in browser but if you really are facing such issue - scrapping forum draft functionality is as easy as blocking requests to https://forum.inaturalist.org/drafts.json that can be easily done in any modern browsers. As you are using Tor already so I am sure you can figure that out.
and yes, on your main issue of images is related to AWS issue and it happens occasionally to everyone on site (it did to me few days back). we can all discuss that we can switch from AWS cloud provider or tighten to better contracts for extreme reliable performance for 100% uptime but note that iNat relies on AWS grant for those CC licensed media, so unless we find a generous donor who can match the grant at scale with better reliability i guess retrying to browse inat few hours later when hit with photos lag isnt that big of deal for everyone ;)
Unfortunately, blocking https://forum.inaturalist.org/drafts.json makes the editor warn “drafts offline” but does not fix the typing speed. I suspect it’s not caused by draft saving but rather by some huge JavaScript having to process the input before it makes its way into the input box – the webpage loads some 6.7 MB of scripts. In general I have nothing against draft saving, it can indeed be useful, however such functionality should always work in the background and not affect how responsive the input box is.
Regarding AWS, I absolutely understand the high value of free resources for low- and non-profit projects such as iNat. However, I must disagree with “retrying […] few hours later” because this issue has persisted for three days now and it prevents me from uploading new observations or identifying existing ones. So yes, it is kind of a big deal for me, especially if it should persist for longer.
you really should contact the Tor folks to look at the issue. as noted before, historically these sorts of issues originate on the user end. so if you’re using Tor as your provider, you really should ask them about the issue first.
Sorry, but it sounds like you have no idea how either Tor or HTTP work. If anything, this is a problem on the AWS side – their servers are returning the error, not anything in the Tor network.
you’re saying the problem is on the AWS side, but AWS just does what iNat configures it to do for them, right? if iNat folks have configured things in a way that is unfriendly to Tor, maybe it’s a mistake, but maybe it’s intentional. for example, we know that iNat has implemented a bot check for a lot of traffic to their site recently. if the issues you’re noting are recent, maybe that’s an extension of that sort of work on the AWS side, too.
fundamentally, the error you’re seeing indicates that you’re just hitting the wrong AWS location. normally AWS should direct you to the proper location, but for whatever reason that’s not happening. i guess you could wait for iNat to look at the issue and maybe they will or maybe they won’t do something about it. but you should also be able to do things on your side that should allow you to get routed to the right place. to me, it seems like it’s easier to pull the levers that you can directly influence, but i guess you can do what you want to do.
oh I just re-checked it via TOR and I can replicate your bug (my earlier reply was assuming this as temporary media issues with AWS servers that happens occasionally) and it seems indeed the bug is from AWS connection to TOR exit node flagging, and I tried few other Tor circuits and some worked fine with your above URL failure.
So, the best guess as pisum said above is your Tor circuit exit IPs are flagged by AWS already maybe for anti-scraping things or such abuses historically on that IP (probably such flagging ends up as generic failure of no-such-bucket errors instead of explicitly saying flaggged by some system) and I am not sure whether AWS implements such single metric on IP level for all AWS resources abuse.
i dont think AWS s3 buckets as is allows any fine grained control for whitelisting anything since there is no design in first place that passes logged-in user data to AWS, the alternative is iNat hosts another edge node resources and then serves the AWS or any other resources via this node that acts as mediator from logged-in user credentials or such to not flag such direct requests but that comes with cost of first designing that system and paying bills for that new edge nodes.
Until then there is nothing that can be done by anyone here except finding a better non-flagged exit node for your TOR connections or host your own private exit nodes by renting servers elsewhere via non-so-trackable methods or use services other than TOR with on-par abilities.
As example, to strongly consider it is Tor exit IP flagging by AWS, here is one successful TOR circuit that is not flagged by AWS when my exit node is something in some European country:
Thank you for the thoughtful response. You are right, there are indeed some exit nodes which work, but they seem like a small minority. I had to reload the circuit 28 times to find one that works, no joke.
i don’t think that’s a generic error exactly. i believe what’s technically happening is that AWS fails to tell the user how to redirect to the proper region. so the error does accurately describe the situation. the user is connecting to the wrong location and not finding the S3 bucket in that region. whether the lack of redirect is a mistake (in configuration) or whether it’s intentional (due to blocking, etc.) is an open question.
that’s one approach. Snowflake and other similar things are intended to provide reliable non-problematic exit nodes, i believe (so that you don’t have to randomly search). or, theoretically, i think if you exit near the AWS region where the S3 bucket is, you should increase your chances of getting routed correctly, i believe, even if blacklisted. and there are other approaches. as i mentioned before, asking Tor support will probably yield these and other suggestions.
Even though “NoSuchBucket” is meant to handle your explanation, there are cases where AWS utilizes the same error template for completely different phenomenon too (which is possible with IAM policy aka probably on IP abuses here) -
not really, snowflake is entry node not exit node in TOR aka it is only meant to circumvent TOR blocking at ISP levels or such.
that is not possible, note the routing is handled by internet BGP/IP and not a specific TOR exit IP node region, you are probably thinking as “let us pick TOR exit node in US and this will reduce these errors as iNat s3 bucket is in us-east” when it is in fact not. The internet routing protocols handles such region routing and should correctly as I am passing same direct media URL and even exact US east url as above. FWIW, the exit node with US region failed in same way on such TOR circuits.
are these failures recent to you on TOR? aka you were using TOR for more time and these higher failures suddenly increased to you in recent days when you posted on forum or you were just trying TOR+iNat as recently itself?
@waaaaah@cthawley probably the title has to be changed to better reflect this thread as its unique among similar image issues on forum.
something like “iNaturalist AWS images fails to load on TOR browser often” ?
and I think it should be unmarked. primarily because it is still an AWS policy implementation that is chosen by iNat for TOR exit IPs and the blanket ban of abuse IPs design ended up being “TOR browsers are mostly banned, even to a genuine logged in Inaturalist users as this bug, just because maybe someone else used that IP for abuse historically even if you are not that user” (Again this is largely my assumption so far, but staff can correct me if this is not IP abuse failures but some other real bug causing TOR failures so until then its better to leave it unsolved)
So now, if iNat is not against such TOR browsers, then a logged-in user fallback media access could probably use implementation of presigned URLs upon such credentials check to provide same media as whitelist mode on blanket IP bans, especially when there is nothing at fault on users side except “they used TOR so …” or “we cant support TOR browsers for now for XYZ reason”, but staff can answer better on what their exact stance is.
