Microsoft Adds Selective ActiveX Filtering to IE9

An anonymous reader writes "A post on the IE blog details the new ActiveX filtering feature in the IE9 release candidate. Microsoft's Herman Ng writes, 'ActiveX Filtering in the IE9 Release Candidate gives you greater control over how Web pages run on your PC. With ActiveX Filtering, you can turn off ActiveX controls for all Web sites and then turn them back on selectively as you see fit. While ActiveX controls like Adobe Flash are important for Web experiences today for videos and more, some consumers may want to limit how they run for security, performance, or other reasons.' My favorite quote from the article is one of the image captions: 'ActiveX content may prevent you from having a good experience viewing a Web site'"

Comments

Flash?

[SilverHatHacker]

I didn't realise Flash was an ActiveX control.

Re:Flash?

[game kid]

For IE, it is. For others it's a NS plugin thingy. The plugin and control are separate downloads but otherwise work much the same way once installed (except maybe tech details like wmode or IE9 hardware surface support or such).

Re:Flash?

[Anonymous Coward]

For all browsers, except for IE, Flash uses NPAPI. However, Microsoft switched to ActiveX with IE6. I've always wondered if one over the other allowed for different exploits in the different version.

Re:Flash?

[shutdown -p now]

Both extensibility models run non-sandboxed native code on your machine. In either case, security is zero.

Re:Flash?

[yuhong]

I wonder how many bash ActiveX without realizing this.

Re:Flash?

[LO0G]

On Windows XP, there are effectively no differences between ActiveX and NPAPI - plugins carry the same risks. For Windows Vista and Windows 7, ActiveX plugins run in the IE "sandbox" which runs with restricted access to the desktop (it's called "low rights IE"). Since Firefox doesn't support a restricted access sandbox (yet), NPAPI plugins are thus more dangerous since they can instantly do anything that the user can do (ActiveX controls need to break out of the sandbox first). Note that in some cases, the IE sandbox is disabled (for instance it's disabled in the local machine zone and for intranet sites).

The original Chrome sandbox only applied to its rendering and JS engine, plugins like flash ran with full access to the desktop. However I believe that Chrome's current extension model runs most extensions in its sandbox as well (I'm not 100% sure - the wikipedia page for chrome is ambiguous on this).

A sandbox acts as a defense-in-depth feature, like data execution protection and ASLR. In general, the more of these features which are enabled, the safer you are when browsing the web.

Re:Flash?

[shutdown -p now]

Well, the difference with ActiveX in IE is that it allows the website to prompt downloading the plugin. Historically, the big problem was that it was a simple OK/Cancel type dialog, essentially click-thru. Many more hoops today, but old painful memories die hard.

Re:Flash?

[LO0G]

If you read this article from the IE blog (from 2005), they claim that ActiveX plugins run in a sandbox. The MSDN documentation for low rights IE has similar contents.

Re:Flash?

[Anonymous Coward]

...except those aren't the only two plugin APIs - Chrome's PPAPI is sandboxed, and Flash is written around it.

Re:Flash?

[LO0G]

Mod parent up +1 informative.

You've hit on the key difference between ActiveX and NPAPI - for NPAPI, the user has to download and install the plugin outside the browser, which means that an attacker couldn't guarantee that a particular plugin was present. For ActiveX, a web page could cause the plugin to be installed automatically which meant that an attacker could be sure that a plugin was present. Of course the code that allowed for silent installs has been gone for the better part of a decade but as you said, old painful memories die hard.

Re:Flash?

[Anonymous Coward]

ActiveX is not limited to IE, Windows and other MS programs use them extensively as well even 3rd-party programs (not even meant for IE use either). The problem with IE/6 is that it allows ActiveX controls not meant to be used in IE used in IE, MS regularly releases killbit updates that are a list of ActiveX controls not allowed to run in IE. Drive-by exploits instantiated vulnerable Windows ActiveX controls not meant for IE a lot and able to execute code without the user having to do anything other than visiting a webpage.

Re:Flash?

[Anonymous Coward]

ActiveX has been sandboxed in Vista and up since IE7.

Chrome's valiant attempts to fake it notwithstanding, XP can't sandbox native code in the same way.

Re:Flash?

[Anonymous Coward]

The critical problem with ActiveX was that Microsoft re-purposed plugins that were intended to run with the user's consent on their desktop as browser plugins, and the only "protection" was a bitflag saying "this is safe to use in a web browser". So most of the early ActiveX "flaws" are just Corporation X's popular plugin Y is mistakenly set as safe for browsing, and it includes a method "write file to hard disk" so now a web page can write files to your hard disk.

NPAPI was only ever for use in browsers, so nobody was writing big complicated desktop plugins using NPAPI and then mistakenly enabling them for the web.

Re:Flash?

[Anonymous Coward]

Google's documentation on writing NPAPI plugins states the following:

http://code.google.com/chrome/extensions/npapi.html

Code running in an NPAPI plugin has the full permissions of the current user and is not sandboxed or shielded from malicious input by Google Chrome in any way.

Re:Flash?

[Warll]

Wait, am I to understand that IE used to allow installation and execution of arbitrary binaries? From the web!? How did any one ever think that this was a good idea?

Re:Flash?

[LO0G]

Not quite. IE used to allow the installation of arbitrary *signed* binaries (in the internet zone).

Back when the ActiveX plugin model was created (1996), the internet was a very different place.

The signing requirement was thought to make a difference (since it blocked arbitrary binaries). What Microsoft didn't realize was that the bad guys just had to find a control with a security vulnerability in it (and there are thousands of controls with security vulnerabilities), host it on their site and ask the browser to load the vulnerable control - the signing requirement wasn't as useful as people though.

Because of this, Microsoft has steadily increased the restrictions on ActiveX controls, adding things like site lock (an ActiveX control can indicate that it only works on a particular site), running the ActiveX controls in a sandbox, adding a killbit list to block vulnerable controls, etc..

The IE team can't get rid of ActiveX controls because of the staggering number of sites that rely on them (apparently the South Korean banking industry is completely dependant on ActiveX controls not to mention the number of intranet sites that depend on them).

Re:Flash?

[Warll]

Ah, thank you that does make much more sense. I certainly don't envy Microsoft's legacy commitments.

Re:Flash?

[Anonymous Coward]

Back when the ActiveX plugin model was created (1996), the internet was a very different place.

No it wasn't. When I first heard of ActiveX I said "they're totally mad, this is a security nightmare". Well it still is. Took them just 15 years to realize ist.

Well this is disappointing

[scourfish]

Microsoft was doing so great on their new feature set for IE9 up until they listed the ability to turn ActiveX back on.

Re:Well this is disappointing

[Anonymous Coward]

They have to. Too many corporations (and in some cases government services) running the stupid things without budget to upgrade to something more standard.

Re:Well this is disappointing

[Bengie]

Plugins work great on the internet, but ActiveX is more of an intranet thing.

I have yet to see a plugin for FireFox/Chrome/etc that allow tight intranet integration.

Kind of a functionality requirement.

Re:Well this is disappointing

[GameboyRMH]

Yep, unfortunately idiot companies are still to this day building web interfaces for security cameras that require ActiveX. I mean if you have to use a shitty proprietary solution, at least use Flash.

Re:Well this is disappointing

[jellomizer]

If Microsoft turned it off... The corporations and governments would find the budget. That should be the penalty for using ActiveX anyways.

Re:Well this is disappointing

[kevinmenzel]

Which is ActiveX in Internet Explorer... so... that would still require ActiveX....

Re:Well this is disappointing

[GameboyRMH]

Only because Flash basically runs on top of ActiveX in IE. ActiveX wouldn't be required if IE used a different plugin architecture.

Disappointing

[mysidia]

'ActiveX content may prevent you from having a good experience viewing a Web site'"

Since I define a good experience as having at least 3 unknown, untrusted executables run in the background, doing god knows what, with only routine prompting.... I am highly skeptical about the improvement.

Now my users are going to have to go to the tried and true old fashioned way of getting their computers' infected. Clicking the executable, and then hitting the 'Run' button, or Saving first.... And Windows 7 was being touted as 'user firendly'...feh. :(

<eg>

Re:Disappointing

[MrEricSir]

Don't worry, every time Microsoft plugs one hole, they add another for legacy services.

For example, look at the workarounds for installing various types of ActiveX controls -- without prompting -- on this page.
http://msdn.microsoft.com/en-us/library/cc721964(v=ws.10).aspx

Or read this page about starting elevated executables from within ActiveX -- again, without prompting.
http://msdn.microsoft.com/en-us/library/bb250462(v=vs.85).aspx#wpm_elebp

Now consider the following: on Vista and Win7, all of the registry values described on these pages can be set from within the ActiveX installer itself! In other words, you can write an ActiveX component that installs, runs, and performs IPC with elevated processes. And the user will have no idea.

So if Microsoft keeps up their practice of adding holes while they plug others, then rest assured that you'll be able to continue your practice of installing viruses with minimal hassle.

Re:Disappointing

[Anonymous Coward]

Chin up. There's always hope - through Silverlight.

Re:Disappointing

[MrEricSir]

Before anybody asks, all the the above post is speaking from firsthand experience. Unfortunately.

Re:Disappointing

[Anonymous Coward]

Before anybody asks, all the the above post is speaking from firsthand experience. Unfortunately.

So you're saying a low privilege level privilege active-X control has the ability to install the ActiveX installer service, something that normally requires admin privs? It also magically has has write access to registry keys that users normally have read-only access to? I call FUD unless you can point to a working example of an active-x control that can do such feats.

Re:Disappointing

[MrEricSir]

Define "low level." The ActiveX control I created was signed, which automatically gives it certain powers. There is a point during the install process during which the DLL gets hooked into the installer service and you have write access to an alarmingly large portion of the registry. It's not a documented feature as far as I was ever able to tell.

The product I worked on was canceled, afaik, so I can't send you a link to it. But it's not like I invented all of this myself.

Re:Disappointing

[vistapwns]

"the ActiveX Installer Service checks whether the URL requesting the ActiveX control installation is approved in Group Policy." The URL has to be approved (by the administrator of the PC) before active-x can be auto-installed. You did know this right? The second link talks about making your own broker process to bypass IE sandbox, but you need again code running (and authorized by the user) on the box first.

Re:Disappointing

[MrEricSir]

Sure, but that's not the point -- the point is they made all these security features, then told you exactly how to work around them right there on MSDN.

Why did they bother?

Re:Disappointing

[Anonymous Coward]

So what is the alternative then? Make a system where the administrators have no way of installing software without doing it themselves or handing out the administrator password to people who shouldn't have that power?

Your examples required someone with administrator privileges to set it all up. Someone has to install an optional subsystem and then use Group Policies to grant installation privileges to an ActiveX control at a known, particular URL. Then you have to get the user to browse to that URL.

You think that everyone will get viruses this way? If you have a virus that can automate all that, or someone malicious enough to manually do that, then it is already too late. The virus could have been installed directly without having to go through all that bother with the ActiveX Installer Service.

Re:Disappointing

[Anonymous Coward]

Don't worry, just having Javascript enabled and begging every errant script on the internet to violate your machine is *plenty* good enough an experience.

And hey, the new wave of web design pretty much requires that anyway. Trade one Flash for another, apparently.

Re:Disappointing

[Tim C]

They're telling the administrator of the PC how to work around them. That's a good thing surely?

Re:Disappointing

[Anonymous Coward]

For the above to work with no prompt as you've said, the user would need to be an administrator of the machine AND would have had to have UAC turned off. If those are both true, then sure that could happen. I'm not sure who would be doing that as it is like saying, "please hack me", but sure - some users probably do that exact thing. We've got a medium large deployment (90,000 machines) and we don't allow UAC to be off or allow general users to have admin rights. We also don't have to worry about the items in your post as they just aren't an issue if you are running your systems configured correctly.

Re:Disappointing

[vistapwns]

Like the other guy said, it's a good thing for the Admin to be able to bypass this security when and where he needs to. The point of these protections is to prevent unwanted code on the internet from running on the user's box. And they do that just fine. BUT if the Admin wants to make exceptions for specific sites (for corporate intranet sites that need this or whatever) then he can, but that's all. Normally, without an Admin setting an exception in group policy, active-x can not auto-install and you can not bypass the IE sandbox. Not sure how much more clear I can make this...

Re:Disappointing

[MrEricSir]

You're missing a key point: namely that the ActiveX control itself can change these settings.

Re:Disappointing

[Anonymous Coward]

Because, if you can work around them, it means you already own the box. The whole point of any protection mechanism is to keep people out, not to bother those who are already in.

Re:Disappointing

[mysidia]

I'll take Javascript over flash any day.

At least Javascript is cross-browser.... [when it doesn't improperly use IE-specific extensions]

Re:Disappointing

[Anonymous Coward]

But to install a broker requires admin level privleges. So installing a broker is done in installers which still elevated. So you gave the malware permission to do this to you, and you got what you derserved.

Re:Disappointing

[Anonymous Coward]

yeah, god forbid that they trust plugins from, say, their own internet website.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Microsoft Virus Installer

[MrEricSir]

ActiveX really is like Microsoft Virus Installer. For legacy reasons it requires elevated privileges to install, which is pretty much the opposite of a sandbox.

Leave it to Microsoft to screw up something to simple.

Re:Microsoft Virus Installer

[BitZtream]

Explain, in detail the differences between ActiveX and any Mozilla extension with a compiled binary XPCOM component or any nsplugin api based plugin.

Not the implementation specific but the flow of how they work.

I'm afraid you'll find that ActiveX is really no different than any other plugin system.

The problem is that ActiveX is more or less a GLOBAL, system wide plugin system versus a web browser specific api like nsplugin.

IE previously had serious problems because it would allow ActiveX controls to be downloaded and installed in a multitude of ways sometimes with the user being prompted, but due to bugs it also happened without the user ever being prompted. It defaulted to allow in early version as well, which of course is the exact wrong thing to do.

Add too that the high number of ActiveX controls that incorrectly had themselves flagged as safe to be used by websites and you have a horrible implementation ... several years ago.

Badly written ActiveX controls much be registered globally, requiring admin to install it, however properly written ActiveX controls are happy to install themselves on a per user basis. As long as you are warned and given the option to say no, there is no issue, it gives the user a way to make it work without having to go to command line to register the component or finding a gui tool to do it.

The overall features provided by ActiveX surpass pretty much every other plugin system currently implemented, they are essentially self describing DLLs that contain everything needed for any random developer to use, no source code required (which of course OSS fans don't appreciate but thats another story entirely).

Unfortunately, even with the extra things built into ActiveX (like the ability to flag it as unsafe for use in untrusted environments like a web browser, Microsoft fucked up the original implementation and didn't fix it for years, and then it took them several years to make it actually fix all of the major problems.

ActiveX controls no longer install without multiple clicks of user interaction. Its easier to get owned with a gecko based application such as Firefox or Thunderbird than it is with IE, it takes fewer clicks.

Yes, there are a lot of shitty, broken ActiveX controls, no argument there, but to say 'ActiveX is bad' is like saying 'plugins are bad' because thats all they are.

Microsoft has COM, which ActiveX is built on (And the entire .NET framework as well), Mozilla uses XPCOM, and you can generate code for both from the same IDL file if its fairly simple.

Re:Microsoft Virus Installer

[93 Escort Wagon]

Badly written ActiveX controls much be registered globally, requiring admin to install it, however properly written ActiveX controls are happy to install themselves on a per user basis. As long as you are warned and given the option to say no, there is no issue, it gives the user a way to make it work without having to go to command line to register the component or finding a gui tool to do it.

Here's the problem I have with this statement. Sure, you can write secure ActiveX if you know what you're doing. But in my experience, most still-being-written ActiveX code seems to be put together by poorly trained coders who, back in 2003, took a 2-day free Microsoft course "how to quickly and easily write intranet apps" and who have never updated their skillset since then. Those intranet developers who HAVE updated their skills stopped using ActiveX when it became obvious that being tied to IE-only development was not a good long-term strategy for numerous reasons - everything they've done in the last several years has been more of a LAMP-style model (even if it's on a Windows server with MS SQL behind it) that works with any reasonably recent client browser and doesn't treat HTTP as just a delivery platform for transferring Windows applications from server to desktop.

Re:Microsoft Virus Installer

[MrEricSir]

I think you're missing the point here -- ActiveX was built to do things that it should never have been allowed to do, and with minimal user interaction.

Microsoft encourages writing a "proper" ActiveX control, sure. But your boss will not. Why? Because that "proper" control means more warnings for the user, and more warnings are bad for business. What you're referring to as a "broken" ActiveX control is a "perfect" ActiveX control to the guys in suits.

Re:Microsoft Virus Installer

[Anonymous Coward]

blah blah blah Micro$haft announces new anti-virus technology blah blah blah
Next day: blah blah Cert advisories announce that Microsoft's new technology has significant flaws blah blah blah
Next day: blah blah blah New virus exploits micro$oft new technology...blah blah blah...
Next year: blah blah blah Symantic actually have seen the new viruses in the wild blah blah blah..

Note: The DEP/ASLR crap that is featured in Windows XP SR3, has plenty of back doors to keep Symantic in anti-virus blood-money for years.
Its STILL vulnerable even after the recent patch.

Microsoft really needs to be taken down a few notches...

Re:Microsoft Virus Installer

[kevinmenzel]

XP has back doors? If only Microsoft would release a new version of the OS with some of those blocked. OH WAIT. THEY DID. TWICE. Not to mention that if they ever say, included the functionality of say MS Security Essentials in the OS, well, they would never be allowed to because OMG monopoly.

Re:Microsoft Virus Installer

[Gravis Zero]

The problem is that ActiveX is more or less a GLOBAL, system wide plugin system versus a web browser specific api like nsplugin.

almost all browsers, except IE uses the "nsplugin" aka NPAPI. this means that the MAJORITY of browsers use NPAPI. so what's the problem? check it out...

NPAPI is solely for Internet plugins, while ActiveX is used for a wide variety of purposes, including application composition in windows applications. A typical Windows user has a vast array of ActiveX controls installed, a number of which are probably marked "safe for scripting", but are not actually secure.

Re:Microsoft Virus Installer

[Anonymous Coward]

Microsoft encourages writing a "proper" ActiveX control, sure. But your boss will not. Why? Because that "proper" control means more warnings for the user, and more warnings are bad for business. What you're referring to as a "broken" ActiveX control is a "perfect" ActiveX control to the guys in suits.

It's actually the other way around, and GP is saying as much. A properly authored ActiveX control will not demand more privileges than it requires, so if it does not require admin privs, it will not prompt you for it either. An improperly written ActiveX control will incorrectly prompt you for elevated privs that it does not required, and hence becomes both a security risk, and an extra click (at least) for users.

Re:Microsoft Virus Installer

[Anonymous Coward]

The overall features provided by ActiveX surpass pretty much every other plugin system currently implemented, they are essentially self describing DLLs that contain everything needed for any random developer to use, no source code required (which of course OSS fans don't appreciate but thats another story entirely).

Very true. Even in an open source world, a well-defined component model with bindings to every language would be incredibly useful. But there isn't one, and nobody seems to understand what they're missing. The standard response is "have you looked at dbus", which entirely misses the point.

BTW, .Net is not built on COM.

Re:Microsoft Virus Installer

[Anonymous Coward]

> Microsoft has COM, which ActiveX is built on (And the entire .NET framework as well)

Overall, your post is accurate. However, I'm a Microsoft developer who has worked directly with the .NET Framework source base for years, and this statement is not accurate. The .NET Framework includes support for interoperating with COM, but the .NET Framework is not based on COM. It is a JIT-based implementation of the (publicly-available-for-free-as-in-beer-and-free-as-in-IP-rights) MSIL/CIL ECMA standard. You could remove all COM support from .NET and most of it would still work. That's exactly what was done for the stripped-down version of the .NET Framework that runs on the XBOX 360 and on Win Phone 7.

"Web pages run on your PC"

[Anonymous Coward]

"Web pages run on your PC"
Run? RUN?

Re:"Web pages run on your PC"

[ThePromenader]

...they crawl on mine.

NoScript

[slinches]

This may be a dumb question (IANAWD), but does this also block javascript from the same site? If so, it seems like MS is making the basic features of NoScript available to IE users. Seems like a good idea to me. With this I might not hate IE9 that much as long as they move the home, stop and refresh buttons back to a sane location.

Re:NoScript

[jack2000]

The basic features of NoScript exist for IE since forever, you can define custom levels of trust for stuff like Javascript, cookies and ActiveX per zones, you can stick sties into trusted and untrusted with variety of customization for each. It's just that getting to that and configuring it is going to be hectic for joe6pack and no one has noticed it.

I wouldn't care about this myself if I didn't have to support IE for people who absolutely must use it. :\

Re:NoScript

[dakameleon]

No, Javascript is not an ActiveX plugin.

How Slashdot perceives things

[bonch]

Slashdotters on Google Native Client: "Native code running in the browser is the future! I can't believe this. It's amazing! Google rocks."

Slashdotters on ActiveX: "Haha, even Microsoft is adding a way to turn off ActiveX. It sucks. Look at that caption saying it can interfere with a webpage! Hahaha! Who ever thought native code in the browser was a good idea?"

Re:How Slashdot perceives things

[MrEricSir]

Google Native Client has a code verifier and requires the use of a custom version of the C library.

So while it might potentially have negative consequences, Google has learned from the mistakes of ActiveX.

Re:How Slashdot perceives things

[Anonymous Coward]

I wish I had 5000000000 mod point thingys to give you.

Re:How Slashdot perceives things

[im_thatoneguy]

It's even worse since it also goes:

Android on Choice: "Let the user choose what programs and features they want to run? Yay freedom!"
Microsoft on Choice: "Option to turn feature on? Users are too stupid to be trusted with extra features!"

Re:How Slashdot perceives things

[BitZtream]

A custom C library doesn't matter, if its 'native code' the C library is irrelevant as you're producing x86 machine code in the final NCI file.

To be safe, they essentially need to run it in a virtual machine without access outside the VM.

x86 code verifiers are about as useful as enabling heuristics detection in a virus scanners, the only thing they catch is something thats already more or less been seen in the exact same sort of form.

Re:How Slashdot perceives things

[jonwil]

The difference is that ActiveX is allowed to do anything it likes, Google Native Client is sandboxed and limited.

Re:How Slashdot perceives things

[Simon80]

Code verification in this context doesn't imply an attempt to understand the intent of code before running it. Rather, they verify that the code sticks to a safe subset of possible operations that effectively sandbox it out of being able to do anything nasty. They seem to have thorough design documentation on their wiki. I have no prior familiarity with NaCl, but this seems like an appropriate page to look at: http://www.chromium.org/nativeclient/design-documents/nacl-sfi-model-on-x86-64-systems

Re:How Slashdot perceives things

[washort]

Ignorance on parade.

Re:How Slashdot perceives things

[Anonymous Coward]

A code verifier is certainly effective when it refuses to run the assembly upon finding unsafe opcodes. That's precisely why Native Client requires a custom compiler, and is why NaCl binaries are slower compared to regular native binaries.

As if that's not enough, the processes are then chrooted on Linux, and are assigned a null token on Windows & run under low-integrity mode.

Re:How Slashdot perceives things

[Anonymous Coward]

Quote:

"Because Native Client runs within its own sandboxed execution space and validates executable modules against a special set of rules designed to protect the resources on the user's system, it offers the safety of traditional web apps in addition to its native performance benefits."

Re:How Slashdot perceives things

[Jahava]

A custom C library doesn't matter, if its 'native code' the C library is irrelevant as you're producing x86 machine code in the final NCI file.

To be safe, they essentially need to run it in a virtual machine without access outside the VM.

x86 code verifiers are about as useful as enabling heuristics detection in a virus scanners, the only thing they catch is something thats already more or less been seen in the exact same sort of form.

Maybe you should read up a bit on it before you make stupid comments. Their code verifier doesn't scan for known attacks (antivirus-style). Instead, Google has identified a subset of instructions which, when run in a specific sandboxed environment, eliminate the ability for the code to perform malicious activities. One pruning of the instruction set removes instructions that enable code to hide from the verifier (alignment requirements, removal of register jumps, etc.). The second constrains the instruction set, removing things like direct system calls, far jumps, etc.

The system also uses x86 segmentation capabilities to enforce a specific sandboxed execution environment. Doing this implicitly limits the scope of the code's branching and allows the verifier to make some critical assumptions that validate the assembly.

Rather than reproduce the paper, you should check out the link that I provided. Regardless, to say that the code verifier is not adequate is just foolish. The papers clearly explain, using logical proofs, how the various constraints enforced by the NaCl runtime, sandboxes, and code verifier are enforceable and provide reliable security. The "custom C library" is used in conjunction with the constraints to retain a general usefulness, facilitate inter-process communication (the primary mechanism of action), and work within NaCl constraints to perform higher-level operations like system calls.

Re:How Slashdot perceives things

[darkpixel2k]

It's even worse since it also goes:

Android on Choice: "Let the user choose what programs and features they want to run? Yay freedom!" Microsoft on Choice: "Option to turn feature on? Windows Users are too stupid to be trusted with extra features!"

Fixed that for you...

Re:How Slashdot perceives things

[shaper]

Not all of us. IMHO, native code in the browser is still a bad idea and an unnecessary one at that, regardless of who is doing it, Microsoft or Google. The state of the web is progressing very nicely without introducing potential security problems and platform dependencies. And yes, Google Native Client is platform specific to both hardware and OS. There are a few potential hiccups looming with (the language formerly known as) HTML5 and standard technologies like video codecs. But I'd still rather go that route than just go native.

Re:How Slashdot perceives things

[Anonymous Coward]

No matter how hard you try, HTML5 and JavaScript will never be able to simulate large 3D environments, regardless of any browser enhancements made over the next 10 years.

Maybe now you understand the purpose of NaCl - it isn't there to replace anything currently on the web; the only thing it's possibly a remote threat to is Silverlight and desktop applications. A standard webpage would never use it.

Re:How Slashdot perceives things

[gig]

Running anything other than HTML, CSS, and JavaScript in the browser is antiquated and impractical.

If you want to run native code, there are native windows for that.

Re:How Slashdot perceives things

[gig]

There's a markup standard called W3C HTML5 with 100% deployment on every platform. There's an audio video standard called ISO MPEG-4 with 100% deployment on every platform. There's a photo standard called ISO JPEG with 100% deployment on every platform. Every PC, smartphone, and set-top comes out of the box with support for all of these standards and more. The ISO standards are hard coded into every GPU. The only issues are with legacy devices, but HTML5 provided many ways to deal with that until time takes care of it for good. For example, you provide fallback content for modern tags in your markup and you play ISO media in FlashPlayer or QuickTime Player on PC's with IE6-IE8 or Firefox. You still have 100% support.

So there is no need for running native code in the browser.

Re:How Slashdot perceives things

[Nutria]

GNOME on Choice: "Option to turn feature on? Users are too stupid to be trusted with extra features!"

Fixed that for you...

Re:How Slashdot perceives things

[Anonymous Coward]

Although I agree with you, there was a time and there are still many semantic web nazi's who think javascript should not be included in that group. Its so funny how these things change. First its never build your site to depend on javascript. Today its almost expected you have features that will utilize javascript.

Re:How Slashdot perceives things

[Anonymous Coward]

Cool story bro. Now tell all of us retarded Flash and Silverlight programmers how to do this using JS and WebGL: http://www.youtube.com/watch?v=qRrX7Rb1PdA.

Or how about an HTML5 image editor which isn't slow as fuck at complex image operations?

Re:How Slashdot perceives things

[bytesex]

But you can never prove that code is not going to smash the stack. Or the context that I'll be in, when that happens.

Re:How Slashdot perceives things

[hairyfeet]

And I can see their point as JavaScript sucks security wise. lets be honest folks all these hacks like NoScript and sandboxing is just bandaids on bullet wounds, when what we need is either to rewrite JavaScript from the ground up with a focus on security or come up with a new language that allows the features we have come to depend on without having the wide latitude that we have with JavaScript.

I mean it is pretty sad that by just blocking JavaScript ads with ABP I cut my customers infection rate by a good 70%+ and if I add NoScript to that their risk of infection drops to practically nothing. I have a feeling we are gonna end up with the JavaScript equivalent of Code Red and then we'll have to find something else to use on websites because folks will simply kill JavaScript the way they don't use ActiveX anymore.

It is frankly just getting too risky to allow much JavaScript and while I feel sorry for website owners when so much malware comes in via JavaScript ads it simply isn't wise to allow them at all.

Re:How Slashdot perceives things

[Anonymous Coward]

ActiveX is sandboxed too... ooops ! Forgot this was slashdot.. carry on.

Re:How Slashdot perceives things

[Anonymous Coward]

Slashdotters on Google Native Client: "Native code running in the browser is the future! I can't believe this. It's amazing! Google rocks."

Slashdotters on ActiveX: "Haha, even Microsoft is adding a way to turn off ActiveX. It sucks. Look at that caption saying it can interfere with a webpage! Hahaha! Who ever thought native code in the browser was a good idea?"

Name one "Slashdotter" who has expressed both of those opinions. You won't, because you can't.

I thought ActiveX died

[bedouin]

Like -- in iE7 or something?

At least I haven't encountered it in years.

Re:I thought ActiveX died

[dakameleon]

ActiveX is the plugin mechanism for IE - they haven't replaced that yet, and it's not like they would replace it with the NPAPI mechanism used in Firefox, Chrome et al.

Incorrect, Flash runs in IE sandbox

[Anonymous Coward]

ActiveX in IE has supported sandboxing since IE7. Flash was one of the first to use it. MS has designed a method for plugins (ActiveX controls) running inside a sandbox to reach the outside: Broker processes. IE comes with a general purpose broker process (which has never been broken). Flash has their own broker process (which was broken at one time).

I'll punch the next in the face...

[Anonymous Coward]

...who utters the phrase "web experience".

Re:1st post

[andrea.sartori]

You are a moron.

O RLY?

[GameboyRMH]

No matter how hard you try, HTML5 and JavaScript will never be able to simulate large 3D environments, regardless of any browser enhancements made over the next 10 years.

Good thing nobody told that to these guys:

http://en.wikipedia.org/wiki/WebGL

http://www.youtube.com/watch?v=Vva36undIss&feature=related

Re:O RLY?

[Anonymous Coward]

That's rendering, not simulating. Now try to process a busy environment using Javascript and you'll think you were programming in Ruby.

Re:O RLY?

[GameboyRMH]

"Simulating" can mean a lot of things. I can simulate a ball bouncing in a large transparent box at 1/10th speed and that will be a simulated large 3D environment. That shouldn't bog down a JS engine too much.

Re:1st post

[Anonymous Coward]

Please stop feeding the trolls.
By replying to them you make them more visible even after moderation because you start with 2 mod points.

Wow!

[mordejai]

C'mon guys, give them a break... it's not like other browsers have supported this for, I dunno, five years, because they put the user in charge instead of the content providers... Right?

You see a lot of it in ASP.NET development

[Anonymous Coward]

E.G.-> Crystal Reports in business apps @ work/on the job.

(As an aside, & another example, albeit online instead of in a corporte intranet environs, but rather on the public internet? Korea is also way, Way, WAY into ActiveX, & yes, online on the public internet to this day from what I understand also, but, I am not 100% sure why (banking maybe? Again - not totally sure!))

APK

P.S.=> It's like the older VB .OCX model, plugins you can use to extend apps, albeit in this case, webbrowser applications with Crystal Reports putting in ActiveX into ASP.NET (the faster than ASP server-side marshalled ISAPI DLL with garbage cleanup & runtime driven)... apk