7 ms·

One I am going to start to ask is "Are all developers allowed to have local admin access of their computers?" I've struggled against this in my last 3 positions

One I am going to start to ask is "Are all developers allowed to have local admin access of their computers?" I've struggled against this in my last 3 positions. This is a dealbreaker for me, and should be for all developers.

kemiller2002 7y ago
I agree. I have never been at a place where developers don't have admin access and seen development be successful in anything they've created. This seems to be a decent indicator of overall culture towards development and removing obstacles to getting things done.
relax88 7y ago
From an infosec professional perspective, this one is always a challenge for security sensitive places. I agree with you that developers need admin rights on their development machines, but I have witnessed first hand why many companies attempt to take away local admin rights. When I'm responding to security alerts where developers have downloaded random .dll files from the internet, or some "troubleshooting utility" that is actually malware, it doesn't take long until the local admin conversation comes up. This is one of those classic "technical solutions for bad human behaviour" scenarios where a small number of idiots ruin it for everyone. If you want local admin as a developer, then we need to be able to trust that you aren't going to do something stupid. It seems the best way to do this is to issue developers multiple boxes (corporate laptop + dev box only for dev), and or use a good software whitelisting program that tracks elevations & the reasons for them, instead of just blanket giving everyone local admin on their own PC.
- chii 7y ago
  i wonder if making the development machine use something similar to qubes (https://www.qubes-os.org/ https://www.qubes-os.org/) by default works. Also, if a compromised machine on the internal network destroys your company's security assumptions, then there must not have much defense in depth.
  - theamk 7y ago
    qubes-like solutions are great at preventing malicious code from accessing your internal websites, but pretty useless from "code leak" perspective. If you have downloaded a trojaned "super library" and put it to your build process, it will, by definition, be in the same security domain as your source code. Unless you audit all file accesses and outgoing internet access, you won't be able to prevent code exfiltration.
    - chii 7y ago
      is code exfiltration really the threat model though?
      - ThrowawayR2 7y ago
        Depends on whether you work on a product or in IT. For products in certain industries, yes, it is a concern.
- an_d_rew 7y ago
  Both excellent points. Maybe the better question is: how do you prevent your lowest-bidder corporate antivirus marks from marking git-bash as malware, stopping all work for the team for two days? Developers don’t need admin access, they need ways of getting their jobs done with the best available tools. That’s a damn difficult balance to find!
  - jrjarrett 7y ago
    Yes! Will add this to my list. Just going thru this where I work all in the name of "ISO Certification."
  - WorldMaker 7y ago
    Or corporate firewall tools that block Android SDK zips as "hacking tools" for daring to include such evocatively named "black hat" files as a "traceview.bat". It's not my fault as a developer that Android Studio needs me to download such a zip quite regularly to keep working on Android stuff. It's an interesting hygiene problem. Semi-related, I love UAC, and taking UAC seriously. It's the closest thing we have to "good handwashing habits" for admin access. I don't understand how many corporate GPO defaults/admin "standard images" I've seen where if someone has admin access at all they default to UAC off. (I make sure to turn it immediately back on as a matter of instilled corporate habit. One job I had to remember to do that after every restart/full relogin because of GPO overrides. Gross.) Sometimes I wonder if there is some oath I just could sign as a developer that starts with something like "I promise always to at least wash my hands / pay attention to UAC prompts" and "I swear I usually have good reasons to authorize admin access when I reply to a UAC prompt". (And/or you know, use the GPO for what it was meant to do and enforce a minimum UAC, rather than disable it.) (I also find it peculiar how many Windows IT admins and developers I've met that disable UAC in a corporate environment but then personally use macOS and are so happy that is has SUDO prompts and wish Windows had something similar but somehow don't realize UAC is the exact same thing. It's a strange cognitive dissonance that I don't think I will ever understand. Yes, I've heard all the arguments that Vista's first usages of UAC confused them and they gave up learning it before it settled down and they didn't want to unlearn decades of bad habits from 95 to XP, but I guess I find that a really poor excuse because I was a heavy Vista user by choice, partly specifically for UAC. Washing your hands is great, and very professional, and decades of a habit of not washing your hands isn't an excuse I'd expect anyone reasonable to expect, but especially in a hospital. Anyway, I digress.)
