Any setting you expose to the user you implicitly expose to applications


Often, in response to some sort of design decision, people will say, “Well, sure, you made this decision because it would allow applications to do Bad Thing, but why not expose it as a setting the user can select? For example, let the user pick a Topper Than Topmost Awesome Top Window Super Top (Extra Super edition), and keep that window on top regardless of what any application does.”

Because anything the user can do, an application can do.

Suppose there was a new context menu item for a window called Make this Topper Than Topmost Awesome Top Window Super Top (Extra Super edition). Well, an application could just programmatically send the WM_SYS­COMMAND message with wParam set to SC_TOPPER­THAN­TOPMOST­AWESOME­TOP­WINDOW­SUPER­TOP­EXTRA­SUPER.

If you say, “Nope, that context menu item is super secret and has a random command ID so nobody knows what its ID is”, well, the program could just call Get­System­Menu and enumerate the menu items and then extract the ID from the one whose name is Make this Topper Than Topmost Awesome Top Window Super Top (Extra Super edition).

If you say, “Nope, that menu item will be hidden from enumeration, so programs which enumerate their system menu can’t see it”, well, the program could just use Accessibility to programmatically open its system menu, and then programmatically click the Make this Topper Than Topmost Awesome Top Window Super Top Super (Extra Super edition) button.

Anything the user can do, a program can do by simply pretending to be the user.

