IE8 Security Part II: ActiveX Improvements

re: IE8 Security Part II: ActiveX Improvements

someone — Wed, 07 May 2008 22:10:09 GMT

All these security improvements for XP and Vista users while other Windows versions don't even get the core improvements made in IE6 for XPSP2. It's still possible in IE6SP1 to malware to silently install an ActiveX control. Although the marketshare of these operating systems is negligible, it makes no sense supporting IE6SP1 or IE5 SP4 because anyways they're so insecure, users of these OSes will be forced to use an alternative browser.

re: IE8 Security Part II: ActiveX Improvements

jes — Wed, 07 May 2008 23:13:43 GMT

ActiveX Improvements is nice can we also have the option to temporary install an activeX add-on then when we close the IE browser it delete or disable the add-on. In standard user account (non-admin in Vista) when user choose to "install this add-on for all user on this user" will they be prompted with a UAC password.

The Favorites Bar is nice but can you also add a search favorite or search commands functionality so user can find what ever they want in IE 8 User interface. Something similar to the office 2007 search command add-ins.

re: IE8 Security Part II: ActiveX Improvements

Mark Sowul — Wed, 07 May 2008 23:56:53 GMT

Wow, per-user ActiveX - that's pretty huge (and arguably how it should have been done since the beginning).

re: IE8 Security Part II: ActiveX Improvements

PS — Thu, 08 May 2008 03:29:08 GMT

I will agree that it could have been done from the beginning, but we should remember the first environment that IE was developed for... the Win9x environment.

In any case I'm happy to see something like this, please continue making our life (as sysadmins) a bit easier!!

re: IE8 Security Part II: ActiveX Improvements

internet security — Thu, 08 May 2008 05:23:00 GMT

It's good that IE 8 has this feature. Improving the security measures on the Internet is a very good idea. Internet security nowadays are at risk since hackers are always ready to do their unpleasant doings. There are many preventive measures, all we have to do is follow what is right.

re: IE8 Security Part II: ActiveX Improvements

Mike — Thu, 08 May 2008 07:22:13 GMT

Will this feature be enabled for XP users as well?

----------------------------

Running IE8 in Windows Vista, a standard user may install ActiveX controls in their own user profile without requiring administrative privileges

----------------------------

This makes it seem like it won't but a definate answer would be awsome.

re: IE8 Security Part II: ActiveX Improvements

mattcrow [msft] — Thu, 08 May 2008 08:05:46 GMT

@Mike: The per-user ActiveX feature is for Vista and higher.

re: IE8 Security Part II: ActiveX Improvements

Andreas Lanjerud — Thu, 08 May 2008 12:20:57 GMT

Does this work without "Emulate IE7" too?

re: IE8 Security Part II: ActiveX Improvements

Mitch 74 — Thu, 08 May 2008 12:41:36 GMT

And what, pray tell, prevents per-user ActiveX to be implemented in XP?

Oh, sorry: limited user accounts in XP are unusable anyway; it would have worked with Win 2000 (which has working 'advanced users' accounts), but since Win 2000 is stuck with IE 5 and 6 (at best) anyway...

I guess then that users of Win XP will just switch to other browsers that allow user-level extensions and plugin installations, and get rid of ActiveX altogether.

If they haven't already done so.

...

You do realize that this 'great security improvement' can only be used to demonstrate how ANCIENT IE actually is? I mean, program a Firefox extension today, it already works as a user level extension only, works with all OS version supported by Firefox (from win9x to Vista), and as long as it doesn't make use of assembly language or OS dependent features (relying on Gecko's CSS, HTML and Javascript engine), can run ANYWHERE Gecko has been ported, and in the browser's context?

What's left to implement is an independent Javascript engine (but then, Chris Wilson protested the Mozilla's foundation attempt at writing one that could be plugged into IE, so, either you're arrogant, or you're not planning to do that), and you'd get a browser mostly unstuck from the OS, and the ability to improve it again.

...

Remember that XP just got a new lease on life, due to Vista being too bloated to run on machines that are all the rage today: UMPCs. So, spending time improving ActiveX just for Vista is of little to no interest, especially when your competitors are going at these new markets aggressively:

- Firefox 3 got a smaller footprint than version 2, making it eligible to run on very small devices;

- Opera already is there;

- KHTML/Webkit are geared to go that way too.

What browser do you want to see outside the desktop? If people spend more time with their mobile devices, and notice that they can keep the same browser in and out of their desktop machine, and cumulate it with nice stuff like roaming browser preferences (yes, it exists for at least Firefox, hosted by Google), what's getting more interesting? IE 8, glued to costly, underperforming machines, or Firefox/Webkit/Opera that you can bring with you?

If separating first rendering contexts, then ActiveX from the core OS is part of a strategy to unglue IE from Windows, it's really good, congrats!

If not, pfeh.

re: IE8 Security Part II: ActiveX Improvements

rdavl — Thu, 08 May 2008 13:31:41 GMT

First of all you should all burn in hell for ever making Internet Explorer 6 and any kind of Active X...

And as for the security concerns with Active X, how can you patch up something that is fundamentally flawed!?

Get rid of the IE and make windows installs with FF or something, links even ffs.

Or buy opera and name it IE but just make it work for F+ sake!

re: IE8 Security Part II: ActiveX Improvements

fr — Thu, 08 May 2008 15:05:32 GMT

The earlier suggestion of temporary activex would be good, there are occasions where I would like to use something which requires activex but am unlikely to need it again.

re: IE8 Security Part II: ActiveX Improvements

killbits question — Thu, 08 May 2008 15:53:37 GMT

I have to question the real value of killbits. If the vendor knows there's a vulnerability in their Active-X tool wouldn't it make more sense for them to just patch the vulnerability itself unless the vulnerability is required for the add-on to work right? They'd probably have to be close to being able to patch it if they were going to come up with a killbit that wouldn't break their add-on since there's no reason to swallow the pill if it's working fine.

From my viewpoint, which I'll admit isn't as a security expert or researcher in any way, it looks like the killbits only real value would be as a temporary fix while the group responsible for the add-on patches the vulnerability, but even then that assumes that a windows update including the kill bit will come out before the team can fix their problem. The other possibilities I can think of are use the killbit on an add-on that needs something that creates the vulnerability to work, just patch it w/o the killbit if it will still work, or completely ignore this if the add-on will not work without the vulnerability and having a killbit stop the add-on from working is not a possibility.

Either they know enough about the vulnerability to patch it if they're going to set a unobtrusive killbit or the add-on will not work if it's patched or has a killbit set. Is there some middle ground I'm missing here, not counting the set up of an obtrusive killbit?

re: IE8 Security Part II: ActiveX Improvements

User Access Control - Huh? — Thu, 08 May 2008 16:46:10 GMT

Re: "Running IE8 in Windows Vista, a standard user may install ActiveX controls in their own user profile without requiring administrative privileges"

So what you are telling us, is that although IT has locked down what you can do on your PC, you can now in fact evade those security measures and install all the spyware infected "CoolSearch", "MyWay", "BonziBuddy", "360" toolbars you want now.

Can't wait to see how the IT Crowd responds to this when the news gets out.

re: IE8 Security Part II: ActiveX Improvements

SamY — Thu, 08 May 2008 17:35:01 GMT

@User Access Control - Huh?

What part of "While this feature offers the possibility of lowering total cost of ownership, IT Administrators running managed environments may elect to disable this feature via Group Policy." do you not understand?

re: IE8 Security Part II: ActiveX Improvements

Dave — Thu, 08 May 2008 18:19:56 GMT

I'd really like a solution where I don't have to train every user to decide whether to trust an add-on.

re: IE8 Security Part II: ActiveX Improvements

Marshall — Thu, 08 May 2008 18:52:19 GMT

@@killbits question: The problem is that a bad guy could save a copy of the buggy/signed AX control on his server and offer to install it from his page. Without a killbit, the buggy old version can be installed & run.

Anyone claiming that Firefox's model is somehow magically better than ActiveX doesn't really understand Firefox's NPAPI plugin model.

re: IE8 Security Part II: ActiveX Improvements

Killbits — Thu, 08 May 2008 19:20:06 GMT

Thanks for the reply. I had not thought of that. How easy/hard is it for someone to do that, and how easy/hard is it to install an older version of an add-on over the newer one?

I've never actually let an active-x thing download/run on my machine and take the view of, if your site needs it, I don't need your site; because of this I have not had enough exposure to know the difficulty of setting up the exploit you mention above. I'll fully admit it's a good reason for killbits I didn't think of, but knowing the difficulty level of the exploit and therefore how many people could actually use it is important for determining how big the problem being fixed is.

IE8 Security Part II: ActiveX Improvements

Donna's SecurityFlash — Thu, 08 May 2008 23:40:09 GMT

IE Team describes the ActiveX improvements in IE8 and summarize the existing ActiveX-related security

re: IE8 Security Part II: ActiveX Improvements

bond — Fri, 09 May 2008 06:52:03 GMT

"Running IE8 in Windows Vista, a standard user may install ActiveX controls in their own user profile without requiring administrative privileges"

An ActiveX improvement means going back the old xp way user will fall victim on malicios activeX. I feel it's a Bad choice to allow a standard user to install activeX control without requiring administrative privileges. Sure the overall system will be unaffected if standard user install a malicious ActiveX control but you're putting inexperienced user (kids, mothers...Etc) at risk and to be an easy target for dangerous active X. Right now I don’t like that admin(possibly home user)have to go through Group Policy to disable this feature I think If you are going to allow standard user to install active X then I think you should add a UI option for user(admin) to easily turn on the default setting which require administrative privilege on every activeX. You have to choose between usability and security but you went with usability user experience.

re: IE8 Security Part II: ActiveX Improvements

bond — Fri, 09 May 2008 07:18:08 GMT

Basically what I'm saying earlier is that I'm concern about the user. Do you really want the user to look at the information bar and hope that he/she make the right decision in installing activeX.

re: IE8 Security Part II: ActiveX Improvements

PatriotB — Fri, 09 May 2008 08:25:55 GMT

@bond -- it's no different than the browser allowing you to download arbirary EXEs and the OS allowing you to run them. Those arbitrary EXEs can install ActiveX controls within your user profile (this goes as far back as Windows 2000 with per-user COM registration under HKEY_CURRENT_USER).

What IE8 is doing is taking the "in-browser" installation mechanism, and allowing that to be per-user as well.

re: IE8 Security Part II: ActiveX Improvements

Lance — Fri, 09 May 2008 14:16:54 GMT

As well as the 'install...' options, how about an 'Ignore this request from this site' option.

re: IE8 Security Part II: ActiveX Improvements

Dominic Shiells — Fri, 09 May 2008 21:05:01 GMT

Can Silverlight be added as part of the operating system say a part of Windows XP, as it is allready part of Vista, as it is annoying!

Could you with activeX make it more open source!

re: IE8 Security Part II: ActiveX Improvements

Crisp — Sat, 10 May 2008 01:14:16 GMT

I like how you're using Google as your search engine on those screenshots. Replacing MSN search with Google would be a really good improvement in IE8. ;)

re: IE8 Security Part II: ActiveX Improvements

Steven Roussey — Sat, 10 May 2008 03:07:13 GMT

Per session installation would be a great option.

And ignore the idiots that don't even know the difference between a firefox plugin, and a firefox extension. Sheesh.

Though when you get silverlight merged with IE (for IE9), then 'extensions' could be written in that, I suppose.

re: IE8 Security Part II: ActiveX Improvements

logistyka — Sun, 11 May 2008 01:03:35 GMT

That post is very good, thank you it is very interesting ;)

re: IE8 Security Part II: ActiveX Improvements

Mitch 74 — Sun, 11 May 2008 14:59:01 GMT

