3 ms·

fwiw, when I have to share a password or api key in a DM once the party acks receipt I then delete the message. Unless a snapshot is taken in the interval I rea

fwiw, when I have to share a password or api key in a DM once the party acks receipt I then delete the message. Unless a snapshot is taken in the interval I reason that there won't be a persistent copy left behind. Does anyone 'behind-the-curtain' know anything that would contradict my assumptions?

ecnahc515 7y ago
Those messages are certainly not deleted in the backend. They can be read by your organization's slack admins even.
- Wowfunhappy 7y ago
  Wow. This should be considered harmful, due to exactly the scenario described by the GP! Perhaps it's true that tokens and such should not be shared on a channel like Slack to begin with, but it's also very reasonable to assume that deleted messages actually get deleted, at least absent a data forensics expert or similar.
  - ci5er 7y ago
    Why would you assume that? I (as the 'designer' of a couple of distributed event-sourced systems), will create a message (as an event) that ricochets around to update several SQL and non-SQL systems that are normalized or denormalized views, or what not. When a 'delete' command (event) gets sent around, that gets accepted by subscribers/listeners, and they 'mark' their respective 'column' equivalents as 'deleted', but in an append-only log, the idea that a disk block gets updated is kind of nonsensical. The logic goes: 1) something happened. 2) we regret it - please hide it from (most) quesry responses. I know if I was dealing with an RDBMS, it's probably easy enough to delete it, but in an eventually consistent, heterogenous, append-only world, an actual delete-delete is kind of a hassle to even contemplate.
    - Wowfunhappy 7y ago
      If it needs to exist in the raw database for technical reasons, that's one thing, but it shouldn't be visible to anyone including the administrator.
      - ci5er 7y ago
        If you mean the site-/team- administrator, that's probably right. (We have similar issues for HIPAA related reasons). Our production emergency debuggers, there aren't many, get a bit more leeway than they probably should because they are trying to help us respond to failures under heavy SLA penalties. The 'these-people-ran-this-query' logs are immutable, and (hopefully) keep them in check from random lookups on their ex's during some dumpster fire exercise or another.

ecnahc515 7y ago

Those messages are certainly not deleted in the backend. They can be read by your organization's slack admins even.

Wowfunhappy 7y ago
Wow. This should be considered harmful, due to exactly the scenario described by the GP! Perhaps it's true that tokens and such should not be shared on a channel like Slack to begin with, but it's also very reasonable to assume that deleted messages actually get deleted, at least absent a data forensics expert or similar.
- ci5er 7y ago
  Why would you assume that? I (as the 'designer' of a couple of distributed event-sourced systems), will create a message (as an event) that ricochets around to update several SQL and non-SQL systems that are normalized or denormalized views, or what not. When a 'delete' command (event) gets sent around, that gets accepted by subscribers/listeners, and they 'mark' their respective 'column' equivalents as 'deleted', but in an append-only log, the idea that a disk block gets updated is kind of nonsensical. The logic goes: 1) something happened. 2) we regret it - please hide it from (most) quesry responses. I know if I was dealing with an RDBMS, it's probably easy enough to delete it, but in an eventually consistent, heterogenous, append-only world, an actual delete-delete is kind of a hassle to even contemplate.
  - Wowfunhappy 7y ago
    If it needs to exist in the raw database for technical reasons, that's one thing, but it shouldn't be visible to anyone including the administrator.
    - ci5er 7y ago
      If you mean the site-/team- administrator, that's probably right. (We have similar issues for HIPAA related reasons). Our production emergency debuggers, there aren't many, get a bit more leeway than they probably should because they are trying to help us respond to failures under heavy SLA penalties. The 'these-people-ran-this-query' logs are immutable, and (hopefully) keep them in check from random lookups on their ex's during some dumpster fire exercise or another.