Chrome: Anti-DDoS HTTP Throttling of Extension-Originated Requests

[lidel]

Discovered when working on embedded js-ipfs in Brave (#754 and #716)

This is fun: preload module in js-ipfs in Brave triggers Anti-DDoS HTTP Throttling of Extension-Originated Requests when opening Web UI 🙃

https://dev.chromium.org/throttling says:

The way the mechanism works is, once a few server errors (HTTP error codes 500 and greater) in a row have been detected for a given URL (minus the query parameters), Chrome assumes the server is either unavailable or overloaded due to a DDoS, and denies requests to the same URL for a short period of time. If, after this period of time, requests keep failing, this "back-off interval" period is increased using an exponential factor, and so on and so forth until the maximum back-off interval is reached. It's important to note that failures due to the throttling itself are not counted as failures that cause the back-off interval to be increased.

It gets better:

Back-off does not kick in until after the first 4 errors, which helps avoid back-off from kicking in on// flaky connections. To simplify life for web developers, throttling is never used for URLs that resolve to localhost.

Turns out, Web UI does dynamic discovery of available locale files, and that triggers lookup for non-existent files. Preload calls for those paths end with HTTP 500, triggering the "Anti-DDoS protection" 🤕

Potential solutions

Need to sleep on this, but from the top of my head:

• disable preload and delegate calls (those are temporary measures anyway)
• throttle preload calls on HTTP 500 (probably not worth time)
• change response code in go-ipfs (breaking change, not worth time without being a part of overall API revamp and cleanup)

[lidel]

Superseded by #967