@Roussey: the difference between a Firefox plugin and a Firefox extension is that a plugin is a third-party installable binary that can interact with Firefox; this goes back to the Netscape plugin model, and is usually a system-wide installed software in its own right that gives a handle and a API for some web page content to use it. Current plugins are the Sun Java plugin and the Adobe Flash plugin.

This model is flawed like ActiveX is, this is why more and more recent improvements to Firefox are done with extensions; but even then, plugins can be installed as user-level restricted binaries - while ActiveX has full SYSTEM read/write/execute access (yes, that was really, really dumb).

In short, an extension can make use of the browser's own capabilities to do something un-browser-like, like (as is the case with Firefox) use the chrome engine (which is also Gecko) to create a different GUI, then use the Javascript engine to animate it etc.

In some cases, an extension can access another, external program to run something more intricate through Firefox's own mechanisms; that's the case with the ActiveX wrapper extension used to work Windows Media player's ActiveX control inside the browser.

You can perfectly run Firefox unpacked as a standalone software in a limited account in Windows XP, and have its plugins installed as local user binaries too (that's the way it works in Linux, for example). You have all the power of the brower available to you, but it's safeguarded inside your user space - subverting the machine requires the user to be root, or a privilege escalation hack.

What I said in my previous comment then, was that if the IE team is currently trying to unglue IE from the system, then it will also be usable safely inside a limited user account; with the HTML renderer done, and now the ActiveX part, that leaves the Jscript engine part of the system.

However, Chris Wilson rejected Mozilla's project to write an external, user-installable ECMAscript 4-compliant engine for IE, leaving us with Microsoft's seven years old Jscript 5.7, tied into the system, leaks and all, under the pretext that only Microsoft knows how to do a Microsoft Javascript-like engine, but the Jscript team won't do more than mere bug fixing in Jscript anyway.

Now, does anyone want to bet when we'll see an XHTML parser in IE? Or a MathML one, or a SVG one?

re: IE8 Security Part II: ActiveX Improvements

Frank — Sun, 11 May 2008 23:47:50 GMT

@Match74: Before displaying your lack of understanding in a public forum, you should do some basic research.

You can already run IE in a limited user account just fine.

Your assertion that ActiveX runs with "SYSTEM" permissions is incorrect. ActiveX runs with the permissions of the current user.

Further, your claim that IE runs with a "seven year old" version of Javascript is also incorrect; beyond the improvements made in the version of Javascript shipped with IE7, myriad improvements have been made thus far in IE8. If you check out the benchmarks, you'll find that it's far faster than the older version it replaced. The JScript engine isn't "tied to the system"-- it's a standards IActiveScript engine that runs in the IE IActiveScript host.

re: IE8 Security Part II: ActiveX Improvements

JRG — Mon, 12 May 2008 03:02:30 GMT

These are good improvements to IE, I am very much looking forward to IE8 and beyond.

re: IE8 Security Part II: ActiveX Improvements

pcolmer — Mon, 12 May 2008 13:36:02 GMT

It is a shame that this isn't going to be supported on XP.

--Philip

re: IE8 Security Part II: ActiveX Improvements

StevenR — Tue, 13 May 2008 02:57:36 GMT

It is a shame that this isn't going to be supported on Windows 95.

re: IE8 Security Part II: ActiveX Improvements

Ajay Pathak — Tue, 13 May 2008 03:29:11 GMT

these are ver y good improvements introduced by ie 8 team

re: IE8 Security Part II: ActiveX Improvements

chaz — Tue, 13 May 2008 06:37:26 GMT

Just hated it when one website causes IE 7 to freeze or slow down and it effect every other website in IE 7. Can you isolate the website so that all other website”IE tabs” are not affected?

Thank you very much

almhml — Tue, 13 May 2008 19:29:33 GMT

I should be watching this Code

Thank you very much

re: IE8 Security Part II: ActiveX Improvements

Mitch 74 — Thu, 15 May 2008 01:37:34 GMT

It seems my first answer to Frank was moderated, or something...

Running an application in a limited account is one thing; running an application in a limited account, said application having access to other authorizations the user has, is called process-bound privilege escalation; it means the process can do stuff the user by itself should be unable to do.

It seems safe enough; the application should be written to do only what it's supposed to do, and its evolved privileges can't be abused.

Until you get a little bit of code hitting a bug in the application, and processing an unexpected bit of code with the process' privileges.

Or, in other words, a user with a limited account goes to a web page with IE, runs a bit of code that hits the Jscript engine, or an ActiveX control in an unexpected way, triggering a buffer overflow and some exploit code execution with IE's, Jscript's or ActiveX's privileges - as in, SYSTEM authorizations (even better than Administrator).

Now, we learned last time that since IE7, and now even better in IE8, IE actually runs in user space with user's authorizations in Vista (and maybe XP, too, I don't remember) and, now, ActiveX can do the same in Vista: run with user's authorizations, no longer with SYSTEM authorizations. Two down (in Vista; XP still lags behind with those).

