On Tue, Sep 20, 2022 at 10:32:29AM -0400, Raul Miller wrote: > On Tue, Sep 20, 2022 at 10:06 AM Alton Shaw <[email protected]> wrote: > > I don't know it this is the same thing but I opened Firefox's console ... > > The network inspector should be a tab in the console. > > That said, I believe network errors should show up in the console. > > That said, it's entirely possible that the message is from a > javascript timeout, which would underline some of the points raised in > Crystal Kolipe's summary. (It's also plausible that the bank's > security people have decided that an excessively slow network is, for > their purposes, an insecure network.)
So the next step would be to either: 1. Read through all of the javascript, work out which requests should be made, and compare that list to the actual list of requests made. or 2. Compare the requests made on a setup which is known to work, with the requests made on a setup which does not work. Presumably either something is not being sent from the client, or something is not received, (or is received too late, after a timeout has expired). Or maybe it is being sent as far as the client is concerned, but then gets mangled or delayed at the IP layer. Getting that far is complicated by the fact that there could be more than one issue, more than one request not being serviced, that the requests might be answered by different machines at the remote end, and there might also be some intentional randomisation going on between otherwise 'identical' login attempts. If you do manage to work out which javascript-initiated communication is not going through, you then need to find the _real_ reason why. It could be something seemingly completely unrelated. Maybe deep within that javascript is a function that is also implemented in web-assembly and that version is being used on Firefox but not on Surf, (which doesn't support it), causing a slight timing difference. The list of possibilities is almost endless at this point.
