Skip to content

the speedtest warned about Brave Shields while running fine in Brave - #3017

Merged
Flotapponnier merged 1 commit into
devfrom
fix/speedtest-measured-warning
Oct 16, 2026
Merged

Flotapponnier merged 1 commit into
devfrom
fix/speedtest-measured-warning

Conversation

@Flotapponnier

Copy link
Copy Markdown
Collaborator

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.

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.
@Flotapponnier
Flotapponnier merged commit 058b572 into dev Oct 16, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant