Ten Fucking DaysMozilla can deploy a fix for any security bug reported under responsible disclosure in "Ten Fucking Days", according to Mike Shaver.

RSnake, the recipient of this claim written black on white over a business card, sounds quite skeptic.
But I can see it happening.

I've seen many security patches which couldn't wait (i.e. cats out of the bag), being developed and reviewed in 3-4 days.
In a famous recent case, even in 2 days.
Counting the Q/A needed before deploying an automatic update, 10 days is a feasible goal.

The key word here is can't wait: responsible disclosure, according to some schools of thought at least, may weaken the "can't wait" perception, and the management of other bugs in the past may be seen as supporting this theory.

We'll see if Window Snyder is going to seize all the business cards from Shaver's pockets, or if "a certain someone will be working remotely from an undisclosed location for a few weeks".

But this public statement, no matter how much bold, is a good thing, because I know Mozilla can really live to this promise.

Aug 6th Update:

It's official, Window Snyder didn't like the 10FD story.
Mozilla's new policies and restrictions over Mike Shaver's business cards have not been disclosed yet.

17 Responses to “Ten, they can! (if they want)”

  1. #1 Alan Baxter says:

    The link to Mike Shaver, http://hackademix.net/2007/08/03/ten-they-can-if-they-want/http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMike_Shaver , takes me to a 404 Not Found on Fx in safe-mode. Is that what you intended? Hope this long link doesn't mess up the formatting of my comment. Can I use BBCode or something like that in my comment? Sure wish I could preview it before submitting it. Hope this helps.

  2. #2 Giorgio says:

    Thanks Alan, the Shaver link (a Google, copy, paste and clean from Google tracking URL gone wild) is fixed now.
    Regarding the comments, I'm still not very into WordPress stuff, but I think something like bbcode or textile and a preview functionality would be great.
    TODO :)

  3. #3 Alan Baxter says:

    I don't think you're quite there yet. The link now is
    http://hackademix.net/2007/08/03/ten-they-can-if-they-want/http//en.wikipedia.org/wiki/Mike_Shaver , which takes me to the hackademix.net home page. I assume you intend it to be just http://en.wikipedia.org/wiki/Mike_Shaver . Right?

  4. #4 Giorgio says:

    thanks again, this must be the much troubled link in the internet.
    BTW, did you check if the new backgrounds play nice with your old 600Mhz CPU?

  5. #5 Alan Baxter says:

    Scrolling speed with the new backgrounds is still the same: one to two lines per second! (Cleared cache; three separate profiles including a clean one in safe-mode; using adblock only on the troublesome backgrounds.) Blocking the two overlays, black_overlay_50.png and black_overlay_50.png seems to eliminate the problem completely. I don't know why no one else notices any difference. Could it be that my seven year old video card doesn't have the features necessary to speed up that kind of graphics? 32MB ATI Rage 128 with updated drivers (no new drivers available in recent years, of course).

    I haven't checked it out in IE7 yet. Trying that now... !?!?!? The only thing that's displayed at all is the brick background. Internet zone with default security level. No more time to investigate now, but I've never run across this kind of a problem before.

  6. #6 Giorgio says:

    thank you very much for the IE7 report: it was a problem with sibling IE conditional comments that I couldn't spot otherwise, because I've got a side-by-side IE6+IE7 setup and conditional comments don't work reliably in this configuration.

    Regarding your scrolling woes, could you please retry one more time? I've just removed the "background-attachment: fixed" style from the original Royale theme. This was likely inflicting an over-taxation on the CPU, because it forces transparency recalculation on every scroll step, and I can surely live without it. Should this not suffice to fix your problem, a Gecko bug deserves to be filed, because pre-calculating transparencies for elements whose relative position doesn't change is a fairly obvious optimization.

  7. #7 Alan Baxter says:

    Scrolling performance has been restored to normal, thanks. I forgot to mention previously that my CPU was (and still is) pegged while scrolling. It just scrolls a lot faster now -- about the same as it does on other web sites. Also, IE7 seems[2] to be displaying correctly. IE7 has always scrolled a lot faster than Firefox. I suppose IE7 is able to take advantage of some Windows only performance optimizations because it's not cross platform. Firefox scrolling speed is adequate though, so I'm not complaining.[3]

    [1] I see you used HTML tags here. Let me see if the XHTML tags provided by the BBCode extension work too.
    [2] Forgive (or appreciate) the weasel word "seems", if you will. Comes from my testing background in which we would often say about a production system: "It appears not to be critically broken." We always thought that if we didn't find anything terribly wrong, then it might mean we weren't testing thoroughly.
    [3] It might streamline the process if you just emailed me whenever you start a new project. I seem to have a knack for finding issues. :P

  8. #8 Alan Baxter says:

    Well, I couldn't leave well enough alone. Went to http://hackademix.net in both Gran Paradiso 3.0a7 and Minefield nightly 20070812. Scrolling performance is poor on both of them: about five or six lines per second, as opposed to the relatively speedy scrolling of about 40 lines per second in Fx No extensions, default prefs. mozillazine.org scrolled at normal speed in all three, so it seems like there's something special about hackademix.net that slows things down in Fx 3.0. Advise please?

  9. #9 Alan Baxter says:

    Had time to try Adblocking some content. Turns out that it's necessary and sufficient to block the bricks_lf.jpg for GP 3.0a7 to scroll reasonably. Should I report this as a bug in bugzilla and/or the MozillaZine builds forum?

  10. #10 Giorgio says:

    Definitely worth a bug report in Mozilla's Bugzilla.
    Many thanks for your findings :)

  11. #11 Pfff says:

    No disclosure is responsible disclosure.

  12. #12 Alan Baxter says:

    I just reported this issue in the MozillaZine Builds forum. Since this might warrant a fix in Fx 3.0, please don't do anything on your end to make the problem go away. It's the only test case I have. If it comes to that, may I ask you for assistance in putting together a Bugzilla report with a minimal test case that isn't tied to a production web page?

  13. #13 Giorgio says:

    I'll keep this page as it is.
    Thanks for your continued commitment in making Firefox a better browser ;)

  14. #14 Alan Baxter says:

    Take a look at my MozillaZine Builds topic: http://forums.mozillazine.org/viewtopic.php?t=577463 . The problem goes away if the windows graphics hardware acceleration is turned down one notch for my seven year old ATI video card. Guess I can hardly call this a Firefox bug, although it is curious that it happens only in Fx 3.0

  15. #15 Giorgio says:

    That's not surprising at all, since Fx 3.0 uses a quite different graphic back-end than older series.

  16. #16 hackademix.net » Old NoScript Tricks Blocking New Vulnerabilities says:

    [...] bugs may live ten days only… A NoScript fix is forever [...]

  17. #17 japanese business cards says:

    Check out the Mozilla blog to find out what bugs exist and what fixes have been implemented, I'm so glad that Mozilla stays on top of the fire fox browser. That's more than I can say for the other guy; he's starting to look like, how he is portrayed in the Mac commercials

Bad Behavior has blocked 924 access attempts in the last 7 days.