The following website is Unresponsive when Navigating to it. Therefore I can not log into my bank online. Can this be fixed? It is a major Banking site. The site is:
Thanks for the report @JoeyTiets
Should resolve this. Give it 24-48hrs. let me know of any issues
All resolved & fixed @JoeyTiets ?
Yes thank you for fixing the url.
There remains a WebGL issue, re the Fifth Third website.
For Sign In purposes, Fifth Third website (53.com) wants some of its collection of Fingerprinting (device ID) info, to include what WebGL (re your Internet browser and computing device) can offer.
Ref. a general discussion, including a tip re Brave Shields:
Scrolling down to one of the comments, the following (by “Iron Heart” Feb. 1, 2022):
“Brave randomizes WebGL when set to ‘Standard’ and turns it off entirely when set to ‘Aggressive’”
PS. WebGL also related to Hardware Acceleration / GPU; but I am skipping all those details. Just trying to supply clues, for anybody who drops by, wanting to investigate further.
There is a somewhat related piece of info at that link, regarding ANGLE GRAPHICS:
At the Brave Community, since last fall (2021), there were several issues where an adjustment to ANGLE GRAPHICS (Brave flags / computer settings) would seem to fix the issues.
Some Brave Browser users, went to brave://flags and made an adjustment re ANGLE graphics or something. Some users also made a change for their display(s) (NVIDIA / OpenGL / D3D11 / Metal). I do not recall the details.
But now I wonder, if such users tested the Aggressive to Standard levels change, for Shields Fingerprint blocking.
on 53.com and others, they’re using threatmatrix. Which is deployed to detect bots, but also is quite cpu intensive since we also block 127.0.0.1 requests. Easy to get around when detected
You wrote, “we also block 127.0.0.1 requests”
Is that frustrating the resolution(s) for the following issues:
@lasvegas - .local
@trekco - localhost
Unrelated? We don’t block 127.0.0.1 outright, only on third-party sites, so if
sdsdfsdf.com decided to try to access 127.0.0.1. We don’t change the http/https on localhosts, that I’m aware of, can check later but would be surprised if https everywhere rules would do this.
I tried directing to https. It didn’t make a difference. Note that Brave Browser on another computer running the same OS has not problem with the ‘.local’ address.