Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

setBigTimeout

evanhahn.com

Post reply on HN
Print view View original

11–20 of 129 posts

Re: setBigTimeout

#11

Post by yifanl »

keithwhor wrote: post #9
yifanl wrote: post #7

If we're pedantic, this doesn't actually do what's advertised, this would be waiting X timeouts worth of event cycles rather than just the one for a true Big timeout, assuming the precision matters when you're stalling a function for 40 days.

I haven’t looked at the code but it’s fairly likely the author considered this? eg the new timeout is set based on the delta of Date.now() instead of just subtracting the time from the previous timeout.

No, it pretty much just does exactly that.

    const subtractNextDelay = () => {
      if (typeof remainingDelay === "number") {
        remainingDelay -= MAX_REAL_DELAY;
      } else {
        remainingDelay -= BigInt(MAX_REAL_DELAY);
      }
    };

Re: setBigTimeout

#12

Post by 8n4vidtmkvmk »

BillyTheKing wrote: post #6
miiiiiike wrote: post #2

Got hit with this one a few months ago.

this is the thing with JS and TS - the types and stuff, it's all good until you realise that all integers are basically int 52 (represented as float 64, with 52 bits for the fraction). Yes, it's nice and flexible - but also introduces some dangerous subtle bugs.

2^53-1 I thought.

And no, they're not all that. There's a bunch that are 2^32 such as this timeout, apparently, plus all the bit shift operations.

Re: setBigTimeout

#13

Post by arghwhat »

n2d4 wrote: post #10

The default behaviour of setTimeout seems problematic. Could be used for an exploit, because code like this might not work as expected: const attackerControlled = ...; if (attackerControlled { console.log("Surely at least 1min has passed!"); }, attackerControlled); The attacker could set the value to a comically large number and the callback would execute immediately. This also seems to be true for NaN. The better so…

A scenario where an attacker can control a timeout where having the callback run sooner than one minute later would lead to security failures, but having it set to run days later is perfectly fine and so no upper bound check is required seems… quite a constructed edge case.

The problem here is having an attacker control a security sensitive timer in the first place.

Re: setBigTimeout

#14

Post by vhcr »

BillyTheKing wrote: post #6
miiiiiike wrote: post #2

Got hit with this one a few months ago.

this is the thing with JS and TS - the types and stuff, it's all good until you realise that all integers are basically int 52 (represented as float 64, with 52 bits for the fraction). Yes, it's nice and flexible - but also introduces some dangerous subtle bugs.

Not ALL integers are 52 bit, BigInts were added on ECMAScript 2020.

Re: setBigTimeout

#16

Post by sfvisser »

n2d4 wrote: post #10

The default behaviour of setTimeout seems problematic. Could be used for an exploit, because code like this might not work as expected: const attackerControlled = ...; if (attackerControlled { console.log("Surely at least 1min has passed!"); }, attackerControlled); The attacker could set the value to a comically large number and the callback would execute immediately. This also seems to be true for NaN. The better so…

Don’t ever use attacker controlled data directly in your source code without validation. Don’t blame setTimeout for this, it’s impolite!

Re: setBigTimeout

#17

Post by cout »

graypegg wrote: post #4
miiiiiike wrote: post #2

Got hit with this one a few months ago.

Just out of curiosity, what was the use case for a really long timeout? Feels like most if not all long timeouts would be best served with some sort of "job" you could persist, rather than leaving it in the event queue.

https://thedailywtf.com/articles/The_Harbinger_of_the_Epoch_

Re: setBigTimeout

#19

Post by graypegg »

cout wrote: post #17
graypegg wrote: post #4

Earlier quoted context omitted.

Just out of curiosity, what was the use case for a really long timeout? Feels like most if not all long timeouts would be best served with some sort of "job" you could persist, rather than leaving it in the event queue.

https://thedailywtf.com/articles/The_Harbinger_of_the_Epoch_

To be fair, this will be fixed by browsers when it's within spitting distance of the scale of numbers setTimeout is normally used with. (not huge numbers) Like, if it's close enough that setTimeout(() => {}, 5000) will stop working a month later, that would be a major failure on the browser vendor's part. Much too close for comfort.

But I totally understand it not being a priority if the situation is: setTimeout(() => {}, 500000000) not working in X years.

Post reply on HN