I fully support Jeff's opinion there. All of the systems I have seen that implement strict rules have people invent easy-to-remember, yet extremely to guess passwords that pass the rules. It is my firm belief that password rules make passwords way more insecure.

A projector has a very low contrast, because what you see when you turn it off (the usually white wall) is it's blackest black. This is a huge difference to modern TVs.

The difference between asm.js with and without special optimizations is not necessarily that big. See benchmarks here, showing it can be anywhere from 1x (almost no change) to 5x. It depends a lot on the benchmark. And in a demo like this, the GPU matters a lot too, which makes asm.js matter less.
So all modern browsers should already work on this demo. But this is a very large codebase (over 1M lines of C++ compiled to JS), and it pushes the limit of what browsers have tested on. Now that this demo is public, that should make it easier for other browsers to fix what they need so the demo can work on them.

It doesn't require special asm.js optimizations (asm.js is a subset of JavaScript, so it already runs properly in all modern browsers). The demo works fine in the stable release of Firefox for example, which has no special asm.js optimizations. It is faster in Firefox nightly though which does have those optimizations. But how much faster depends on the CPU and GPU, it might matter a lot or it might matter a little. In this demo a lot of time is spent in WebGL, so a fast GPU and good WebGL implementation matters a lot too.

The demo should work in any browser with WebGL and JavaScript support. For example the only reason it currently fails in Chrome is due to a bug related to memory use. Hopefully that will be fixed soon.

Actually, only RSA public-key cryptography is based on that asymmetry, and even that is not precisely correct. And RSA is considered the most probable candidate to be broken at some time of the bunch of algorithms that are used. Even ssh uses DSA (at least you should, and not use RSA if you are paranoid) which is based on the assumed difficulty of calculating discrete logarithms in finite fields. If you are even more paranoid, use something that is based on elliptic curves.

Actually, Having a real message (i.e. pass spellcheck) is quite easy to detect. It's getting there that's the hard part. It can take some time (time we have). Finding the one time pad key (where the key is as long as the message) is to use enough known messages to force a collision. Known plain text comparisons (like known plain text of similar pigeon messages). The governments might already have the exact message decoded by other means. Generate one time pads for the entire known text and see if you get a hit. Use statistical methods to create agents to process certain targets of known plaintext pairs. Having a message header or sign off pattern would be a great place to start!

Smalltalk has a built in IDE. Check out http://www.pharo-project.org/home

Actually, changing clothes at security to provided, standardized suits and have your clothes packed together and transported in the luggage compartment should be fairly safe as well. Of course, everyone would look the same in flight then...

You can compile C++ to JS and run it on the web, using Emscripten. It supports SDL.

Here is an example 2D game ported that way: http://www.syntensity.com/static/mams/mams.html

Wireless thunderbolt, except for power xfer, why not use software defined radio to support *all* standards AND have a wideband "thunderbolt io" compatible mode as well. One wireless standard to rule them all...

Linux, NVidia drivers. 3D games and WebGL work perfectly here, so it isn't a problem with the hardware or drivers, must be something with their support I guess as you said.

Even if this ran, it took 600MB. That's huge, if it's ported from an iOS game it must take much less memory there. So I am very unimpressed by the quality of this port.

Looks broken. Takes very long to load, then takes 600MB and something seems to happen, but no polygons are rendered. Looks like just one ugly repeating texture for the ground, and a few bushes. I can pan around though but there is nothing to actually see no matter how long I wait. http://imagebin.org/206217 This port doesn't look very successful.

They ported it, but how well does it run? Until we see the demo in the wild, so we can test it ourselves, I am skeptical. Their demo machine is likely not a typical one.

The important bit is "eventual". Right now, NaCl is CPU specific, and it is indeed fast. But making it portable may diminish the speed, it is not clear how fast PNaCl will be when it is finished, there are numerous challenges - for example, the LLVM bitcode that is shipped is very large (bitcode is much larger than object code because it contains higher-level information), and it takes time to optimize before it is run.

Supporting NaCl now when it is CPU specific, in the hopes of it fixing its problems some time in the future, is a big leap of faith.

As for PPAPI, yes, it is BSD licensed. But open source doesn't mean it is an open standard, nor does it mean it is usable without an extreme amount of engineering; for practical purposes, it isn't in its current state - it's tied to Chrome internals, and cannot just be dropped in Firefox or Opera; worse, it is constantly changing to fit Google's needs (mainly driven by NaCl and Flash) - it's a moving target with no spec.

There has been a lot of talk about this in the past, the main issues that I recall are

• Pepper's goal is to enable plugins to do more things. But all web browsers except for Chrome are moving away from plugins and towards HTML5, there are no plugins in iOS nor in Windows 8 Metro for example. Implementing Pepper would take a lot of effort, other browsers prefer to look to the future and optimize HTML5 technologies. Even WebKit doesn't want Pepper in it.
• Pepper has a single implementation and no formal standardization documentation. Trying to implement it now means reproducing whatever behavior Pepper has in Chrome. Since Pepper has lots of methods and is quite complex, this would be a very hard and perhaps impossible task (since Chrome can keep changing Pepper when it needs/wants to).
• Pepper has been driven by two main use cases: Flash and Native Client. Both are technologies that only Google supports, all other browsers prefer HTML5 over Flash and oppose Native Client because it is CPU arch specific. With those two use cases out of the way, it isn't clear there is a reason for other browsers to implement Pepper at all