O Pinterest demitiu engenheiros que monitoravam demissões no Slack — o que isso revela sobre privacidade, confiança e telemetria interna?

/Em geral/ Por

Segundo relatos, o Pinterest demitiu dois engenheiros depois que eles escreveram scripts para identificar quais colegas estavam sendo removidos de ferramentas internas durante uma demissão em massa — e então compartilharam essa lista amplamente. À primeira vista, trata-se de uma história dramática sobre o ambiente de trabalho. No entanto, em sua essência, é um estudo de caso excepcionalmente claro sobre como as empresas modernas realmente funcionam: sistemas de identidade como fonte da verdade, plataformas de bate-papo como organogramas de fato e “dados internos” que são tecnicamente acessíveis muito antes de serem socialmente aceitáveis.

O incidente é relevante para além do Pinterest porque os mesmos ingredientes existem em quase todas as empresas de tecnologia: identidade centralizada, Slack ou Teams, sistemas de RH e uma longa lista de painéis internos e APIs. Em tempos de calmaria, ninguém reflete muito sobre a tênue linha que separa a observabilidade da vigilância. Quando ocorrem demissões, essa linha se torna evidente.

Nesta explicação, analisaremos o que provavelmente aconteceu, por que é tentador realizar esse tipo de rastreamento, onde ele ultrapassa os limites éticos e políticos e o que as organizações podem fazer para reduzir tanto os danos à privacidade quanto a tentação de coletar informações de forma obscura.

O que aconteceu (e o que "um roteiro" provavelmente significa aqui)

Segundo a BBC, o Pinterest afirmou que "dois engenheiros escreveram scripts personalizados que acessaram indevidamente informações confidenciais da empresa para identificar a localização e os nomes de todos os funcionários demitidos e, em seguida, compartilharam essas informações amplamente", classificando a ação como uma violação das políticas da empresa e uma questão de privacidade para os funcionários afetados. A reportagem também descreve o mecanismo utilizado como um sistema de monitoramento para identificar nomes de funcionários sendo removidos ou desativados em uma ferramenta de comunicação interna "como o Slack".

Em muitas empresas, o Slack (ou similar) está diretamente vinculado ao provedor de identidade (Okta, Azure AD, Google Workspace, etc.). Quando uma conta é desativada, ocorre uma reação em cascata: os tokens de acesso expiram, os grupos mudam e o usuário deixa de aparecer em determinadas buscas de diretórios, canais e integrações. Se você tiver acesso à API (mesmo que somente leitura), muitas vezes é possível inferir quem teve a conta encerrada simplesmente detectando as mudanças de estado.

  • Um usuário desaparece da lista de “usuários ativos”.
  • O perfil do usuário é desativado.
  • Um bot não pode mais enviar mensagens diretas para eles.
  • A participação deles varia entre canais ou grupos de usuários.

Um "script", neste contexto, não precisa ser sofisticado. Pode ser apenas algumas dezenas de linhas de código consultando uma API, comparando a lista de usuários de ontem com a de hoje e emitindo um alerta. De uma perspectiva puramente técnica, é o mesmo padrão que os engenheiros usam para tarefas operacionais legítimas: comparar duas versões para detectar mudanças.

A diferença reside no que está sendo detectado (pessoas), no motivo da detecção (demissões) e no destino dos resultados (amplamente divulgados).

Por que os funcionários fazem isso durante as demissões?

Existe uma verdade incômoda sobre demissões: as pessoas geralmente ficam sabendo dos detalhes por canais indiretos antes que a liderança esclareça qualquer coisa. Às vezes, isso acontece porque a liderança ainda não pode compartilhar os detalhes. Outras vezes, é porque "ainda estamos definindo os detalhes" é um eufemismo para "não queremos dizer nada".

Assim, os funcionários recorrem a quaisquer sinais que existam:

  • Os amigos de repente ficam em silêncio.
  • Os convites do calendário desaparecem.
  • O acesso aos repositórios foi revogado.
  • O status no Slack muda repentinamente ou a pessoa desaparece do diretório.

