You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it make sense for uBO to provide rate-limiting rules or extended-filters?
The use-cases I had in mind were:
Preventing a buggy (but essential) script from sending too many requests to the same host
Slowing-down or stopping "declarative" infinite redirections, such as G-Search on FF Android.
Prevent excessive non-root-doc redirects (that is, redirections that happen to any request that isn't the main HTML document or media file)
Since "too many" and "excessive" are ambiguous, inspiration could be taken from no-large-media: The user specifies the count and interval that should be considered "frequent request". For example:
1req 1s: one or more requests per second is "too many"
4req 100ms four requests within 0.1 seconds is "excessive"
There are some details that are open to interpretation:
Should requests be throttled or blocked?
ask the user, I guess?
If throttled, what's the max frequency?
adding yet another setting seems overkill
If blocked, should there be a temporary cool-down period, or a perma-block that lasts until the next tab-reload?
If cooldown, how long should it last?
should it be de-bounced, thereby resetting the count-down every-time a request is attempted? or should it be "forgetful"?
Should this task be delegated to a different browser-extension? If so, would that extension "play nice" with uBO?
I can reproduce the loop with Google search, these may needs a well-damped filter (compatible with enabled JS and whole Google services under www subdomain) or a new hard if (as we see improvement for the rest of the services):
!#ifjs_fw_disabled! fo bar!#endif
Or more modestly we block JS for Google while avoiding refresh:
$script,inline-script,domain=google.*! + one of to disable raw and base64 script from attribute:||google.*^$csp=script-src 'self' *$csp=script-src 'self' *,domain=google.*
Pretending to be a phone on a computer may require forcing the uBo to work in mobile mode (no loops "without" - Maybe are not allowed remove some parameter using removeparam like gbv with disabled JS).
In Firefox beta or Nightly we can test whether deactivating JS at the browser level also generates loops and whether Moz://a has restored work uBo Dashboard.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Would it make sense for uBO to provide rate-limiting rules or extended-filters?
The use-cases I had in mind were:
Since "too many" and "excessive" are ambiguous, inspiration could be taken from
no-large-media
: The user specifies the count and interval that should be considered "frequent request". For example:1req 1s
: one or more requests per second is "too many"4req 100ms
four requests within 0.1 seconds is "excessive"There are some details that are open to interpretation:
Should this task be delegated to a different browser-extension? If so, would that extension "play nice" with uBO?
Beta Was this translation helpful? Give feedback.
All reactions