That is, unless the enterprise has policies to abide by disallowing API calls, in which case you're stuck with the official client and vetted integrations.

Same for mobile, the advantage vanishes once enterprise requires your (usually personal) phone to be surrendered to corp IT via MDM (which I sure as hell won't do).

The whole value proposition of Slack and Teams for their customers is control.

It's self-evidently false that the whole value proposition of Slack is control. The value proposition is, obviously, "IRC but more stuff, with searchable, durable messages". Which is why all sorts of groups that don't care about control at all still use Slack, rather than IRC, to coordinate.

> That is, unless the enterprise has policies to abide by disallowing API calls

...What?

Welcome to enterprise, where breaking things is a feature so commonly used Microsoft has documentation for it [1] and things are often deployed by people whose sole concern is "minimize attack surfaces". Our Teams installation not only disables API calls (official Teams client only), chat sessions are deleted if no one posts to them meaning most chat history is lost every weekend.

[1] https://docs.microsoft.com/en-us/office365/troubleshoot/acce...

Microsoft uses these anti-features as a selling point, and in a large enough organization, it's not immediately clear who turned them on or who can turn them off.

What a perfect way to describe the situation.

Imagine an enterprise disallowing all VCS service providers -- whether hosted on-prem or cloud -- because they use SSH instead of HTTP.

You think you're joking but I've lived through exactly that. Reason: SSH cannot be examined by a HTTP proxy. The moment we raised that HTTP CONNECT is a TCP passthrough thus equivalent we got to install a bespoke root certificate on our machines for the proxy to MITM every single connection.

Yep. Sounds like a common-enough pattern then. (I wasn't joking in my post).

> Our Teams installation not only disables API calls (official Teams client only)

Wait? Can you even make API calls to Teams without getting the account owner to make a key for you? I’ve been looking for a way to use a personal key or credentials to make some calls, but the docs are absolutely impenetrable.

If the official client can still post and receive messages, what's preventing anyone else from doing it in the exact same way...?

Or is this something stupid like a user-agent check?

Would IRC even work in that nameless enterprise?

Technically, yes. In real life, no.

I don't even blame such enterprises because most of the time it comes from regulations or outside policies that customers mandate, something like all enterprise data (and thus communication) has to be firmly under control of the enterprise with hard guarantees, otherwise you just don't get to work with those customers. So you get a locked down Slack/Teams, and the email+calendar system disallows any native app unless the device is MDM'd, and even that is only with first party clients such as the Gmail app or Outlook.

TBH I think most companies are trying to do their best there, but they're stuck with some kafkaesque liability system.

What's more "under control of the enterprise" than a self-hosted IRC server?

It doesn't prevent clients from logging communications in that server. I know the same is possible in slack or teams, but they don't consider that from a legal perspective.

From a legal, practical and technical perspective, any window displayed on any screen is equally succeptible to logging. I can't imagine the fact that the company disabled ctrl+c in the policy settings making any difference in a liability case.

> I can't imagine the fact that the company disabled ctrl+c in the policy settings making any difference in a liability case.

Taking reasonable measures absolutely does absolve the company. At that point, it becomes a rogue employee who’s deliberately circumvented policies and technical enforcements, who is now potentially personally liable.

It’s garbage, but hey ho.

Fair enough, they did "try", but still feels equivalent to putting sensitive documents in a glass frame with a "no photos please" label on it and then claiming you did everything you could to protect them. I can't imagine that would fly in court, but I guess as soon as computers are involved, all common sense is lost.

*print screen and phone cameras.

Also legal: doing it in house it's on you vs being a Slack feature means it's on them. CYA by outsourcing.

And consider this also: "hey we're quite sure pur homegrown system is as leak proof as it can be, trust us or fire up an audit team for 5 sprints to asses compliance" vs "Slack has the box checked already"

The fact that folks can e.g technically fire up a headless browser and programmatically interact with the app via capybara or whatever to rebuild a makeshift API, or just take pictures with their phones because the compliant system is inconveniencing them daily is immaterial.

that's really funny. because i did this for CYA reasons.. with different methods, but mostly with screenshotting or autohotkey stuff.

IRC might be run by engineering there for themselves. 3rd party chat would got through procurement and be provided by IT for the whole company, and after the last SOC2 audit, they had to lock it down.