- danieldk 7y ago
  Or one could provide a package manager that allows user installs of software, like Nix. (Depending on the threat model, of course.)
- hvidgaard 7y ago
  Developers can have local admin because it's expected that you can trust them. If they betray that thrust, then they lose that privilege, and depending on the nature of their work that might mean they cannot work. Bad for them, but surely it was written in their contract.
  - ben509 7y ago
    It's never actually in a contract, these are always policies since employment is at-will. But "they cannot work" is implying that person gets fired. I agree that serious breaches of security are a firable offense, because it's plainly a fact that people get fired over them. Generally, though, developers are fairly hard to replace and anyone who is hard to replace is equivalently hard to fire. So most security policies have to work out some kind of compromise between those competing interests.
    - hvidgaard 7y ago
      Some of the US might be at will employment, but it's not like that everywhere. In Denmark employment is not at will, but you can only fire someone if there is just cause. This particular scenario is in the security policy, and in my contract it's stated that I will follow that.
- gwbas1c 7y ago
  > If you want local admin as a developer, then we need to be able to trust that you aren't going to do something stupid. Issues with trust imply greater problems in the workplace. Unless you're in a high-risk (of hacking) industry, like military, treating adults like children is a huge problem. Granted, there are plenty of ways around these limitations. By now, all of my "I need admin rights" development is performed within a VM.
  - deleted 7y ago
    [deleted]
- kemiller2002 7y ago
  As a person whose straddled infosec and development, I always struggled with this. The multiple development machines is probably the best approach, but I've never truly seen it implemented correctly. I would love to not need admin access to my machine, but each time the companies I've worked for try this, it's always a struggle to do anything. This is everything from, "I need to modify/monitor core components of the operating system" to "The development tools came out with an update that needs to be installed." Most of the time, the response I've received was, "Enter a ticket, and we'll get to it." Often management seems to understand, "I'm waiting someone else" as "I'm behind, I'll work the weekend." You're right the downloading random things from the internet is an issue. Sadly I think a lot of this can be solved by the organization spending the money to buy all the needed tools and evaluate the correct open source ones, but there always seem to be budget and time constraints. I think a lot of this stems from the fact that most of the managers in infosec for companies aren't developers and haven't ever been one. They really have no idea what developers really do. I'm not belittling them. It's just not the career path they took to get where they are. It's difficult to explain to them how frustrating being hindered is, and this causes a lot of good people to just leave an organization like that to find something better.
  - deleted 7y ago
    [deleted]
  - marsRoverDev 7y ago
    Multiple machines approach can work if you have an IT person dedicated to a development team, located in the same office, with a low ratio of IT-to-other-staff. If the process for getting something like IntelliJ IDEA installed on an airgapped machine involves less than an hour with their help, it's workable. If it is not, forget it. Unfortunately, it takes a lot for management in most companies to see why this is a good idea, and why spending that much on staff ratios is a good idea.
  - devdas 7y ago
    IT security people also have different incentives. If developers got bonuses for uptime while being compliant with all security policy requirements, while security and operations got bonuses based on features reliably delivered, you would have different results.