Comments (38)
  1. GWO says:

    The low drooling sound you can hear is 1000000 Web Designers saying "Use a CAPTCHA!"

  2. Yuri says:

    And then you'll get a request on how to make a Super Street Topper Than Topmost Awesome Top Window Super Top II (Turbo Hyper edition)

  3. muxecoid says:

    There should be a UAC popup when trying to do it. Only administrative users should be allowed to top the topness.

  4. Maurits says:

    Consider the "allow this app to use the microphone?" prompt when using a Windows Store app.

  5. Rick C says:

    @Maurits:  for those of us who haven't experienced this prompt, why?

  6. Danny Moules says:

    "There should be a UAC popup when trying to do it. Only administrative users should be allowed to top the topness."

    And thereby encourage people to disable UAC because it's not being used for security reasons but for a reason that, to a typical end-user, are poorly defined and irrelevant to what he or she is currently attempting to do. Getting people to keep UAC on is already a monumental task without making it even less desirable to the user.

  7. Mordachai says:

    Giving software individual rights is far preferable to blanket on/off of UAC.

    The biggest issue with UAC encouraging users to hate its guts, is that its retarded in its blanket-ness.  If you enable it, you get asked the same questions over & over & over (it never learns a damn thing).

    The metro-apps, for all their downsides, do a have a much smarter authorization model, where the user answer "does this app have this right?"  now and forever for you, as a user.  MUCH smarter.

  8. @MAurits:

    "allow this app use microphone" should be a fixed permission assigned to the installation package (and then to the app account on the computer). This privilege should only be given to the package explicitly by Microsoft app store, after submitter's explanation. Same for "allow to use video camera".

  9. Joshua says:

    There's a nasty virus making its rounds taking over Windows machines that have weak passwords. UAC does absolutely nothing to stop it, and there's no reasonable way it could. The virus operates by remote desktop, and tries usernames and passwords until it gets in. Obviously, it now knows the password to provide to the UAC dialog box.

  10. EvilKiru says:

    @GWO The presence of a Captcha automatically disqualifies the person responsible for the Captcha from being referred to as a Web Designer.

  11. I'm sure that, contrary to conventional wisdom, installation permissions do not serve its intended purpose. It's only a fad of the "new" style of applications for mobile devices. Do you really expect a user to read a list of a dozen permissions, most of them being as obvious (and user-unfriendly) as "access contact list" or "use local storage"? Do you really expect the user to refuse the installation of an application s/he has already downloaded (and maybe payed for) if there is only one item s/he doesn't agree with?

    What makes these platforms a bit safer than conventional open OSes is the owner of the application store (Google, Microsoft, Apple…) curating it and discarding malware from it. But the plain user has not the knowledge to know what permissions s/he has to give to a single app. And in most cases, s/he doesn't care.

    It's sad, but let's accept that: any platform that isn't completely closed will have malware as soon as it gets enough market share.

  12. Maurits says:

    IIRC, there is an installation permission for Windows Store apps. In order to record from a microphone, an app needs to declare its intent to capture from the microphone in its manifest.

    If it does this, the Store will advertise this to the customer. When the app actually tries to record from the microphone, Windows pops up the prompt.

    If the app does not declare the intent, but tries to record from the microphone anyway, Windows will fail the attempt without bothering to show a prompt at all.

  13. Clipboarder Gadget says:

    The window that registers most of Explorer shortcuts (eg Win+D) hides itself from Window enumeration functions. I found that out while trying to make a program that disables the charmsbar hotkey. Took me quite a while to figure this out. Very nasty.

  14. Dave says:

    I definitely like the finer-grained security model that all the app stores have, but it doesn't affect this particular case where an app wants to be the Topmost Window Bar None. If 10 installed apps have the fine-grained Topmost Window Bar None permission, then 10 shall enter topmost but only one shall be topmost. Or the device will crash. Or something. And don't tell me the user will have actually read the list of permissions and said "This flashlight app wants to be the Topmost Window Bar None? Well forget this download!"

  15. dave says:

    Anything the user can do, a program can do by simply pretending to be the user.

    I prefer the explanation that the user can't actually do anything beyond click mouse buttons and press keys. From there onwards, everything that is done is done by 'a program'.

    (Hmm, I wonder how much intersection there is between those who suggest that 'only the user' be allowed to do something-or-other, and those who complain about Microsoft software having 'hidden [sic] APIs')

  16. @Maurits. This sounds good to me. Modern app stores show what capabilities the app wants. Trust in the system is broken if an app who said it didn't need microphone access suddenly starts asking for microphone access.

  17. @Maurits: The situation is somewhat different for Windows Store apps, because they would need to escape the sandbox in order to act as the user, which is something they (deliberately) cannot do. It's the advantage you gain by not giving access to every aspect of the situation to applications, although you subsequently pay the price that there are certain types of application (such as accessibility tools) which simply cannot be written within that framework.

  18. Joshua says:

    @Entegy: What permissions do you expect a program that hosts arbitrary third-party plugins to ask for?

  19. Considering that's not a possibility for Windows Store apps, it's a non-issue.

  20. In order to record from a microphone, an app needs to declare its intent to capture from the microphone in its manifest.

    Does MS app store actually vet the submissions? As in: "we're not accepting this application because it wants the microphone (or other privilege) without a legit reason."

  21. No, it just checks that the manifest is correct, the app doesn't crash or break the store guidelines for submission.

  22. Anonymous Coward says:

    This is real weakness of Windows at present. Metro helps, but creates too many other problems in terms of usability that have nothing to do with permissions, so it's no solution.

    A good way to fix this is by realising that applications are often not fully trusted by the user and base individual applications on that. Most of the permissions can be kept off by default. If an application requests permission to do something potentially evil, you can opt to allow it or to lie to the application and pretend in a safe way that the permission was granted.

    Declining permission and telling the application as much doesn't seem useful to me, because that just makes applications (especially the crap in ‘app stores’) stop working until permissions are granted, which in turn will just train users to give everything full permissions to make stuff work, because they want to see the dancing bunnies.

    From this it follows that permissions must be set sensibly initially, e.g. a document editor needs access to the document you're editing. This means that if you want to protect a user from document editors that destroy documents, you have to use something like Subversion.

  23. MItaly says:

    [ Well, an application could just programmatically send the WM_SYS­COMMAND message with wParam set to SC_TOPPER­THAN­TOPMOST­AWESOME­TOP­WINDOW­SUPER­TOP­EXTRA­SUPER. ]

    The sad thing is that I've seen people pull this stunt even when there are already perfectly documented APIs.

  24. Cheong says:

    How about just limiting programatic access to the (hyper… maybe need Shift + Alt?) extended context menus?

    If the option is currently forbidden because it'd allow The Bad Thing, they aren't going to see it directly anyway. And those who really wants it can do web search and find out the setting is avaliable under extended context menus.

    Just some suggestions.

  25. Simon Farnsworth says:

    @cheong00

    How do I permit accessibility aids programmatic access to the option, while prohibiting other programs from obtaining programmatic access?

    *That's* where it gets tricky – there are legitimate programs that need to spoof being the user (e.g. a voice-controlled input system for someone with muscle control problems, or a puff-type input system for someone like Stephen Hawkins). As a result, in the Windows (and X11 – this is not a Microsoft-only issue) security model, any program can spoof being the user who runs it; you'd need to move to a security model a bit like Android's, where each application is in its own security domain, and the OS controls interactions between the security domains. That's no longer Win32 as we know it…

  26. apz says:

    @cheong00,

    Way to miss the entire point of the article! The whole article is about how it's *impossible* currently under Windows to do what you are suggesting. In your example, how is "limiting programmatic access" going stop an application from either SendMessaging to the command, or if that doesn't work, SendKeys to simulate the keyboard input, or if that doesnt work, MouseInput to simulate mouse activity, or if that doesn't work, installing itself as a USB mouse/keyboard and directly simulating keypresses, etc.

    The whole point of this article is, for an unsandboxed program, you *cant*.

  27. Speaking of SuperTop, Windows 8 supports it – open Task Manager, set it as topmost, then observe what happens (it's easy to replicate this in your own program if you know what Task Manager is doing).

  28. Kevin says:

    @dave:

    I prefer the explanation that the user can't actually do anything beyond click mouse buttons and press keys. From there onwards, everything that is done is done by 'a program'.

    So the kernel and Windows Shell are now programs?

  29. Cheong says:

    @apz: Just like how FaceBook detects javascript clicks of "Like", maybe Windows should introduce a parameter in the messaging system that only exist when the I/O comes from a lower level driver of corresponding type. Therefore the application that wants to invoke some function IIF it's invoked by user can check them, and those who don't care can continue to work.

    Maybe we could just have an extra function DispatchMessageEx() to return the additional information.

  30. Gabe says:

    Kevin: The Windows shell is now, and has always been, a program. For the purposes of this discussion, the kernel is probably not what you would consider a program.

  31. @cheong00: how would that handle the accessibility functions (whose sole purpose is to programmatically simulate user input)?

  32. @Gabe, The kernel is a collection of machine code instructions that are executed by the CPU to accomplish a set of tasks, therefore it is indeed a program. I think what you meant was that the kernel is not an *application*.

  33. Cheong says:

    @ender9: For those function that don't care to block fake inputs, they'll continue to work.

    For, those function that wants to block fake inputs, these functions won't allow accessibility programs to simulate input for users.

    Since these function would be a limited set, I think it'd be okay even for those "disabled" peoples. If they don't understand the security implications behind and accept have to find someone typing these settings for them on these rare circumstances, maybe they shouldn't take the job that requires them to touch these settings, IMO.

    ["Oh, I'm sorry. If you're disabled, then you cannot pin anything to your taskbar." Good luck with that. -Raymond]
  34. Cheong says:

    Btw, I just check that things like Windows' built in speech recognization engine won't work with "secure desktop" either. So when building for security, at some point you have to accept loss in accessibility too.

  35. Cheong says:

    ["Oh, I'm sorry. If you're disabled, then you cannot pin anything to your taskbar." Good luck with that. -Raymond]

    If you need speech recognition, you don't need pin items in taskbar because you'll "talk your way to pearl" to get the program you need. So I assume there's pretty good chance for people who make this particular decision to have good luck. A wallpaper with commonly used program names (and possibly aliases) would have been more useful for them.

    If you're talking about other special designed accessibilty device, since it matches the defination of "originates from lower level driver of corresponding type", this suggestion shouldn't affect them at all.

    [Which would you rather say, "Start. Microsoft Word. File. Open. Budget 2012. Enter." or "Hotkey Windows 2"? And (going back to the original issue), you're saying that people with disabilities will not be able to make an app super awesome topmost? -Raymond]
  36. Cheong says:

    For the example you choose, the user could just place the file shortcut to desktop and assign shortcut there, no need to bother with taskbar pinning.

    Regarding "make an app super awesome topmost", I don't agree with you either because there's quite some accessibities software that works correctly only if the application they try to interact are both active window and topmost window (especially when model dialog got involved… I've got support calls more than once when they find some of the windows have model dialog not selectable to them so have to play "hide and seek" with application to get the dialog out and close it). The fact that allowing some window topmost will give them difficultly to move around makes me feel that they would rather NOT have this feature until their accessibilities software got fixed. Therefore hiding this function from them maybe doesn't matter at all.

    Or thing's have been better now, afterall I've left the job for like 7 years now.

    [Imagine some awesome feature. Now imagine that accessibility tools could not use that awesome feature. -Raymond]
  37. alexcohn says:

    Which would you rather say, "Start. Microsoft Word. File. Open. Budget 2012. Enter." or "Hotkey Windows 2"?

    I'd rather say "open 2012 budget" and let the AI engine figure out what has to be done to accomplish my wish. It should be reasonably easy if "2012 Budget.doc" happens to be one of the "recent documents".

  38. Cheong says:

    [Imagine some awesome feature. Now imagine that accessibility tools could not use that awesome feature. -Raymond]

    That'd require "case by case analysis" to produce meaningful result. Like what I said, even the build-in speech recognition doesn't work with the secure desktop. And I think able to input occasionally on secure desktop themselves without the need to call someone to help is already a very important thing to them. No need to put in "awesome feature" at all.

    Most disabled people, when come to computing, just hope they can do mundane things and have very low expectation on what they can do, because of current limitation of accessibility softwares. With this reason, if your "awesome feature" that is not anything their routine work touches, there's very good chance not heard from them being excluded from using it.

    [Which goes back to the original problem. If you want to protect a feature from applications, you also make it inaccessible. If you are the sort of person who wants to protect all features, then the consequence is that you also make all features inaccessible. -Raymond]

Comments are closed.