Welcome to MSDN Blogs Sign in | Join | Help

Improvements to AutoPlay

As mentioned before on this blog (regarding our UAC changes) and on the IE blog (regarding the SmartScreen® filter for malware), we have an increased focus to enable customers to be in control and feel confident about the software that they choose to run on their computers. Folks on this blog have also commented about the concerns they have specifically in the AutoPlay area. This blog entry addresses some of the changes that we have made to increase customer confidence when using their media and devices with Windows.  It is authored by Arik Cohen, a program manager on the Core User Experience team. –Steven  [Note: There was a technical problem so this post was reposted in its entirety.]

Certain malware, including the Conficker worm, have started making use of the capabilities of AutoRun to provide a seemingly benign task to people – which masquerades as a Trojan Horse to get malware onto the computer. The malware then infects future devices plugged into that computer with the same Trojan Horse. For further information about Conficker please visit http://www.microsoft.com/protect/computer/viruses/worms/conficker.mspx

In the following example for a USB flash drive that has photos, malware registers as the benign task of “Open folders to view files.” If you select the first “Open folders to view files” (circled in red), you would be running malware. However, if you select the second task (circled in green), you would be safe running the Windows task.

Infected USB AutoPlay
Infected USB AutoPlay

People are confused why they have two tasks that appear to do the same thing – and even a knowledgeable person who is careful not to run software from an untrusted source can easily make the mistake of selecting the first task. As a result, people lose confidence and don’t feel in control.

A growing attack

While presenting an AutoRun task in AutoPlay has been available since Windows XP, we have seen a marked increase in the amount of malware that is using AutoRun as a potential method of propagation. According to the Security Intelligence Report, an enterprise study by Forefront Client Security found that the category of malware that can propagate via AutoRun accounted for 17.7% of infections in the second half of 2008 – the largest single category of malware infections.

The chart below shows the increasing amount of detection reports by Microsoft anti-virus software of the class of infections that spread via AutoRun. (Note: The actual method of infection cannot be determined.)

Infection Detections of Malware that Spread via AutoRun

Infection Detections of Malware that Spread via AutoRun

Currently, disabling AutoPlay completely is the only solution for consumers and enterprises to gain confidence with the use of USB flash devices on their computer. Guidance on disabling AutoPlay is available here.

Increasing customer confidence

Windows 7 introduces key changes to AutoPlay that keep you from being exposed inadvertently to malware like Conficker when doing your common scenarios with devices (e.g., get to the files on your USB flash drive, download pictures from an SD card, etc.).

In particular, Windows will no longer display the AutoRun task in the AutoPlay dialog for devices that are not removable optical media (CD/DVD.) because there is no way to identify the origin of these entries. Was it put there by the IHV, a person, or a piece of malware? Removing this AutoRun task will block the current propagation method abused by malware and help customers stay protected. People will still be able to access all of the other AutoPlay tasks that are installed on their computer.

With these changes, if you insert a USB flash drive that has photos and has been infected by malware, you can be confident that the tasks displayed are all from software already on your computer:

Infected USB AutoPlay after AutoPlay changes

Infected USB AutoPlay after AutoPlay changes

On the other hand, if you insert a CD that offers software to install, Windows will still display the AutoRun task provided by the ISV during their media creation process. For example:

AutoPlay for a CD that offers an AutoRun Task

AutoPlay for a CD that offers an AutoRun Task

You will first see this updated AutoRun experience in the Windows 7 RC build, and we will be bringing this change to Vista and XP in the future.

Ecosystem Impact

We are working with our ecosystem partners to help mitigate situations where this AutoRun change will have an impact on them.

CDs and DVDs (including CD emulation), where the IHV specified AutoRun task authored during manufacturing, will continue to provide the AutoRun choice allowing customers to run the specified software. IHVs of generic mass storage devices should expect that people will browse the contents of the device to launch any software. The new behavior will allow customers to continue to use AutoPlay (including all Windows and ISV installed tasks) to access their media and devices while not being presented with tasks from malware. Additionally, device classes, such as portable media players and cell phones, now support Device Stage™ on Windows 7. Device Stage offers the IHV a multifunction alternative to AutoPlay where they can present links to software and common tasks, and provides additional features as you use the device.

