Hacker News Reader

Comment by rincebrain | Hacker News Reader

It's not, actually, solely that.

If you're using a product that does not make API calls externally with your data previously in a corporate environment that has very strict controls, and they add a feature that is part of the base install package, even if opt-in, that allows it to do that, and they do not have something like Group Policy hooks to forcibly disable it from on high, then they will block the product globally until the functionality is more contained to something their compliance systems can prevent, be it via a group policy hook or blocking the install at all.

Companies take "we might make an external call with your data" very seriously, and regardless of how much you trust the external entity, adding that in is rightfully seen as a very serious concern in some environments.

View on HN

This comment is aimed at the people who made this argument, not you specifically.

This is a completely ridiculous strawman.

If a corporation needs strict controls then they don't allow for auto-updated software without vetting. They could have asked for a policy to disable the integration but they didn't, instead those people screamed about how they were going to have to completely block iTerm which showed their incompetence. This was in beta for quite a while and none of these "serious IT people" cared so either they are asleep at the wheel (not vetting beta versions) or they allow for auto-updates to software they don't control, either way it screams incompetence to me.

Also we are talking about a terminal here, a tool that can connect wherever the developer tells it to connect to. Are you telling me these companies lock down where a developer can SSH to but are too stupid to block traffic to OpenAI? Or they don't lock down where a developer can SSH and therefore don't talk to me about "strict controls".

Make it make sense. It just doesn't. This argument never held any water for me.

Various people suggested or demanded various things for various reasons.

Some described company controls. Some described company policies without controls. Some described their own strong feelings.

Some had auto updated. Some had not. Some did not say.

Some supported their companies' policies. Some stressed the policies were out of their control. Some did not say.

Some asked how to make sure the integration was disabled. Some did ask for a setting an IT department could manage. Some demanded a plugin or separate build. Some said a plugin would work for them.

Many things don't make sense if you assume everyone you disagree with are a collective.

I didn't assume they were a collective. I read through many of the comments on the GitLab issue as they were happening and there wasn't as single valid complaint. Not one. Zero. Zilch.

It was opt in, full stop. That should have been the end of this aside from IT managers asking for a group policy or a was to disable the feature (in a nice way).

Everyone complaining could either not update or move to a different tool and ask for a refund... oh wait... that's right, this was open source software. And people wonder why no one wants to maintain open source software. Just add this whole ordeal to the ever-growing pile of reasons why it's almost not worth doing. People are so entitled. My personal favorite were the people that said "If you remove this I'll start support you monetarily", which I assume 99% of those people were lying through their teeth based on the lack of spike in new donations to his patreon [0].

[0] https://graphtreon.com/creator/gnachman

You combined parts of different comments, ignored others, and claimed the combination represented all.

Some were IT managers. Some were users capable to speak for their IT managers. Some did not say. There was no reason comments should have been limited to identified IT managers.

Some asked how to make sure the feature was disabled. Some did ask for a group policy. Some asked for a plugin or separate build because a group policy would not satisfy their company's requirements. The maintainer solicited these requests even though he disagreed with the requirements.

Some blocked the update. Some rolled back. You must know unsupported software has costs.

Do people wonder why more people don't maintain open source software? Most people don't maintain open source software. They have reasons. I think they can imagine other people not maintaining open source software for the same reasons.

I maintained open source software. Attitudes like yours tired me more than the rude minority of users.

Patreon is 1 of 6 donation methods. And I don't think the people who offered to pay $50 meant monthly.

> Companies take "we might make an external call with your data" very seriously, and regardless of how much you trust the external entity, adding that in is rightfully seen as a very serious concern in some environments

Please don't take this as an attack to you, but one would think that environments where this is a very serious concern would also be environments that either buy software, or buy support contracts with open source developers, to make sure that what they install is compliant with their concerns.

A lot of times the open-source software is used "unofficially", where IT/security turns a blind eye to it as long as it doesn't openly violate policies.

And often the developer is not offering a support contract. They might even take umbrage at the idea of being bribed to make changes!

