Live data from Hacker News

Figure out who's leaving the company: dump, diff, repeat

rachelbythebay.com

381–390 of 392 posts

Re: Figure out who's leaving the company: dump, diff, repeat

#381
When I was working on a small sized startup. We used to write “obituaries” for people who resigned in a newspaper format. We would add some insider jokes as a side article and some parody ads about their new company on the page if the person resigned already found a new company.

IIRC, it started from my resignation. Then we kept doing it for future leavers

Re: Figure out who's leaving the company: dump, diff, repeat

#382

Earlier quoted context omitted.

The blog post mentions "Someone else who knew you had to add it", but this is not exact (or no longer exact). An employee can send an email to a special address with the content, and it will show up when they leave the company. That's what I did. That said, I can't double-check to see if it worked. :) Thanks for the tool, Evan!

Laurent FYI it didn't work (FYI we interacted over the cider font size thing). I couldn't find you anywhere even though I know your ldap.

Ah, maybe I wrote the email and forgot to press send. :)

Well, you can update Epitaphs and add a link to "go/laurentlb". Thanks!

Re: Figure out who's leaving the company: dump, diff, repeat

#384

Earlier quoted context omitted.

> A diff of the directory is abuse? Yes, if it contains employment information. A bunch of diffs can cross the threshold into event sourcing and if you have enough of them you might end up with a copy of the directory.