As you try out the Windows 7 RC, we hope these changes will make you feel more confident and in control when using your media and devices.

-Arik Cohen

Published Monday, April 27, 2009 12:00 AM by e7blog
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: Improvements to AutoPlay

Nice job, as always.

Keep the information.

W7 best OS from Microsoft Ever.

Monday, April 27, 2009 11:24 PM by Nehemoth

# re: Improvements to AutoPlay

I like the fact that security is taking precedence here, but this can be bad in certain situations.  For example, I have a flashdrive running Portable Apps.  Because AutoRun is disabled, it will be much more difficult to launch the program.  The option to reenable AutoRun for removeable media should be able to be changed through the control panel, so those who actually know what they are doing can have ease of access as well as security.

Thanks, and I can't wait for the release of this awesome OS!

Tuesday, April 28, 2009 12:07 AM by RyGuy12

# re: Improvements to AutoPlay

This is a short-sighted half solution.

Code-signing the autorun.exe applications would be more significant for future looking improvements.

Using mutlitple hashes to check against a database  in a method similar to IE's phishing filter can cover older software.

If the system is off the internet or an item is not in the database on way or the other, you can use a warning dialog to indicate that there is no way to verify the authenticity of the application much in the way that unsigned activeX controls get treated in an intranet setting.

For corporate environments, allow AD policies to supliment these databases.

And then apply this across autoplay unilaterally.

When possible you verify what IS trustworthy, protect users when recognized threats are found and warn them against potential threats when nothing can be verified.  This way, the system can grow, be reactive and actually engender a sense of trust that users can actually rely upon.

Just randomly turning off autoplay leaves gaping holes in the system that WILL eventually be exploited in ways you have not yet expected.  Surely, we have seen enough of those types of solutions?

Tuesday, April 28, 2009 12:28 AM by Xepol

# re: Improvements to AutoPlay

This is a good move, but unfortunately this won't cover those malware which deliberately use an icon that looks like a folder for their executable. Those cannot be differentiated from folders at a first glance, unless extension hiding is disabled. That also make the user "lost confidence and don't feel in control". Why not provide an option to disable silent code execution from removable drives (prompt before any executable can be run from a removable drive), with an user-managed whitelist to allow certain executables (verified by hash-checks) to bypass the prompting?

Or overlay all executables with a marker that identifies them as executable files.

Tuesday, April 28, 2009 1:02 AM by soumyasch

# re: Improvements to AutoPlay

Nice nice nice JOB  !!!

Windows 7 is coming.. resistence ?? FUTILE :D

Go Team !!

5 May coming soon

Tuesday, April 28, 2009 1:03 AM by Domenico

# re: Improvements to AutoPlay

5 may eh?

Isn't 7100 build was compiled few days ago? And the article dated april 27. So, I barely doubt any features after build7100 date will be included in RC.

Or, may be, it is just delayed articles, idk...

Tuesday, April 28, 2009 2:10 AM by Kein

# re: Improvements to AutoPlay

What is annoying the hell out of me is that whenever I dock my laptop I get an Autoplay window, since I have a USB hard drive for backups connected to the dock.

It makes me mad that I cannot disable it, only if I get rid of it for all USB removable devices.

I would like the option to turn off Autoplay for specific devices, not just categories.

@Kein

You shouldn't expect the developers to run here and quickly type in their newest changes whenever they decide on them. Most of the articles are in-depth views of features that are already implemented.

Tuesday, April 28, 2009 2:36 AM by mludwig

# re: Improvements to AutoPlay

soumyasch: Ya man I agree with you. I wish Microsoft had done that. It would be really great even for a novice.

And this is another good move by Microsoft :)

Tuesday, April 28, 2009 6:01 AM by Asesh

# re: Improvements to AutoPlay