Rastrear esses sinais pode parecer um ato de autodefesa. As pessoas querem saber:

  • Minha equipe foi afetada?
  • Meu gerente foi demitido?
  • Meus colaboradores mais próximos ainda estão aqui?
  • A empresa está bem, ou trata-se de uma reestruturação mais ampla?

Essa motivação é humana e previsível. Mas comportamentos previsíveis ainda podem ser prejudiciais.

O problema da privacidade: o status de demissão é uma informação sensível.

Um processo de demissão não é apenas uma "curiosidade de trabalho". Trata-se de informação pessoal sensível sobre a situação laboral de alguém, frequentemente relacionada a benefícios, imigração, seguro de saúde e perspectivas de emprego futuro.

Mesmo que uma empresa planeje anunciar publicamente uma redução no número de funcionários, a identidade dos indivíduos e seus locais de trabalho geralmente devem ser divulgados apenas quando necessário:

  • Os departamentos de RH e folha de pagamento precisam de detalhes.
  • A equipe de TI precisa executar o processo de desligamento de funcionários.
  • Necessidades legais para garantir a conformidade.
  • Os gestores precisam se comunicar diretamente com suas equipes.

O compartilhamento interno amplo de uma lista de funcionários demitidos é diferente. Pode:

  • Eliminar a capacidade da pessoa afetada de controlar a narrativa.
  • Revelar a localização ou a qual equipe alguém pertence.
  • Incentivar fofocas e especulações (“foi uma atuação?” “foi algo político?”).
  • Aumenta o risco de assédio direcionado ou divulgação de informações pessoais fora da empresa.

A estratégia do Pinterest — de alegar que violou a privacidade de ex-colegas — não é apenas relações públicas. Trata-se de uma categoria real de dano.

O problema de segurança: controle de acesso não é o mesmo que autorização.

Muitos sistemas internos funcionam com permissões genéricas: se você for um engenheiro, poderá consultar um diretório ou usar uma API interna. Isso não significa que você esteja autorizado a usá-la para qualquer finalidade.

É aqui que muitas organizações encontram dificuldades. Elas criam ferramentas internas que são:

  • Fácil de usar,
  • Poderoso,
  • Mal administrado.

E então eles se apoiam em políticas (“não faça isso”) como principal mecanismo de proteção. Quando a pressão é alta, mecanismos de proteção baseados apenas em políticas falham.

O NIST SP 800-53 é um dos catálogos padrão que as organizações usam para pensar em famílias de controles, como controle de acesso e auditoria. Mesmo sem nos aprofundarmos nos IDs de controle, a ideia básica se aplica perfeitamente aqui: o acesso aos dados deve ser restrito, monitorado e atribuível a propósitos comerciais legítimos — especialmente para categorias de informações sensíveis.

Em outras palavras: “tecnicamente você pode ler isto” nunca deve ser interpretado como “não há problema em você ler isto”.

O problema cultural: o Slack se tornou o organograma.

Atualmente, a maioria das empresas vive com duas realidades paralelas:

  1. A realidade formal: sistemas de RH, hierarquia, comunicados oficiais.
  2. A realidade vivida: canais do Slack, mensagens diretas em grupo, menções no GitHub, rodízio de plantões.

Quando algo muda no sistema formal (como o desligamento de funcionários), isso produz imediatamente artefatos visíveis no sistema em uso. Os funcionários interpretam esses artefatos como verdade — às vezes com mais convicção do que confiam nas comunicações da liderança.

Essa discrepância cria um incentivo perverso:

  • Se a liderança não lhe disser o que está acontecendo,
  • Você irá reconstruí-lo a partir de quaisquer vazamentos de telemetria.

Este incidente serve de lembrete de que a "transparência interna" não é apenas uma estratégia de comunicação, mas também uma estratégia de segurança da informação. Se as pessoas sentirem que precisam reconstruir a realidade a partir de vazamentos, elas o farão.

