none
Preventing UI Automation access to an application

    Question

  • Hi

    Congratulations of the new forum, it should be a great thing to have.

    I just wanted to know -  is there a way of preventing or limitting UI Automation access to an application?

     

    Friday, February 24, 2006 11:06 AM

Answers

All replies

  • Thanks for being the first to use the forum!

    Could we get more details on why you need to prevent or limit UIA access to an application?

    Generally UIA will always require access to applications for assistive technologies such as screen readers and screen magnifiers.  These applications will run with certain security permissions that enable them to access applications on the desktop and make them accessible for end users.

     

    Friday, February 24, 2006 6:15 PM
  • Hi.

     

    There is a method that you could use to prevent programmatic access through UI Automation, but it can be a lot of work, especially for applications that consist of more than a few controls.  UI Automation works on something of an ask and tell model, UI Automation asks controls for various bits of information that it then passes on to UI Automation clients, such as screen readers used by the blind.  If you don't tell UI Automation the information it asks for, by not implementing one of the provider interfaces, then UI Automation won't know about the control.  I mentioned this could potentially be a lot of work, and the reason for this is that most of the standard and common controls have the UI Automation information provided for them through things like proxies.  So, an application wishing to hide itself from UI Automation would have to be constructed primarily from custom controls that didn't implement the provider interfaces.

     

    As Thomas said, it would be useful to have a bit more information on why you would want to do this.  I can see it being useful from the viewpoint of attack surface reduction, but then it would also prevent people who use access technologies, such as the blind, some people with dyslexia, and many others from using the application.  This is a point worth mentioning, as to sell to federal, and some state, agencies in the US, software has to be accessible, and to sell in other parts of the world there has to be at least reasonable adjustments made to make software accessible.  So, disabling UI Automation could reduce the potential market for an application.  One way around this could be not to disable UI Automation completely, instead only exposing information through UI Automation if you detected it was needed, say you detected access technologies were running on a system or a user had selected an option indicating they required UI Automation.

     

    Will

    Saturday, February 25, 2006 6:33 AM
  •  

    Hi

    Thanks (to Thomas too) for your answer.

    We actually write software that is a UI Automation client (it uses UIA to automate user actions). I wanted to find out how easy will it be for other application to hide themselves from UIA, in order to assess the possibility that it will become a common custom.

    Thomas mentioned that screen readers and screen magnifiers have certain security permissions that allow them to access UIA providers. Are these special security permissions, beyond the regular permissions that any administrator-elevated process has?

     

    Sunday, February 26, 2006 7:25 AM
  • Hi.

    There is no technical reason that I know of preventing someone from completely hiding their software from UI Automation, but I don't think this is a situation that will be encountered that often.  There's a few factors that have led to this opinion.  Firstly, if software uses standard controls, which most do, most of these standard controls will be made available to UI Automation through things like proxies.  So, it's very likely that applications will have at least partial visibility to UI Automation through their use of standard controls alone.  Secondly, UI Automation offers benefits to more developers than it's predecessor, MSAA, did through UI Automation's dual role as a mechanism for test automation.  Therefore, if a developer, or their organisation, uses test automation it's quite likely that they will use UI Automation.  The final factor is the promotion Microsoft have given to UI Automation through things such as Thomas's PDC talk last year.  The more developers that know about UI Automation the better.

    Yes, UI Automation clients that are designed to provide accessibility, as opposed to test automation clients, do require higher privileges than the standard admin account.  This requirement is due to the need for accessibility orientated UI Automation clients to perform cross-process messaging, or the UI Automation client side proxies on their behalf, across an entire Windows session.  Several of the system dialogs, such as the dialog prompting a user to elevate their privileges in order to run a process or activity and the Windows Logon screen, have had cross-process messaging disabled, likely to prevent an elevation of privilege attack.  However, disabling cross-process messaging with these dialogs degrades their accessibility, and therefore accessibility orientated UI Automation clients can gain special privileges to perform cross-process messaging with these dialogs in order to render them accessible.  The special privileges are requested by means of a UIAccess attribute set to "true" in the RequestedExecutionLevel of an application's manifest file.  The application's files also need to be code signed.

    Will

    Tuesday, February 28, 2006 10:12 PM
  • Thanks Will for such an excellent response!

    For more details about the UIAccess flag and RequestedExecutionLevel please see MSDN article http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp

    Searching on UIAccess will bring you to relevant information.  Hope this answers your questions.


    Thomas

    Wednesday, March 01, 2006 9:46 PM
  •  

    When setting UIAccess flag to "true" and disabling the secure desktop, a could indeed access the consent dialog using UI Automation.

    However, it seems to me that on Vista RC1 this behaviour was changed, and I cannot get to the consent dialog.

    Is this a "by design" change, or should I still be able to manipulate the consent dialog and might be doing something wrong?

     

    Thanks

    Tuesday, November 14, 2006 3:17 PM
  • Will:

     

    No one is allowed to use my computer except me. I do not need assistive technologies. The magnifier switches on even when I USE THE MICROSOFT MOUSE. I do not want any of these items to be available. How can I pernanently remove or disable the technology in my machines?

    Thursday, July 28, 2011 12:59 AM
  • Hi,

    Is the main issue here that Magnifier runs in response to a mouse button press, and you don’t want it to? Some Microsoft mice are configured by default such that a press of the Left side button runs Magnifier, and it can be easy to press that unintentionally. If you go to the Control Panel’s Mouse Properties, on the Buttons tab you can change the action related to all the mouse buttons. So if one of the buttons is configured to run Magnifier, you could change that to “disabled” if you don’t want anything to happen when that button is pressed, or select some other action if you prefer.

    Thanks,

    Guy

    Thursday, July 28, 2011 3:49 AM