That leaves Jscript, which is supposed to have its own security model, but hasn't been improved for years, apart from bug fixing. What you read about IE Jscript improvements, were IE's improved W3C DOM: Jscript, which is still ECMAscript 3 compliant (since 1999), can work more correctly with Jscript and declares more properties and functions to its browser objects. The language hasn't changed, the interpreter either, and the garbage collector still barely collects.

What's left? Well, if Microsoft finally goes all the way, we'll have IE, ActiveX and Jscript all running as user-level, user-space processes, without access to the rest of the system and little risk to get meaningful attacks and zombified systems. Maybe with IE 8, Jscript 6.0 and Vista or Windows 7.

Or, you can get a 2k/XP/2k3 system, install Firefox in your limited user account, install those few plugins you really need, and a bunch of extensions, and achieve the same result.

re: IE8 Security Part II: ActiveX Improvements

EricLaw [MSFT] — Thu, 15 May 2008 02:37:13 GMT

Mitch74: I think you misunderstand how IE, Javascript, and ActiveX run.

On all current Windows platforms, IE & Javascript run with the user's permissions (or lower) and not "System" as you suggest.

It's ~possible~ to develop an ActiveX control that calls into a collaborating service running with higher level of permission, but such an architecture is very rare; the vast majority of ActiveX controls run only with user permissions.

The advantage of IE7 on Vista (over competitive browsers) is that IE, Javascript, and ActiveX all run at "Low" Integrity, which means they run with even fewer permissions than the user has in their "Limited" account. Thus, even if IE is compromised, the user's documents and applications cannot be modified/deleted/etc.

re: IE8 Security Part II: ActiveX Improvements

Mitch 74 — Fri, 16 May 2008 12:45:11 GMT

Thank you Eric for the clarification.

My experiences, every time I used IE on a Windows machine, led to complete system subversion in under a few minutes (less with IE 7, true), or, in a very limited user account with manually locked down file authorizations, prompts everywhere and non-working controls at the drop of a hat - which makes what you say quite hard to relate to.

Or maybe, those cases where the system was zombified (I do mean, clean Win XP installs with updates, no OEM customizations, no third-party softwares - I don't like bloat) may then have been as you say, a user-level ActiveX and/or Jscript seizing control of another Windows process and using said process to gain privilege escalation.

But then, if, as you say, on all current Windows platforms, mshtml, ActiveX controls and Jscript run with current user's authorizations, they should be able to run with ONLY a user's authorizations, and be installed in a user's profile, with no administrator rights. Something like, user 1 has IE 6 installed in his profile with Jscript 5.4 and a Flash 7 ActiveX control, user 2 has IE 7 installed with Jscript 5.6 and a Flash 8.5 ActiveX control, and user 3 has has IE 8 with Jscript 6.0 and Sun Java 1.7 plugin, on the same system.

what I distrust is the fact that, currently, even if the process runs in a user's space, the file the process started from (because Windows PE still need to run from a disk's binary) has Administrator rights.