Onde os engenheiros cruzaram a linha

Mesmo que você compreenda os motivos que levariam alguém a criar um roteiro desse tipo, existem pelo menos três limites claros que são ultrapassados:

1) Limitação de finalidade

Se a fonte de dados for "informação confidencial da empresa", espera-se que seja usada para uma função comercial legítima, e não para planejamento de demissões.

A estrutura de privacidade do NIST enfatiza a gestão do risco à privacidade e a utilização de práticas que protejam os indivíduos. Em termos práticos, isso significa "coletar e usar dados para fins específicos e legítimos, evitando usos secundários que criem novos danos".

Um script para identificar colegas demitidos é, quase por definição, um uso secundário: os sinais de desligamento existem para proteger os sistemas e executar os processos de RH, não para gerar uma lista interna de demissões.

2) Amplificação

As pessoas percebem os desaparecimentos no Slack de forma espontânea — isso é vazamento de informações ambientais.

Um script transforma vazamentos de informações ambientais em um conjunto de dados estruturado (nomes, locais, equipes prováveis, horário de término). Isso é amplificação: o potencial de dano aumenta drasticamente quando sinais vagos se tornam uma lista clara.

3) Redistribuição

Compartilhar o resultado "de forma mais ampla" é o passo que torna difícil defendê-lo como mera curiosidade. Isso cria um novo canal de distribuição para informações sensíveis e responsabiliza os autores por eventuais usos indevidos posteriores.

O que as empresas podem fazer: reduzir as perdas, aumentar a confiança e reforçar os controles.

Existe um equívoco de que a solução é "bloquear tudo". Na prática, são necessárias três medidas complementares: governança, controles técnicos e comunicação.

1) Trate os eventos de desligamento como sensíveis e planeje-os com foco na privacidade.

O desligamento de funcionários inevitavelmente altera os sistemas, mas você pode reduzir o desperdício de informações:

  • Minimize as alterações no diretório público até que as comunicações ocorram.
  • Evite remoções em massa de usuários que sejam fáceis de identificar.
  • Considere adiar por algumas horas certas atualizações não críticas para a segurança, para que elas não funcionem como um alerta de demissões em tempo real.

O objetivo não é esconder a realidade para sempre. É evitar transformar um evento doloroso em uma caça ao tesouro.

2) Adicionar controles de acesso baseados em finalidade e registro de atividades

Se APIs internas puderem revelar mudanças no status dos funcionários em larga escala, então:

  • O acesso deve ser limitado às funções que realmente precisam dele.
  • A exportação em grande escala deve exigir justificativa.
  • As consultas devem ser registradas com identificação e intenção.
  • A votação automatizada deve se destacar.

É aqui que a mentalidade de "auditoria e responsabilização" se torna importante: se um script estiver enumerando usuários e emitindo alertas, ele deve acionar a detecção.

3) Tenha um plano de comunicação humanizado para demissões.

O principal fator que impulsiona o rastreamento de sombras é a incerteza.

As empresas podem reduzir o impulso de descartar ferramentas internas sendo explícitas:

  • Quando os funcionários afetados serão informados?
  • Quando as equipes serão informadas?
  • O que pode ser compartilhado e quando?
  • Onde as pessoas devem procurar atualizações verificadas?

Se a liderança fornecer informações específicas e oportunas, a "necessidade" de listas do tipo "faça você mesmo" diminui.

4) Ofereça aos funcionários uma maneira autorizada de verificar o trabalho dos colaboradores.

Isso é sutil, mas importante. As pessoas não estão apenas curiosas — elas estão tentando coordenar o trabalho e verificar como estão os amigos.

Uma mensagem de status de diretório simples e oficial ("esta conta não está mais ativa"), sem registros de data e hora, localização ou listas, poderia satisfazer as necessidades básicas sem permitir a reconstrução em massa.

