This is excellent. But I was hoping for a setTimeout that survived JavaScript environment restarts. Maybe setBigReliableTimeout is in your future? Hahaha! :)
setBigTimeout
81–90 of 129 posts
Re: setBigTimeout
#82Earlier quoted context omitted.
The exploit could be a DoS attack. I don't think it's that contrived to have a service that runs an expensive operation at a fixed rate, controlled by the user, limited to 1 operation per minute.
A minimum timing of an individual task is not a useful rate limit. I could schedule a bunch of tasks to happen far into the future but all at once for example. Rate limits are implemented with e.g., token buckets which fill to a limit at a fixed rate. Timed tasks would then on run try to take a token, and if none is present wait for one. This would then be dutifully enforced regardless of the current state of schedul…
I don't think it's that far fetched that a developer implements a rate limiter with setTimeout, where a task can only be executed if a timeout is not already running. The behaviour in the article is definitely a footgun in this scenario.
Re: setBigTimeout
#83Sounds a lot like the famous windows 95 bug when it would crash after 49.7 days of uptime [1]
Re: setBigTimeout
#84Earlier quoted context omitted.
You are a bad programmer if you think silently doing the wrong thing is not a bug. The right thing to do with unexpected input as the setTimeout library author is to raise an exception.
It's in the standard library. You're a bad programmer if you don't learn the ins and outs of the standard library, or make sweeping generalizations.
Standard library is an API just like any other library. The only thing different about it is backward compatibility (which in JS is paramount and the is reason setTimeout can't be fixed directly). It is a bad design still.
Re: setBigTimeout
#85because no one asked. If you need shorter intervals than the minimum you can make a function that calls the other function multiple times in a row.
Re: setBigTimeout
#86Earlier quoted context omitted.
> I don't think it's that contrived to have a service that runs an expensive operation at a fixed rate, controlled by the user Maybe not contrived but definitely insecure by definition. Allowing user control of rates is definitely useful & a power devs will need to grant but it should never be direct control.
Can you elaborate on what indirect control would look like in your opinion? No matter how many layers of abstraction you put in between, you're still eventually going to be passing a value to the setTimeout function that was computed based on something the user inputted, right? If you're not aware of these caveats about extremely high timeout values, how do any layers of abstraction in between help you prevent this?…
>Can you elaborate on what indirect control would look like in your opinion?
although not the OP this is what I would mean by indirect control.
pseudo if userAccountType === "free" then rate = longRate
if userAccountType === "base" then rate = infrequentRate
if userAccountType === "important" then rate = frequentRate
obviously rate determination would probably be more complicated than just userAccountType
Re: setBigTimeout
#87This is great for the folks running serverless compute! You get to start a process and let it hang until your credit card is maxed out. /s
That was before DBOS -- the serverless platform that bills you only for CPU time, not wall clock time ;) see https://www.dbos.dev/blog/aws-lambda-hidden-wait-costs
So... do they not charge for sitting idle and consuming memory?
Re: setBigTimeout
#88In response to this, I read the spec of setTimeout, bu I couldn't find the part where implementations may have an upper bound. Can someone more familiär with the specs point me in the right direction?
Re: setBigTimeout
#89setTimeout is stranger than you think.
We recently had a failed unit test because setTimeout(fn, 1000) triggered at 999ms. That test had ran more than a hundred times before just fine. Till one day it didn't.
Re: setBigTimeout
#90setTimeout is stranger than you think. We recently had a failed unit test because setTimeout(fn, 1000) triggered at 999ms. That test had ran more than a hundred times before just fine. Till one day it didn't.
Interesting.
Maybe the system clock did a network time synchronisation during the setTimeout window.