9 ms·

I've not used teams, but both slack and Google chat make it very easy to post messages, a simple curl call has often been more than enough in lots of scripts

by mcfedr 5y ago

lloeki 5y ago
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.
- deberon 5y ago
  Would IRC even work in that nameless enterprise?
  - singron 5y ago
    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.
  - lloeki 5y ago
    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.
    - franga2000 5y ago
      What's more "under control of the enterprise" than a self-hosted IRC server?
      - u801e 5y ago
        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.
        franga2000 5y ago
        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.
        jethro_tell 5y ago
        *print screen and phone cameras.
        oarsinsync 5y ago
        > 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.
        franga2000 5y ago
        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.
- efdee 5y ago
  > That is, unless the enterprise has policies to abide by disallowing API calls ...What?
  - tl 5y ago
    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/access-management/office-feature-disabled 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.
    - tomrod 5y ago
      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.
      - lloeki 5y ago
        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.
        tomrod 5y ago
        Yep. Sounds like a common-enough pattern then. (I wasn't joking in my post).
    - userbinator 5y ago
      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?
- tptacek 5y ago
  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.

I've not used teams, but both slack and Google chat make it very easy to post messages, a simple curl call has often been more than enough in lots of scripts

by mcfedr 5y ago

I've not used teams, but both slack and Google chat make it very easy to post messages, a simple curl call has often been more than enough in lots of scripts

lloeki 5y ago

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.

deberon 5y ago
Would IRC even work in that nameless enterprise?
- singron 5y ago
  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.
- lloeki 5y ago
  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.
  - franga2000 5y ago
    What's more "under control of the enterprise" than a self-hosted IRC server?
    - u801e 5y ago
      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.
      - franga2000 5y ago
        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.
        jethro_tell 5y ago
        *print screen and phone cameras.
        oarsinsync 5y ago
        > 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.
        franga2000 5y ago
        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.
efdee 5y ago
> That is, unless the enterprise has policies to abide by disallowing API calls ...What?
- tl 5y ago
  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/access-management/office-feature-disabled 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.
  - tomrod 5y ago
    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.
    - lloeki 5y ago
      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.
      - tomrod 5y ago
        Yep. Sounds like a common-enough pattern then. (I wasn't joking in my post).
  - userbinator 5y ago
    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?
tptacek 5y ago
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.