Uma tendência mais ampla: demissões como teste de estresse em segurança da informação

As demissões revelam pontos fracos na governança porque criam:

  • uma série de eventos delicados,
  • uma alta temperatura emocional,
  • e muita rotatividade de acessos.

É exatamente aí que você vê casos extremos: funcionários extraindo dados dos sistemas, gerentes improvisando e ferramentas sendo usadas de maneiras para as quais ninguém as projetou.

Sites como o Layoffs.fyi existem porque as pessoas querem um sinal independente sobre a dimensão dos cortes no setor. Dentro de uma empresa, essa mesma necessidade existe — só que os sinais são mais diretos e as consequências são pessoais.

Resumindo

A demissão de engenheiros pelo Pinterest por criarem scripts para rastrear demissões não é apenas um "não seja intrometido". É um alerta de que a observabilidade interna pode se transformar em vigilância interna no momento em que a confiança organizacional diminui.

Se suas ferramentas facilitam a transformação da rotatividade de funcionários em uma lista de colegas demitidos, as pessoas farão isso — especialmente durante processos de demissão em massa. A solução não é apenas punir quem criou o script; é construir sistemas e práticas de comunicação que não transformem o desligamento de funcionários em um vazamento de dados e que tratem o status de emprego como a informação sensível que ele é.

Fontes

