> https://esdiscuss.org/topic/using-max-stack-limit-to-determine-current-js-engine-and-revision#content-7 > indicates there may be security issues with throwing out-of-memory exceptions.
That's hardly worth considering. The technique described there for fingerprinting is interesting from a theorist's perspective, but exposing no data that cannot already be more reliably extracted from navigator.userAgent with a simple regex. An out-of-memory in a sandbox is just exposing information about the sandbox, and worth nothing therefore if the sandbox version itself isn’t already compromised, at which point the user is generally screwed anyway if he didn't patch in time. Being able to detect a vulnerability is not a prerequisite for exploiting it. Niels -----Original Message----- From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Anne van Kesteren Sent: zaterdag 26 september 2015 16:35 To: Justin Novosad <ju...@google.com> Cc: WHAT Working Group <wha...@whatwg.org>; Mark Miller <erig...@gmail.com> Subject: Re: [whatwg] Handling out of memory issues with getImageData/createImageData On Fri, Sep 25, 2015 at 4:48 PM, Justin Novosad <ju...@google.com> wrote: > Currently there is no spec'ed behavior for handling out-of memory issues > for the specific case of attempting to allocate a large buffer through > image data APIs. Actually, there is no specified behavior for out-of-memory behavior, period. This is a problem that starts with the ECMAScript standard and everything that builds upon it. I have seen Mark Miller discuss some of the issues surrounding this and perhaps even the necessity to eventually define it, but so far this has not happened. Not sure if the full story is documented somewhere. Mark? https://esdiscuss.org/topic/using-max-stack-limit-to-determine-current-js-engine-and-revision#content-7 indicates there may be security issues with throwing out-of-memory exceptions. -- https://annevankesteren.nl/