Stop me if I'm wrong, but let's take mshtml.dll: it is run as a user-level process, all right; an attack makes it modify itself in memory (buffer overflow, etc.); due to the way a Windows process is linked to its originating binary, it can then modify its originating file, and next time the file is read and run in a SYSTEM context or Administrator context (say, when the Windows Help service restarts), whatever was written in the binary gets executed with said elevated privileges.

Several processes may mitigate the success of such an attack: on reboot, the modified mshtml.dll file would be restored from the dll cache (maybe not on Windows 2000), an antivirus may catch it...

But then, a 0-day attack (not detected by AV) restarting the Windows Help service (by causing a crash) right after infecting mshtml.dll (before it's caught by SFP) will have said code running in a SYSTEM context. As far as I know, that's a similar process (more complicated) that used Flash (an ActiveX control, running as a Low process) to compromise Vista SP1 (with UAC enabled) recently. XP doesn't even require privilege escalation, as limited accounts are unusable.

Don't tell me "that's impossible", if there's a MEAN then there's a WAY.

Under a POSIX system (Solaris, Linux, BSD), a process can start from a file that can only be executed ((--x)): it is read by the kernel, locked down in user space, and then run. The process belongs to a user's memory space and is separated from its originating binary, so it can't patch itself on disk even if subverted (in the case I just exposed, it can't even read itself), so this attack vector just plainly doesn't exist (it would need kernel-level privilege escalation) with properly set-up authorizations.

In Windows, something similar could be obtained by marking the files as being property of the user, and marking them off-limits to SYSTEM and Administrators (and other users). That would require that each and every user account that requires IE gets a copy of the file only he can execute (that can now be done with ActiveX, and MultipleIEs proved it can also be done with mshtml) barring all others, but that leaves... Jscript (and maybe one day msxml, if you ever start implementing XHTML, SVG and MathML support).

Too onerous in disk space? Let me count the ways...

- System32's copy of those files can be removed

- Dll cache, ditto

- System Restore, several times over

All it needs is a MSI package hosted in All Users, installed when required by a user.

About the other softwares using (as in my example) mshtml.dll, they are all user-level: SYSTEM doesn't need Help, Administrators don't need Flash and very little WWW access (a serious admin shouldn't browse recklessly), and Messenger should be able to detect and run user-installed mshtml and Flash.

Back to my point: when will Jscript be unglued from the system and the browser be made really user-level only?

re: IE8 Security Part II: ActiveX Improvements

Ted — Fri, 16 May 2008 17:59:10 GMT

Mitch--

"the file the process started from (because Windows PE still need to run from a disk's binary) has Administrator rights"

Files don't have rights; processes do. Most folders in the Program Files and Windows directory provide read and execute rights to all user accounts. They don't provide write access to normal User level accounts, and due to System File Protection, they often cannot be overwritten even as Admin.

The Flash compromised did not happen at all how you think it did, and recall that the terms of the CanSecWest conference were that "winning" meant reading a file from disk. Protected Mode doesn't attempt to protect from file system reads.

You really need to do more reading and less typing. Its clear that Windows isn't your system of choice, which is fine, but talking about Windows architecture as if you understand it is a mistake. If you're getting compromised on a patched version of Windows "within minutes" that says more about you than it does about windows.

-ted

re: IE8 Security Part II: ActiveX Improvements

Mitch074 — Sat, 17 May 2008 11:01:38 GMT

It seems a comment of mine got 'lost on upload' again or something.

To answer Ted: having used all MS OSes from MS-DOS 3.2 up to and including Vista, I do know a little bit about Windows. You should read up on ACL support for the Win32 naming space in NTFS. Specifically, a Win32 system can support the following on any file:

- read

- write

- become owner

- change authorizations

An authorization may be set as allow, neutral (check parent's) and deny (overrides all other settings).

A file can also inherit its parents' authorizations. Any number of user or group of users may be specified for a single file.

In a POSIX system (a namespace also supported in NTFS), a file has 3 users:

- owner

- group (may not be the owner's group)

- world

which each have 3 rights:

- read (boolean)

- write (boolean)

- execute (boolean).

All in all, the Win32 file authorization is MORE ADVANCED than POSIX's - it's just almost never used in Windows, even to protect Windows' own subsystem (the only exception is the System Volume Information folder, which merely contains the System Restore backups, and is never cleaned up if there's a lost snapshot: if you bemoan the loss of a few untraceable Gb of space, look no further).

IF mshtml.dll, the Jscript engine and ActiveX controls resided in a user's local profile (not anywhere in %SYSTEM%), with tight file access rights, not only would it allow side-by-side installation of IE versions, but it would also mean that IE couldn't be used in that way to hit the system.

For installation of a default version, nothing prevents an install package to be put in All Users, deployed every time a new user is created (a small check giving a user the choice: "default IE version is more recent than your installed version. Upgrade Y/N ?").

And last, subsystems requiring mshtml (like Install/Remove Software and MS Help) may simply link with a user's installed IE files, and be done with it.

So I'm asking again, since we already have a somewhat independent mshtml.dll (see MultipleIE), ActiveX controls (see article), when is Jscript becoming local too, so that IE can become unglued from the system?

re: IE8 Security Part II: ActiveX Improvements

mihaela — Sat, 17 May 2008 17:42:08 GMT

most ActiveX controls are global in nature; once installed, any web page can make use of them. This increases security exposure.

re: IE8 Security Part II: ActiveX Improvements

romanet — Sun, 18 May 2008 14:30:45 GMT

Another useful ActiveX control lets the Web distribute Microsoft PowerPoint Animation files directly to Internet Explorer, complete with transitions and other presentation attributes, but without the need for PowerPoint itself. Currently, the ActiveX control needs to be manually downloaded and installed from Microsoft at http://www.microsoft.com/mspowerpoint/internet/player/default.htm, but once you do, you can interactively work with PowerPoint files directly with your Web browser.

thanks

re: IE8 Security Part II: ActiveX Improvements

Hypotheek — Sun, 18 May 2008 19:42:31 GMT

Romanet, that is a pretty cool feature. Thanks for sharing!

re: IE8 Security Part II: ActiveX Improvements

andrewh6 — Tue, 20 May 2008 06:19:06 GMT

This is an excellent feature - it will be interesting to see over the next few years how bullet proof it is though.

re: IE8 Security Part II: ActiveX Improvements

amine — Tue, 20 May 2008 12:38:00 GMT

hhb tfv u i8y9 i8gifgu uuyfcuynyt

re: IE8 Security Part II: ActiveX Improvements

amine — Tue, 20 May 2008 12:38:11 GMT

hhb tfv u i8y9 i8gifgu uuyfcuynyt4ry 67m

IE8 and 'Killbits'

Robert McLaws: Windows Vista Edition — Tue, 27 May 2008 18:55:10 GMT

I was reading up about IE8 Beta 2 yesterday, and I came across an interesting post about how ActiveX

What's Coming in Internet Explorer 8 for IT Professionals?

IEBlog — Wed, 11 Jun 2008 23:00:46 GMT

Yesterday at Tech Ed IT Pro 2008 in Orlando we announced some of the enhancements we’re making in Internet

Firefox 3 - Come break a world record!

Bend in the Weather — Tue, 17 Jun 2008 16:27:26 GMT

At 3:00am AEST on Wednesday 18th of June will herald the release of Firefox 3. It's a big jump ahead from the heady days of Firefox 1 and Firefox 2 days. This version includes over 15,000 enhancements from the 2.x series. It's faster, funkier an

IE8 Security Part III: SmartScreen® Filter

IEBlog — Wed, 02 Jul 2008 19:02:13 GMT

As someone whose email address is posted in thousands of forum posts, newsgroup discussions, and blogs,

Internet Explorer 8 - Security

Timeless Journeys — Thu, 03 Jul 2008 13:07:03 GMT

Internet Explorer 8 - Security

8con의 생각

8con's me2DAY — Wed, 09 Jul 2008 16:56:39 GMT

번역은 나같은 초보가 함부로 손대는게 아니구나. 쉽지 않아 쉽지 않아.. 어쨌든 IE 8 보안 파트 2번역 다 했고, 곧 엔쵸비 블로그에 올라갈 예정..

만박의 생각

sumanpark's me2DAY — Mon, 21 Jul 2008 16:59:47 GMT

인터넷 익스플로러8에서 액티브X 없어진다고 낚는 기사 뭐임. 오히려 더 개선되는구만.

리거니의 생각

dykin's me2DAY — Sun, 27 Jul 2008 23:59:52 GMT

IE8의 ActiveX 관련 보안 문서. 그리고 Add-on 관리 기능. 참고로 IE7의 ActiveX 보안

IE 8 Beta2

Igor Macori — Wed, 13 Aug 2008 12:12:19 GMT

Si sta avvicinando a grandi passi il rilascio della Beta 2 della versione 8 di Internet Explorer . Come

불안을 줄여줄 Internet Explorer 8 베타2!

bkchung's WebLog — Thu, 28 Aug 2008 06:01:10 GMT

Windows Internet Explorer 8 Home page (홈페이지) Internet Explorer 8: Worldwide sites (다운로드) Internet Explorer

Consumers Begin Using Internet Explorer 8 Beta 2

US ISV Developer Evangelism Team — Thu, 28 Aug 2008 20:16:19 GMT

The next beta for Internet Explorer has been released for broad distribution to the public, according

Trustworthy Browsing with IE8: Summary

IEBlog — Fri, 29 Aug 2008 22:38:29 GMT

Back in June, Dean Hachamovitch kicked off a series of blog posts explaining how the IE team approached

IE8 Q&A: If the user doesn't have administrator rights, how do I install add-ons or enable ActiveX components?

Public Sector Developer Weblog — Wed, 08 Oct 2008 07:02:26 GMT

A: One of the new features for Internet Explorer 8 (Windows Vista only) is ability to install ActiveX

IE8 Security Part VIII: SmartScreen Filter Release Candidate Update

IEBlog — Mon, 09 Feb 2009 23:10:08 GMT

Hello, I'm Alex Glover and I'm the test owner of the SmartScreen Filter in Internet Explorer 8. The SmartScreen

IE8 Security Part VIII: SmartScreen Filter Release Candidate Update

Блог команды разработчиков Internet Explorer 8 — Wed, 18 Feb 2009 14:27:19 GMT

Изменения в фильтре SmartScreen в IE8 RC1 Привет, меня зовут Алекс Гловер (Alex Glover) и я являюсь главным

IE8 보안 2부 : ActiveX 보안 개선

IE8 팀 블로그 — Tue, 17 Mar 2009 11:49:10 GMT

    아래 글은 IEBlog에 올라온 IE 8 보안 관련 글 중 두번째 글을 번역한 것입니다. 현재 파트 5까지 나와있는데 시리즈로 번역할 예정입니다. 이 글 뿐

Internet Explorer 8 의 IT 관리자용 새로운 기능

IE8 팀 블로그 — Fri, 20 Mar 2009 10:21:32 GMT

    올랜도에서 개최된 Tech Ed IT Pro 2008 (영어) 에서 Internet Explorer 8 을 조직내에서 배포, 관리하기 위해, 몇가지 기능을

IE8 Security Part IX - Anti-Malware protection with IE8’s SmartScreen Filter

IEBlog — Thu, 26 Mar 2009 03:43:53 GMT

Over the last year, we’ve published two posts about how the IE8 SmartScreen ® filter helps to prevent

Безопасность IE8: защита от вредоносного ПО с помощью фильтра SmartScreen

Блог команды разработчиков Internet Explorer 8 — Mon, 30 Mar 2009 23:00:40 GMT

В прошлом году мы опубликовали пару статей о том, как фильтр IE8 SmartScreen помогает предотвращать фишинговые

End to End Trust and Windows 7

Windows Security Blog — Tue, 21 Apr 2009 20:51:35 GMT

I attended Scott Charney’s keynote this morning at RSA – Moving Towards End to End Trust: A Collaborative