Your comment leads me to believe you've never done any significant software development work. Consider that the Acid3 test was released at the tail end of the Gecko development cycle. This puts Mozilla in a bad position, because they were already at feature freeze and didn't want to further delay the final release. So, shooting for Acid3 compliance at this point would be the height of stupidity.
The Acid3 test is also a bit controversial in its own right. Acid1 and Acid2 addressed broad compatibility with several core web standards, without regard for any particular browser. In contrast, Acid3 covers an odd mix of quirks chosen to intentionally highlight bugs in different browsers. Acid3 also includes a random mix of features from things like SMIL and SVG, which are enormously complex standards not supported in their entirety by any major browser. That also means that Acid3 can be gamed by simply implementing just enough of a feature to pass the test, but not enough to be genuinely useful in practice.
Simply put, Acid3 is a much less useful test than the previous versions. I have no doubt that Mozilla will eventually pass, but they won't delay the Firefox 3.0 release and have made it clear that they won't play the partial implementation game to beat the test.
Sorry, but you're wrong. A typical Win32 application has maximum address space of 2GB, regardless of available swap. This is by far the most common scenario. Another poster mentioned that you must also consider the largest available chunk of contiguous memory, which is almost always smaller. In practice, I haven't seen most real-world applications successfully allocate more than 1GB of contiguous memory after they've been running for a little while.
The next thing you need to understand is how to get a value larger than the allocation cap. Many applications simply accept an unbounded length for some fields, which presents no barrier. If there is a bound, there are still a variety of ways to cause a failure. For example, in a browser you can use JavaScript operations to fragment the memory until the target size is no longer available. You also need to look at how a value is used after it's accepted. In the case of this particular vulnerability, the bound is defeated by later operations that result in a large integer. If you're not familiar with these types of arithmetic vulnerabilities I suggest you take a look at the sample chapter from Dowd's book: http://www.awprofessional.com/content/images/0321444426/samplechapter/Dowd_ch06.pdf
Regardless, it's often quite easy to force an allocation failure.
I don't think that it has much at all on automating the workflow, which makes sense to me. Tools and fuzzers are changing so fast that they aren't well served by books. I already have a few books on those topics, and they've all grown stale within a year or two.
The books that I keep around for a long time are the ones that really cover the essentials. I put this book in that category because it explains vulnerabilities more clearly and thoroughly than anything else out there. And it lays out all the process and tricks for finding security bugs. That's the kind of stuff that will be relevant for years.
It's news because it's a general method for code execution from a common class of NULL pointer dereferences. He turned something that most people consider a crash bug into a code execution bug. Here's a simpler example from Dowd's blog: http://taossa.com/index.php/2007/04/15/bored-games/
The other reason why it's news is that his method for exploiting Flash in this case is technically brilliant. I can understand if you don't appreciate it, but any security people out there are just overwhelmed.
It's not a salt, it's just an artifact of how the Flash VM operates. There's a year-old post on Dowd's blog with a much simpler example of the same class of vulnerability: http://taossa.com/index.php/2007/04/15/bored-games/
Basically, the vulnerability occurs when you can write to an arbitrary offset from NULL. This is probably a common enough mistake that no one has been looking for because NULL derefs are usually just a crash bug. What Dowd has shown is that with a little application knowledge, and control of the deref value, you can make this type of bug into a perfectly reliable exploit that is unaffected by application hardening like stack canaries and heap checking.
Yeah, that book has become bible on vulnerability research. There's really nothing else comparable if you want to understand how vulnerabilities work, and how to find them. The odd thing is that it's style is more directed at programmers than security people.
Point taken. I should have more appropriately phrased it as "I think you're understating the pervasive reality of implementation flaws." Sorry, I tend to jump into this battle swinging because I regularly deal with development teams that think security was finished in the design phase. As such, they don't see the need to write secure code or perform code reviews. It's my biggest professional headache, and seems to be the prevailing attitude across the industry. Until that view changes, we're not going to see a large-scale improvement in the state of software security.
You're completely ignoring the reality of implementation flaws. Unfortunately, you fit in with the majority of the industry. I suggest you pick up a copy of Mark Dowd's "The Art of Software Security Assessment". It's 1100 pages exploring implementation flaws in real code (from a guy who's cracked everything from OpenSSH to Sendmail and MS Exchange). That's the stuff that programmers need to learn if they want to stop writing swiss cheese code, but instead they just claim that their encryption protocols solve everything. Yeah, secure protocols and design are necessary, but a bad implementation will beat you every time.
I never used the term "trojan." That stated, I did mention supplying a file containing an exploit directed at the handling application. You can call that a trojan if it makes you happy.
Uh, no. First off, null sessions have never granted the rights necessary to execute a remote shell (unless paired with an exploit). You need admin rights to kick off an exe via the SCM or scheduler. If you have that access already, copying a file is a foregone conclusion because you can just open a share.
Of course, all of that assumes you have Netbios connectivity... over the Internet. That may have been plausible 5 years ago (probably more more), but someone in between will be blocking it these days. On top of that, current Windows XP and better have a lot more restrictions on Netbios traffic, in particular disabling the default null sessions.
One final point: This scenario is actually quite reasonable if you assume they're exploiting an application on the attacker's system. There's likely to be exploits against the trojan itself if the binary is available for analysis, or if you can identify exploitable bugs in code shared between the client and server components. There's also the possibility of attacking any services he exposes, or perhaps file parser attacks against whatever he uses to read the content he nabbed. The details of such a counterattack are more complex, but well within the realm of reason.
That's my big fear also. It's too likely that this is just more pork for someone like EDS or Eagle Alliance. On the off chance it's done correctly, however, I can't think of a better agency to handle it.
I'm not sure what exactly you mean. The SID half of NSA is the hub of the signals intelligence and information operations mission for the DoD. Ft Meade houses the SigInt and IO hub for every branch of service, including the 704th Military Intelligence Brigade, Naval Network Warfare Command, 694th Intelligence Group, and Marine Cryptologic Support Battalion (never ignore the Marines). Then you have the RSOCs and field sites, which are pretty much all military installations, receiving their tasking from and reporting back to the Fort. This always seemed like a pretty standard military structure to me.
The IAD half of NSA is a bit more like you say in that they do function as a service provider, security standards designator, and training institution. However, the SigInt mission accounts for a lot more in the realm of attack monitoring and analysis than I expect you are aware of. Either way, they're still a major component of DoD's information security capabilities. The NSA regularly assesses the security of DoD networks by supporting IG inspections or via organizations like the Red and Blue teams. They are also constantly participating in exercises and training scenarios, such as the Eligible Receiver exercises.
Now, your stance may be based on the fact that DirNSA reports to both the SecDef and the DNI, meaning he has one master outside the DoD. That (and the CIA's existence outside the DoD) is probably the major contributing factor to the creation of DISA in 1960. As the cold war spun up the uniformed services wanted an intelligence agency they could task independently, so they made their own. However, the creation of the NSA/CSS in 1972 added some pretty concrete guarantees to the role of uniformed services, and integrated the NSA more closely into the rest of the DoD.
Basically, I would agree with your position if it was narrowed to IAD and included in some extra caveats concerning training, exercises, and external monitoring. However, your statements certainly don't apply to NSA as a whole.
They aren't a DOD agency in the normal sense. They have a flag officer, but they are outside of DOD for all intents and purposes. The DOD already has a joint network protection group (JTF-GNO) and they are monitoring and protecting their networks across the three branches fairly well now. NSA provides input and expertise, but they aren't doing any of the actual work.
Wow, someone should really tell that to the half of the NSA in the Information Assurance Directorate, not to mention the military units that comprise roughly 50% of the agency's staff. Because your comment makes me think they're really confused about who they are and what their mission is.
Congrats on being the first (and so far only) person to get this right; the only thing missing is dates. In my opinion, the dates show parallels between 2K -> XP and Vista -> Windows 7. There was about a year and a half between 2K and XP releases, with XP initially just adding polish and tweaks to smooth out the major architectural changes of 2K. It also gave time for a compatible driver base to get established. In the end this resulted in much better uptake for XP than 2K. Maybe they're shooting for a similar scenario.
I use Understand on a daily basis to review other people's code. It does have it's quirks (mainly on really big codebases), but I haven't found anything that works better. And while it isn't cheap, there is a free one-month trial version.
OSX drivers are built on IOKit, so porting would be a non-trivial task (even more so for associated userland utilities). Plus you need to consider the reality that while Linux and BSD have very broad device support, the quality of individual drivers is a mixed bag. Some are great, some are barely functional, and many are experimental.
I also think you're underestimating the support impact of third party drivers. MS has posted statistics from Watson reports showing that the majority of blue-screens are the result of third-party drivers. However MS still gets the blame because it's their OS that crashed. Of course, their bull-headed response is to move Vista to signed-only drivers, which I don't agree with but does show how seriously they take this issue.
So, consider the above and think about how commodity hardware support would affect Apple's nicely polished, "just works" image. Simply put, it would kill that notion and put them in exactly the same situation as MS (which you already implied in your post). They really don't want to be there, and have good reason not to.
In summary, I do agree that Apple could potentially get a leg up using the BSD codebase, but they'd still need invest tremendous effort and jeopardize their current strategy and consumer base. Personally, I think Apple is making the smart choice for now by avoiding those risks, and the market seems to agree. Mind you, it's what keeps me from buying a personal Mac, but I can't fault the logic behind their decision. Finally, none of this discounts the notion that at some point Apple should make the move to commodity hardware, but doing it now would be a bad business move.
You're dead-on, but you forgot to mention that they have no incentive whatsoever to incur the massive overhead of implementing support for the broad range of commodity hardware that Windows must run on. Their control of the hardware not only buys them a nice profit margin, it also drastically reduces their development QA costs.
For someone that's complaining about misinformation, you really need to stop spreading it yourself. The benchmark was written by a Webkit dev, not a Mozilla dev. Taking cheap shots at an innocent third party doesn't help anyone.
That stated, you have a completely valid point that the base64 benchmark is inaccurate. However, IE still has documented issues with string concatenations, which does account for weaker performance in string handling, just not the orders of magnitude difference that this test shows.
Either way, this benchmark is not a good indicator of real-world performance, as many people have pointed out. Most web sites are more bound by the DOM interactions and layout than anything else.
I'm forced to assume you have no knowledge of how a browser is implemented, otherwise you'd be aware that the tricks you do to optimize page load time have almost no effect on memory footprint.
For example, you may shrink an image by reducing the pallet and ramping up the compression, but when any application displays that image it must expand it to it's uncompressed form. So, even a 100x100 JPG shrunk down below 2k still must be expanded to 40k (dimensions x RGBA) in memory. Of course, a developer can reduce memory overhead by gaming exactly when the image data is uncompressed and how long it's cached, but that almost always means sacrificing speed and responsiveness.
The image decompression is a really obvious example and pretty much applies to all compressed data, but everything else in the browser tends to expand in a similar manner. HTML parsing involves representing all the objects in a DOM tree, and each DOM node contains quite a bit of essential metadata making it much larger larger than just the associated file text. Then presentation requires building the layout structures for each element and rendering the result. Once again the developer can game expansion and caching, but the trade-offs don't change.
And then there's JavaScript, which has just as much parsing and interpretation overhead as HTML, but is a full-fledged programming language. I'm sure I don't have to explain how a few bytes of script code can easily consume arbitrary amounts of memory through object instantiation, looping, and recursion.
So, we're not even getting into things like cyclic references and fragmentation, but hopefully this is enough to clue you in on why page load size can have very little relation to actual memory consumption. If you want more detail I suggest grabbing the source for Firefox and reading the code (or look at Konqueror, which is bit less painful to follow). That's about the only way to really get a sense of how complex a modern browser is. Of course, you'd better come armed with a strong foundation in C/C++ and system-level programming.
They never specified Ogg as a requirement. They made it a recommendation but not to the exclusion of other formats. Realistically, if you don't give a concrete recommendation in the standard we'll be waiting for years while companies push different incompatible formats that fit their separate agendas. How does that make things any better than they are now?
Color and mouse precision? That's a load of crap. Macs have no technical advantage over PC's for graphics work. It's simply that Apple started courting designers early on and successfully won them for life. In fact, Adobe actually tried to dispel the common myth back in 2003 but the community still chooses to pay a 25% Mac tithe.
As a case in point, my wife works in Chicago as a graphic designer primarily on print media. At work she uses a Mac, along with her designer coworkers and friends from art school (and at SAIC Apple's hooks were so deep they only supported Macs). However, at home she uses a PC and actually prefers CS on the PC because all the menu commands have keyboard shortcuts. She does have some occasional headaches with font assignment when switching files back and forth, but that's the only issue. As for web design, she freelances some of that on the side, and has worked with a mix of PC and Mac groups, but they usually lean more toward the PC.
I suppose I should more accurately state that (as I understand it) Blu-Ray is encumbered with a variety of patents (owned by Sony and its Blu-Ray partners) on the technologies involved in both the players and disc manufacturing. These patents must be licensed in addition to fees for use of logos and access to specifications documents (which both Blu-Ray and HD-DVD have). As it was explained to me, HD-DVD is not encumbered with the same patent licensing issues. That, along with its basis in existing DVD manufacturing methods, are why HD-DVD is so much cheaper while both format's technical capabilities are essentially the same (excluding Blu-Ray's higher capacity per layer and HD-DVD's higher baseline requirements).
Also, I have to admit that I'm not particularly close to the issue myself. My viewpoint is based entirely on conversations with a friend working as an engineer in the industry.
Yes, how deliciously evil for Microsoft to be buying support for an open and public standard (HD-DVD) versus a proprietary format tied to expensive licensing fees and Sony's whims (Blu-Ray). So deliciously... Wait, I think I lost the evil somewhere.
Seriously though, I think Michael Bay is just a wacko who's bought into way too much industry punditry. If his directing is any clue, he was probably fed some absurd story with a heavy reliance on pseudo-science fantasy and unrealistic motivations for all involved parties. That, and some really top-notch special effects.
Uh, attack trees are one of several techniques used in threat modeling. And the whole point of the exercise is to identify the security aspects of a system. That means understanding the trust relationships, attack surface, and associated threats. So, the threat model should be helping you identify if the lock on the front door really helps or if there's a big gaping hole in the wall next to it.
That said, a threat model isn't a panacea. It doesn't replace good coding practices, code reviews, testing, or anything else. But it can help show the big picture and prioritize security efforts.
Slashdot Mirror
Your comment leads me to believe you've never done any significant software development work. Consider that the Acid3 test was released at the tail end of the Gecko development cycle. This puts Mozilla in a bad position, because they were already at feature freeze and didn't want to further delay the final release. So, shooting for Acid3 compliance at this point would be the height of stupidity.
The Acid3 test is also a bit controversial in its own right. Acid1 and Acid2 addressed broad compatibility with several core web standards, without regard for any particular browser. In contrast, Acid3 covers an odd mix of quirks chosen to intentionally highlight bugs in different browsers. Acid3 also includes a random mix of features from things like SMIL and SVG, which are enormously complex standards not supported in their entirety by any major browser. That also means that Acid3 can be gamed by simply implementing just enough of a feature to pass the test, but not enough to be genuinely useful in practice.
Simply put, Acid3 is a much less useful test than the previous versions. I have no doubt that Mozilla will eventually pass, but they won't delay the Firefox 3.0 release and have made it clear that they won't play the partial implementation game to beat the test.
Sorry, but you're wrong. A typical Win32 application has maximum address space of 2GB, regardless of available swap. This is by far the most common scenario. Another poster mentioned that you must also consider the largest available chunk of contiguous memory, which is almost always smaller. In practice, I haven't seen most real-world applications successfully allocate more than 1GB of contiguous memory after they've been running for a little while.
The next thing you need to understand is how to get a value larger than the allocation cap. Many applications simply accept an unbounded length for some fields, which presents no barrier. If there is a bound, there are still a variety of ways to cause a failure. For example, in a browser you can use JavaScript operations to fragment the memory until the target size is no longer available. You also need to look at how a value is used after it's accepted. In the case of this particular vulnerability, the bound is defeated by later operations that result in a large integer. If you're not familiar with these types of arithmetic vulnerabilities I suggest you take a look at the sample chapter from Dowd's book: http://www.awprofessional.com/content/images/0321444426/samplechapter/Dowd_ch06.pdf
Regardless, it's often quite easy to force an allocation failure.
I don't think that it has much at all on automating the workflow, which makes sense to me. Tools and fuzzers are changing so fast that they aren't well served by books. I already have a few books on those topics, and they've all grown stale within a year or two.
The books that I keep around for a long time are the ones that really cover the essentials. I put this book in that category because it explains vulnerabilities more clearly and thoroughly than anything else out there. And it lays out all the process and tricks for finding security bugs. That's the kind of stuff that will be relevant for years.
Yes, thank Tom Ptacek, the Hagrid of the security world. And I state that with nothing but respect for Tom.
It's news because it's a general method for code execution from a common class of NULL pointer dereferences. He turned something that most people consider a crash bug into a code execution bug. Here's a simpler example from Dowd's blog: http://taossa.com/index.php/2007/04/15/bored-games/
The other reason why it's news is that his method for exploiting Flash in this case is technically brilliant. I can understand if you don't appreciate it, but any security people out there are just overwhelmed.
It's not a salt, it's just an artifact of how the Flash VM operates. There's a year-old post on Dowd's blog with a much simpler example of the same class of vulnerability: http://taossa.com/index.php/2007/04/15/bored-games/
Basically, the vulnerability occurs when you can write to an arbitrary offset from NULL. This is probably a common enough mistake that no one has been looking for because NULL derefs are usually just a crash bug. What Dowd has shown is that with a little application knowledge, and control of the deref value, you can make this type of bug into a perfectly reliable exploit that is unaffected by application hardening like stack canaries and heap checking.
Yeah, that book has become bible on vulnerability research. There's really nothing else comparable if you want to understand how vulnerabilities work, and how to find them. The odd thing is that it's style is more directed at programmers than security people.
Point taken. I should have more appropriately phrased it as "I think you're understating the pervasive reality of implementation flaws." Sorry, I tend to jump into this battle swinging because I regularly deal with development teams that think security was finished in the design phase. As such, they don't see the need to write secure code or perform code reviews. It's my biggest professional headache, and seems to be the prevailing attitude across the industry. Until that view changes, we're not going to see a large-scale improvement in the state of software security.
You're completely ignoring the reality of implementation flaws. Unfortunately, you fit in with the majority of the industry. I suggest you pick up a copy of Mark Dowd's "The Art of Software Security Assessment". It's 1100 pages exploring implementation flaws in real code (from a guy who's cracked everything from OpenSSH to Sendmail and MS Exchange). That's the stuff that programmers need to learn if they want to stop writing swiss cheese code, but instead they just claim that their encryption protocols solve everything. Yeah, secure protocols and design are necessary, but a bad implementation will beat you every time.
I never used the term "trojan." That stated, I did mention supplying a file containing an exploit directed at the handling application. You can call that a trojan if it makes you happy.
Uh, no. First off, null sessions have never granted the rights necessary to execute a remote shell (unless paired with an exploit). You need admin rights to kick off an exe via the SCM or scheduler. If you have that access already, copying a file is a foregone conclusion because you can just open a share.
Of course, all of that assumes you have Netbios connectivity... over the Internet. That may have been plausible 5 years ago (probably more more), but someone in between will be blocking it these days. On top of that, current Windows XP and better have a lot more restrictions on Netbios traffic, in particular disabling the default null sessions.
One final point: This scenario is actually quite reasonable if you assume they're exploiting an application on the attacker's system. There's likely to be exploits against the trojan itself if the binary is available for analysis, or if you can identify exploitable bugs in code shared between the client and server components. There's also the possibility of attacking any services he exposes, or perhaps file parser attacks against whatever he uses to read the content he nabbed. The details of such a counterattack are more complex, but well within the realm of reason.
That's my big fear also. It's too likely that this is just more pork for someone like EDS or Eagle Alliance. On the off chance it's done correctly, however, I can't think of a better agency to handle it.
I'm not sure what exactly you mean. The SID half of NSA is the hub of the signals intelligence and information operations mission for the DoD. Ft Meade houses the SigInt and IO hub for every branch of service, including the 704th Military Intelligence Brigade, Naval Network Warfare Command, 694th Intelligence Group, and Marine Cryptologic Support Battalion (never ignore the Marines). Then you have the RSOCs and field sites, which are pretty much all military installations, receiving their tasking from and reporting back to the Fort. This always seemed like a pretty standard military structure to me.
The IAD half of NSA is a bit more like you say in that they do function as a service provider, security standards designator, and training institution. However, the SigInt mission accounts for a lot more in the realm of attack monitoring and analysis than I expect you are aware of. Either way, they're still a major component of DoD's information security capabilities. The NSA regularly assesses the security of DoD networks by supporting IG inspections or via organizations like the Red and Blue teams. They are also constantly participating in exercises and training scenarios, such as the Eligible Receiver exercises.
Now, your stance may be based on the fact that DirNSA reports to both the SecDef and the DNI, meaning he has one master outside the DoD. That (and the CIA's existence outside the DoD) is probably the major contributing factor to the creation of DISA in 1960. As the cold war spun up the uniformed services wanted an intelligence agency they could task independently, so they made their own. However, the creation of the NSA/CSS in 1972 added some pretty concrete guarantees to the role of uniformed services, and integrated the NSA more closely into the rest of the DoD.
Basically, I would agree with your position if it was narrowed to IAD and included in some extra caveats concerning training, exercises, and external monitoring. However, your statements certainly don't apply to NSA as a whole.
Congrats on being the first (and so far only) person to get this right; the only thing missing is dates. In my opinion, the dates show parallels between 2K -> XP and Vista -> Windows 7. There was about a year and a half between 2K and XP releases, with XP initially just adding polish and tweaks to smooth out the major architectural changes of 2K. It also gave time for a compatible driver base to get established. In the end this resulted in much better uptake for XP than 2K. Maybe they're shooting for a similar scenario.
I use Understand on a daily basis to review other people's code. It does have it's quirks (mainly on really big codebases), but I haven't found anything that works better. And while it isn't cheap, there is a free one-month trial version.
OSX drivers are built on IOKit, so porting would be a non-trivial task (even more so for associated userland utilities). Plus you need to consider the reality that while Linux and BSD have very broad device support, the quality of individual drivers is a mixed bag. Some are great, some are barely functional, and many are experimental.
I also think you're underestimating the support impact of third party drivers. MS has posted statistics from Watson reports showing that the majority of blue-screens are the result of third-party drivers. However MS still gets the blame because it's their OS that crashed. Of course, their bull-headed response is to move Vista to signed-only drivers, which I don't agree with but does show how seriously they take this issue.
So, consider the above and think about how commodity hardware support would affect Apple's nicely polished, "just works" image. Simply put, it would kill that notion and put them in exactly the same situation as MS (which you already implied in your post). They really don't want to be there, and have good reason not to.
In summary, I do agree that Apple could potentially get a leg up using the BSD codebase, but they'd still need invest tremendous effort and jeopardize their current strategy and consumer base. Personally, I think Apple is making the smart choice for now by avoiding those risks, and the market seems to agree. Mind you, it's what keeps me from buying a personal Mac, but I can't fault the logic behind their decision. Finally, none of this discounts the notion that at some point Apple should make the move to commodity hardware, but doing it now would be a bad business move.
You're dead-on, but you forgot to mention that they have no incentive whatsoever to incur the massive overhead of implementing support for the broad range of commodity hardware that Windows must run on. Their control of the hardware not only buys them a nice profit margin, it also drastically reduces their development QA costs.
For someone that's complaining about misinformation, you really need to stop spreading it yourself. The benchmark was written by a Webkit dev, not a Mozilla dev. Taking cheap shots at an innocent third party doesn't help anyone. That stated, you have a completely valid point that the base64 benchmark is inaccurate. However, IE still has documented issues with string concatenations, which does account for weaker performance in string handling, just not the orders of magnitude difference that this test shows. Either way, this benchmark is not a good indicator of real-world performance, as many people have pointed out. Most web sites are more bound by the DOM interactions and layout than anything else.
I'm forced to assume you have no knowledge of how a browser is implemented, otherwise you'd be aware that the tricks you do to optimize page load time have almost no effect on memory footprint.
For example, you may shrink an image by reducing the pallet and ramping up the compression, but when any application displays that image it must expand it to it's uncompressed form. So, even a 100x100 JPG shrunk down below 2k still must be expanded to 40k (dimensions x RGBA) in memory. Of course, a developer can reduce memory overhead by gaming exactly when the image data is uncompressed and how long it's cached, but that almost always means sacrificing speed and responsiveness.
The image decompression is a really obvious example and pretty much applies to all compressed data, but everything else in the browser tends to expand in a similar manner. HTML parsing involves representing all the objects in a DOM tree, and each DOM node contains quite a bit of essential metadata making it much larger larger than just the associated file text. Then presentation requires building the layout structures for each element and rendering the result. Once again the developer can game expansion and caching, but the trade-offs don't change.
And then there's JavaScript, which has just as much parsing and interpretation overhead as HTML, but is a full-fledged programming language. I'm sure I don't have to explain how a few bytes of script code can easily consume arbitrary amounts of memory through object instantiation, looping, and recursion.
So, we're not even getting into things like cyclic references and fragmentation, but hopefully this is enough to clue you in on why page load size can have very little relation to actual memory consumption. If you want more detail I suggest grabbing the source for Firefox and reading the code (or look at Konqueror, which is bit less painful to follow). That's about the only way to really get a sense of how complex a modern browser is. Of course, you'd better come armed with a strong foundation in C/C++ and system-level programming.
They never specified Ogg as a requirement. They made it a recommendation but not to the exclusion of other formats. Realistically, if you don't give a concrete recommendation in the standard we'll be waiting for years while companies push different incompatible formats that fit their separate agendas. How does that make things any better than they are now?
Color and mouse precision? That's a load of crap. Macs have no technical advantage over PC's for graphics work. It's simply that Apple started courting designers early on and successfully won them for life. In fact, Adobe actually tried to dispel the common myth back in 2003 but the community still chooses to pay a 25% Mac tithe.
As a case in point, my wife works in Chicago as a graphic designer primarily on print media. At work she uses a Mac, along with her designer coworkers and friends from art school (and at SAIC Apple's hooks were so deep they only supported Macs). However, at home she uses a PC and actually prefers CS on the PC because all the menu commands have keyboard shortcuts. She does have some occasional headaches with font assignment when switching files back and forth, but that's the only issue. As for web design, she freelances some of that on the side, and has worked with a mix of PC and Mac groups, but they usually lean more toward the PC.
I suppose I should more accurately state that (as I understand it) Blu-Ray is encumbered with a variety of patents (owned by Sony and its Blu-Ray partners) on the technologies involved in both the players and disc manufacturing. These patents must be licensed in addition to fees for use of logos and access to specifications documents (which both Blu-Ray and HD-DVD have). As it was explained to me, HD-DVD is not encumbered with the same patent licensing issues. That, along with its basis in existing DVD manufacturing methods, are why HD-DVD is so much cheaper while both format's technical capabilities are essentially the same (excluding Blu-Ray's higher capacity per layer and HD-DVD's higher baseline requirements).
Also, I have to admit that I'm not particularly close to the issue myself. My viewpoint is based entirely on conversations with a friend working as an engineer in the industry.
Yes, how deliciously evil for Microsoft to be buying support for an open and public standard (HD-DVD) versus a proprietary format tied to expensive licensing fees and Sony's whims (Blu-Ray). So deliciously... Wait, I think I lost the evil somewhere.
Seriously though, I think Michael Bay is just a wacko who's bought into way too much industry punditry. If his directing is any clue, he was probably fed some absurd story with a heavy reliance on pseudo-science fantasy and unrealistic motivations for all involved parties. That, and some really top-notch special effects.
Uh, attack trees are one of several techniques used in threat modeling. And the whole point of the exercise is to identify the security aspects of a system. That means understanding the trust relationships, attack surface, and associated threats. So, the threat model should be helping you identify if the lock on the front door really helps or if there's a big gaping hole in the wall next to it.
That said, a threat model isn't a panacea. It doesn't replace good coding practices, code reviews, testing, or anything else. But it can help show the big picture and prioritize security efforts.