Document Title
Pinterest fired engineers who tracked layoffs in Slack — what it says about privacy, trust, and internal telemetry
Pinterest fired engineers after scripts tracked layoffs via internal tools; why employment-status data is sensitive and how to prevent internal surveillance.
Title Attribute
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin
How Apple’s Lockdown Mode can derail iPhone forensics — and why that’s the point
Senators grill Waymo and Tesla on robotaxi safety — what’s actually at stake
Page Content
Pinterest fired engineers who tracked layoffs in Slack — what it says about privacy, trust, and internal telemetry
Nature
Climate
/
General
/ By
Admin
Pinterest reportedly fired two engineers after they wrote scripts to identify which coworkers were being removed from internal tools during a layoff — and then shared that list more broadly. On the surface, this is a workplace drama story. Underneath, it’s an unusually clear case study in how modern companies actually run: identity systems as the source of truth, chat platforms as de facto org charts, and “internal data” that is technically accessible long before it is socially acceptable.
The incident matters beyond Pinterest because the same ingredients exist in almost every tech company: centralized identity, Slack or Teams, HR systems, and a long tail of internal dashboards and APIs. When times are calm, nobody thinks too hard about the line between observability and surveillance. When layoffs happen, that line lights up.
In this explainer, we’ll look at what likely happened, why it’s tempting to do this kind of tracking, where it crosses ethical and policy boundaries, and what organizations can do to reduce both privacy harm and the urge for shadow information-gathering.
What happened (and what “a script” probably means here)
According to the BBC, Pinterest said “two engineers wrote custom scripts improperly accessing confidential company information to identify the locations and names of all dismissed employees and then shared it more broadly,” calling it a policy violation and a privacy issue for affected staff. The reporting also describes the mechanism as watching for employee names being removed or deactivated inside an internal communication tool “like Slack.”
In many companies, Slack (or similar) is tied directly to the identity provider (Okta, Azure AD, Google Workspace, etc.). When an account is disabled, a cascade follows: access tokens expire, groups change, and the user stops appearing in certain directory searches, channels, and integrations. If you have API access (even read-only), you can often infer who was terminated simply by detecting state changes:
A user disappears from the “active users” list.
A user’s profile becomes deactivated.
A bot can no longer DM them.
Their membership changes across channels or user groups.
A “script” in this context doesn’t have to be sophisticated. It could be a few dozen lines of code polling an API, comparing yesterday’s user list to today’s, and emitting an alert. From a purely technical perspective, it’s the same pattern engineers use for legitimate operational tasks: diffing two snapshots to detect change.
The difference is what is being detected (people), why it’s being detected (layoffs), and where the results go (shared broadly).
Why employees do this during layoffs
There’s an uncomfortable truth about layoffs: people usually learn the shape of the event through side channels before leadership clarifies anything. Sometimes that’s because leadership can’t share details yet. Sometimes it’s because “we’re still working through the details” is a euphemism for “we don’t want to say.”
So employees reach for whatever signals exist:
Friends suddenly go silent.
Calendar invites vanish.
Access to repos is revoked.
Slack status flips, or the person disappears from the directory.
Tracking those signals can feel like self-defense. People want to know:
Is my team impacted?
Did my manager get cut?
Are my closest collaborators still here?
Is the company okay, or is this a larger restructuring?
That motivation is human and predictable. But predictable behavior can still be harmful behavior.
The privacy problem: layoff status is sensitive information
A termination event is not just “work trivia.” It’s sensitive personal information about someone’s employment status, often tied to benefits, immigration, health insurance, and future job prospects.
Even if a company plans to announce a headcount reduction publicly, the identity of the individuals and their locations is typically meant to be disclosed on a need-to-know basis:
HR and payroll need details.
IT needs to execute offboarding.
Legal needs to ensure compliance.
Managers need to communicate directly with their teams.
Broad internal sharing of a list of terminated employees is different. It can:
Remove the affected person’s ability to control the narrative.
Expose someone’s location or team affiliation.
Encourage gossip and speculation (“was it performance?” “was it political?”).
Increase the risk of targeted harassment or doxxing outside the company.
Pinterest’s framing — that it violated former colleagues’ privacy — is not just PR. It’s a real category of harm.
The security problem: access control isn’t the same as authorization
Many internal systems work on coarse permissions: if you’re an engineer, you might be able to query a directory or use an internal API. That doesn’t mean you’re authorized to use it for every purpose.
This is where a lot of organizations struggle. They build internal tools that are:
Easy to use,
Powerful,
Poorly governed.
And then they rely on policy (“don’t do that”) as the primary guardrail. When the pressure is high, policy-only guardrails fail.
NIST SP 800-53 is one of the standard catalogs organizations use to think about control families like access control and auditing. Even without getting lost in control IDs, the basic idea applies cleanly here: data access should be constrained, monitored, and attributable to legitimate business purposes — especially for sensitive categories of information.
In other words: “you can technically read this” should never be treated as “it’s fine for you to read this.”
The cultural problem: Slack has become the org chart
Most companies now have two parallel realities:
The formal reality: HR systems, reporting lines, official announcements.
The lived reality: Slack channels, group DMs, GitHub mentions, on-call rotations.
When something changes in the formal system (like offboarding), it immediately produces visible artifacts in the lived system. Employees interpret those artifacts as truth — sometimes more strongly than they trust leadership communications.
That mismatch creates a perverse incentive:
If leadership won’t tell you what’s happening,
you will reconstruct it from whatever telemetry leaks.
This incident is a reminder that “internal transparency” is not just a comms strategy — it’s also an information-security strategy. If people feel they must piece together reality from leaks, they will.
Where the engineers crossed the line
Even if you empathize with why someone might build such a script, there are at least three bright lines that get crossed:
1) Purpose limitation
If the data source is “confidential company information,” the expectation is that it’s used for a legitimate business function, not for layoff reconnaissance.
NIST’s Privacy Framework emphasizes managing privacy risk and using practices that protect individuals. A practical translation is “collect and use data for specific, legitimate purposes, and avoid secondary uses that create new harms.”
A script to identify terminated colleagues is almost definitionally a secondary use: the offboarding signals exist to protect systems and execute HR processes, not to generate an internal layoff list.
2) Amplification
People notice disappearances in Slack organically — that’s ambient information leakage.
A script turns ambient leakage into a structured dataset (names, locations, likely teams, time of termination). That is amplification: the harm potential rises sharply when vague signals become a clean list.
3) Redistribution
Sharing the output “more broadly” is the step that makes it hard to defend as mere curiosity. It creates a new distribution channel for sensitive information and makes the authors accountable for downstream misuse.
What companies can do: reduce leakage, increase trust, and tighten controls
There’s a misconception that the solution is “lock everything down.” In practice you need three complementary moves: governance, technical controls, and communication.
1) Treat offboarding events as sensitive and design for privacy
Offboarding inevitably changes systems, but you can reduce the informational exhaust:
Minimize public-facing directory changes until communications occur.
Avoid mass user removals that are easy to diff.
Consider delaying certain non-security-critical updates by hours so they don’t act as a real-time layoff feed.
The goal isn’t to hide reality forever. It’s to avoid turning a painful event into a scavenger hunt.
2) Add purpose-based access controls and logging
If internal APIs can reveal employee status changes at scale, then:
Access should be scoped to roles that need it.
Bulk export should require justification.
Queries should be logged with identity and intent.
Automated polling should stand out.
This is where the “audit and accountability” mindset matters: if a script is enumerating users and emitting alerts, it should trigger detection.
3) Have a humane comms plan for layoffs
The biggest driver of shadow tracking is uncertainty.
Companies can reduce the impulse to scrape internal tools by being explicit:
When will impacted employees be told?
When will teams be informed?
What can be shared, and when?
Where should people go for verified updates?
If leadership provides timely, specific information, the “need” for DIY lists drops.
4) Give employees a sanctioned way to check on collaborators
This is subtle but important. People are not only curious — they’re trying to coordinate work and check on friends.
A simple, sanctioned directory status message (“this account is no longer active”) without timestamps, location, or lists could satisfy basic needs without enabling mass reconstruction.
A wider trend: layoffs as an information-security stress test
Layoffs reveal weak points in governance because they create:
a burst of sensitive events,
a high emotional temperature,
and a lot of access churn.
That’s exactly when you see edge cases: employees scraping systems, managers improvising, and tools being used in ways nobody designed for.
Sites like Layoffs.fyi exist because people want an independent signal about the scale of cuts in the industry. Inside a company, that same need exists — except the signals are more direct and the stakes are personal.
Bottom line
Pinterest firing engineers for scripting layoff tracking isn’t just “don’t be nosy.” It’s a warning that internal observability can become internal surveillance the moment organizational trust drops.
If your tooling makes it easy to turn identity churn into a list of terminated coworkers, people will do it — especially during layoffs. The fix isn’t only punishing the people who wrote the script; it’s building systems and communication practices that don’t turn offboarding into a data leak, and that treat employment status as the sensitive information it is.
Sources
https://www.bbc.com/news/articles/cn0k670n0ydo
https://layoffs.fyi/
https://www.nist.gov/privacy-framework
https://csrc.nist.gov/pubs/sp/800/53/r5/final
←
Previous Post
Next Post
→
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin
How Apple’s Lockdown Mode can derail iPhone forensics — and why that’s the point
Senators grill Waymo and Tesla on robotaxi safety — what’s actually at stake
Pinterest fired engineers after scripts tracked layoffs via internal tools; why employment-status data is sensitive and how to prevent internal surveillance.
Document Title
Page not found - Florin.blog
Image Alt
Florin.blog
Title Attribute
Florin.blog » Feed
RSD
Skip to content
Placeholder Attribute
Search...
Page Content
Page not found - Florin.blog
Skip to content
Home
Blog
Garden Decor
Indoor
Main Menu
This page doesn't seem to exist.
It looks like the link pointing here was faulty. Maybe try searching?
Search for:
Search
Quick Links
Outdoors
About
Contact
Explore
Bestsellers
Hot deals
Best of The Year
Featured
Gift Cards
Help
Privacy Policy
Disclaimer
: As an Amazon Associate, we earn from qualifying purchases — at no extra cost to you.
Florin.blog
Florin.blog » Feed
RSD
Search...
o Português