- quotemstr 7y ago
  > use a good software whitelisting program that tracks elevations & the reasons for them, instead of just blanket giving everyone local admin on their own PC You can propose such a thing. If you're in charge at a company, you might get to implement it. But if you do, know that it's a huge black mark against your company. I've seen how these whitelists work in practice. They're massive wastes of time. They get in the way of actually doing one's job, as creative work can't be constrained and approved in advance by some committee with a ten-business-day turnaround on getting some damn file conversion utility to run. The golden rule of "security product" culture is this: inconvenience is a feature, not a bug, since friction reminds people that the infosec group exists. When it comes to stuff like this, all the incentives are lined up to just inconvenience people, not protect them. We ought to protect data, not code.
  - tomp 7y ago
    > We ought to protect data, not code. Code is more dangerous than data. Personally, I'd be most worried by someone getting a virus that hacks into other computers and encrypts them and/or wrecks the network. Both can be protected against, first by cold backups and second by resilient / disaster recovery network, but both would also severely affect the company for a few days, so I'd rather avoid them.
    - devdas 7y ago
      That's code destroying data. Losing data is bad for the business. A random box had software crashing? Just replace the box.
      - tomp 7y ago
        even setting up a new box might take one day of a productive person's time... unless, of course, if you standardise the dev setup... again many devs will complain, probably more than if you just remove local admin :D
- theflyinghorse 7y ago
  This just irks me the wrong way. What problem are you solving by making work for devs range from "incredibly hard" to "outright impossible" via taking admin privileges away? Surely you must understand that all things should be in balance, that security isn't the sole goal of an organization but rather an important consideration in the overall structure. Are you attempting to create a tech "solution" to a hiring problem? You aren't going to succeed.
- lokar 7y ago
  I can be done will, with effort. Google manages it.
- marsRoverDev 7y ago
  I worked at one place where instead of giving us root access to our machine, gave us one that was offline (with access to an air-gapped local network and a dedicated IT guy to ensure we had access to tools/IDEs/licenses etc) and another, shittier one that had internet access side by side. This worked fine. I went somewhere else where we had locked down machines. I am never, ever, ever going back to a place like that. Fuck working in that kind of environment.
- java-man 7y ago
  I've never seen a clear separation between production environment (machines, network) and the dev. Air gap the two and a lot of problems might go away (not all, of course, but the most common ones).
deleted 7y ago
[deleted]
Cthulhu_ 7y ago
I / we are in an interesting position in that regard, in that there is a policy installed on our laptops that gives us admin access on the one hand, BUT forces encryption and allows our employer to trigger a remote lock / wipe in case of theft. I think that's a good middle ground myself, I mean what if I get murdered and robbed abroad? I don't expect it but it's a possible scenario that might put our customers' code at risk.
raxxorrax 7y ago
Indeed. Don't forget to ask for exceptions for the corporate firewall. And bring some cookies for the grumpy security guy that will make himself heard shortly after the request is permitted by the boss.
growlist 7y ago
I don't think I'm alone in having to switch between multiple machine configs from day to day. The only way I could avoid using VMs would be to physically swap hard drives, at which point why not just work in VMs... As long as one has admin access in the VM of course!
quotemstr 7y ago
Important followup: "Am I allowed local unconstrained root without a usually-performance-killing daemon interfering with my work?" At a few places, I experimented with running Windows. Every time, the Windows machine came with Bit9 or some other performance-killing compatibility-breaking security "solution" that made the system unusable. Windows is a great operating system. What IT departments do to Windows turns it into a nightmare. These same places all had a much lighter touch on Linux VMs, desktops, and laptops, so clearly the invasive "security product" mindset was just contained to the Windows (and in one instance, macOS) groups.
- WorldMaker 7y ago
  > Windows is a great operating system. What IT departments do to Windows turns it into a nightmare. That's a great bumper sticker. There are so many cases you find of people's Windows complaints where the questions are "Why does Windows even allow GPO to hurt users that badly?" and "Why does your IT staff hate you so much personally that they configured Windows into that particular contortion?" The Unix world has decades of tales of the "sysadmin from hell" / BOFH, of course, but something about Windows administration just seems to elevate to almost universal "art form" across every company, but at the same time has managed to make it "business as usual" rule rather than the to-be-irked-by exception. On no other operating system would that level of IT micromanagement and terrible "security products" be accepted, and on just about no other platform would people just as easily assume it to be OS "bugs" or "inabilities" rather than the forced masochism of some local BOFH.
  - relax88 7y ago
    > "Why does Windows even allow GPO to hurt users that badly?" and "Why does your IT staff hate you so much personally that they configured Windows into that particular contortion?" Typically its because the GPO configuration has 15 years of kludge and your IT department is under resourced and doesn't have the ability to spend 6 months sifting through and testing all of it. In Windows environments group policy is often one of the biggest piles of technical debt.
    - 7y ago
goatinaboat 7y ago
Are all developers allowed to have local admin access of their computers? These are the same devs who install random things with curl|sudo bash right? Or write code that can only run as root in production? No thanks. These days of virtualenvs and similar, only incompetent devs insist on being root too. In fact, this will make an excellent interview question, thanks!
- ccccc0 7y ago
  I think if I got this answer during an interview, as a candidate, I would be pleased that your criteria reject me as an incompetent dev.
- dangus 7y ago
  When you're not allowed to install applications and tools to your own, that gets in the way of productivity and happiness at work. I've worked at companies where even being able to install something simple like Notepad++ or VSCode was turned into a major chore or made impossible thanks to the locked down environment. Locking down trivially important system preferences like your desktop background is another example of just plain annoying management that I've witnessed. Don't forget corporate network content blocking, and I don't mean the obviously not safe for work content, but companies acting as the productivity police e.g. blocking Twitter and YouTube just because they don't trust you enough to not slack off at work, and furthermore not trusting your supervisor to be competent enough to determine whether or not you've been productive enough lately.
  - jjkaczor 7y ago
    ... You are aware that at a point in time, Notepad++ was compromised, right?... https://notepad-plus-plus.org/news/notepad-7.3.3-fix-cia-hacking-issue.html https://notepad-plus-plus.org/news/notepad-7.3.3-fix-cia-hac... As both developer and a systems administrator, I am constantly on both sides of the fence. I have seen developers who cannot even maintain their machines and download any random thing to streamline their job to the detriment of security. Yet, I have seen other organizations where it takes months to get something like VSCode installed (try keeping that up-to-date on an air-gapped machine, that isn't connected to the internet... or ... Node.js or... full Visual Studio...)
chinhodado 7y ago
I'm curious what the answer to this question is for MS/Google/FB/other big companies

kemiller2002 7y ago

I agree. I have never been at a place where developers don't have admin access and seen development be successful in anything they've created. This seems to be a decent indicator of overall culture towards development and removing obstacles to getting things done.

relax88 7y ago

From an infosec professional perspective, this one is always a challenge for security sensitive places. I agree with you that developers need admin rights on their development machines, but I have witnessed first hand why many companies attempt to take away local admin rights. When I'm responding to security alerts where developers have downloaded random .dll files from the internet, or some "troubleshooting utility" that is actually malware, it doesn't take long until the local admin conversation comes up. This is one of those classic "technical solutions for bad human behaviour" scenarios where a small number of idiots ruin it for everyone. If you want local admin as a developer, then we need to be able to trust that you aren't going to do something stupid. It seems the best way to do this is to issue developers multiple boxes (corporate laptop + dev box only for dev), and or use a good software whitelisting program that tracks elevations & the reasons for them, instead of just blanket giving everyone local admin on their own PC.

