WebM-H264-Flash

Then move on to content providers: the first one, YouTube, supports both the H.264 WebM. Beyond that, we must also look to find videos in WebM. And for good reason: this waltz codec has a cost, not just storage, but also encoding.

Content providers are primarily looking for the highest common denominator between all browsers and all platforms. For now, the duo Flash and H.264 that wins, because the plug-in Adobe can play H.264 video in browsers that do not have this feature. Similarly, IOS, Flash private, can play videos in H.264 format, like most mobile platforms.

Take the case of Daily motion, which hosts some 16 million videos, the 3G format (240p), SD (380p), HQ (480p) and HD (720p). To fully support the WebM, should convert each video to each of these resolutions, to ultimately do not get absolutely any benefit from the perspective of the host: support for WebM would not increase the scope of the site. Besides Daily motion receives many videos already encoded in H.264 with regard to the quantity of material to support this format natively, and encoders WebM are two to three times slower than their counterparts in H.264. Recognizing further that the MPEG-LA has decided to permanently abandon his royalties on the free dissemination of content in H.264, WebM does not even compensating on that plane.

Adobe has already announced plans to add support of WebM in Flash, and Google also speaks of a plug-in to read the WebM (probably as a codec for QuickTime and Windows Media rather than a plug-ins for each browser, read WebM: freedom, politics and ... installing plug-ins). It nonetheless remains that IOS cannot read the WebM. Site publishers who wish to remain accessible on the Apple devices will be well advised to keep H.264, which will remain readable in Firefox, Chrome and Opera through Flash.

And that's where Google's announcement demonstrates its adverse effects, far from encouraging the abandonment of Flash, it only strengthens his position. Some observers have also not failed to raise an inconsistency in the attitude of Google, if it abandons the H.264 for philosophical questions relating to proprietary code, what does the code of Flash within the one Chrome? And what about other Google products that retain their support H.264? Olivier Poitrey, technical director of Daily motion, does not mince words: "Google wants us to believe that his only interest is to advance open source, but keeping the support of this proprietary format in YouTube, Google Android and TV it demonstrates the hypocrisy of his actions. "

Also remains the thorny question of hardware acceleration, which is crucial for mobile devices, and so far the exclusive domain of H.264. Certainly, the support of WebM in hardware has been promised, but what about the current generations of hardware, and various contractual commitments with its partners YouTube?

HTML5 video: they redid the game?

Google has decided to remove the H.264 support in its browser within two months. The reason stated for this choice: the promotion and support of open formats to the detriment of the open standard (but not least the owner) what is H.264.

Here is another episode in the long battle that pits two camps around the HTML5 video tag. WebM supporters are surprised to dream that such support is crucial to switch things ... The Free Software Foundation does not hide his enthusiasm after the announcement. But despite the undeniable weight of Google, it will take much to tip the current balance of things.

Let's start by estimating the forces in place. In the field of computer browsers, only Safari and Internet Explorer remain in the camp of H.264, while Firefox, Opera and now Chrome (which was previously the only browser to support both formats) are in the camp WebM. Regarding the effective support of HTML5, only IE9 (0.46% market share), Safari 4 + (5.41%), Firefox 3.5 + (21.09%), Opera 10.5 (2%) Chrome and 3 + (9.8%) support the video tag, at least among the browsers on your computer. This still represents a minority of all browsers currently used.

Because we must not omit mobile devices, particularly iOS, whose inability to read from Flash was one of the drivers of the adoption of H.264 on the web. If not iOS assumes "only" 1.69% market share of operating systems (all machines together), it is nonetheless the backbone of mobile platforms, a highly strategic area. Other mobile OS also offer all native support for H.264, with hardware acceleration that makes reading more energy efficient.

Change of strategy

Overall, the whole approach of the Apple security that Charlie Miller and castigated early March, although he conceded being "somewhat responsive to bugs that has been providing it with:" Apple does not pay security researchers. Apple assumes that it has no security problem and did not need to work with researchers. "Worse, he said," Apple is certainly capable of producing a safe product, but do just not yet made the effort. "And, in fact, Apple may have changed his tune: he moreover subject - among others - pre-release version of Mac OS X Leo.

In addition, Apple has recently recruited several experts in computer security: David Rice, a former NSA, Ivan Krstic, former director of the OLPC, or Windows Snyder, who has contributed to strengthening the security of Firefox.

And he has this apparent convergence between Mac OS X iOS. Apple uses sandboxing widely within IOS, but not in Mac OS X, maybe it will evolve. ALSR arrived in IOS with version 4.3, its use may be extended with Leo. Code signing is also utilized to secure iOS. With the Mac App Store, it used to protect applications distributed through this, against piracy. But perhaps Apple plans to go further ...

Safari, a victim of his age?

But if there's one application that one might be tempted to apply this perspective, it's Safari. A French window all the more sensitive it is open to a world where hostility is not lacking. And then, Apple has fallen behind Google and its sensitive Chrome: it is fully designed to isolate processes from each other and HTML rendering extensions, is the concept of sandboxing, confinement in bins sand, literally.
Safari for Mac could give the impression to use the sandboxing for plug-ins like flash, but isolation is not complete - it is just there to prevent the component to crash the browser.

Mac OS X Lion could change somewhat the situation: a new process is associated with Safari, and it could be exclusively dedicated to rendering HTML, Safari Web Content (read: Safari 5.1: separate processes and WebGL). But it remains far from that Chrome isolates each tab in a dedicated process. And for Miller, Apple has "failed - or did not seek" to make regularly available for Safari updates made to its rendering engine, WebKit. As to better illustrate this assertion, Chrome has already enjoyed a patch for the vulnerability exploited in the last Pwn2Own to make him fall.

Faults! Yes, but it is still necessary to exploit ...

But it is on one side and holes on the other, the possibility of exploiting them. Mac OX 10.5, Apple introduced two devices to protect its operating system against this: the ASLR and DEP. The first, and Address Space Layout Randomization, is to introduce an element of chance in the distribution of data areas in virtual memory. And thus limit the possibilities of executing malicious code introduced in memory overflow the buffer, for example. DEP completes the first device by prohibiting the execution of injected code still in memory areas reserved for data. The DEP is closely tied to the hardware architecture of the computer.

In Mac OS X 10.5 and 10.6, the ASLR is too partial. Charlie Miller underlines that "there are many things that are not random, as the location of the dynamic linker [which deals with memory and seek to link shared libraries when an application is launched], or stack and heap [two areas in memory where some data are stored temporarily]. "And for the DEP, the situation is no better: it only applies to 64-bit process. Charlie Miller, he must report this to the world in the face: "In Windows, ASLR is complete and they have the DEP." And if, for Apple, the move to 64 bit improves security for Miller " this makes the circumvention of DEP that more difficult. "But not impossible.

Certainly, as pointed out Charlie Miller, Apple has made available to developers - and uses in Safari - tools from further strengthen security: "canary." These are reference values that are placed in a buffer and to verify the data stored in the stack to monitor potential buffer overflows, the first data corruption in this case to just be the canary. But again, the expert pointed out that using this type of security systems based on the specific compiler may require a migration to environment and development is not entirely suited to large projects with a strong history.