This goes for all social networks (including Slashdot) but I will use Facebook as an example:

You do not have a FaceBook page.

No you don't.

Facebook has a page on you, which you update for them for free. You are a product that Facebook produces for its customers. The customers of Facebook are the advertisers, not you. This is not necessarily a bad deal for you. You get to show people Facebook's page about you, and derive pleasure from interacting with Facebook's pages about your friends. All for free.

But don't get upset when Facebook decides to improve things for its customers, because they can (and should) put them first. Facebook owes you nothing.

Regulating social networks seems like an exercise in frustration. What counts as a social network? Does my blog count? Do I need to let users download all their comments in an "industry standard format"? Do MMO's count? Can I download my +5 firesword?

Sometimes I wish Slashdot would let me download my mod points in an open format and use them on another web site. I have some Facebook posts in mind that need down-modding.

That NASA link is 50 times as interesting as this lame story. Thanks.

Exactly right. I have noticed a huge upswing of probing behavior in my Wordpress site logs, all targeting timthumb in various common themes. Wordpress is easy to install (and easy to upgrade) but requires ongoing upkeep as vulnerabilities are found and patched. Too many people just install it and let it rot.

With Roulette you don't need to predict very well to get an edge on the house. Even you if can fairly consistently guess which quarter of the wheel the ball will land in, you can shift the odds well into your favor over the long run. That's what the "cheaters" with electronic aids were doing.

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.