Excellent. AutoRun has always had security issues, AutoPlay was a much better effort. Removing AutoRun from AutoPlay is a solid improvement as AutoPlay handlers are fully customizable. But when malware gets onto the system in the first place and registers as an AutoPlay handler, we will get a UAC prompt right? If not, why not introduce UAC prompts when AutoPlay handlers are registered?

Tuesday, April 28, 2009 6:35 AM by someone

# re: Improvements to AutoPlay

Two comments here. First, where is the secure workaround to allow autoplay? We're providing a product to some clients who specifically want absolutely automatic and transparent install just by plugging in a USB stick. Admittedly, they're not running Win7, and the chance of them upgrading to it any time soon are nonexistent, but it doesn't change that in a couple of cases autoplay may pretty much be a necessity. So some option to sign the executable or similar, to allow autorun to work, please?

Second, a more personal annoyance. This means that most of the time, we will s the autoplay dialog pop up *with only one option*. So why show it at all? Why not just open Explorer directly, if that is the only option displayed anyway?

The alternative is clumsy, and looks unprofessional. It gives the impression that you never even thought about how to make this convenient for the user (which may be true, but shouldn't be)

Tuesday, April 28, 2009 7:22 AM by Jalf

# re: Improvements to AutoPlay

I've read every entry on this blog and I've been astonished how well thought out and engineered it's all been.

This concept however seems like a knee-jerk reaction to recent security hole. Some of the other suggestions in these comments sound like a much more sensible way of dealing with the problem rather than "someone hacked it, so just disable all of it!"

Thanks for your great work so far and I hope you'll consider changing this decision.

Tuesday, April 28, 2009 7:46 AM by acaldwell@live.com

# re: Improvements to AutoPlay

I would have to agree with a few of the other posts on here.  This feels like a dodgy workaround for a deeper issue.  Simply not showing the autorun tasks in removable media doesn't really stop any infection, it just prolongs the process.  I like the ideas that Xepol had posted for more secure autorun actions.

Maybe you just need to provide us with a bit more detail on this method.  However, right now, I don't get any warm fuzzy feelings about what you just wrote.

On the whole, I think Microsoft is doing a wonderful job, but this area is deffinately lacking.

Tuesday, April 28, 2009 8:44 AM by krsanford

# re: Improvements to AutoPlay

A very nice start, but while this will slow the spread of malware via flash drives, there's still a huge hole open if you're keeping the optical drive autorun feature.  People are still generally dumb and a number of them will still put in a CD without thinking about it.  There are also U3 USB keys which appear to Windows as an optical drive.

I think disabling all executable autorun whatsoever is the better option.  Yes it means the user might need to (oh no!) double-click setup.exe on their own, but it's far better for security.  Neither OS X nor Linux has autorun for a reason.

Tuesday, April 28, 2009 12:59 PM by wolrah

# re: Improvements to AutoPlay

Autorun from portable devices has never been useful, don't listen to the short-minded asses here.

It's only matter of several minutes to write, say, lightweight shell service which will reintroduce this functionality better way for caring program vendors.

Tuesday, April 28, 2009 3:03 PM by Tihiy

# re: Improvements to AutoPlay

"To enable customers to be in control and feel confident about the software that they choose to run on their computers"

This may be slightly off topic, but for while now I have been thinking, what Windows really needs is a repository based install system like Linux.

Microsoft are working on an "App Store" for Windows Mobile, why not Windows 7 (ok too late, maybe Windows 8)

We need to condition users so when a web page says you need to install this piece of software they click start > app store and search for it.

I believe this would help in the fight against drive-by downloads.

What do guys think?

Tuesday, April 28, 2009 4:54 PM by manicmarc

# re: Improvements to AutoPlay

Manicmarc, a Microsoft app store would surely require signed code, which would become a $200-$500/year entry fee that would exclude a lot of software.

Tuesday, April 28, 2009 9:02 PM by Don Reba

# re: Improvements to AutoPlay

Why not turn General Options to green buttons?

Like "Open folder to view files" option, why not turn it to a green button or a green-circle button?

A autorun malware cannot simulate this behavior, I think. Unless malware was activated first, it wouldn't interfere.

Wednesday, April 29, 2009 12:25 AM by Xlfdll

# re: Improvements to AutoPlay

How about this idea; get rid of the feature. It is of no measurable benefit to anyone and is a massive security vulnerability that you could fly a 747 through.

If you want to install something - you have to manually open the cd and double click on the setup.exe file - something that most people are used to anyway so there is no loss by removing the feature in the first place.

Wednesday, April 29, 2009 5:04 AM by kaiwai

# re: Improvements to AutoPlay

This will break most GPRS modems! (For non-tech-savvy users.)

Those usually come in the form of a USB drive with the modem driver installing through Autorun once the drive is plugged in - a very convenient, zero-configuration system that works well.

With Autorun turned off for USB drives, the user will have to navigate to the drive and often make his choice between multiple executables with nondescriptive filenames. At least some GPRS modems (I have one like it) do NOT provide any instructions for this case in their manual. The "no knowledge required", plug-and-play experience is definitely gone this way.

I strongly believe that this should be reevaluated. Ideally, a prompt would be shown asking whether the drive should be autorun, along with an appropriate warning message (something which, by the way, should be introduced with optical drives as well).

Wednesday, April 29, 2009 9:38 AM by limulus

# re: Improvements to AutoPlay

limulus -> Break is perhaps an overstatement since you can manually run the app and some people already have the feature disabled anyways.

It will, however, degrade the end user experience.

Wednesday, April 29, 2009 5:04 PM by Xepol

# re: Improvements to AutoPlay

I think disabling autorun alltogether is a realy bad idea.

There are good reasons to use autorun. I'm using a USB-Harddisk with TrueCrypt. If you plug in the drive you can automaticly mount the truecrypt volume using the entry displayed in the autorun dialog.

Without autorun you have to start truecrypt and set all the options, which are normally set by using command line options in autorun.ini, manually.

I think enabling autorun for signed executables is a good compromise.

Wednesday, April 29, 2009 6:32 PM by cyberdrop

# re: crippling AutoPlay

Short-sighted move.  I've found autorun very useful for utilities I place on a USB drive.  For example, insert the USB drive, launch the portable TrueCrypt to auto-mount my secure volume.

Vista had a good practice of asking if you wanted to autorun. Disabling it totally will be annoying.  If you're going to disable it, at least give those of us who know what we're doing the option to go into Control Panels and turn it back on.

It worked with UAC: giving me the option to turn it off completely kept me from hurling my Vista PC out the window.  (Three separate UAC prompts to create a new folder in my start menu and move something into it kinda sent me over the edge.)  I turned off UAC and have no problems with malware. Autorun (especially with the "ask first") is not going to cause me problems either.

Wednesday, April 29, 2009 6:36 PM by davidmahaffy

# Response to feedback

Thank you for the feedback.  I wanted to chime in directly on limulus's comment about GPRS modems.

In our testing, most of the GPRS modems are not affected by the change because they expose their driver partition as a emulated CD drive.  This partition can continue to display an AutoRun task to you.  For example, the TRU-Install driver installation used by many of these devices like the Sprint Compass 597 or O2 Compass 885 continues to run without any changes.  

Because a particular device must declare itself as a emulated CD drive in the firmware of the device, we can trust that the IHV has done that for the purpose of exposing the device content like their physical installation CDs and malware cannot cause a generic USB flash drive to mimic this experience.

- Arik Cohen

Wednesday, April 29, 2009 7:43 PM by arikc

# Signature requirements

I was wondering what the requirements are for "Publisher not specified" vs. "Published by ..."

Microsoft tends to be somewhat inconsistent here, and it could be a healthy opportunity to revise the specs.

At different times (security warnings when running a local/online/blocked file, properties, etc.), the publisher name shown to the user is either taken from the digital signature, or from the resource (RC). This duality is not good, especially when the two strings are different.

Additionally, different requirements exist for what constitutes a "trusted" digital signature: for some parts of the Microsoft universe, only a Class 3 code signing certificate by providers such as VeriSign is good enough (e.g. for Winqual/logo purposes). For others, any signature will do (Thawte, Comodo, etc.)

As some have posted here, it would be good to at least demand that any executable code that is invoked by AutoRun be signed. I fully agree with that. As the dialogs indicate, the choice has already been made to expose a publisher name to the user, so this should IMHO come from the Authenticode information, and nowhere else (not from the simple file properties).

While agreeing to the signing requirements, I'd also have to add that this would not solve the issue of malware. Drivers also have to be signed, yet unsigned code can exploit a driver to invoke something else. While this is generally malicious, an AutoRun application usually does this by design, because AutoRun launchers such as MenuBox are there exactly to open a window and propose some options which include launching an installer, running an application from CD or USB, etc. USB itself is increasingly chosen as an application distribution medium (while standards are on the rise to trust the USB medium).

HTML Applications (HTA files) are another example, similar to an AutoRun launcher application. By design, Microsoft allows HTAs to be unsigned and to run executables. Which is great for AutoRun. Should we break this, only because of some new signature requirements? Even if you signed the first layer, the second layer (invoked by HTA or apps like MenuBox) would still not be subject to the same requirement.

My opinion is that at the very least, "Published by ..." should have information coming from Authenticode. If the application is unsigned, it should be marked as such. This is because you are providing this information to the user with respect to this specific application, and the information should be as accurate and trackable as possible.

For the rest, the issue is more complex than it may seem at first sight, and autoRun itself is not the (only) problem. IMHO, code signing should be a requirement for all executables, at least in an optional way, if you want to raise the bar for what may or may not run on a PC. So any user, home or corporate, could have a list of trusted application publishers, if desired, and the surface for malicious code management would be narrowed a lot. Code exploits and social engineering will always exist, but if all code were signed, from Windows system executables, to applications, management would be easier. Doing this in a "leaky" way will always favor the unpatched scenario, be that a USB key that looks like a CD drive to the system, or a second layer that is not subject to the restrictions of the first layer, like unsigned code run by signed code.

At the end of this, I just noticed that Windows 7 has a feature called "AppLocker", which I haven't seen yet. It may do what I was talking about, with respect to only allowing signed code with certain requirements to run. I hope that AutoRun and AppLocker will work hand in hand, giving the user the option to add a publisher that is "introduced" in an AutoRun context to the AppLocker list, without jumping through too many dialogs.

Just my two cents!

Mike

Wednesday, April 29, 2009 9:53 PM by MikeMS

# Optical discs are historically an attack vector

Be aware that optical discs (CDs and DVDs) are routinely used as an attack vector by malware.  To cite just a few examples, there's the W32.Mabezat, W32.HLLW.Infex, and W32.Serflog families, which add their own executable and autorun.inf to the %UserProfile%\Local Settings\Application Data\Microsoft\CD Burning  directory, so any disc the user burns will be infected.  

This is historically a pretty widespread tactic, so keep it in mind.

Wednesday, April 29, 2009 10:18 PM by mechBgon

# re: Improvements to AutoPlay

@ Arik Cohen:

That is very interesting. I wasn't aware of this functionality in those drives. To me it always looked like they are just standard USB drives.

I have to admit that the idea of emulating a CD drive for this purpose is amazing.

Friday, May 01, 2009 2:25 AM by limulus

# re: Improvements to AutoPlay

 I understand the threat and concerns of virus spreading through removable drive by Microsoft and limit this auto play feature is a good thing.  However, if we totally disable the autorun feature for all removable drive will have an affect with some removable drive products.

 I'm using a secure USB drive where instead of using CDs emulation to auto launch the application to unlock the secure partition by taking advantage of auto play feature for CDs, this drive would just show as a normal read-only removable drive and launching the application to unlock the private partition with the autorun feature.  Thus, when this feature is turned-off for all the removable drive the user experience will have an impact.

 In my opinion, to be fare with all the CDs emulator drive where autorun doesn't get turned off, Microsoft products should still let's the autorun and autoplay feature available for all READ-ONLY removable drive, media.  Thus it won't affect lots of removable media already out in the market.  

Phong

Friday, May 01, 2009 5:11 PM by phongm

# re: Improvements to AutoPlay

That's a good thing to disable this thing at all, that was a wide security whole. At present I fear each time someone want to plug a USB drive onto my computer, and most of the time there is some kind of malware. Autorun or Autoplay should never had existed.

To those who complain about it, it's not that difficult for the user to explore his drive and launch what he wants, only two clicks, are you so lazy ?

There still remains the kind of malware who hide the folders and create some executables files named accordingly to the hidden folders. For that, it would be nice to have a way to differentiate an executable file from the others !

Saturday, May 02, 2009 12:16 AM by gabsoftware

# sorry about the OFF

Finally installed the RC. Just wondering is there any settings for Aero Peak? It would be great to have an application exclusion list or something. We have the Sticky Note which makes a useful gadget but disappears on Aero Peak. :( Actually what is the reason for Aero Peak if it hides everything? So you can have a peak on your desktop background? Yeah ok it keeps the desktop gadgets. But those are not really useful. it should keep the Calculator, Sticky Notes, Contacts, Character Map basically a there should be a customizable list of software.

Love the ability for displaying UTC time though.

Also there should be a way to control network traffic (controlling upload/download speed and schedule) natively in the OS. I use Netlimiter but it is crashing under W7.

Anyway W7 is nice unforunatelly lots of cool feature have not made it into  the RC. (like multiple desktops) Wonder why, concurrent OS-s have that for ages now. All to gather it is how Vista should have looked like 3 years ago. Nothing revolutionary compared to Vista SP1 just more cleaned up.

Again very nice OS but somehow it is missing the edge, the one that cuts.

Saturday, May 02, 2009 5:29 AM by lyesmith

# re: Improvements to AutoPlay

This interferes with Ceedo. WHYYYYYYYYYYYYYYYYYYYY? I LOVE CEEDO!

Sunday, May 03, 2009 5:55 PM by SwooshyCueb

# PROPOSAL: Use Signed Code For a Better Solution

I believe this solution disables functionality used by millions of users (the ability to easily start legitimate software installed on portable devices like the PortableApps.com Platform) while still leaving a vulnerability that has been used in the past (malware autorunning from CDs/DVDs like Sony's malicious software fiasco).

A better solution would be to check for signed code.  This could be easily accomplished using the existing infrastructure (including revoking remotely) and presented to the user simply with a minimum of coding changes.

I've put together a complete proposal with the details and screenshots here:

http://johnhaller.com/jh/useful_stuff/windows_7_autoplay/

Tuesday, May 05, 2009 1:00 PM by John T. Haller

# "Improvements" ...really!? (+PROPOSAL)

This has been a part of Windows functionality for over a decade. While a few mal-ware proponents have taken liberty with Autoplay and Autorun functionality, many more actual customers and users have found it a boon.

I agree that security and having confidence in the Windows environment is paramount, however it just seems like you're "throwing out the baby with the bathwater" here.

The Dev Team sure is proud of their "deep insight" features, why not apply that same thinking to AutoPlay? In the dialog, add visual indicators regarding the validity (digital sig's anyone?) of the executables. Your illustration--with the red and green outlines--seems to be an excellent start; why not grow on that concept?

"Spoofs" are easy to detect, since they are mocking the appearance of the UI defaults... we don't even need WinDefender to check it, it's obvious because it's a copy-cat!

(Nodding to others in the thread) Regarding selective AutoPlay actions with respect to individual media; for anyone that works with more than 10 different removable drives in the course of a day, picking specific behavior for each drive could surely be a boon. Moreover, eliminating AutoPlay framework for removable/re-writable media would impact a significant portion of IT professionals that have crafted independent (sometimes ingenious) solutions around that framework.

AutoPlay was conjured-up in the age of the CD-ROM... well before the advent of flash-memory media. The problem has been that the AutoPlay framework "stood still" while a wave of removable media washed over the industry; today, there's just as much a chance that users will insert USB key drives or card-readers than a CD-ROM or DVD. AutoPlay should reflect that fact, as well as anticipate potential abuses.

Re-consider this move; have you really come all this way just to axe an idea that was introduced before its time?

Thursday, May 07, 2009 12:18 PM by Duggeek

# re: Improvements to AutoPlay

It's good that you have removed AutoPlay, but could you please also return the option "Do nothing" in this windows? It was in Win XP. Theoretically, there also was a possibility to remember this choice (did not work always, though). But not in Vista, nor in Win 7. Why? It's *terribly* annoying. Why I insert my flash drive I do not want _any_ windows to appear. Return this option, please.

Wednesday, May 13, 2009 12:57 PM by vicza

# Signed applications

I noticed that Internet Explorer 8 automatically checks the hashes of any file downloads, and can block potentially suspicious files. Would it be a better idea to have a similar implementation for the Auto-Play feature?

Friday, May 22, 2009 6:38 AM by Soon Bing

# re: Improvements to AutoPlay

Here's a pretty simple idea that I'm surprised no one has mentioned yet.

Why don't you just disallow anyone from creating an AutoRun/AutoPlay option that is named "Open folder to view files"? (or other variants/languages)

Prevent ASCII or those ALT+keypad codes or any other workaround, and that should reduce the chances of anyone mistaking file execution from file viewing.

Friday, May 29, 2009 3:38 PM by k0b033

# re: Improvements to AutoPlay

For me, it would be nice if there's an option to run anti-virus scan on autoplay.

Sunday, May 31, 2009 11:02 PM by mucs

# re: Improvements to AutoPlay

The problem has been that the AutoPlay framework "stood still" while a wave of removable media washed over the industry; today, there's just as much a chance that users will insert USB key drives or card-readers than a CD-ROM or DVD. AutoPlay should reflect that fact, as well as anticipate potential abuses.

Saturday, June 13, 2009 4:55 AM by Thesis Help

# re: Improvements to AutoPlay

There still remains the kind of malware who hide the folders and create some executables files named accordingly to the hidden folders. For that, it would be nice to have a way to differentiate an executable file from the others !

Saturday, June 13, 2009 4:56 AM by GCSE Coursework

# re: Improvements to AutoPlay

I think that a serious problemis the fact that the autoplay framework feature basically froze which a torrent of removable media flooded the market. It is in need of a complete overhaul, I hope to see this in the newly released version of windows.

Wednesday, June 24, 2009 8:06 PM by Paddy Power Free Bet

# Autoplay for blind people

As limulus mentioned, it will break some software, like for instance a usb stick (with CDrom partition)which launches a screenreader for blind people. Under XP, when the user plugs the USB stick, the software is automagically launched without further action, so even a blind people can run it. Now, under W7, it will require the user to click a button... err remember, he's blind !

What do you suggest ?

We cannot require that his computer (potentially it could be a public computer) is preconfigured to "always run" the software from CD.

Wednesday, July 01, 2009 4:52 AM by laurentz

# re: Improvements to AutoPlay

The biggest and easiest improvement to the AutoRun/AutoPlay feature would be an easy and reliable way to turn it off completely. This feature is hugely annoying and a security hole, why is there no checkbox in the control panel to do ABSOLUTELY NOTHING when a new drive is connected?  Like, completely and absolutely, no exceptions, no content handlers, no autoinstalls, no nothing. When it's not possible, I feel that I am simply not in control of my own PC, and this absolutely sucks and makes me want to install Ubuntu.

I don't want the Windows Explorer to hand-hold me, just don't look into my disks until I've told you to, how hard is that? On the Vista, you have to install a patch to be able to disable it, can it get any worse? Why am I not in control of my own PC?

Sunday, November 15, 2009 8:07 PM by deemon@gmail.com

# re: Improvements to AutoPlay

Great stuff.That sounds pretty cool. Really helpful thanks for the Article, Great job, hope we can expect more advanced....

Saturday, November 28, 2009 9:22 PM by blu ray ripper

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker