|
| Featured Contents |
| Question of the Day |
| The Voice of the DBA |
The Road to Better Data Handling Recently I was on an internal communication thread with multiple people at Redgate Software. We have various ways to keep our (semi-) distributed teams in touch with one another and handle issues. While email works, I think many people like Slack better for quick discussions. I appreciate that as a remote worker since I'm not around to hear a conversation around a desk. To be fair, with a busy staff, others often aren't as well, so a thread in Slack often saves details others can see later. In any case, we had some issue. I don't know if this was a product issue with a customer or a communication item for our marketing group. No matter what it was, we had someone mention they could help if the first poster would provide details. The next message that I saw was great. It said something along the lines of "Please do not post email details in Slack." A gentle reminder, but one that was needed. It's great that we want to help others and work through problems, but in many companies we've played far to fast and loose with data. Many of us hate the constant struggle to extract (or remove) information in "notes" fields in our databases. It's a hassle when we want to work with data that hasn't been put in a normalized space. It's also a source of data leakage. While we might appreciate getting a quick note, these aren't secured communications, and more importantly, they provide yet another attack vector for problems if we lost control of the backups, archives, etc. Even worse, we could have gotten a request to remove emails and someone decide to contact the user later, knowing they can search through old Slack messages. Likely a bit of an extreme example, but still a place where data handling should be better. We have secure systems for tickets or issues where we can store data. Or we can reference their information in another way. I've started doing this in GitHub, where we often log issues for SSC users. Rather than putting in an email, I'll put a user ID or other identifier. If the user wants to delete their account, I don't want their email floating around anywhere it isn't required. While it might be a bit more hassle to be careful with personal information, I think it's much better than treating it as unimportant and potentially having it disclosed in some security incident. Whether it's my email, tax ID number, or credit card, I'd want my own data handled carefully and am trying to do the same for others. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