A lot of open-source software usage in the workplace is the equivalent of bringing your own tools to a worksite, or bringing your own knife set to the kitchen. I obviously can't see the project's finances, but funding for tools like iTerm 2 can be heavily dependent on individual users acting as patrons, making monthly donations purely out of gratitude for bringing them joy and/or improving their personal work productivity.

All of what you said is true, but I just want to add a note that I mentioned a support contract with open source developers, not necessarily the authors of the open source software in question.

It's like when a company buys a contract with an enterprise Linux distribution: the entity offering the contract didn't author the full stack (though I'd guess they have at least some kernel contributors on staff) but they can still support it in a way that keeps the compliance department of the buying company happy.

Also, your kitchen knife set example is very relevant because, from personal experience, I know this happens but I also know problems (including accidents) resulting from using a personal knife set aren't attributed to the manufacturer of the knives but instead are treated exactly as if they happened using ones provided by the business that owns the kitchen.

Not to mention that an IT department that is truly concerned about this risk would just block the AI APIs at the network level and be done with it. A competent IT department with the concerns that OP is expressing would know that there's no way for them to keep track of all the software that is implementing AI features and would make the very easy change that would solve all of those concerns at once, not go on a witch hunt against iTerm2.

This means that the only people that we're supposedly catering to here are incompetent IT departments, which doesn't seem worth the hassle for the maintainer or all of the other users.

Or, more likely, this hypothetical IT department that cares enough to block iTerm2 but doesn't care enough to block on the network level is a fiction invented by people who just really hate seeing AI added to everything.

Totally! People in these kinds of environments have no leg to stand on criticizing a free and open source project. If you don't like it, don't use it, but CERTAINLY do not demand of the developers that they honor your requests when you don't contribute to development.

Most employees in corporate environments do not get to set company policy.

Most users of open source software do not have the skills necessary to modify said software.

Complaining is the only recourse that most people have.

They can take their fat corporate salaries and hire a therapist to listen to them complain. Leave the FLOSS maintainers alone.

This is not universal.

I work in a company that uses many different products that (attempt to) make external API calls with extremely sensitive data, and none of these products are blocked from installation, because we block all their requests at the network level, instead.

Yes, the corporate management is useful, but not critical, and the lack of it absolutely didn't justify the generated outrage.

e: You changed this from "This is not true." to "This is not universal." in the time when I was writing this response, which is fine, but I wasn't claiming this is universally the case, I was claiming that in some environments, this is how the logic works. It's more or less the same outcome and rationale as when JetBrains had theirs in a "plugin" that you couldn't effectively block even if it was a noop because it required an API key.

Sure, in an environment where external access is not necessary or can be easily allowlisted, that works fine.

But on someone's interactive workstation, where they might need to access parts of the internet without getting explicit allowlisting of every web site, then it's a different set of tradeoffs, and not every company implements this the same way.

From the perspective of "some corporate environments will block your software if it doesn't have this feature", then I suppose I can understand the frustration that users felt.

I would argue that there's more nuance, but the feeling is reasonable - I would also be frustrated if a piece of software that I used and loved at work was in danger of being taken away because of the addition of a feature that I didn't want in the first place!

What do these companies do about browsers? If they can block at the network level, group policy to disable an app feature is moot.

Put another way: if corporate policy blocks this app but not access to OpenAI, they are not solving the underlying issue. If they already block OpenAI they don't need the application control.

> What do these companies do about browsers?

Many things, browsers are pretty configurable via group policy. One possibility is to force browsers to go through a proxy that inspects all traffic, for example.

So these companies configure every application on the system individually to use a proxy? What about things like curl?

More likely they configure the operating system to force network traffic through a certain hole, or force users to manually connect to full tunnel VPN to access work resources.

Currently my employers inspect every network call made on my device, and while they do not block OpenAI, they do block us from running specific browsers that cannot have their built in “secure” DNS settings changed such that they won’t sidestep inspection.

I get emails if I visit the Eicar test file website.

In a sufficiently high-security environment, they just block all network access that doesn't go through the proxy. That's a fairly nuclear option, however, as it also blocks a lot of harmless traffic (Spotify, for example)

Which, incidentally, would render this feature useless and harmless.

It's just really hard to see the argument against the feature as anything other than an excuse for general anti-AI sentiments. Organizations that really care about this already have the tooling in place to stop all AI features in all products with just a few network-level rules. If they don't have that tooling, they're not taking it seriously and they're not going to start suddenly blocking iTerm2 because it added an optional AI feature.

They don't, actually. Network blocking is all fine and dandy until someone adds a secure proxy into their software. Shit like this is exactly why enterprise software implements policy controls (as iTerm has just done).

I think people expect browsers to go outside the LAN, though? I don't expect a termainal like iTerm2 to be sending out network requests other than maybe to see if there's an update. I think people in IT, especially ones where security is core, like that sort of thing. That said they could courteously request it get turned off rather than freak out over it (it is free after all), but I think people don't like surprises out of staples like a terminal.

You're missing the point though: the only real argument I've seen for this being extracted altogether is a corporate environment where the existence of this feature would be enough to get the application blocked. OP is questioning why that would be a reasonable approach for an IT apartment to take—if they already block OpenAI then the feature won't do anything even if configured. If they don't already block it, then there are almost certainly people in their company using OpenAI with the browser.

Network level blocking is easier and more effective, so why should iTerm2 have to go to contortions to remove an already opt-in feature that would be easily blocked by a network block?

Mandatory browser extensions are common, as are MITM proxies for all traffic.

What do these companies do about curl or telnet or SSH or any number of developer tools?

From experience, “we don’t talk about those”.

> Companies take "we might make an external call with your data" very seriously

No, they want to be seen taking it seriously, so they say that they take it very seriously. But if you will actually audit their system you will find they do not in reality and it was just a negotiation tactic.

Having worked in such environments one of two things happen:

1. Developers are forced to use Windows and given very little CLI access. And they certainly wouldn’t be using iTerm since it’s macOS only.

2. Developers are given a Windows corporate device as well as a MacBook Pro. The MBP doesn’t have access to any corporate systems

3. Developers can access corporate systems on MBP via jamf or InTune. The corporate side of the business accepts the risk that developers can access external (read: non-vetted) services but the business has access to all internet traffic logs from your device (usually pushed into some kind of security package that monitors for suspicious traffic) plus the ability to remote wipe it. So there is a degree of trust given to the developers.

Those that are stuck with option 1 are usually the unhappiest and least productive. So it’s not something most businesses like to entertain unless senior management is very corporate and the business is considered high risk.

What's good for the goose is good for the gander. None of these companies so much as bat an eye when applying the most sweeping, invasive data collection against their users. They should be equally thrilled to have spyware on their LAN that may enable more relevant workplace experiences for their employees.

iTerm is a terminal program that only runs on MacOS.

Unless those very strict controls include either blocking at the network level accesses to IP addresses not on a pre-approved list or removing a large number of programs and libraries that are standard on MacOS the person using iTerm will have plenty of readily available ways to use external services with that data if they want to.

Heck, the free version of ChatGPT can tell you how to access ChatGPT with curl if you don't know how [1].

I specifically asked about curl, but it would also work if I asked it to suggest a MacOS command like tool: "On MacOS what command line tools could I use to ask ChatGPT a question? Assume I have a ChatGPT API key". It suggests curl, httpie, and wget and shows how to use all of them. I updated the link below to include that too.

[1] https://chatgpt.com/share/00d9de15-4e43-497f-a116-bfe3972471...

Block it with the same mechanisms you use to block web browsers from accessing the same content. If you do that already, you’re got. If you don’t, apparently it’s not that much of an issue.

So, just because some corporate cannot keep up with their IT compliance team with new additions to existing tools in their stack (which is honestly a tedious job), should the OSS stop experimenting and shipping new 'optional' features? There are many developers who use iTerm2 outside of a corporate environment too. I, for one, developed clx[1], which is similar in nature to what iTerm's OpenAI integration is. I am happy to have this built right into my terminal. And the code is open source as well, allowing anyone to audit what actual external API calls are being made.

[1]: https://github.com/mr-karan/clx

Reply on news.ycombinator.com