Repository navigation
the speedtest warned about Brave Shields while running fine in Brave - #3017
Merged
Merged
Conversation
I drove the page headlessly in Brave itself, on the machine that reported the failure, with default Shields and a clean profile. It prefilled Ethereum, dropped the one endpoint that sends no CORS header, ran 29 probes against each of the other four and ranked them: Tenderly 74 ms p50, dRPC 91, PublicNode 98, 100% ok. The banner reading "Brave Shields will block this test" sat above that run. It was false, and I had just made it louder. A false warning is worse than none. It hands the reader a culprit, so they stop looking, which is exactly what it did to me: an hour spent on Shields, then on CORS, then on DNS, while the only question that mattered went unasked, which was whether the thing works at all. The page already knew. The prefill POSTs eth_chainId to every endpoint before the run, and when all of them fail it keeps the list and says nothing. That silence is the gap. The warning now fires on that measurement instead of on the browser's name, and Shields appears as one candidate among the local causes rather than as the verdict. The post-run message loses the same certainty. What I checked before touching the copy, all from this Mac: DNS resolves through the router with no filter, no proxy, certificates issued by Google Trust Services and Let's Encrypt with no interception, the five Ethereum endpoints answering POSTs in 77 to 101 ms, access-control-allow-origin: * on both the preflight and the real response for the production and the staging origin, a CSP whose connect-src allows all https, and a sweep of the whole directory finding 0 of 81 chains without a browser-usable endpoint. Gates: tsc clean, eslint clean, 561 tests.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
the speedtest warned about Brave Shields while running fine in Brave
I drove the page headlessly in Brave itself, on the machine that reported
the failure, with default Shields and a clean profile. It prefilled
Ethereum, dropped the one endpoint that sends no CORS header, ran 29 probes
against each of the other four and ranked them: Tenderly 74 ms p50, dRPC 91,
PublicNode 98, 100% ok. The banner reading "Brave Shields will block this
test" sat above that run. It was false, and I had just made it louder.
A false warning is worse than none. It hands the reader a culprit, so they
stop looking, which is exactly what it did to me: an hour spent on Shields,
then on CORS, then on DNS, while the only question that mattered went
unasked, which was whether the thing works at all.
The page already knew. The prefill POSTs eth_chainId to every endpoint
before the run, and when all of them fail it keeps the list and says
nothing. That silence is the gap. The warning now fires on that measurement
instead of on the browser's name, and Shields appears as one candidate among
the local causes rather than as the verdict. The post-run message loses the
same certainty.
What I checked before touching the copy, all from this Mac: DNS resolves
through the router with no filter, no proxy, certificates issued by Google
Trust Services and Let's Encrypt with no interception, the five Ethereum
endpoints answering POSTs in 77 to 101 ms, access-control-allow-origin: *
on both the preflight and the real response for the production and the
staging origin, a CSP whose connect-src allows all https, and a sweep of the
whole directory finding 0 of 81 chains without a browser-usable endpoint.
Gates: tsc clean, eslint clean, 561 tests.