netflix and amazon are subscription services, not individual movie downloads. itunes is an awesome service, but it's expensive - $5 per movie. So the only conclusion is freetards.
Amazon, Youtube, iTunes and others all let you legally rent or buy digital copies of newly released movies. The prices and quality are competitive or better than DVD rentals, but the convenience factor of digital is the huge differentiator.
Sorry, the antecedent in my response was a bit misleading. What I was correcting was the claim that the PDF reader wasn't a plugin. It's in fact a plugin that ships with the browser (like the Flash plugin does). Third party plugins have always been a difference between Chromium and Chrome, because there's no license to distribute the binaries outside of the official Chrome builds.
That's incorrect. There's never been a PDF reader built into Chromium. The Chrome PDF reader (added in Chrome 8) has always been licensed third-party code in a plugin that ships with Chrome. It's fully sandboxed using PPAPI and has been aggressively audited and fuzzed (this latest round of fuzzing just used a more advanced toolset, so it found new things).
Google uses Chrome to track user's browsing habits for the purpose of targeted advertising.
This is simply not true and never has been. If you are interested in the facts, the Chrome Privacy Team thoroughly explains every feature that can be configured to exchange information with external services: http://www.google.com/chrome/intl/en/privacy.html
Actually, Flash has been sandboxed in Chrome for about a year, but it's not fully sandboxed. To explain, the Chrome sandbox architecture supports five levels on Windows. Chrome's web content and its native PDF reader run at USER_LOCKDOWN and JOB_LOCKDOWN (level 5), which means a deny-only token. Right now Chrome's Flash sandbox runs at USER_INTERACTIVE (level 2) plus low-integrity level (just a bit better than IE's sandbox). However, we've been working for almost two years on a version of Flash that runs in as strong a sandbox as native Chrome content. My post was explaining how to test an alpha release of that improved Flash sandbox.
No, the sandbox in adobe reader X is the chrome one.
It is the Chrome sandbox, but the architecture lets you select the degree of sandboxing. IIRC the Reader X sandboxed process runs at sandbox::USER_LIMITED, which means it can access resources as the Users and Everyone SIDs, and it runs on the interactive desktop. Whereas Chrome runs its sandbox at sandbox::USER_LOCKDOWN, which is a deny only token plus an isolated window station and desktop (along with some additional restrictions).
I don't want to undersell Adobe's accomplishment with Reader X, however. It's a good sandbox and a serious improvement over Windows Low IL on its own. But sandboxing is always a matter of degrees, and the more you can lock it down the better.
I don't see innuendo or unsubstantiated accusations as adding anything to the conversation. But I do think it's useful to address the technical portion of your claim.
If I hit a 404, Chrome phones home with the URI I was trying to reach. And what do you do with that data, I wonder?
I think you undermine the legitimacy of your question by trying to manufacture some evil ulterior motive here. The simple fact is that people often mistype URLs (or clip portions when pasting them), so it's helpful when the correct URL can be easily determined. And if you read through the privacy policy I linked above, you'll see that it very clearly describes what occurs in this scenario:
In order to offer suggestions of alternative or similar webpages, the browser sends Google the URL of the page you're trying to reach whenever the web address does not resolve or a connection cannot be made. Information is logged and anonymized in the same manner as Google web searches. Any parameters in the URL are removed before the URL is sent. The logs are used to ensure and improve the quality of the feature.
So, the submission of the URL is no different than if you'd stripped the parameters and pasted the URL into Google from an anonymous incognito window. If you're uncomfortable with that, then the same link provides instructions for disabling the feature.
Flash is not yet in the Chrome sandbox (except on Chrome OS), but there's a work in progress that you can experiment with on canary or dev channels.. On Windows, Chrome stable's Flash is in an enhanced Low IL sandbox, which is a bit tighter than the Internet Explorer sandbox, but much weaker than the full Chrome sandbox. (Basically, sandboxing an existing piece of software takes quite a bit of work to get right.)
You may personally have the expertise to make good security decisions about your browser. However, all empirical evidence shows that the vast majority of users are not capable of that, and are much better served by a browser that manages updates for them.
That said, you can disable automatic updates and perform them manually if you choose. However, I also consider myself capable of making those security decisions, and I still prefer the silent update dramatically over manually updating.
As an engineer on Chrome security this particular FUD really bothers me. The BSI takes privacy very seriously, and would never make such a recommendation if Chrome did anything like what you suggest. To the contrary, Chrome has an exceptionally responsive privacy team and a very clear and simple privacy policy. It identifies any feature that can exchange data with Google services, and provides clear instructions for opting out. More importantly, the vast majority of features that can exchange any such data are explicitly opt-in.
That still doesn't change anything. Microsoft lets other browsers implement ActiveX too if they want to. But they don't.
You can't implement ActiveX in another browser. You can instantiate an ActiveX control on Windows in any application you want, but that's an entirely different thing. To implement ActiveX on another platform you'd have to also implement all of Windows, because that's the platform and API that ActiveX is written to. So, the comparison isn't really valid.
Why would other browsers suddenly start supporting everything Google does, especially non-standard stuff?
They shouldn't unless they have a compelling reason. If NaCl proves itself viable and and develops a broad base of supporting apps, then other browser makers might certainly find that to be a compelling reason to add support--hopefully using the open source code and documentation already available.
The parts of Chrome that differ from Chromium don't have anything to do with NaCl. The extras in Chrome amount to branding, settings, and plugins that cannot be distributed under an open source license (ie. Flash, PDF).
Re:Is Google trying to fragment web?
on
MAME Running In Chrome
·
· Score: 5, Informative
I can appreciate your confusion, but comparing NaCl to ActiveX doesn't really make sense. Once you instantiate an ActiveX control it runs arbitrary code at your full user privilege. Whereas NaCl is much more accurately compared to the restricted execution environment of a virtual machine, such as Java,.NET CLR, or even JITed JavaScript. It's just that NaCl virtualizes a well-defined subset of an existing hardware instruction set, rather than one developed specifically for it. That virtualization (and the associated instruction validation) is the primary security mechanism, and is typical of a VM environment. The process sandbox is just a defense-in-depth measure (and a very strong one) layered underneath an existing VM sandbox.
However, there's no reason to take my word for it. If you research it a bit you should find that NaCl has a comparable or (in most cases) a more robust security model compared to the web-delivered execution environments most people are already running.
Sorry, I was only addressing the issue of opening write permission on the application directory. I should have been more specific in stating that I was not answering the question concerning the malformed file path. Though in retrospect, I wouldn't be surprised if the copy protection is the cause of the write permission requirement also.
This is lying marketing speak. All those things were available long before NT. NT polished and packaged them, that's all.
I'm picking up a little animosity here, so perhaps I wasn't clear enough on my point. For the most part MS didn't invent these features; as you stated, they polished and packaged them. A perfect example of this is the NT hybrid micro-kernel, which was heavily inspired by Rick Rashid's previous work with the Mach microkernel project at CMU. But I don't think the fact that they "stood on the shoulders of giants" makes the result any less groundbreaking or forward thinking. It took serious engineering effort to integrate commercial capabilities that had up until then existed primarily in the realm of research. It's also an extremely bold effort to try to match or exceed your entrenched competition on so many fronts.
You don't have to like MS, and no one should make apologies for their questionable business practices. I just think it's important present accurate information and give credit where credit is due.
Solving the problem by making the directory writable basically defeats the purpose. Write access to the content means that you can replace essential files, such as the executables themselves. Even if write permissions are not allowed to the contained files, you can still use DLL redirection to trojan the executables. So basically, they need to fix the app.
As for the specific issue, based on what you've written there are three likely scenarios that cause this problem. The first is that they're not separating system and user specific config data, and it's all being stored in the application directory. That's a big no-no and it can require some significant effort to fix. The remaining possibilities are easier. They may just be creating temp files under the application directory, in which case they just need to use the system provided temp path for the current user. The last one is that they're opening files under the application directory as writeable, when they only need read access. This one happens a lot, and the fix is to just make sure the file is opened as read-only if it only needs to be read.
If you are interested in finding the actual cause of the problem, you can probably diagnose it with Filemon (freeware) from Sysinternals. Who knows, you may be able to sway their developers to fix it with some specific information.
I used to manage the base software image for a very large network. That often entailed profiling apps to identify excessive permission requirements and finding ways to fix these issues. I can honestly say that pretty much all enterprise level software I saw worked fine in an LUA environment by 2000. For example, a lot of massaging was necessary for MS Office 96 (changing reg keys to alter file paths, opening write permission on application directories, etc.). Office 2K however, worked out of the box and separated user and system specific data properly. In general, I've found that you're fine with any application released in the last 5 years that is Windows logo compliant for enterprises.
The real issue here is that developers are pushing this practice out to all applications, and MS will be enforcing it in Vista.
SCO didn't purchase Unix rights until 1995, and Windows NT 3.1 was released in 1993. Plus, I've never heard of any agreement that would have prevented Windows NT from being a fully compliant Unix. They even built it with swappable OS subsystems so they could go that route if the market demanded it. There was even a third party vendor that sold a really good Unix subsystem several years ago, but the name escapes me.
As for advanced features, I think the GP is referring to things like the swappable OS subsystems; a hybrid micro-kernel; a strong and flexible access control model; a highly portable hardware abstraction layer supporting three widely different architectures; and an extremely versatile file-system. This was all really groundbreaking in the early 1990's and a lot of it is still very impressive from a design and engineering perspective. Plus this is back when MS was the versatile upstart that was challenging the clunky proprietary Unixes of its day. MS was much friendlier back in those days too, as they were doing a lot more embracing and a lot less extending.
The tragedy of Windows NT is that MS became too dominant and its direction changed. As a result many of the kernel's greatest features were never really visible through the layers of crap piled on top. The Win32 subsystem eliminated the competition and brought us abominations like pseudo-handles and a truly evil GDI. The hybrid micro-kernel became suspiciously monolithic as it absorbed the GDI, Win32 subsystem, and anything else in the name of performance. The exceptional access control model was all but ignored by the majority of software developers, with even enterprise developers doing a poor job of supporting secure multi-user access. The hardware abstraction layer slowly evaporated as support dwindled to only x86. The advanced functionality of the file-system was never utilized much, in order to maintain parity the bastard family line known as Win9x. And so the operating system crystallized to what it is today.
So I'm glad to see that Windows NT is finally headed back to its roots and picking up some old initiatives. Vista will finally push secure multi-user access (LUA) and kick the GDI's ass out of the kernel. I was very unimpressed by MS a few years ago, and I'm always extremely suspicious of them. But it really looks like they're headed in the right direction with respect to security and stability, and I don't think anyone should begrudge them that. That stated, I'm also very happy that we now have viable and, in some scenarios, superior and more affordable alternatives to the Windows platform. As far as I'm concerned the consumer's options are just continuing to get better.
My apologies for running with that piece of misinformation. The original parent post led me to believe Bonjour was a file sharing service, not general purpose network discovery protocol. I admit I'm not familiar with the specifics of Rendezvous or Bonjour, and I appreciate the correction. But I don't think that changes my point about the dangers of dismissing vulnerabilities without understanding the real attack surface.
iTunes has a lot more attack surface than than just file sharing via Bonjour. There's the potential for privelege escalation or remote exploit via the iPod service that comes with it. I agree that playing the disclosure game does encourage security companies to release hazy vulnerabilities reports early and often. But dismissing a security threats is generally not a good idea either.
MS uses ActiveX scripting objects to support additional languages, so doing it the MS way would require blanket support for ActiveX. That actually wouldn't be difficult to do in FF for Windows, but it leaves FF out in the cold on every other platform. It also sets a really bad precedent.
This could also be supported through the plugin architecture, but that puts us back in the 90's, where sites commonly required proprietary binary plugins or ActiveX controls. We already know that's a developmental dead end and a security nightmare. The current JavaScript architecture however, is an open ECMA spec that is directly addressed in the W3C standards. The presense of and adherence to these standards is one one the major factors contributing to the current explosion of new web technologies. I agree that AJAX is a silly buzzword, but at least it's keeping browser and web developers focused on standards support and interoperability.
I do think there is still a vacuum for a language Nuetral VM with a strong security sandbox that can hook into the DOM. Java applets should have filled this niche, but Sun repeatedly botched the delivery. MS.NET client web controls are another option, and Mono can provide support on non-MS platforms. Unfortunately these don't really seem to be going anywhere. I'd really like to see something in this arena catch on, but interoperability and security are essential for that to happen. And blind scripting interfaces won't provide that.
Now, language independence for extensions and internal development is a different issue. If you had done a little research you would see that Mozilla has had Python support for years, but it's not in the release versions. A little more research would probably land you at the Gecko roadmap where you'd find some info on the language neutral DOM interface in Gecko 1.9. Poking a little further would probably lead you to XULRunner. At that point I hope you will see that the intent of the development is quite intelligent and open. The fact is that it just takes time to get there and there are lot of factors to consider.
P.S. - I'd also suggest taking a closer look at JavaScript before calling it a brain-dead language. It's far from perfect, but certainly more intelligible and maintainable than Perl when used properly. And for it's target environment it actually works quite well.
I totally agree with you here. If you've ever taken a look at the NTSC (Never The Same Color) spec you realize that it's an absolute kludge that sacrificed significantly better picture quality for backwards compatability. I'd hate to see the same thing happen to HDTV. This technology has been hovering for the past twenty years and the only thing stalling it has been competing standards and backwards compatibility issues. The current spec is damn good; it dumps the evolutionary baggage and provides ample time for people to adapt. Besides, the cost issue will most likely evaporate once production increases.
I'm not so sure that porting Stella or z26 to these devices is really that good of an option. The overhead of emulating the 2600 on a palm device or cell phone might be a little more than you'd want. That along with a decent library of ROMs would really eat into the comparatively small amount of memory and system resources. Plus there's the whole licensing issue.
That said, I really think the idea of native versions for these new devices has some merit.
Slashdot Mirror
Chrome was the first browser to do this, and has been blocking out-of-date and commonly exploited plugins (like Java) since 2010.
Here's every "security" report he's made against Chrome. None were valid.
netflix and amazon are subscription services, not individual movie downloads. itunes is an awesome service, but it's expensive - $5 per movie. So the only conclusion is freetards.
Amazon, Youtube, iTunes and others all let you legally rent or buy digital copies of newly released movies. The prices and quality are competitive or better than DVD rentals, but the convenience factor of digital is the huge differentiator.
Sorry, the antecedent in my response was a bit misleading. What I was correcting was the claim that the PDF reader wasn't a plugin. It's in fact a plugin that ships with the browser (like the Flash plugin does). Third party plugins have always been a difference between Chromium and Chrome, because there's no license to distribute the binaries outside of the official Chrome builds.
That's incorrect. There's never been a PDF reader built into Chromium. The Chrome PDF reader (added in Chrome 8) has always been licensed third-party code in a plugin that ships with Chrome. It's fully sandboxed using PPAPI and has been aggressively audited and fuzzed (this latest round of fuzzing just used a more advanced toolset, so it found new things).
Google uses Chrome to track user's browsing habits for the purpose of targeted advertising.
This is simply not true and never has been. If you are interested in the facts, the Chrome Privacy Team thoroughly explains every feature that can be configured to exchange information with external services: http://www.google.com/chrome/intl/en/privacy.html
Actually, Flash has been sandboxed in Chrome for about a year, but it's not fully sandboxed. To explain, the Chrome sandbox architecture supports five levels on Windows. Chrome's web content and its native PDF reader run at USER_LOCKDOWN and JOB_LOCKDOWN (level 5), which means a deny-only token. Right now Chrome's Flash sandbox runs at USER_INTERACTIVE (level 2) plus low-integrity level (just a bit better than IE's sandbox). However, we've been working for almost two years on a version of Flash that runs in as strong a sandbox as native Chrome content. My post was explaining how to test an alpha release of that improved Flash sandbox.
No, the sandbox in adobe reader X is the chrome one.
It is the Chrome sandbox, but the architecture lets you select the degree of sandboxing. IIRC the Reader X sandboxed process runs at sandbox::USER_LIMITED, which means it can access resources as the Users and Everyone SIDs, and it runs on the interactive desktop. Whereas Chrome runs its sandbox at sandbox::USER_LOCKDOWN, which is a deny only token plus an isolated window station and desktop (along with some additional restrictions).
I don't want to undersell Adobe's accomplishment with Reader X, however. It's a good sandbox and a serious improvement over Windows Low IL on its own. But sandboxing is always a matter of degrees, and the more you can lock it down the better.
I don't see innuendo or unsubstantiated accusations as adding anything to the conversation. But I do think it's useful to address the technical portion of your claim.
If I hit a 404, Chrome phones home with the URI I was trying to reach. And what do you do with that data, I wonder?
I think you undermine the legitimacy of your question by trying to manufacture some evil ulterior motive here. The simple fact is that people often mistype URLs (or clip portions when pasting them), so it's helpful when the correct URL can be easily determined. And if you read through the privacy policy I linked above, you'll see that it very clearly describes what occurs in this scenario:
In order to offer suggestions of alternative or similar webpages, the browser sends Google the URL of the page you're trying to reach whenever the web address does not resolve or a connection cannot be made. Information is logged and anonymized in the same manner as Google web searches. Any parameters in the URL are removed before the URL is sent. The logs are used to ensure and improve the quality of the feature.
So, the submission of the URL is no different than if you'd stripped the parameters and pasted the URL into Google from an anonymous incognito window. If you're uncomfortable with that, then the same link provides instructions for disabling the feature.
Flash is not yet in the Chrome sandbox (except on Chrome OS), but there's a work in progress that you can experiment with on canary or dev channels.. On Windows, Chrome stable's Flash is in an enhanced Low IL sandbox, which is a bit tighter than the Internet Explorer sandbox, but much weaker than the full Chrome sandbox. (Basically, sandboxing an existing piece of software takes quite a bit of work to get right.)
You may personally have the expertise to make good security decisions about your browser. However, all empirical evidence shows that the vast majority of users are not capable of that, and are much better served by a browser that manages updates for them.
That said, you can disable automatic updates and perform them manually if you choose. However, I also consider myself capable of making those security decisions, and I still prefer the silent update dramatically over manually updating.
As an engineer on Chrome security this particular FUD really bothers me. The BSI takes privacy very seriously, and would never make such a recommendation if Chrome did anything like what you suggest. To the contrary, Chrome has an exceptionally responsive privacy team and a very clear and simple privacy policy. It identifies any feature that can exchange data with Google services, and provides clear instructions for opting out. More importantly, the vast majority of features that can exchange any such data are explicitly opt-in.
That still doesn't change anything. Microsoft lets other browsers implement ActiveX too if they want to. But they don't.
You can't implement ActiveX in another browser. You can instantiate an ActiveX control on Windows in any application you want, but that's an entirely different thing. To implement ActiveX on another platform you'd have to also implement all of Windows, because that's the platform and API that ActiveX is written to. So, the comparison isn't really valid.
Why would other browsers suddenly start supporting everything Google does, especially non-standard stuff?
They shouldn't unless they have a compelling reason. If NaCl proves itself viable and and develops a broad base of supporting apps, then other browser makers might certainly find that to be a compelling reason to add support--hopefully using the open source code and documentation already available.
The parts of Chrome that differ from Chromium don't have anything to do with NaCl. The extras in Chrome amount to branding, settings, and plugins that cannot be distributed under an open source license (ie. Flash, PDF).
I can appreciate your confusion, but comparing NaCl to ActiveX doesn't really make sense. Once you instantiate an ActiveX control it runs arbitrary code at your full user privilege. Whereas NaCl is much more accurately compared to the restricted execution environment of a virtual machine, such as Java, .NET CLR, or even JITed JavaScript. It's just that NaCl virtualizes a well-defined subset of an existing hardware instruction set, rather than one developed specifically for it. That virtualization (and the associated instruction validation) is the primary security mechanism, and is typical of a VM environment. The process sandbox is just a defense-in-depth measure (and a very strong one) layered underneath an existing VM sandbox.
However, there's no reason to take my word for it. If you research it a bit you should find that NaCl has a comparable or (in most cases) a more robust security model compared to the web-delivered execution environments most people are already running.
Sorry, I was only addressing the issue of opening write permission on the application directory. I should have been more specific in stating that I was not answering the question concerning the malformed file path. Though in retrospect, I wouldn't be surprised if the copy protection is the cause of the write permission requirement also.
I'm picking up a little animosity here, so perhaps I wasn't clear enough on my point. For the most part MS didn't invent these features; as you stated, they polished and packaged them. A perfect example of this is the NT hybrid micro-kernel, which was heavily inspired by Rick Rashid's previous work with the Mach microkernel project at CMU. But I don't think the fact that they "stood on the shoulders of giants" makes the result any less groundbreaking or forward thinking. It took serious engineering effort to integrate commercial capabilities that had up until then existed primarily in the realm of research. It's also an extremely bold effort to try to match or exceed your entrenched competition on so many fronts.
You don't have to like MS, and no one should make apologies for their questionable business practices. I just think it's important present accurate information and give credit where credit is due.
Solving the problem by making the directory writable basically defeats the purpose. Write access to the content means that you can replace essential files, such as the executables themselves. Even if write permissions are not allowed to the contained files, you can still use DLL redirection to trojan the executables. So basically, they need to fix the app.
As for the specific issue, based on what you've written there are three likely scenarios that cause this problem. The first is that they're not separating system and user specific config data, and it's all being stored in the application directory. That's a big no-no and it can require some significant effort to fix. The remaining possibilities are easier. They may just be creating temp files under the application directory, in which case they just need to use the system provided temp path for the current user. The last one is that they're opening files under the application directory as writeable, when they only need read access. This one happens a lot, and the fix is to just make sure the file is opened as read-only if it only needs to be read.
If you are interested in finding the actual cause of the problem, you can probably diagnose it with Filemon (freeware) from Sysinternals. Who knows, you may be able to sway their developers to fix it with some specific information.
I used to manage the base software image for a very large network. That often entailed profiling apps to identify excessive permission requirements and finding ways to fix these issues. I can honestly say that pretty much all enterprise level software I saw worked fine in an LUA environment by 2000. For example, a lot of massaging was necessary for MS Office 96 (changing reg keys to alter file paths, opening write permission on application directories, etc.). Office 2K however, worked out of the box and separated user and system specific data properly. In general, I've found that you're fine with any application released in the last 5 years that is Windows logo compliant for enterprises.
The real issue here is that developers are pushing this practice out to all applications, and MS will be enforcing it in Vista.
SCO didn't purchase Unix rights until 1995, and Windows NT 3.1 was released in 1993. Plus, I've never heard of any agreement that would have prevented Windows NT from being a fully compliant Unix. They even built it with swappable OS subsystems so they could go that route if the market demanded it. There was even a third party vendor that sold a really good Unix subsystem several years ago, but the name escapes me.
As for advanced features, I think the GP is referring to things like the swappable OS subsystems; a hybrid micro-kernel; a strong and flexible access control model; a highly portable hardware abstraction layer supporting three widely different architectures; and an extremely versatile file-system. This was all really groundbreaking in the early 1990's and a lot of it is still very impressive from a design and engineering perspective. Plus this is back when MS was the versatile upstart that was challenging the clunky proprietary Unixes of its day. MS was much friendlier back in those days too, as they were doing a lot more embracing and a lot less extending.
The tragedy of Windows NT is that MS became too dominant and its direction changed. As a result many of the kernel's greatest features were never really visible through the layers of crap piled on top. The Win32 subsystem eliminated the competition and brought us abominations like pseudo-handles and a truly evil GDI. The hybrid micro-kernel became suspiciously monolithic as it absorbed the GDI, Win32 subsystem, and anything else in the name of performance. The exceptional access control model was all but ignored by the majority of software developers, with even enterprise developers doing a poor job of supporting secure multi-user access. The hardware abstraction layer slowly evaporated as support dwindled to only x86. The advanced functionality of the file-system was never utilized much, in order to maintain parity the bastard family line known as Win9x. And so the operating system crystallized to what it is today.
So I'm glad to see that Windows NT is finally headed back to its roots and picking up some old initiatives. Vista will finally push secure multi-user access (LUA) and kick the GDI's ass out of the kernel. I was very unimpressed by MS a few years ago, and I'm always extremely suspicious of them. But it really looks like they're headed in the right direction with respect to security and stability, and I don't think anyone should begrudge them that. That stated, I'm also very happy that we now have viable and, in some scenarios, superior and more affordable alternatives to the Windows platform. As far as I'm concerned the consumer's options are just continuing to get better.
My apologies for running with that piece of misinformation. The original parent post led me to believe Bonjour was a file sharing service, not general purpose network discovery protocol. I admit I'm not familiar with the specifics of Rendezvous or Bonjour, and I appreciate the correction. But I don't think that changes my point about the dangers of dismissing vulnerabilities without understanding the real attack surface.
iTunes has a lot more attack surface than than just file sharing via Bonjour. There's the potential for privelege escalation or remote exploit via the iPod service that comes with it. I agree that playing the disclosure game does encourage security companies to release hazy vulnerabilities reports early and often. But dismissing a security threats is generally not a good idea either.
MS uses ActiveX scripting objects to support additional languages, so doing it the MS way would require blanket support for ActiveX. That actually wouldn't be difficult to do in FF for Windows, but it leaves FF out in the cold on every other platform. It also sets a really bad precedent.
This could also be supported through the plugin architecture, but that puts us back in the 90's, where sites commonly required proprietary binary plugins or ActiveX controls. We already know that's a developmental dead end and a security nightmare. The current JavaScript architecture however, is an open ECMA spec that is directly addressed in the W3C standards. The presense of and adherence to these standards is one one the major factors contributing to the current explosion of new web technologies. I agree that AJAX is a silly buzzword, but at least it's keeping browser and web developers focused on standards support and interoperability.
I do think there is still a vacuum for a language Nuetral VM with a strong security sandbox that can hook into the DOM. Java applets should have filled this niche, but Sun repeatedly botched the delivery. MS .NET client web controls are another option, and Mono can provide support on non-MS platforms. Unfortunately these don't really seem to be going anywhere. I'd really like to see something in this arena catch on, but interoperability and security are essential for that to happen. And blind scripting interfaces won't provide that.
Now, language independence for extensions and internal development is a different issue. If you had done a little research you would see that Mozilla has had Python support for years, but it's not in the release versions. A little more research would probably land you at the Gecko roadmap where you'd find some info on the language neutral DOM interface in Gecko 1.9. Poking a little further would probably lead you to XULRunner. At that point I hope you will see that the intent of the development is quite intelligent and open. The fact is that it just takes time to get there and there are lot of factors to consider.
P.S. - I'd also suggest taking a closer look at JavaScript before calling it a brain-dead language. It's far from perfect, but certainly more intelligible and maintainable than Perl when used properly. And for it's target environment it actually works quite well.
I totally agree with you here. If you've ever taken a look at the NTSC (Never The Same Color) spec you realize that it's an absolute kludge that sacrificed significantly better picture quality for backwards compatability. I'd hate to see the same thing happen to HDTV. This technology has been hovering for the past twenty years and the only thing stalling it has been competing standards and backwards compatibility issues. The current spec is damn good; it dumps the evolutionary baggage and provides ample time for people to adapt. Besides, the cost issue will most likely evaporate once production increases.
I'm not so sure that porting Stella or z26 to these devices is really that good of an option. The overhead of emulating the 2600 on a palm device or cell phone might be a little more than you'd want. That along with a decent library of ROMs would really eat into the comparatively small amount of memory and system resources. Plus there's the whole licensing issue. That said, I really think the idea of native versions for these new devices has some merit.