That's great, but what are websites supposed to do? Start serving up PNGs (or whatever modern equivalent) and hope that users have the correct plugin? Or do they stick with something not quite as good that they know will work? That is why having a small list of supported codecs is important (leaving aside the fact that many users simply cannot install additional software).

Nobody cares about Matroska files except for pirates (which is a shame, because it has nice features). Neither Windows or MacOSX are interested in supporting every single codec under the sun. You can install additional codecs for both Windows and Quicktime if you want to, but if you are distributing files it is better to just use an industry standard like h264. This is exactly my point.

I don't really have anything to add except to say the Netflix and similar products will never use the standard video tag to stream video, since it doesn't offer the flexibility and DRM that they need. Netflix isn't really a web-based product anyway, all the heavy lifting is done outside of the browser.

Video codecs and fonts are similar in that they are both complex binary formats whose readers have until recently not been exposed to the cesspit of exploits known as the internet. Both font rendering code (on all OS's) and base video codecs have had patches to fix security holes (mainly buffer overflows) in recent years. Mozilla does not want to be in a position where they know there is an exploitable hole in a video codec that the vendor won't quickly fix (which has happened in the past).

What are they supposed to do in that situation, disable the feature? Ship a product they know is insecure? At least with their own codecs, they know they can always ship an update immediately if a problem is found.

On your second point, I am not sure it is Firefox's job to be all things to all people. It is a web browser, not a security console. If you want a web enabled security console then you would use a web-ready video codec. Besides, Firefox still supports plugins for additional behavior if you really need something non-standard. You could even make a plugin that forwarded everything onto gstreamer (or DirectX, or Quicktime) if you really want to - just don't expect me to install it.

They shouldn't "support H.264" but rather, they should support any unknown (to the browser) codec by trying the OS.

No, no, no. That will lead to the bad old days of having to install a different codec for each web site. Remember when we had Real, various MS codecs, Quicktime, and Flash, and various others I have forgotten all competing for memory? It sucked.

In a perfect world the video tag would define a small list of codecs that are broadly supported by OSes and mobile devices. The list of codecs can be revisited every 5 years or so as technology improves but should be fairly static. The browser can chose to implement the codecs themselves or let the OS do it, but should not attempt to pass every unknown codec onto the OS. H264 is the industry standard (like it or not) and if Firefox can't implement it itself (for good reasons) then I think using the OS is a fair enough compromise.

I wrote about this 2 years ago when this issue first came up. At the time one of the Mozilla devs explained that they didn't really trust the OS codecs from a security point of view, but time has moved on and I would expect that most H264 codecs are pretty secure now.

So the moon contains rare earth elements, and now we have rare moon minerals on Earth. MAKE UP YOUR DAMN MINDS, EARTH/MOON SYSTEM!

I have some good news - although they don't seem to actually have a really ready yet.

The setup they are using is completely adequate for securing the privacy of communication between the user and Apple's server.

TFA describes how they eavesdropped on the communication between the user and Apple's server. Doesn't sound very secure to me.

I think you have missed my point. If the certificate is signed by some random authority it is "valid" but that only says that the authority (whoever that is) trusts the server. If the client did as it should (and what other Apple apps do), then it should check that the certificate is signed by a authority that it can check directly using the authority's public key built into the client.

That way it would be impossible to spoof the server and perform man-in-the-middle attack without either a) knowing the private key of Apple's signing authority (in which case Apple has bigger problems than people cracking Siri) or b) modifying the binary of the client application itself (always possible not matter what you do).

I just find it interesting that some applications do this properly, and others just seem to say "The cert looks legit to me, let's talk some secret stuff".

I have just done this. That exact text (as far as I can tell) is included in the text about 7/8ths of the way through.

So it looks like Apple is in the clear on this point.

TFA is actually pretty interesting:

As you know, the “S” in HTTPS stands for “secure” : all traffic between a client and an https server is ciphered. So we couldn’t read it using a sniffer. In that case, the simplest solution is to fake an HTTPS server, use a fake DNS server, and see what the incoming requests are. Unfortunately, the people behind Siri did things right : they check that guzzoni’s certificate is valid, so you cannot fake it. Well they did check that it was valid, but thing is, you can add your own “root certificate”, which lets you mark any certificate you want as valid.

Some Apple software (parts of iTunes) goes further and checks that the certificate presented by the server is actually signed by Apple. If the Siri software did this then the server would be impossible to fake man-in-middle-wise without hacking the client itself. Just checking that the certificate is valid is pretty useless protection - any certificate could be valid, what you care about is whether the server is who it says it is.

When your company is circling the drain, and all your previous products don't cut it, then yes, you bet everything on something new, because if you don't, your out of the race anyways. This is what jobs did with OSX, and led to his other stuff.

MacOS was pretty crusty at that point, and Apple hadn't had a breakout product for years but the company was far from dead when Jobs came back. Apple still had a lot of money in the bank - any other company would have limped along for years and then sold itself to one of the giants. Jobs could have done that and been considered a success, but he chose not to.

The iPhone was the real turning point. A lot of people thought that there was no way that Apple could worm its way into the entrenched cell phone market, Apple did so by doing a complete endrun around the traditional telco channels. It could have easily gone sour.

You people talk Jobs up like he was the messiah or something, but he was just a businessman that truely, got lucky

Maybe, but he got lucky several times in a row. Perhaps he was just a good businessman, but there don't seem to be too many of them around.
 

What has always surprised me about Jobs is the amount of risk he was willing to take on. People forget what a huge leap it was to ditch everything that came before (including several up-and-coming products) and focus on OSX. The iPhone also represented a huge effort - a radical departure for Apple and radically different from other cell phones, if it hadn't been an immediate success Apple would only be a fraction of what it is today.

History is littered with the wreckage of companies that decided to change direction, diverting resources from existing customers to look for fresh fields. Apple somehow managed to do it several times to great success.

Another thing that strikes me about Apple is how old-fashioned the corporate culture seems to be (from the outside). They do business by figuring out what people want, and then selling it directly to the public with a minimum of fuss at a price that both parties can live with. Contrast this with their competitors in the computer and cell phone markets, who sell pretty much the same devices encumbered with "special offers", "free malware detection (for 30 days)", or annoying contracts, none of which customers actually desire. I can't see why other manufacturers haven't gotten the hint yet.

And you'll find that applets are slow because the Java plugin distributed and maintained by Sun/Oracle doesn't use any kind of preloading as far as I can see. Who knows if Dart is better in this regard, but Java is it's own worst enemy when it comes to startup times. It is a shame, because I like almost everything else about it.

You an not wrong, but are missing the point. Java conceded the desktop to other technologies not because it was an inferior language (I find that even the much-maligned Swing produces very nice UIs) but because it took an age to start, making it unacceptable for any kind of in-browser use.

Oh please,

Java (or more correctly; its user base) has been crying out for some sort of faster startup since the mid 90s. No other problem has done more to keep Java off the desktop that the very slow startup times. If Java applets started as quickly as Flash objects manage to then we would still be seeing Java implemented on major web sites. I could never understand why Java doesn't snapshot and cache a prelinked version of a class the first time it loads, if anything the JVM is getting slower - the demo Java Applets on my website take about as long to start up in 2011 as they did in 2000 but my computer is many times faster.