I already have a copy of the entire source code for this application, including all of the secret database logins. Why would having a copy of the employee directory be a bigger problem? (To be clear: I'm trying to understand the issue, not dismiss it)

First off, the article is about processing and metadata analysis, not just a mere "copy". Then, let's clarify: You legally stream a movie, you are also "copying" files to your computer, yet keeping "a copy" of the entirety would be considered illegal. Pedantic, naive technicalities are a ill-advised legal defense, and so is the expectation of object-oriented jurisprudence. Not everything is categorically same, because of a shared attribute. Intent matters.

With your argument you are conflating intellectual property and business assets of your company, with privacy and informational self-determination of your colleagues. The latter isn't necessarily in the direct interest of your employer, but rather a right given by ethics, or governmental entities. Never mind metadata, a simple copy could mean transferring sensible information to a context where access control for unauthorized parties isn't implemented. Eg. you could have your take-home work laptop stolen, or compromised while watching porn. Legislative example: Under the GDPR, a doctor or therapist is not allowed to handle any patient data on private devices, which extends to contact information stored on their private phone. Context matters.

Not everything is about money, or monetary damage. Privacy rights are about freedom and self-determination of the individual.

Although, the organizational structure and history of a corporation certainly has implications for operational security as well. Try mapping and exfiltrating employment graphs and collected personal metadata at a defense contractor and see where that gets you. Mind you, OP's respective metadata analysis has little informational value in a ten peopled start-up, where you talk to everyone anyway. We're here considering corporations large enough for the individual employee to miss operational oversight by direct means. Corporations large enough, that meta-data would be valuable for third parties, too. Trust matters.

Re: Figure out who's leaving the company: dump, diff, repeat

#385
post #234

Earlier quoted context omitted.

Are you referring to GDPR? Does it apply to employees too, or only customers?

GDPR definitely applies to employees as well. It applies to all handling of personal data. One of the most important rules in GDPR is the requirement for companies to have an up to date list of all places where personal data is being stored, the reason it's stored there and what it's used for and the retention policy. So an employee creating their own lists of previous employees could potentially get the company in t…

Not speaking about GDPR, but your post is triggering me (my issue, not yours).

Here’s what is crazy to me about employee PII (personally identifiable information) being considered sensitive.

Say in a well designed system you can audit who made each change or the last change to each business record. As an example, each database table has a login ID of who modified the last record/row most recently.

Now every single such table is polluted with PII?

I get having a list of all the places where personal data is stored, but some people think we need a list of all the places a pointer to personal data is stored (ie an identifier that enables linking; that is what “PII” literally means) and that is just such a bigger dataset I don’t think it is appreciated how deep the rabbit trail goes applying policy to technology.

Every email in an organization contains PII and every system emails can get saved and attached to.

Back to your comment, does GDPR require just listing the personal information locations, or also the (PII) identifiers to it? Is a name alone considered personal information (if I sign my emails with my name does that go on the list and if so, can companies just declare huge subsystems as having personal information?)

Re: Figure out who's leaving the company: dump, diff, repeat

#386
post #11

If you're going to run something like this, I thoroughly recommend using Git for it. You can have your cron do something like this: curl https://internal.corp/employees.txt > employees.txt git add employees.txt git commit -m "Automated: $(date -u)" || exit 0 The || exit 0 should ensure no errors even if there is nothing to commit Now you have a commit history of every change made to that source of information - just…

  if git is-there-anything-to-commit; then git commit ...; fi

  'is-there-anything-to-commit' is aliased to '! [ -n "$(git status -s --porcelain --untracked-files=no)" ]'

Re: Figure out who's leaving the company: dump, diff, repeat

#387
post #11

If you're going to run something like this, I thoroughly recommend using Git for it. You can have your cron do something like this: curl https://internal.corp/employees.txt > employees.txt git add employees.txt git commit -m "Automated: $(date -u)" || exit 0 The || exit 0 should ensure no errors even if there is nothing to commit Now you have a commit history of every change made to that source of information - just…

A colleague of mine would do a sort of temporal-network analysis of this data to see which people either enjoyed working with (or for) each other or which did not, based on how people would switch groups over time.

Did s/he use the analysis results for anything? (If you know)

Re: Figure out who's leaving the company: dump, diff, repeat

#388
post #11

If you're going to run something like this, I thoroughly recommend using Git for it. You can have your cron do something like this: curl https://internal.corp/employees.txt > employees.txt git add employees.txt git commit -m "Automated: $(date -u)" || exit 0 The || exit 0 should ensure no errors even if there is nothing to commit Now you have a commit history of every change made to that source of information - just…

I've been seriously considering using Git for all sorts of oft-changing-but-rarely-majorly data. Lists of books in my bookshelves. The other problem is that I sorta want transactional-database features on top of these things. Git does this well. I also want fast indexing on parts. Git does not do this well. I am considering writing a "standard" for the dumping of sqlite to git, so that I can just delegate this out; A…

If anyone is coming in late, I have discovered https://immudb.io/ , which claims to be a lot of what I'm looking for. Transactional SQL database, indexed, yet immutable data and verifiable chains of transactions.

Re: Figure out who's leaving the company: dump, diff, repeat

#389
Epitaths is a Google thing. I had a friend at Qualcomm who wrote a script to sample the employee phonebook every morning before work so he'd know if he were laid off. We used "ph" from UIUC and the company strangely laid people off not by deleting them but instead by putting them into department 700, "The laid-off department".

The web UI allowed elaborate queries so the first time there was a big layoff the ph web page almost went down because everyone was querying to find out who was laid off. Management got mad at this but they really shouldn't have; its correct that you shouldn't work someplace that tries to hide attrition no matter what the source!

My friend never got put into dept 700 because i recruited him into Google a few years later ...

Re: Figure out who's leaving the company: dump, diff, repeat

#390

Earlier quoted context omitted.

A colleague of mine would do a sort of temporal-network analysis of this data to see which people either enjoyed working with (or for) each other or which did not, based on how people would switch groups over time.

Did s/he use the analysis results for anything? (If you know)

I'm fairly certain they used it to gauge future project opportunities as our work was often multi-disciplinary across departments. It was probably also useful for validating people's stories if they came up. For example, if someone wanted to switch into your group 'A' from group 'C' and they had been working on a project with X, Y, and Z, then you could get a strong sense of why that might feel that way.
Post reply on HN