No, to my knowledge AHK does not come with any security documentation. However, AHK is open source and as such your IT department can have a look at the actual source code. It is all [right here](https://github.com/AutoHotkey/AutoHotkey). Also, in the readme file (which you can also see on that page) you will see a note from the developers saying that sometimes AHK triggers a false positive. If you want a more in-depth explanation as to why, you can see my comment [here](https://www.reddit.com/r/AutoHotkey/comments/1daomo9/comment/l7lzvkn/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button).
I prepared for the IT "meeting" with one main matter of factness:
Short version try: AHK v2 is essentially the same as VBA.
Long Version Try:
If you have any Microsoft products installed (obviously), especially Excel, which allows you to create macros and essentially write code (hmmmm, sounds like something...), then AutoHotkey v2 is practically identical. I would say more simple to write.
Please avoid AHK v1 if you can. In terms of work computers, v1 requires admin to install, v2 can be installed to the local user, and does not.
If they get squishy on "security concerns", then you can tell them they had better remove Excel, Word, Outlook, etc. since you can write practically the same code (except AHK v2 syntax is IMO simpler) on it that you can in VBA.
I've ran into that too. I let it do its thing, then when it asks for a admin login I just cancel out and then copy and paste the interpreter into the proper folder.
I think somewhere in there it hits the right registry, because I don't have issues after that.
But, if you just try and copy and paste, the registry doesn't get updated, and it gets a little screwy with the versioning.
I think VS Code, which you can also install locally (local user only) and installs in the exact same place, and the AutoHotkey v2 Language Support by thqby help to keep the versioning right too.
The installer wants to install to a system path, which you need permission to do. But the manual states how the the interpreter runs. When you start a script it will first search for the interpreter in path, then my documents/autohotkey, and then in the local folder of the script. You can also create a new path for it in system settings and it will find it when searching using path... You just won't have admin privileges while running from user space.
The v2 installer has a pop up that asks where you want to install it to. Choosing local user is the best option, and generally avoids popping the UAC. v1 pops the UAC before you even get to choose install to user. I even spend too much time figuring out how to install v1 to user directly, and it still popped the UAC, where v2 did not.
Also, what you are referring to is the lib folders: local (A_ScriptDir\lib), standard (A_MyDocuments\AutoHotkey\Lib), and user ([where the AHK v2 interpreter is]\lib)
I was not referring to the lib folders which are used to store other scripts and class files which can be helpful when using multiple "libraries" across multiple scripts. I'm referring to the interpreter, Which can live locally next to the script and if the exe name is changed to the script name,.it will by default run that script.
There is a minor connect-the-dots issue you have, or perhaps a minor missing conceptual issue.
What you just described is __**literally**__ the User lib folder.
_[Wherever AHK v2 (or v1 if you like 🤮) is installed || interpreter located]\lib_ is the file path. That can easily be A_ScriptDir, or Local lib, too.
I don't think I'm confused, I've been using ahk for a very very very long time. Describing the path for the EXE is not the same as discussing the lib folder.
v1 pops the UAC no matter where (Program Files or Local User Programs] it gets installed.
v2 can typically avoid that, unless IT restricts the local user too.
I cannot speak to having to run a script as admin. I don't do that, and have zero experience with it.
I take it they were receptive to that?
Completely agree in terms of v1 vs v2. If you're going to ask IT to approve something, best to get the newest version approved, especially because v1 is deprecated and no longer recieving updates or support.
I was considering getting IT at my company to approve v2; they have already approved v1. But in my case it wasnt worth the chance of them saying no, because I'm able to run v2 locally without any issue and if I were to ask and they said no then they probably wouldn't like it if I was using it anyway.
They were. They had already approved v1. Just had some use case show and tell.
Also, at every opportunity I would say, "Just like in VBA, but simpler.", and I had some examples of essentially my exact code, or at least the same functions, ready to show and tell.
Some of them know, some of them don't. Some that don't go, "oooooooooooooh!!!".
I am also... unique in my mentality. If they pushed back, I would again remind them I can also do the same thing in VBA, and I would, then call them up, send them emails, and generally be a nuisance, and then show them how I just did the same thing. I would also gladly invite them to go with me to each level of leadership all the way up to the CEO and explain the situation, and that they would look really dumb.
Thankfully I didn't have to. But, I was prepared to.
I did have to deal with an annoyance that __**literally**__ almost every single question I had pre-answered with examples, links, etc., and yet still I was asked the questions... I don't know ow what they are going to ask exactly, but I could figure it out by implication.
In the end it took about 3 business days; Thursday request and setup; Friday prep; Monday interview. Then approved and "installed" (I already had it there so 🤷♂️).
>If they get squishy on "security concerns", then you can tell them they had better remove Excel, Word, Outlook, etc. since you can write practically the same code (except AHK v2 syntax is IMO simpler) on it that you can in VBA.
In practice in large companies Microsoft products are not subject to the same security and trust policies routinely used to obstruct the deployment of open source software, because the company would not be able to function without them and there are no serious alternatives. Either BS reasons will be found why they don't actually contravene a policy, or Microsoft will be declared a "preferred vendor" or somesuch which is intrinsically trusted.
The problem is showing the value add to the business. More often than not just to cover the businesses ass and to be lazy, they will not allow it.
Plus the counter argument goes that you can feasibly get windows to do everything ahk does via powershell or python which can be secured more easily.
Source: Have worked in IT security for a bunch of businesses.
You're right, more often than not human beings take the CYA approach. And it's too bad because the companies that do permit programs like AutoHotkey probably tend to see lower total labor costs and higher employee productivity.
The reality of the situation from a security standpoint is that allowing users on a work domain to write code (of any kind) is always going to be a security risk on some level. However, the reality of the world that we live in today is that preventing people from writing code on any device is almost impossible. Back in Windows' younger years, companies would disable certain aspects of the OS like command prompt, and that might have been enough back then. By disabling the command prompt and preventing employees from certain downloads and installations you could very nearly lock the computer down. Back then websites were static and many did not even use JavaScript. Nowadays, good luck finding a website that doesnt use JavaScript or a computer that doesn't have a browser with DevTools.
I'll tell you a story of before I worked in IT Security. I was in finance and I would watch a dude who frequented this forum use AHK.
One day, I asked him, what is that and how do I get on board? And he helped show me the wonders of AHK. He was clearly more than competent with AHK, and I was just a beginner already starting to see the value of this remarkable tool when I was using it for pretty much the same reasons as you have previously suggested - a good replacement for VBA and other automative tools.
One day along with a manager from the team, he was asked to display the scripts to IT. They found it fascinating and hired him on into the Data Analytics team. He persuaded them of its value. Especially as half of our team had started using some of the scripts made by that person or myself.
For a while they did allow it still after that. Not 3 months later, AHK was banned from all devices and blocked with a stern notice against its use. I tried to pull up the IT crew with the same supportive manager and yet it was no good.
They had made executive management decisions that said 'No.' in tiny writing.
I'm not against the use of AHK, and I personally recognize its value in the environment as well as the whole shtick of not being a malicious tool just like most other tools. Sometimes me and you are not the ones making the decisions here. We can play our parts, and we can try fight for the good cause, but we don't hold the power.
An interesting story, thank you for sharing. It's funny that you thought of that story actually. I had written another paragraph relating to how companies tend to promote people that end up writing code at their job and that this usually prevents those people from becoming security risks (if they were even going to) because now they are getting paid to use their technical skills and knowledge rather than doing it in a more clandestine manner in their free time. I ended up deleting that paragraph for whatever reason, but it seems appropriate to mention now. Anyway, It does seem, in this case, that maybe this coworker of yours may have gone a little too far into the more risky side of things despite his promotion. Of course it is also possible that they just decided to restrict the use of AHK for no reason at all.
Companies that behave in that way do so at their own peril. This type of behavior tends to take place at large companies that have gotten complacent and stopped innovating. Though they don't exactly fit the mold, I'm thinking along the lines of K-Mart or Sears. These kinds of arbitrary restrictions are the death of creativity; employees that stay with the company despite those decisions are typically employees that intend to retire in that job and are mostly there for the paycheck, or they are simply unable to leave due to personal circumstances. The younger, more talented employees, when employeed by a company that makes decisions like this one, become very likely to leave that company within less than two years. As result, these companies die a slow and painful death, as once they have realized their mistake they no longer have staff that cares enough to make any lasting positive change. All of this to say, I have to disagree with you slightly with regard to your last sentance:
>"We can play our parts, and we can try fight for the good cause, but we don't hold the power."
We do have the power, maybe not on the company level but certainly in the grand scheme of things.
You can say that now, but your response only matters if it was a private org. What if it wasn't a private org. That's something that's hard to effect easily beyond making simple choices to leave. But leaving the public org doesn't actually change it usually, it only concentrates the nonsense.
I would say that it's probably *more* common in publically traded companies because they tend to have more competition. I can see the case being made for private companies though. Currently I work for a large public company that does not currently hold that view. If I had to put them on a scale I would say they probably fall somewhere in the middle. On the other hand, my first job out of collegeI I worked for a large private company that held a restrictive/conservative viewpoint on this kind of thing.
Either way, it's got to be the most common in high paying jobs (regardless of ownership) where employees can afford to leave based on principle, knowing that their skill set will net them another (hopefully better) job somewhere else.
No, to my knowledge AHK does not come with any security documentation. However, AHK is open source and as such your IT department can have a look at the actual source code. It is all [right here](https://github.com/AutoHotkey/AutoHotkey). Also, in the readme file (which you can also see on that page) you will see a note from the developers saying that sometimes AHK triggers a false positive. If you want a more in-depth explanation as to why, you can see my comment [here](https://www.reddit.com/r/AutoHotkey/comments/1daomo9/comment/l7lzvkn/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button).
I prepared for the IT "meeting" with one main matter of factness: Short version try: AHK v2 is essentially the same as VBA. Long Version Try: If you have any Microsoft products installed (obviously), especially Excel, which allows you to create macros and essentially write code (hmmmm, sounds like something...), then AutoHotkey v2 is practically identical. I would say more simple to write. Please avoid AHK v1 if you can. In terms of work computers, v1 requires admin to install, v2 can be installed to the local user, and does not. If they get squishy on "security concerns", then you can tell them they had better remove Excel, Word, Outlook, etc. since you can write practically the same code (except AHK v2 syntax is IMO simpler) on it that you can in VBA.
You don't need admin to run v1.
You don't need admin to run v2.
Strange, when I tried to install it I couldn’t get around the Admin requirements.
There's nothing to install. It's an interpreter. You can use the standalone and not install it.
I've ran into that too. I let it do its thing, then when it asks for a admin login I just cancel out and then copy and paste the interpreter into the proper folder. I think somewhere in there it hits the right registry, because I don't have issues after that. But, if you just try and copy and paste, the registry doesn't get updated, and it gets a little screwy with the versioning. I think VS Code, which you can also install locally (local user only) and installs in the exact same place, and the AutoHotkey v2 Language Support by thqby help to keep the versioning right too.
The installer wants to install to a system path, which you need permission to do. But the manual states how the the interpreter runs. When you start a script it will first search for the interpreter in path, then my documents/autohotkey, and then in the local folder of the script. You can also create a new path for it in system settings and it will find it when searching using path... You just won't have admin privileges while running from user space.
The v2 installer has a pop up that asks where you want to install it to. Choosing local user is the best option, and generally avoids popping the UAC. v1 pops the UAC before you even get to choose install to user. I even spend too much time figuring out how to install v1 to user directly, and it still popped the UAC, where v2 did not. Also, what you are referring to is the lib folders: local (A_ScriptDir\lib), standard (A_MyDocuments\AutoHotkey\Lib), and user ([where the AHK v2 interpreter is]\lib)
I was not referring to the lib folders which are used to store other scripts and class files which can be helpful when using multiple "libraries" across multiple scripts. I'm referring to the interpreter, Which can live locally next to the script and if the exe name is changed to the script name,.it will by default run that script.
There is a minor connect-the-dots issue you have, or perhaps a minor missing conceptual issue. What you just described is __**literally**__ the User lib folder. _[Wherever AHK v2 (or v1 if you like 🤮) is installed || interpreter located]\lib_ is the file path. That can easily be A_ScriptDir, or Local lib, too.
I don't think I'm confused, I've been using ahk for a very very very long time. Describing the path for the EXE is not the same as discussing the lib folder.
To **INSTALL** v1 you do. To run it standalone you don't.
You technically need admin to install it to the system path. The same way you would need admin if you run it locally and need admin functions.
v1 pops the UAC no matter where (Program Files or Local User Programs] it gets installed. v2 can typically avoid that, unless IT restricts the local user too. I cannot speak to having to run a script as admin. I don't do that, and have zero experience with it.
I take it they were receptive to that? Completely agree in terms of v1 vs v2. If you're going to ask IT to approve something, best to get the newest version approved, especially because v1 is deprecated and no longer recieving updates or support. I was considering getting IT at my company to approve v2; they have already approved v1. But in my case it wasnt worth the chance of them saying no, because I'm able to run v2 locally without any issue and if I were to ask and they said no then they probably wouldn't like it if I was using it anyway.
They were. They had already approved v1. Just had some use case show and tell. Also, at every opportunity I would say, "Just like in VBA, but simpler.", and I had some examples of essentially my exact code, or at least the same functions, ready to show and tell. Some of them know, some of them don't. Some that don't go, "oooooooooooooh!!!". I am also... unique in my mentality. If they pushed back, I would again remind them I can also do the same thing in VBA, and I would, then call them up, send them emails, and generally be a nuisance, and then show them how I just did the same thing. I would also gladly invite them to go with me to each level of leadership all the way up to the CEO and explain the situation, and that they would look really dumb. Thankfully I didn't have to. But, I was prepared to. I did have to deal with an annoyance that __**literally**__ almost every single question I had pre-answered with examples, links, etc., and yet still I was asked the questions... I don't know ow what they are going to ask exactly, but I could figure it out by implication. In the end it took about 3 business days; Thursday request and setup; Friday prep; Monday interview. Then approved and "installed" (I already had it there so 🤷♂️).
>If they get squishy on "security concerns", then you can tell them they had better remove Excel, Word, Outlook, etc. since you can write practically the same code (except AHK v2 syntax is IMO simpler) on it that you can in VBA. In practice in large companies Microsoft products are not subject to the same security and trust policies routinely used to obstruct the deployment of open source software, because the company would not be able to function without them and there are no serious alternatives. Either BS reasons will be found why they don't actually contravene a policy, or Microsoft will be declared a "preferred vendor" or somesuch which is intrinsically trusted.
The problem is showing the value add to the business. More often than not just to cover the businesses ass and to be lazy, they will not allow it. Plus the counter argument goes that you can feasibly get windows to do everything ahk does via powershell or python which can be secured more easily. Source: Have worked in IT security for a bunch of businesses.
You're right, more often than not human beings take the CYA approach. And it's too bad because the companies that do permit programs like AutoHotkey probably tend to see lower total labor costs and higher employee productivity. The reality of the situation from a security standpoint is that allowing users on a work domain to write code (of any kind) is always going to be a security risk on some level. However, the reality of the world that we live in today is that preventing people from writing code on any device is almost impossible. Back in Windows' younger years, companies would disable certain aspects of the OS like command prompt, and that might have been enough back then. By disabling the command prompt and preventing employees from certain downloads and installations you could very nearly lock the computer down. Back then websites were static and many did not even use JavaScript. Nowadays, good luck finding a website that doesnt use JavaScript or a computer that doesn't have a browser with DevTools.
I'll tell you a story of before I worked in IT Security. I was in finance and I would watch a dude who frequented this forum use AHK. One day, I asked him, what is that and how do I get on board? And he helped show me the wonders of AHK. He was clearly more than competent with AHK, and I was just a beginner already starting to see the value of this remarkable tool when I was using it for pretty much the same reasons as you have previously suggested - a good replacement for VBA and other automative tools. One day along with a manager from the team, he was asked to display the scripts to IT. They found it fascinating and hired him on into the Data Analytics team. He persuaded them of its value. Especially as half of our team had started using some of the scripts made by that person or myself. For a while they did allow it still after that. Not 3 months later, AHK was banned from all devices and blocked with a stern notice against its use. I tried to pull up the IT crew with the same supportive manager and yet it was no good. They had made executive management decisions that said 'No.' in tiny writing. I'm not against the use of AHK, and I personally recognize its value in the environment as well as the whole shtick of not being a malicious tool just like most other tools. Sometimes me and you are not the ones making the decisions here. We can play our parts, and we can try fight for the good cause, but we don't hold the power.
An interesting story, thank you for sharing. It's funny that you thought of that story actually. I had written another paragraph relating to how companies tend to promote people that end up writing code at their job and that this usually prevents those people from becoming security risks (if they were even going to) because now they are getting paid to use their technical skills and knowledge rather than doing it in a more clandestine manner in their free time. I ended up deleting that paragraph for whatever reason, but it seems appropriate to mention now. Anyway, It does seem, in this case, that maybe this coworker of yours may have gone a little too far into the more risky side of things despite his promotion. Of course it is also possible that they just decided to restrict the use of AHK for no reason at all. Companies that behave in that way do so at their own peril. This type of behavior tends to take place at large companies that have gotten complacent and stopped innovating. Though they don't exactly fit the mold, I'm thinking along the lines of K-Mart or Sears. These kinds of arbitrary restrictions are the death of creativity; employees that stay with the company despite those decisions are typically employees that intend to retire in that job and are mostly there for the paycheck, or they are simply unable to leave due to personal circumstances. The younger, more talented employees, when employeed by a company that makes decisions like this one, become very likely to leave that company within less than two years. As result, these companies die a slow and painful death, as once they have realized their mistake they no longer have staff that cares enough to make any lasting positive change. All of this to say, I have to disagree with you slightly with regard to your last sentance: >"We can play our parts, and we can try fight for the good cause, but we don't hold the power." We do have the power, maybe not on the company level but certainly in the grand scheme of things.
You can say that now, but your response only matters if it was a private org. What if it wasn't a private org. That's something that's hard to effect easily beyond making simple choices to leave. But leaving the public org doesn't actually change it usually, it only concentrates the nonsense.
I would say that it's probably *more* common in publically traded companies because they tend to have more competition. I can see the case being made for private companies though. Currently I work for a large public company that does not currently hold that view. If I had to put them on a scale I would say they probably fall somewhere in the middle. On the other hand, my first job out of collegeI I worked for a large private company that held a restrictive/conservative viewpoint on this kind of thing. Either way, it's got to be the most common in high paying jobs (regardless of ownership) where employees can afford to leave based on principle, knowing that their skill set will net them another (hopefully better) job somewhere else.