Yes, you should block apps that you don't want to see. They are (per your reasonable definition) badly behaved, and you should exclude them from your stream. I think that's exactly the behaviour that FB would want, because it ties the utility/economics of those apps to the quality of their user-experience.
(Disclosure: I start at FB next week, though I don't have any inside info on this.)
Can you give me an example? Sites get entered in there if they try to install malware on people's machines. I think it's straight-up ridiculous to say that FB's text there is an attempt to mislead users. It gives good advice that most people don't keep in mind at a funnel point that's known to be relevant to an enormous number of phishing and other attacks.
Do you actually believe the things you're saying? I'm struggling here.
You're right, of course. While I believe that the MPEG-LA's enforcement practices are not non-discrimatory as it's claimed to be, that's a different discussion, and it wasn't appropriate to single x264 out that way.
No, but this is a common misconception. Though the summaries talk about "sold to users", the license itself defines "sale" in such a way as to include zero-cost distribution:
"Sale (Sell) (Sold) (Seller) – shall mean any sale, rental, lease, license, copying, transfer, reproduction, Transmission, or other form of distribution of an AVC Product or the Transmission by any means of AVC Video either directly or through a chain of distribution."
This is consistent with the discussions I've been party to with the MPEG-LA directly.
Edited to add: I would very much appreciate a reference to MPEG-LA saying the things you indicate in your comment. It would be very interesting to be able to point to those statements, in a number of ways.
No, it's noncommercial (really not user-monetized) streaming of video that's free. Shipping H.264 hardware requires paying licenses regardless of whether it's a commercial situation or not. For software, if the patents are enforceable in your jurisdiction, it's the same thing.
Use and distribution of implementations requires a license (though, curiously, x264 seems to get a pass), so using the decoder will require a license as with using a closed-source one.
Brendan's demo was running at 30fps, I believe on a Macbook Pro (I'll find out). Some content will run slower right now, which is true of all codecs AFAIK but is more so for this stuff right now.
The patches linked from the github README aren't necessary to run the transpiled version that was in the demo -- it's a memory optimization that's being used in the tuned-for-JS version.
As regards derpiness: it lets content distributors decide to pay for H.264, if they want, exactly, and paves the way for other codecs to be deployed by such distributors as well. It also runs the codec in a managed environment -- format decoders are often very fertile territory for exploitable bugs, since they are pretty much by definition all about pointer math and byte-poking. But the initial intent, when they decided a week ago to try it, was to push the envelope of JS performance such that we find new ways to extend said envelope.
You need Firefox nightly for it to run well, because it depends on the hybrid static/dynamic type inference work and some other optimizations. I believe that Brendan was demoing it from a Mac laptop of some kind.
As far as applications, it will let content providers who want to ship H.264 and pay the license fees do so without requiring all browser developers to pay such fees. (For Firefox it would be a meaningful portion of Mozilla's engineering budget.)
And it's a pretty compelling demo, IMO, of the fact that we're not done with JS performance yet, and that people don't need to be running to Dart or NaCl or other rip-and-replace technologies in order to get great perf. There's a lot of opportunity for even better performance on the engine side as well as the library side: they started a week ago with emscripten, Closure and the libstagefright C sources...
This is a FAQ; I should finish writing the FAQ, clearly.
We’re currently aiming at mobile/tablet devices rather than a notebook form factor. We’re looking to expose all device capabilities such that infrastructure like phone dialers can be built with Web APIs, and not only “high level” apps like word processors and presentation software. We also want to provide a stack that's open down as far as we can, and not just the browser-like top layer.
Firefox on Android uses very little in the way of the Java APIs, it's virtually all NDK code. That said, it will certainly require some meaningful adaptation.
"Also, the web platform isn't ready to be the only platform available for applications."
That's the whole point. The web wasn't quite ready to subsume PDF, until people went and tried to do it, found the pieces that were missing, and got them added.
We expect and hope that we're going to hit a ton of things that don't work today, and that we'll have to make them work and get a standardized API and so forth. I think that's a better way to proceed than to make speculative sky-APIs on standards mailing lists.
We are exactly targetting mobile devices (handsets and tablets), because we agree with your assessment of where things are headed, and because that's where the app action mostly is today. (We want to solve the app-store-for-web problem too, but that's another project.)
This isn't just about the web apps you have today. It's about having your contacts manager, camera, gallery, dialer, SMS app, GPS-integrated maps, launcher etc. be hackable using web tech. That work will help on desktop as well, since many of those pieces are on desktop/laptop machines -- if you write OS-specific code to get to them, and you're allowed by the OS to interpose your version of it.
Maybe you're right, maybe it's a fool's errand. We think it will help the web grow in powerful ways, and make important internet technology be accessible to more user-focused customization, so we're going to try it. That's basically what we do.
MSRC didn't say it's not worth it. They said it couldn't survive the SDL process or be securable, which is the standard for technologies they deploy. Given that they deploy those pre-existing technologies and added more in IE9 (WOFF, accelerated H.264, accelerated canvas), and given that they have to pass SDL review, I think they are being unhelpfully inconsistent.
(Does MSRC ever make the worth it/not worth it call? I thought they just analyzed the security side, and didn't make the product decisions.)
The shader models in XNA D3D and WebGL are pretty similar. One travels as pre-compiled bytecode and the other as text, and there are some differences in how loop constructs work, but they're both basically shader model 2.
But the argument I read from MSRC wasn't about the capabilities of the system when working as intended, it was about weaknesses in OEM/IHV drivers causing unintended behaviour that is qualitatively harder to fix than bugs in the drivers for hardware H.264 decoding. I haven't yet found a way that HLSL/XNA is more robust than GLSL/WebGL, and I've been in threads about those shader models for quite a while now. Of note, perhaps, is that on Windows we compile GLSL into HLSL and then effect bytecode (with Microsoft's compiler) and feed it through Direct3D. It's a very very similar pipeline.
The claim is that driver blacklisting hasn't been used to address recent vulnerabilities, but...the recent vulnerabilities have had nothing whatsoever to do with problems in a driver.
Based on face-to-face conversations with senior people at GPU manufacturers, I do, yes. You should absolutely decide for yourself; I said what our belief was, and what it was based on.
My point is that those technologies have been added to browsers, and we've been able to deal with the security surface. Microsoft's position is that WebGL is inherently unsecurable, and therefore somehow qualitatively and fundamentally different from doing hardware accelerated 2D graphics, JS JITs, or -- as they brag about in IE9 literature -- handing off H.264 content straight to drivers and hardware to decode.
WebGL absolutely needs care taken from a security perspective, as do video and RTC capabilities, new network protocols, and support for unicode. (The "text-display facilities" I mention were some OS-supplied ones that crashed out if given the right -- wrong -- sequence of characters to display.) Especially in light of the impending support in SL5, I don't think MSFT has made a case that this facility is actually as world-ending as they make it sound. I believe that WebGL can be secured, and am disappointed that MSFT is throwing up their hands and saying "can't be done! all gonna die!" about WebGL while they've obviously invested to the point of comfort in the equivalent SL5 APIs. On Windows, in fact, we map GL to D3D and use the same shader-compilation and API pipeline as SL5.
Advice and input from Microsoft on this would be very welcome. They know a lot about the whole (Windows) stack, though perhaps not OpenGL, and like us they had to deal with driver and D2D bugs while accelerating the 2D portions of their browser. But if they're going to raise security concerns about things, a conversation rather than a blog-post broadside would probably contribute more to the security of the web.
(People point at the Context IS bug reports, but they had nothing to do with access to fragile driver code or unsuspecting hardware. They were origin-management problems in the spec, and a straight up C-pointer-mgmt-claims-more-toes bug in our implementation.)
[Disclosure: I work at Mozilla, and have been closely involved in the JS engine for some time.]
For a while (3.5 and 3.6, I think), Linux distributors shipped 64-bit builds of Firefox, which did not have JIT support. (Mozilla did not produce supported Linux-64 builds until 4.0.) Experimental Windows 64-bit builds had the same problem, but most people even on 64-bit Windows would use the 32-bit version. Linux distributors would also build Firefox to ease their package management, rather than to optimize startup speed, so again if using a distro Linux build you were in the penalty box.
MSVC also has PGO support which we still can't get working properly on gcc, and which used to make a very substantial difference in JS performance, and still makes a small one. Add to that the PIC register overhead, and that we had to compile with frame pointer on Linux for some time until we added CFI support to the crash reporting software, and there were lots of places where the toolchain just didn't keep up.
Animated performance tests are likely to be slower on Linux than on Windows due to graphics differences rather than the underlying JS performance. In fact, one of the ways that we generally tell if something is JS-related or not in initial triage is whether it's cross-platform or different on different OSes.
Windows is where most of our users are, but most of our developers are still on OS X I think. After that is probably Linux, but it's a close call. More are moving to Windows, mostly to be closer to the dominant user experience. Linux generally suffers most in the graphical department, due to the...variable quality of available drivers. compiz itself has an extensive blacklist of drivers, and that's coming from the distros themselves! I don't think anyone can reliably get Linux video driver bugs fixed, and we've been waging a battle against Linux graphics stack performance problems for some time ourselves.
(One major performance issue for us is theme drawing and using stock icons and doing other "be a good Linux desktop citizen" stuff. Chrome went the other way, doing their own thing and not having to load icons synchronously, or re-initialize the font system on startup, or do all form-widget drawing through gdk-indirection-slowtown. I think it's clear at this point that we erred in listening to what the Linux faithful told us they wanted, and we should have listened to our instincts.)
On Android our JS performance is pretty great, even though the native toolchain isn't exactly fantastic. That's probably the most important Linux platform in the world right now.
(Disclosure: I start at FB next week, though I don't have any inside info on this.)