The scroll bars on the tab are revealing, too. I may be guessing but it is an educated guess. Additionally, there were multiple claims so I would not call that specific data point a basis for a claim, singular.
> If you manage to make a single tab commit that much memory as a delta without Flash (remember, 13 MB to > 400 MB) please screenshot about:memory and get back to me.
I can understand this as a weak prediction, but it certainly doesn't work as a strong one. I can trivially make a tab use over a gigabyte of memory in recent Chromium by creating a gazillion nested objects in JavaScript. (I just did, in fact. If you really want the screenshot and/or source, say so and I'll post it somewhere.) Absent some default limit in V8 that I haven't encountered, I could presumably make it use unbounded memory. I can also create apparently-unbounded latency in a single tab's UI this way, by chewing up CPU in blocking JavaScript code, though this will eventually trigger the “page seems unresponsive” dialog box.
I would also tend to expect an exploit to potentially abuse the JavaScript engine by straining its limits, including things like pouring a large number of identical objects onto the heap to fill memory with exploitable patterns.
There is evidence that this is Flash. However, since everyone seems to want to attack individual parts of that evidence without applying Occam's Razor, I concede it could be something other than Flash. It could be Java, too. It could be a "standard browser exploit" too, whatever that is. Could be cosmic rays too.
The tendency to look for ways to prove me wrong with an alternate theory (which yours is) as opposed to acknowledging that multiple theories are possible with zero evidence aggravates me among technical people. In the absence of a disclosure we are both right.
Let's apply Occam's razor: a) There is no reason why Flash (or another plugin) needs to take up a large amount of space on the page. If I were to write a flash exploit, it'd be a 1x1 object with whatever ActionScript that triggers the vulnerability, no need for a large area. b) VUPEN is a bunch of extremely talented folks and I believe they have little to gain by posting a fabricated exploit video. c) The delay can also be caused by a rather advanced heap-grooming technique, it can be JS garbage collection invoked many times, it can literally be them trying the payload numerous times. Implying it's probably flash is just as speculative as we're being.
Relax man, no one's disagreeing with you to be an asshole, no one's trying to argue with you, we're all just speculating.
Actually, you can fix it, too: chromium is open source.
Good to see this tired claim getting its play in this thread. I wondered how long it would be until it showed up. I think everyone who says "go fix it, it's open-source" should instead be required to come back with a diff within 24 hours.
I don't use Chrome or Windows, so I have almost negative personal interest in this story. However, some people probably do use Chrome and Windows, and those people's demands should be tempered by reality. If they didn't find this bug, why did they expect Google to?
I think everyone who says "go fix it, it's open-source" should instead be required to come back with a diff within 24 hours.
I think everyone should be required to give me a pony.
I love how you assert that literally anybody could check out Chromium and fix the sandbox, a sensitive security-essential part of the browser, with very little effort required to appreciate the source and all of the moving parts.
Not 100% sure, and I haven't tried it, but I suspect it would be possible using this bug: http://code.google.com/p/chromium/issues/detail?id=25047