chii 7y ago
i wonder if making the development machine use something similar to qubes (https://www.qubes-os.org/ https://www.qubes-os.org/) by default works. Also, if a compromised machine on the internal network destroys your company's security assumptions, then there must not have much defense in depth.
- theamk 7y ago
  qubes-like solutions are great at preventing malicious code from accessing your internal websites, but pretty useless from "code leak" perspective. If you have downloaded a trojaned "super library" and put it to your build process, it will, by definition, be in the same security domain as your source code. Unless you audit all file accesses and outgoing internet access, you won't be able to prevent code exfiltration.
  - chii 7y ago
    is code exfiltration really the threat model though?
    - ThrowawayR2 7y ago
      Depends on whether you work on a product or in IT. For products in certain industries, yes, it is a concern.
an_d_rew 7y ago
Both excellent points. Maybe the better question is: how do you prevent your lowest-bidder corporate antivirus marks from marking git-bash as malware, stopping all work for the team for two days? Developers don’t need admin access, they need ways of getting their jobs done with the best available tools. That’s a damn difficult balance to find!
- jrjarrett 7y ago
  Yes! Will add this to my list. Just going thru this where I work all in the name of "ISO Certification."
- WorldMaker 7y ago
  Or corporate firewall tools that block Android SDK zips as "hacking tools" for daring to include such evocatively named "black hat" files as a "traceview.bat". It's not my fault as a developer that Android Studio needs me to download such a zip quite regularly to keep working on Android stuff. It's an interesting hygiene problem. Semi-related, I love UAC, and taking UAC seriously. It's the closest thing we have to "good handwashing habits" for admin access. I don't understand how many corporate GPO defaults/admin "standard images" I've seen where if someone has admin access at all they default to UAC off. (I make sure to turn it immediately back on as a matter of instilled corporate habit. One job I had to remember to do that after every restart/full relogin because of GPO overrides. Gross.) Sometimes I wonder if there is some oath I just could sign as a developer that starts with something like "I promise always to at least wash my hands / pay attention to UAC prompts" and "I swear I usually have good reasons to authorize admin access when I reply to a UAC prompt". (And/or you know, use the GPO for what it was meant to do and enforce a minimum UAC, rather than disable it.) (I also find it peculiar how many Windows IT admins and developers I've met that disable UAC in a corporate environment but then personally use macOS and are so happy that is has SUDO prompts and wish Windows had something similar but somehow don't realize UAC is the exact same thing. It's a strange cognitive dissonance that I don't think I will ever understand. Yes, I've heard all the arguments that Vista's first usages of UAC confused them and they gave up learning it before it settled down and they didn't want to unlearn decades of bad habits from 95 to XP, but I guess I find that a really poor excuse because I was a heavy Vista user by choice, partly specifically for UAC. Washing your hands is great, and very professional, and decades of a habit of not washing your hands isn't an excuse I'd expect anyone reasonable to expect, but especially in a hospital. Anyway, I digress.)
danieldk 7y ago
Or one could provide a package manager that allows user installs of software, like Nix. (Depending on the threat model, of course.)
hvidgaard 7y ago
Developers can have local admin because it's expected that you can trust them. If they betray that thrust, then they lose that privilege, and depending on the nature of their work that might mean they cannot work. Bad for them, but surely it was written in their contract.
- ben509 7y ago
  It's never actually in a contract, these are always policies since employment is at-will. But "they cannot work" is implying that person gets fired. I agree that serious breaches of security are a firable offense, because it's plainly a fact that people get fired over them. Generally, though, developers are fairly hard to replace and anyone who is hard to replace is equivalently hard to fire. So most security policies have to work out some kind of compromise between those competing interests.
  - hvidgaard 7y ago
    Some of the US might be at will employment, but it's not like that everywhere. In Denmark employment is not at will, but you can only fire someone if there is just cause. This particular scenario is in the security policy, and in my contract it's stated that I will follow that.
gwbas1c 7y ago
> If you want local admin as a developer, then we need to be able to trust that you aren't going to do something stupid. Issues with trust imply greater problems in the workplace. Unless you're in a high-risk (of hacking) industry, like military, treating adults like children is a huge problem. Granted, there are plenty of ways around these limitations. By now, all of my "I need admin rights" development is performed within a VM.
- deleted 7y ago
  [deleted]
kemiller2002 7y ago
As a person whose straddled infosec and development, I always struggled with this. The multiple development machines is probably the best approach, but I've never truly seen it implemented correctly. I would love to not need admin access to my machine, but each time the companies I've worked for try this, it's always a struggle to do anything. This is everything from, "I need to modify/monitor core components of the operating system" to "The development tools came out with an update that needs to be installed." Most of the time, the response I've received was, "Enter a ticket, and we'll get to it." Often management seems to understand, "I'm waiting someone else" as "I'm behind, I'll work the weekend." You're right the downloading random things from the internet is an issue. Sadly I think a lot of this can be solved by the organization spending the money to buy all the needed tools and evaluate the correct open source ones, but there always seem to be budget and time constraints. I think a lot of this stems from the fact that most of the managers in infosec for companies aren't developers and haven't ever been one. They really have no idea what developers really do. I'm not belittling them. It's just not the career path they took to get where they are. It's difficult to explain to them how frustrating being hindered is, and this causes a lot of good people to just leave an organization like that to find something better.
- deleted 7y ago
  [deleted]
- marsRoverDev 7y ago
  Multiple machines approach can work if you have an IT person dedicated to a development team, located in the same office, with a low ratio of IT-to-other-staff. If the process for getting something like IntelliJ IDEA installed on an airgapped machine involves less than an hour with their help, it's workable. If it is not, forget it. Unfortunately, it takes a lot for management in most companies to see why this is a good idea, and why spending that much on staff ratios is a good idea.
- devdas 7y ago
  IT security people also have different incentives. If developers got bonuses for uptime while being compliant with all security policy requirements, while security and operations got bonuses based on features reliably delivered, you would have different results.
quotemstr 7y ago
> use a good software whitelisting program that tracks elevations & the reasons for them, instead of just blanket giving everyone local admin on their own PC You can propose such a thing. If you're in charge at a company, you might get to implement it. But if you do, know that it's a huge black mark against your company. I've seen how these whitelists work in practice. They're massive wastes of time. They get in the way of actually doing one's job, as creative work can't be constrained and approved in advance by some committee with a ten-business-day turnaround on getting some damn file conversion utility to run. The golden rule of "security product" culture is this: inconvenience is a feature, not a bug, since friction reminds people that the infosec group exists. When it comes to stuff like this, all the incentives are lined up to just inconvenience people, not protect them. We ought to protect data, not code.
- tomp 7y ago
  > We ought to protect data, not code. Code is more dangerous than data. Personally, I'd be most worried by someone getting a virus that hacks into other computers and encrypts them and/or wrecks the network. Both can be protected against, first by cold backups and second by resilient / disaster recovery network, but both would also severely affect the company for a few days, so I'd rather avoid them.
  - devdas 7y ago
    That's code destroying data. Losing data is bad for the business. A random box had software crashing? Just replace the box.
    - tomp 7y ago
      even setting up a new box might take one day of a productive person's time... unless, of course, if you standardise the dev setup... again many devs will complain, probably more than if you just remove local admin :D
theflyinghorse 7y ago
This just irks me the wrong way. What problem are you solving by making work for devs range from "incredibly hard" to "outright impossible" via taking admin privileges away? Surely you must understand that all things should be in balance, that security isn't the sole goal of an organization but rather an important consideration in the overall structure. Are you attempting to create a tech "solution" to a hiring problem? You aren't going to succeed.
lokar 7y ago
I can be done will, with effort. Google manages it.
marsRoverDev 7y ago
I worked at one place where instead of giving us root access to our machine, gave us one that was offline (with access to an air-gapped local network and a dedicated IT guy to ensure we had access to tools/IDEs/licenses etc) and another, shittier one that had internet access side by side. This worked fine. I went somewhere else where we had locked down machines. I am never, ever, ever going back to a place like that. Fuck working in that kind of environment.
java-man 7y ago
I've never seen a clear separation between production environment (machines, network) and the dev. Air gap the two and a lot of problems might go away (not all, of course, but the most common ones).

deleted 7y ago

[deleted]

Cthulhu_ 7y ago

I / we are in an interesting position in that regard, in that there is a policy installed on our laptops that gives us admin access on the one hand, BUT forces encryption and allows our employer to trigger a remote lock / wipe in case of theft. I think that's a good middle ground myself, I mean what if I get murdered and robbed abroad? I don't expect it but it's a possible scenario that might put our customers' code at risk.

