Except that renegotiation was developed by the very same people at Netscape and for the same specific purpose that it got used for: changing crypto parameters and client certificate authentication after the HTTP request had been made.

I doubt it. ElcomSoft's products are favorites of law enforcement and Apple employs some crypto people who know exactly what they're doing with the product's design.

Law enforcement raids journalists' houses and confiscates their computers for Apple, Apple leaves room for law enforcement to buy software from Russians to use against Americans.

Adobe Flash aren't so much security risks to the site, they're a risk to the user's computer running the browser. The attacker gets to choose whether to attack the browser via Adobe Flash or to attack it via WebGL. Unless the user is specifically running Firefox+NoScript, the site itself has little to do with it.

This is why the discussion about Flash and WebGL security is important for users to be involved in, not just hackers and website authors.

I agree it's misleading to imply that there's a specific 'flaw' that leaves the GPU 'exposed'. That's the entire point of WebGL: to expose the GPU to web applications. Whether or not you think that's a good idea depends on where you fall on the security vs. functionality spectrum. It's an interesting discussion.

Look at it this way: GPUs are extremely complex hardware/software combination systems representing a huge attack surface. They're designed either for zero-cost (integrated graphics) or maximum game performance. Security has never been a big driver for this market. Newer graphics engines like WebGL allow the GPUs to be programmed with somewhat arbitrary code. These programs need lightning-fast parallel access to several different kinds of memory and the security model for this programming environment looks something like an afterthought.

Once again, the developers probably thought they didn't need to put security first since the primary use case was running trusted applications on single-user systems (e.g., games).

It's not uncommon to see crash bugs in GPU systems. They look a heck of a lot like the blue screens that used to plague MS Windows. There's no reason to think these bugs will be any less exploitable than those of Windows XP SP 0. We've seen this play out with Adobe Acrobat reader, Flash, and any number of other binary browser plugins. Hopefully the graphics developers are better, but their challenge is much harder too.

In short, all the ingredients are present making in the recipe for disaster. It's probably only a matter of time for exploitable vulnerabilities to surface. I don't think we should kill off WebGL altogether, but the right thing to do is to put the focus on its security.

Personally, I look forward to using it, but I'm going to turn it off by default. I'm counting on noscript to let me enable it selectively. This is just good practice anyway.

Can't wait to see the article where they update that study with the new data from Fukushima.

I dare you to go into one of the evacuation centers and say that to one of the 70,000 people who have no idea when (or if) they'll ever be able to return to their contaminated home.

That makes no sense. Why should they get credit for something that they destroyed?

If someone sells you a nice house for market price, do they get credit? Not really, they weren't doing you a favor, they were making money.

When they later burn your house down, do they get credit?

No, actually this makes me adverse to things with just Ericsson's name on it too.

OK I'll go read TFA now.

Well the definition of "supercomputer" changes over time obviously, but I imagine you don't have to go too far back in time for a PS3 to qualify. The fact that I have one in my living room counts for a lot.

For the types of thing that cells are good at, probably nothing even comes close to the installed cost (cycles/sec/$) of a pile of PS3s.

Those phony 240 hz screens don't actually change the pixels 240 times per second.

Well your retina doesn't react instantaneously either, but your brain knows how to compensate for it. My personal theory is that the slow response of the LCD is also an analog or analog-appearing process and your brain will find it less offensive than other types of timing distortions.

But even if the LCD itself doesn't respond instantaneously, increasing the frame rate can potentially decrease every frame-count-denominated source of latency preceding them in the pipeline. By going from 33 ms/frame (30 Hz) to 4 ms/frame (240 Hz) you eliminate 14 to 29 ms worth of latency in even the shortest pipeline. Of course, if you have that much extra CPU it seems like you prevent the multiplier effect by runing the game logic at the higher rate and just throw away the extra frames without rendering them to the GPU.

But I'm not a real game developer or expert on these matters.