Slashdot Mirror

You need to get the word on this out there

Shaver just published a blog post on this.

Strangely enough, Flash manages in a free product.

Mozilla could afford the licensing fees, but they don't wish to. They can't pass on their license to other Mozilla partners like linux distros who build their own packages, and think it's worth either the monetary cost or the cost to the ecosystem.

http://shaver.off.net/diary/2010/01/23/html5-video-and-codecs/

They estimate it would cost $5mil, and they had revenues of $104 mil in 2009. They could afford it if they deemed it necessary.
http://www.mozilla.org/foundation/annualreport/2009/sustainability.html

BTW, I think Mozilla, opera, and now Google did the right thing for the web ecosystem, as I have the mid-term view in mind. I just think it's worth examining the likely outcome in the short term and long term also..

> after H.264 became eternally free for streaming

Except it didn't, except in some limited cases. Please read http://shaver.off.net/diary/2010/08/27/free-as-in-smokescreen/

Mozilla can use AVC/H.264. They just need to do it via the OS, like I think IE and Safari will do, and Opera already does. H.264 is already directly supported on Windows 7 and Mac OSX. Linux users need to do their tricks, like with MP3.

They only way they can do as you suggest is by severely compromising Firefox. This has been answered exhaustively many times. See Mike Shaver's blog post about it. To quote:

People have raised questions about using existing support for H.264 (or other formats) that may already be installed on the user’s computer. There are issues there related to principle (fragmentation of format under the guise of standardized HTML), to effectiveness (about 60% of our users are on Windows XP, which provides no H.264 codec), to security (exposure of arbitrary codecs to hostile content), and to user experience (mapping the full and growing capabilities of to the system APIs provided); I’ll post next week about those in more detail, if others don’t beat me to it.

Security is not to be underestimated. It's worth noting that IE9 will not support all media formats supported on the host operating system, purely to limit the attack vector surface area available. See this comment by Microsoft's Frank Olivier on the IE blog. He's talking about image formats but the same applies to video formats:

We've not heard many requests for additional image types - to limit the attack surface in a web browser, it is a good idea to not expose more decoders.

See also Chris Blizzard's blog post about the decision to only support open video in Firefox. And most importantly of all, don't worry about. Open video is the way forward for video on the web. Theora is here now, VP8 may be joining it next month, and Dirac may join both in the future.

Mike Shaver has posted a blog explaining that they are unblocking the Microsoft code because Microsoft has clarified their advisory.

BTW, I don't assume you lie, it's just that your argument doesn't make sense to me as you worded it. And in your own blog you state that "Microsoft is recommending that all users disable the add-on." From everything I've read from Microsoft this is an overstatement. They advised disabling the add-on as a mitigation mechanism for those who had not applied the patch.

It's not exactly a squabble. MS green-lighted the addon being blocked. See http://shaver.off.net/diary/2009/10/16/net-framework-assistant-blocked-to-disarm-security-vulnerability/

Urgh, I hate these links to useless tech news websites, rather than the original sources. To see what the Mozilla executives in question actually had to say, with their words in context, read Mitchell Baker: Browser Soup and Chrome Frame and Mike Shaver: thoughts on chrome frame.

And as a bonus, from a Mozilla-technology using developer (I don't think he's affiliated with Mozilla in any official capacity anymore) Daniel Glazman: Google Chrome Frame.

one doesn't control the fsync behavior of every application running on his/her system

Users can choose applications that properly sync, or in the case of free software, they can put fflush(fp); fsync(fileno(fp)); in strategic places and recompile. Braidwood, which appears to implement a nonvolatile ring buffer for writes, should make it less painful for application developers to sync when appropriate.

By the way that was a sloppy application coding problem

That, and the fact that fsync() doesn't provide any sort of reasonable performance guarantees. Some of the slowdowns of Firefox 3.x on netbooks are due to an SQLite COMMIT (which calls fsync()) taking several seconds to flush writes to a cheap HDD or cheap SSD. That's one thing this Braidwood chip is intended to correct.

1. you still lose your settings under ext3 which "bad code" does not
2. this relies on sane behavior of the OS, no standards required.
3. http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/

...I think you can see where this is going: if thereâ(TM)s a lot of data waiting to be written to disk, and Firefoxâ(TM)s (sqliteâ(TM)s) request to flush the data for one file actually sends all that data out, we could be waiting for a while. Worse, all the other applications that are writing data may end up waiting for it to complete as well. In artificial, but not entirely impossible, test conditions, those delays can be 30 seconds or more. That experience, to coin a phrase, kinda sucks...

its safe to assume your software will be running on systems that run ext3 or rieser4, so slowing down most peoples systems for the benifit of ext4 users will NOT be appreciated!

fsync_then_rename()

this is not needed and a terrible idea. Operations on a file should take place in the order they were committed (i dont care if you commit files out of order but each file should be dealt with correctly (and preferably minimally)) or do you want an rename_then_fsync , fsync_then_delete ... commands for every single in/plausible situation?

Shaver posted on The Missed Opportunity of Acid3.

Could Firefox's fsync() problem be related?