raxxorrax 7y ago

Indeed. Don't forget to ask for exceptions for the corporate firewall. And bring some cookies for the grumpy security guy that will make himself heard shortly after the request is permitted by the boss.

growlist 7y ago

I don't think I'm alone in having to switch between multiple machine configs from day to day. The only way I could avoid using VMs would be to physically swap hard drives, at which point why not just work in VMs... As long as one has admin access in the VM of course!

quotemstr 7y ago

Important followup: "Am I allowed local unconstrained root without a usually-performance-killing daemon interfering with my work?" At a few places, I experimented with running Windows. Every time, the Windows machine came with Bit9 or some other performance-killing compatibility-breaking security "solution" that made the system unusable. Windows is a great operating system. What IT departments do to Windows turns it into a nightmare. These same places all had a much lighter touch on Linux VMs, desktops, and laptops, so clearly the invasive "security product" mindset was just contained to the Windows (and in one instance, macOS) groups.

WorldMaker 7y ago
> Windows is a great operating system. What IT departments do to Windows turns it into a nightmare. That's a great bumper sticker. There are so many cases you find of people's Windows complaints where the questions are "Why does Windows even allow GPO to hurt users that badly?" and "Why does your IT staff hate you so much personally that they configured Windows into that particular contortion?" The Unix world has decades of tales of the "sysadmin from hell" / BOFH, of course, but something about Windows administration just seems to elevate to almost universal "art form" across every company, but at the same time has managed to make it "business as usual" rule rather than the to-be-irked-by exception. On no other operating system would that level of IT micromanagement and terrible "security products" be accepted, and on just about no other platform would people just as easily assume it to be OS "bugs" or "inabilities" rather than the forced masochism of some local BOFH.
- relax88 7y ago
  > "Why does Windows even allow GPO to hurt users that badly?" and "Why does your IT staff hate you so much personally that they configured Windows into that particular contortion?" Typically its because the GPO configuration has 15 years of kludge and your IT department is under resourced and doesn't have the ability to spend 6 months sifting through and testing all of it. In Windows environments group policy is often one of the biggest piles of technical debt.
  - 7y ago

goatinaboat 7y ago

Are all developers allowed to have local admin access of their computers? These are the same devs who install random things with curl|sudo bash right? Or write code that can only run as root in production? No thanks. These days of virtualenvs and similar, only incompetent devs insist on being root too. In fact, this will make an excellent interview question, thanks!

ccccc0 7y ago
I think if I got this answer during an interview, as a candidate, I would be pleased that your criteria reject me as an incompetent dev.
dangus 7y ago
When you're not allowed to install applications and tools to your own, that gets in the way of productivity and happiness at work. I've worked at companies where even being able to install something simple like Notepad++ or VSCode was turned into a major chore or made impossible thanks to the locked down environment. Locking down trivially important system preferences like your desktop background is another example of just plain annoying management that I've witnessed. Don't forget corporate network content blocking, and I don't mean the obviously not safe for work content, but companies acting as the productivity police e.g. blocking Twitter and YouTube just because they don't trust you enough to not slack off at work, and furthermore not trusting your supervisor to be competent enough to determine whether or not you've been productive enough lately.
- jjkaczor 7y ago
  ... You are aware that at a point in time, Notepad++ was compromised, right?... https://notepad-plus-plus.org/news/notepad-7.3.3-fix-cia-hacking-issue.html https://notepad-plus-plus.org/news/notepad-7.3.3-fix-cia-hac... As both developer and a systems administrator, I am constantly on both sides of the fence. I have seen developers who cannot even maintain their machines and download any random thing to streamline their job to the detriment of security. Yet, I have seen other organizations where it takes months to get something like VSCode installed (try keeping that up-to-date on an air-gapped machine, that isn't connected to the internet... or ... Node.js or... full Visual Studio...)

chinhodado 7y ago

I'm curious what the answer to this question is for MS/Google/FB/other big companies