Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

I don’t object to the idea of levels of severity when throwing an exception, but I don’t think it will be sufficient to defend against attacks either. An attacker that wants to infer information about the target VM or stop execution in some target code at a point of inconsistent state will

Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

I don't think that prevents a caller from adversarially injecting - and then catching - faults into a callee in such a way that the caller can control which part of the callee runs and which part doesn't. The ability to catch the fault is what causes the security issues, since the caller can

Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

I see potential security benefits on the server side, though (e.g. Node). If someone manages to DDoS a server through a RAM heavy route, that can become a problem where it's safe to take extra precautions to avoid OOM, but the attacker can't add their own hooks without being able to execute

Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

On Mon, Sep 28, 2015 at 1:20 PM, Geoffrey Garen wrote: > I don’t object to the idea of levels of severity when throwing an > exception, but I don’t think it will be sufficient to defend against > attacks either. > Agreed that if you're throwing, then you are vulnerable to

Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

On Sun, Sep 27, 2015 at 9:57 AM, Filip Pizlo wrote: > Hi Mark, > > It seems that most of the benefit for fail-faster behavior for VM errors > is security. > > To what extent do you think the security problem could be addressed by VMs > simply randomizing the point at which

Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

Hi Mark, It seems that most of the benefit for fail-faster behavior for VM errors is security. To what extent do you think the security problem could be addressed by VMs simply randomizing the point at which stack overflow or OOM happens? I think this would be more desirable, since it

Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

[-whatwg, +es-discuss] Reposting to es-discuss, as Anne's more general question is best seen as a JS issue rather than a browser specific one On Sun, Sep 27, 2015 at 8:30 AM, Mark S. Miller wrote: > On Sat, Sep 26, 2015 at 7:34 AM, Anne van Kesteren >

Re: Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

Android has an older onLowMemory() callback and a newer onTrimMemory() callback: - http://developer.android.com/reference/android/content/ComponentCallbacks.html#onLowMemory () - http://developer.android.com/reference/android/content/ComponentCallbacks2.html#onTrimMemory(int ) iOS has something