http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/

RC2 fixes the really annoying bug 421482 (Firefox 3 uses fsync excessively) which however is arguably not Firefox 3's fault.

I've switched to FF3 Beta 4 on my home computer and have been amazed at the difference. It used to reach 500 MB in memory usage on FF2, but now tops out at just over 100 MB despite me using many more tabs that I previously would have in order to try and stretch it.

That raises the question of how "open" is, say, Firefox, if it always installs Adobe's Flash player for [flash mimetypes]

Firefox doesn't associate flash mimetypes with the Adobe Flash plugin, Flash installs itself to Firefox. Besides, if there's any doubt to who's pushing for Flash/Flex/AIR adoption, you can be confident that it's the Mozilla guys least of all.

That blog post wasn't alarming. Or at least, maybe that one was, but try this one, which says a similar sort of thing, but makes its case at greater length, and, well, generally better.

In fact, if you compare and contrast this quote:

With this story from the same day, then you get a sense that maybe the Mozilla guys aren't so clueless on this topic as you suggest...

Of course, don't get me wrong, I'm not literally suggesting that the Safari guys were so busy getting to 100/100 they directly introduced that security bug as a result of one of the acid3 fixes. (I know the dates don't work out, for starters).

What I am saying, is that were Mozilla saying "fuck acid3", that's alarming. But when they're actually saying things more like the "only add these fixes with thorough QA", above, or

[acid3 tests] should be fair to the web; they should be based on how good the web will be as a platform if all browsers conform...

We will fix standards compliance bugs; it's what we do. But we won't fix them all with the same priority, and I hope that we won't prioritize Acid 3 fixes artificially highly, because I think that would be a disservice to web developers and users.

Then it's not exactly random attention-seeking as much as carefully and broadly considered development strategy.

All that said, I still completely agree that this new address bar and "blurring the edges" talk is hovering somewhere between stark raving bonkers and epic fail.

Why should they, and does it really indicate a deprioritization of standards? Sure, standards support is good, but rushing to release the sort of major changes required to pass Acid2 or Acid3 is a really bad idea. (There's this little issue called regressions - you may have heard of them.) Also, I get the impression the Firefox devs don't think much of Acid3 in general. It looks like they've still fixed some of the issues, particularly the ones that are obvious bugs or may affect other sites, but deferred the rest.

(Also, bits of the test are either obscure, test stuff that's depreciated and essentially unused, or just plain insane.)

No, there is no problem, as others here point out here and Mozilla developers confirm.

As for memory leaks, Mozilla developers have always acknowledged that there are memory leaks in Firefox, as there certainly are in all browsers. The thing is that it simply doesn't do any good to ask for "the memory leak to be fixed," as there is no one memory leak to fix. If you want a bug fixed, you should be prepared to demonstrate exactly which bug you are referring to (generally with a set of steps to reproduce the problem) so your request is not meaningless.

>all.js is *not* user data, it's *public* app data. Your preferences are stored in prefs.js which are not exposed by greprefs.

A firefox developer agrees with the above poster (or possibly since its anonymous could BE the above poster difficult to tell ;-).
http://shaver.off.net/diary/2008/02/10/view-sourceresource-vulnerability-does-not-expose-personal-information/

http://en.wikipedia.org/wiki/Mike_Shaver

And he's already explained how his comment got out of hand and what he really meant by it.

Eh,

http://www.quagga.net/
http://off.net/~jme/vrrpd/
http://sourceforge.net/projects/vrrpd/


To bored to finish feeding you today...

This vulnerability doesn't cause the payload to not be encrypted, it's a means of figuring out how to decrypt them without knowing the key.

Of course, the whole thing relies on you having message authentication (hmac-md5 or hmac-sha1) off. Something which was already known to be a bad idea.

With authentication off, someone can twiddle bits in the packet (without knowing their original state, but they can predictably flip a specific bit). From that, you look at the reply. If you do this enough times to fields that have predicable behavior, such as the TCP sequence number, you can gather enough information to figure out the encryption state and decrypt some of the packets in the stream.

To me, this whole thing is a gigantic "DUH". Almost crypto protocol which doesn't have good integrity protection is likely to be attacked this way. It's been done dozens of times.

Weaknesses using CRC32 as a cryptographically secure integrity check is how the classic SSH crc-compensation attack worked:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999 -1085

Lack of integrity is part of why VTUN is considered insecure to the point of being broken:
http://off.net/~jme/vtun_secu.html

This kind of attack is blatantly obvious. It's been written about many times and demonstrated against many different protocols in the past. It's why nearly every book on IPSEC I've seen warns that if you don't use a MAC, someone will break your crypto.

The only difference is that before it was a obvious theoretical weakness. Now it's one that's been demonstrated in practical application.

Oops .. I meant to point here for Mike Shaver's initial reaction to the ZDNet article, which was to echo the comments of Christopher Blizzard, another Mozilla developer who took issue with the article.

Clear? Good.

It should be noted that Mike Shaver's (formerly of Netscape, still of Mozilla) comments were, as he points out, taken horribly out of context in the ZDNet article.