Hacker News new | ask | show | jobs
by CaptainZapp 5770 days ago
I don't think it's the technical obstacles that much, then the principle of the thing. And I can't say I disagree with it.

The GIF fiasco illustrated very visibly what cans of worms can be opened when propriatary, patented technologies undermine open standards.

I tend to agree with the author that it's more of a pr coup then anything else.

2 comments

Actually, there are also technical obstacles.

The first time there is an exploit in system-provided video decoder (any decoder, not just H.264), you can be sure, who will get blamed for that - the browser, of course. So any browser maker wants to make sure, that they can update anything, that is being touched by web.

In case of Apple and Microsoft, they both can update the system provided H.264 decoder. In case of Opera, Mozilla and Google, they can not. This is one of reasons, why all three browsers bundle their own decoders (the another one is multi-platform consistency).

I am not sure if fear of being accused can be called a technical obstacle.
I think there's a certain irony in this. Isn't FOSS a big proponent of these sort of dependencies? I mean, whenever you discuss Windows or MacOS way of installing software, you'll hear how Linux does it better because each component is separate and therefore they can fix something upstream and your software will automatically use it.

But suddenly now people complain because a piece of software doesn't have control of their pieces...

How are these two views consistent?

(incidentally: I like the Linux's way, and try to replicate it as possible with Macport).

I think this has more to do with GNU/Unix design philosophy rather than being an explicit part of FLOSS ideology.

Also, you need to remember that GNU/Linux projects do have a certain amount of control over upstream, seeing as the source is publicly available and can be forked/modified. On the other hand, if Firefox relied on proprietary software, they would be completely at the mercy of decisions made upstream.

Do you think so little of the vendors that you believe they won't want to fix an error in a widely-used security-critical OS component?

Do you think so little of the ability of the Mozilla team to communicate on the details on a matter of platform security?

When programming anything, you have to decide what components you're going to depend on, and what you're going to write and maintain yourself. On a codec, or C library, or whatever.

And if there are issues with the foundation, then applications will have issues. Other applications will have issues, too.

And if you're rolling your own code for common tasks, there will still be issues. You'll all of them, too. And you'll have a much larger project.

> Do you think so little of the vendors that you believe they won't want to fix an error in a widely-used security-critical OS component?

Considering he never said that... no?

> Do you think so little of the ability of the Mozilla team to communicate on the details on a matter of platform security?

Pointless, that'll still get them blamed.

> And if you're rolling your own code for common tasks, there will still be issues. You'll all of them, too. And you'll have a much larger project.

You have a larger project but you control all the variables, or as many as you can anyway. And you can handle everything on your schedule, you don't have to depend on a third party which may or may not play ball with you (and may have absolutely no interest in playing ball).

> Pointless, that'll still get them blamed.

How are they doing now with Flash? Any record of users complaining with Firefox for a Flash bug?

> How are they doing now with Flash? Any record of users complaining with Firefox for a Flash bug?

Uh yes? Users complain about the browser when Flash crashes it, why do you think Firefox finally moved Flash to an external process, following the lead of Chrome and Safari (and MSIE?). Sure Flash having no 64b support plays a role, but it's not like most users realize it when Flash is involved in making their browser burst in flames or crawl to a halt.

Sorry, I meant security bug, not crashing in flames bug. :)

Often you hear of some security flaw in this or that program that requires Microsoft or Apple to patch the OS. When those happen, are people demanding a fix from Microsoft/Apple or Mozilla?

The first time there is an exploit in system-provided video decoder (any decoder, not just H.264), you can be sure, who will get blamed for that - the browser, of course.

Is this really the case? Aren't there security flaws in platform code all the time that affect browsers along with other apps on the platform? Are those blamed on a specific browser? If both Firefox and Safari use Mac OS X's built-in h.264 and there's a hole in it, is there going to be significant widespread outrage against Firefox?

Yes, few years ago, there was 'Haha, so Firefox is not so secure after all' bug in Windows 'shell:' protocol handler:

http://www.eweek.com/c/a/Security/Mozilla-Flaw-Lets-Links-Ru...

Err, I fail to see any bug in the in the Windows 'shell:' protocol handler. But other parts of the article indicate that the bug was in Firefox and was fixed in there.

>Current versions of Mozilla and Firefox pass unknown protocol handlers to the operating system shell to handle. In this case, the location passed to the shell is a program name that the shell executes.

>Internet Explorer is reported as being less vulnerable. When the user clicks on the link, it opens an "open/save" dialog box in which the user is allowed either to run the program, save it to disk or cancel. Mozilla and Firefox simply run the program without any further user action.

OS X and Windows have accelerated H.264 decoders that are available to programmers. Firefox is an application on each of these platforms. Firefox can use the native decoders like every other developer. They are already using a third-party's H.264 license (Adobe with Flash) to play this sort of video on many sites. I have a hard time seeing why using Flash is any different than using the built in.

For platforms that haven't paid the license, leave a plug-in way to do it and let others fill it just like they are letting Adobe do now.