Have you tried the POC? Ideally under a debugger? It's a null-dereference crash due to failure to check an allocation for out-of-memory conditions. It's not exploitable, as far as I can see. And it's not a stack buffer overflow, by any means.
It'd be nice if these various security advisory services actually double-checked milw0rm postings before echoing them. Half the ones I've seen are in fact crashes, but not the sort the poster claims and not exploitable....
> From the fact that in the last 160 years there was an explosion of copyrighted information > that is far more widely available, to more people, at a lower price, with more choice than > ever before in history?
This might have something to do with the fact that McCauley _won_ the debate and his position was adopted...
We've only been in the regime he was talking about for less than a decade, and the things he talked about are in fact coming true. Give it a few more decades....
Becuase Gears uses low-level binary hooks (e.g. completely replacing the Firefox HTTP cache with its own) and presumably doesn't want to worry about your browser crashing due to a code change on the Firefox end?
323// 0: no restrictions - divert everything 324// 1: don't divert window.open at all 325// 2: don't divert window.open with features 326 pref("browser.link.open_newwindow.restriction", 2);
"Smaller codebase" is usually a matter of programmer-perceived size (and hence reduced complexity). Compile time is a matter of generated code, so macros or templates will affect it to a great extent.
That said, a from-scratch Firefox compile takes 20-30 minutes on my machine (a year-old laptop). Should be faster on a desktop machine with a faster disk. That's on Mac or Linux. The Windows compiler is a bit slower (and generates better code), and Window build time is heavily affected by the slow cygwin disk acccess and the cost of forking all those make processes for all the directories. So build times are longer there.
In any case, last I checked a full-featured browser built on top of Webkit didn't compile any faster. And heck, it's not much less code by lines of code, either... The fact is, browsers do too much.:(
> Now, not only can it be a great little preschool computer for her, but it can also be used > online in a pinch.
I wouldn't use Gecko 1.3.x (which is what this is) online unless you're ok with the machine being exploited. Oh, and unless you're ok with a somewhat crappy user experience. Just for comparison, Firefox 1 shipped on top of Gecko 1.7....
On the other hand, the chance of exploits actually targeting Mac OS Classic is pretty low, I guess.
A thread approach has most of the same difficulties as a process approach without some of the (security, stability) benefits. Put another way, if one thread crashes, you lose.
It can also be _harder_ to write well-isolated shared-nothing code with the thread approach, since threads make it so easy to share state... and then you start running into synchronization, deadlock, and locking overhead issues.
> But the smaller, leaner, more approachable codebase goal?
Somewhat. It doesn't get blogged about much, and when it's blogged about the press doesn't pick it up because nitty-gritty arch work is boring. But there have in fact been significant simplifications to all sorts of stuff in the meantime...
The really ambitious "break compat and all" plan for Mozilla2 seems to have been somewhat abandoned for now, though.
It is if you use the Chrome approach of having all network access in the UI process and having locked-down renderer processes that can't touch the filesystem or network.
Re:Sounds like a few people are confused...
on
XHTML 2 Cancelled
·
· Score: 1
<DOCTYPE HTML>
And even that was only kept in for backwards-compatibility reasons: it's the shortest "doctype" needed to trigger standards mode in all current (non-HTML5-aware) browsers.
Thing is, the XML serialization doesn't really need a doctype (and never has; XHTML1 without the doctype is not conformant, but works just fine in any reasonable XML processor), and the non-XML one is no longer an SGML application, so a doctype doesn't actually make sense.
> XHTML has some great features, notably the ability to embed MathML and SVG in it
Here's an HTML5 snippet using the non-XML serialization that shows an "x squared" when parsed with the new HTML5 parser in Firefox:
x
2
I'm not sure how much more "embed MathML" you could get here...;)
If you wanted to put xmlns attributes on the and , with the XHTML and MathML namespaces respectively, you could use this snippet as either the XML or non-XML serialization, of course.
There is no "CSS3 spec". There is a whole bunch of separate specs all advancing along the REC track separately. They're at various stages of readiness.
For example, CSS Namespaces is in CR ("spec work done, implement it please"). It'll become a REC once there is a test suite and two interoperable implementations and the various paperwork involved in becoming a REC is done.
Selectors Level 3, CSS Color Level 3, CSS Multi-column layout are all in Last Call, with the next step being either CR or PR (PR is "this is done implemented and all; just needs sign-off from the W3C staff"). Same for Media Queries, CSS Basic User Interface, CSS Marquee Level 3, CSS Print Profile, etc.
Was there a particular part of "CSS3" you were interested in seeing specced and implemented?
Re:Sounds like a few people are confused...
on
XHTML 2 Cancelled
·
· Score: 1
> So, we should still be ensuring that all tags have matching close tags?
Only if you want to use the XML serialization.
> What will the document header be?
Not sure what this is asking.
> I have been told that making page uses XML compatible HTML makes for a more predictable > browsing experience and also lowers memory requirements.
Tossing in random "/>" has no such effect. Properly nesting your tags (i.e. avoiding ) most certainly helps reduce memory requirements.
With HTML5 the browsing experience will be predictable no matter what, since the parsing algorithm is fully specified. This means that any browser implementing HTML5 will parse documents the same way as any other browser implementing HTML5.
Re:Sounds like a few people are confused...
on
XHTML 2 Cancelled
·
· Score: 1
There are no SGML parts of HTML 5. It's not an SGML application at all.
And it doesn't break backwards compatibility. In fact, not breaking backwards compatibility is one of its key design goals (unlike XHTML2).
Not quite. While there are DSP-based H.264 decoders out there, there are also H.264 decoder ASICs, which implies someone is using them (and using lots of them, given the sunk costs of ASICs).
What do 32 bit libs have to do with this? You can install a 64-bit build of Firefox 3.5. It won't have the jit, but will have every single other feature 32-bit Firefox 3.5 has. So you're saying that a 64-bit Firefox 3.0 without jit _and_ without those other features is somehow preferable to a 64-bit Firefox 3.5 still without the jit but _with_ those other features.
> Google, Opera and Mozilla won't support anything that puts them at risk of needing to pay > royalties on the huge number of free downloads they give away.
That statement is hard to reconcile with the fact that Google is shipping H.264 support in chrome.
That discrepancy is easy to account for by noting that the MPEG-LA licensing terms for H.264 (see http://www.mpegla.com/avc/AVC_TermsSummary.pdf ) have a cap on royalty payments. Looking at the rates there, anything over 10 million shipping units is effectively a flat fee of $5 million. For this year, at least. It's not clear to me whether the cap applies across both parts (a) and (b) of the licensing agreement; if it does, then Google might hit the cap just due to the "2 cents (per view?) per youtube video longer than 12 minutes" bit.
Note that Opera has explicitly said that the licensing fee is why they're not implementing H.264 support.
Also note that Mozilla has explicitly said that while it can pay the licensing fee it's not clear whether the result would fall within the letter of the open-source licenses it wishes to use, and would clearly fall outside the spirit (in that the browser could not be redistributed by someone else without paying the same licensing fees).
I can't speak to Apple and Microsoft, though I think their patent concerns are valid at least in their minds. But I think you're reading a lot more into the actions of Google, Opera, Mozilla than is there (and reading some things in that are _definitely_ not there in the case of Google).
> I am sure it is possible without _too_ much work.
I should note that saying something like this is very dangerous unless you actually are a specialist... usually if something is not too much work, it's already been done.;)
> The W3C needs to ignore everyone and push forward with Ogg support in the spec
As much as I'd like Ogg Theora support all around, doing what you propose just leads to a useless spec (useless because implementors don't actually follow it, so you can't rely on using it).
> work with Nvidia and ATI and Intel, etc. to get h/w support for Ogg.
The issue is hardware support in the form of ASICs for decoding theora; none of the companies you mentioned are relevant to that. The hardware issue is on cell phones and the like, not desktops, in case you missed that.
The problem might be worked around somewhat by using DSPs and software decoding optimized for those DSPs, but that's not quite clear.
> my iRiver H10 mp3 player had Ogg support
Ogg Vorbis, not Ogg Theora. There's a huge difference in terms of computational complexity.
You seem to be somewhat confused about what Ogg is. It's just a container format. For a real life analogy, think shipping containers. They come in a small number of shapes and sizes, but each one can contain anything from lots of barbie dolls to lots of sewing needles to a single chunk of industrial machinery. Just because you have someone (say a toy store) who knows how to open a container and then sell the barbie dolls they find therein doesn't mean that person will be able to to open that same container and then make effective use of the industrial machinery or sewing needles inside. The situation with container formats and codecs is quite similar.
Actually, the right conclusion from such a pair of benchmarks is that "faster" is not an absolute and that which one is faster might just depend on the particular workload...
Then the question becomes which workload matters to you.;) Typically neither of the benchmark workloads really does.
Slashdot Mirror
Have you tried the POC? Ideally under a debugger? It's a null-dereference crash due to failure to check an allocation for out-of-memory conditions. It's not exploitable, as far as I can see. And it's not a stack buffer overflow, by any means.
It'd be nice if these various security advisory services actually double-checked milw0rm postings before echoing them. Half the ones I've seen are in fact crashes, but not the sort the poster claims and not exploitable....
> From the fact that in the last 160 years there was an explosion of copyrighted information
> that is far more widely available, to more people, at a lower price, with more choice than
> ever before in history?
This might have something to do with the fact that McCauley _won_ the debate and his position was adopted...
We've only been in the regime he was talking about for less than a decade, and the things he talked about are in fact coming true. Give it a few more decades....
Becuase Gears uses low-level binary hooks (e.g. completely replacing the Firefox HTTP cache with its own) and presumably doesn't want to worry about your browser crashing due to a code change on the Firefox end?
323 // 0: no restrictions - divert everything // 1: don't divert window.open at all // 2: don't divert window.open with features
324
325
326 pref("browser.link.open_newwindow.restriction", 2);
See http://hg.mozilla.org/mozilla-central/annotate/94909af358c4/browser/app/profile/firefox.js
"Smaller codebase" is usually a matter of programmer-perceived size (and hence reduced complexity). Compile time is a matter of generated code, so macros or templates will affect it to a great extent.
That said, a from-scratch Firefox compile takes 20-30 minutes on my machine (a year-old laptop). Should be faster on a desktop machine with a faster disk. That's on Mac or Linux. The Windows compiler is a bit slower (and generates better code), and Window build time is heavily affected by the slow cygwin disk acccess and the cost of forking all those make processes for all the directories. So build times are longer there.
In any case, last I checked a full-featured browser built on top of Webkit didn't compile any faster. And heck, it's not much less code by lines of code, either... The fact is, browsers do too much. :(
> Now, not only can it be a great little preschool computer for her, but it can also be used
> online in a pinch.
I wouldn't use Gecko 1.3.x (which is what this is) online unless you're ok with the machine being exploited. Oh, and unless you're ok with a somewhat crappy user experience. Just for comparison, Firefox 1 shipped on top of Gecko 1.7....
On the other hand, the chance of exploits actually targeting Mac OS Classic is pretty low, I guess.
A thread approach has most of the same difficulties as a process approach without some of the (security, stability) benefits. Put another way, if one thread crashes, you lose.
It can also be _harder_ to write well-isolated shared-nothing code with the thread approach, since threads make it so easy to share state... and then you start running into synchronization, deadlock, and locking overhead issues.
You've read up on Chrome's renderer sandbox, right?
> But the smaller, leaner, more approachable codebase goal?
Somewhat. It doesn't get blogged about much, and when it's blogged about the press doesn't pick it up because nitty-gritty arch work is boring. But there have in fact been significant simplifications to all sorts of stuff in the meantime...
The really ambitious "break compat and all" plan for Mozilla2 seems to have been somewhat abandoned for now, though.
> Remember, back then they were doing a complete code rewrite anyway.
The last "complete" rewrite of the relevant code was 10 years ago.
5+ years ago we're talking mostly UI changes, not changes to the core web page rendering code.
> Now with multiple processes is this the case.
It is if you use the Chrome approach of having all network access in the UI process and having locked-down renderer processes that can't touch the filesystem or network.
That worked really well in 1914!
<DOCTYPE HTML>
And even that was only kept in for backwards-compatibility reasons: it's the shortest "doctype" needed to trigger standards mode in all current (non-HTML5-aware) browsers.
Thing is, the XML serialization doesn't really need a doctype (and never has; XHTML1 without the doctype is not conformant, but works just fine in any reasonable XML processor), and the non-XML one is no longer an SGML application, so a doctype doesn't actually make sense.
> XHTML has some great features, notably the ability to embed MathML and SVG in it
Here's an HTML5 snippet using the non-XML serialization that shows an "x squared" when parsed with the new HTML5 parser in Firefox:
x
2
I'm not sure how much more "embed MathML" you could get here... ;)
If you wanted to put xmlns attributes on the and , with the XHTML and MathML namespaces respectively, you could use this snippet as either the XML or non-XML serialization, of course.
There is no "CSS3 spec". There is a whole bunch of separate specs all advancing along the REC track separately. They're at various stages of readiness.
For example, CSS Namespaces is in CR ("spec work done, implement it please"). It'll become a REC once there is a test suite and two interoperable implementations and the various paperwork involved in becoming a REC is done.
Selectors Level 3, CSS Color Level 3, CSS Multi-column layout are all in Last Call, with the next step being either CR or PR (PR is "this is done implemented and all; just needs sign-off from the W3C staff"). Same for Media Queries, CSS Basic User Interface, CSS Marquee Level 3, CSS Print Profile, etc.
Was there a particular part of "CSS3" you were interested in seeing specced and implemented?
> So, we should still be ensuring that all tags have matching close tags?
Only if you want to use the XML serialization.
> What will the document header be?
Not sure what this is asking.
> I have been told that making page uses XML compatible HTML makes for a more predictable
> browsing experience and also lowers memory requirements.
Tossing in random "/>" has no such effect. Properly nesting your tags (i.e. avoiding ) most certainly helps reduce memory requirements.
With HTML5 the browsing experience will be predictable no matter what, since the parsing algorithm is fully specified. This means that any browser implementing HTML5 will parse documents the same way as any other browser implementing HTML5.
There are no SGML parts of HTML 5. It's not an SGML application at all.
And it doesn't break backwards compatibility. In fact, not breaking backwards compatibility is one of its key design goals (unlike XHTML2).
> One interesting approach in the discussion linked to from TFS is to mandate
> "Theora OR H.264"
Yeah, I agree that would be a step up from the state of things.
> You mean like what they currently do for H.264?
Not quite. While there are DSP-based H.264 decoders out there, there are also H.264 decoder ASICs, which implies someone is using them (and using lots of them, given the sunk costs of ASICs).
What do 32 bit libs have to do with this? You can install a 64-bit build of Firefox 3.5. It won't have the jit, but will have every single other feature 32-bit Firefox 3.5 has. So you're saying that a 64-bit Firefox 3.0 without jit _and_ without those other features is somehow preferable to a 64-bit Firefox 3.5 still without the jit but _with_ those other features.
Again, what am I missing?
You might be interested in http://weblogs.mozillazine.org/roc/archives/2009/06/directshow_and.html
> Google, Opera and Mozilla won't support anything that puts them at risk of needing to pay
> royalties on the huge number of free downloads they give away.
That statement is hard to reconcile with the fact that Google is shipping H.264 support in chrome.
That discrepancy is easy to account for by noting that the MPEG-LA licensing terms for H.264 (see http://www.mpegla.com/avc/AVC_TermsSummary.pdf ) have a cap on royalty payments. Looking at the rates there, anything over 10 million shipping units is effectively a flat fee of $5 million. For this year, at least. It's not clear to me whether the cap applies across both parts (a) and (b) of the licensing agreement; if it does, then Google might hit the cap just due to the "2 cents (per view?) per youtube video longer than 12 minutes" bit.
Note that Opera has explicitly said that the licensing fee is why they're not implementing H.264 support.
Also note that Mozilla has explicitly said that while it can pay the licensing fee it's not clear whether the result would fall within the letter of the open-source licenses it wishes to use, and would clearly fall outside the spirit (in that the browser could not be redistributed by someone else without paying the same licensing fees).
I can't speak to Apple and Microsoft, though I think their patent concerns are valid at least in their minds. But I think you're reading a lot more into the actions of Google, Opera, Mozilla than is there (and reading some things in that are _definitely_ not there in the case of Google).
> I am sure it is possible without _too_ much work.
I should note that saying something like this is very dangerous unless you actually are a specialist... usually if something is not too much work, it's already been done. ;)
> The W3C needs to ignore everyone and push forward with Ogg support in the spec
As much as I'd like Ogg Theora support all around, doing what you propose just leads to a useless spec (useless because implementors don't actually follow it, so you can't rely on using it).
> work with Nvidia and ATI and Intel, etc. to get h/w support for Ogg.
The issue is hardware support in the form of ASICs for decoding theora; none of the companies you mentioned are relevant to that. The hardware issue is on cell phones and the like, not desktops, in case you missed that.
The problem might be worked around somewhat by using DSPs and software decoding optimized for those DSPs, but that's not quite clear.
> my iRiver H10 mp3 player had Ogg support
Ogg Vorbis, not Ogg Theora. There's a huge difference in terms of computational complexity.
You seem to be somewhat confused about what Ogg is. It's just a container format. For a real life analogy, think shipping containers. They come in a small number of shapes and sizes, but each one can contain anything from lots of barbie dolls to lots of sewing needles to a single chunk of industrial machinery. Just because you have someone (say a toy store) who knows how to open a container and then sell the barbie dolls they find therein doesn't mean that person will be able to to open that same container and then make effective use of the industrial machinery or sewing needles inside. The situation with container formats and codecs is quite similar.
Actually, the right conclusion from such a pair of benchmarks is that "faster" is not an absolute and that which one is faster might just depend on the particular workload...
Then the question becomes which workload matters to you. ;) Typically neither of the benchmark workloads really does.