Pinterest vyhodil inženýry, kteří sledovali propouštění ve Slacku – co to říká o soukromí, důvěře a interní telemetrii

/Generál/ Od

Pinterest údajně propustil dva inženýry poté, co napsali skripty, které měly identifikovat kolegy, kteří byli během propouštění odstraňováni z interních nástrojů – a poté tento seznam sdíleli širší veřejnost. Na první pohled se jedná o dramatický příběh na pracovišti. Pod povrchem je však neobvykle jasná případová studie toho, jak moderní firmy skutečně fungují: systémy identity jako zdroj pravdy, chatovací platformy jako de facto organizační schémata a „interní data“, která jsou technicky dostupná dlouho předtím, než jsou společensky přijatelná.

Incident má význam i mimo Pinterest, protože stejné ingredience existují téměř v každé technologické firmě: centralizovaná identita, Slack nebo Teams, HR systémy a dlouhá řada interních dashboardů a API. V klidných časech nikdo příliš nepřemýšlí o hranici mezi pozorovatelností a dohledem. Když dochází k propouštění, tato hranice se rozsvítí.

V tomto vysvětlení se podíváme na to, co se pravděpodobně stalo, proč je lákavé provádět tento druh sledování, kde překračuje etické a politické hranice a co mohou organizace udělat pro to, aby omezily jak narušení soukromí, tak i touhu po stínovém shromažďování informací.

Co se stalo (a co zde pravděpodobně znamená „skript“)

Podle BBC Pinterest uvedl, že „dva inženýři napsali vlastní skripty, které neoprávněně přistupovaly k důvěrným firemním informacím, aby identifikovali umístění a jména všech propuštěných zaměstnanců, a poté je sdíleli širší veřejnost“, což označilo za porušení zásad a problém s ochranou soukromí dotčených zaměstnanců. Zpráva také popisuje mechanismus jako sledování odstraňování nebo deaktivace jmen zaměstnanců v rámci interního komunikačního nástroje „jako je Slack“.

V mnoha firmách je Slack (nebo podobný) přímo propojen s poskytovatelem identity (Okta, Azure AD, Google Workspace atd.). Po deaktivaci účtu následuje kaskáda: platnost přístupových tokenů vyprší, skupiny se změní a uživatel se přestane zobrazovat v určitých vyhledáváních v adresářích, kanálech a integracích. Pokud máte přístup k API (i jen pro čtení), můžete často odvodit, kdo byl ukončen, pouhým zjištěním změn stavu:

  • Uživatel zmizí ze seznamu „aktivních uživatelů“.
  • Profil uživatele se deaktivuje.
  • Bot jim už nemůže posílat soukromou zprávu.
  • Jejich členství se mění napříč kanály nebo uživatelskými skupinami.

„Skript“ v tomto kontextu nemusí být sofistikovaný. Může se jednat o několik desítek řádků kódu, které dotazují API, porovnávají včerejší seznam uživatelů s dnešním a vydávají upozornění. Z čistě technického hlediska se jedná o stejný vzorec, jaký inženýři používají pro legitimní provozní úkoly: porovnávání dvou snímků za účelem detekce změn.

Rozdíl spočívá v tom, co je detekováno (lidé), proč je to detekováno (propouštění) a kam se výsledky dostanou (sdílejí se široce).

Proč to zaměstnanci dělají během propouštění

O propouštění existuje nepříjemná pravda: lidé se obvykle o průběhu události dozvídají z postranních kanálů, než vedení cokoli objasní. Někdy je to proto, že vedení zatím nemůže sdílet podrobnosti. Jindy je to proto, že „na detailech stále pracujeme“, což je eufemismus pro „nechceme to říct“.

Zaměstnanci se tedy snaží využít jakékoli existující signály:

  • Přátelé najednou ztichnou.
  • Pozvánky z kalendáře mizí.
  • Přístup k repozitářům je odebrán.
  • Status na Slacku se změní, nebo daná osoba zmizí z adresáře.

Sledování těchto signálů se může jevit jako sebeobrana. Lidé chtějí vědět:

  • Je můj tým ovlivněn?
  • Dostal můj manažer výpověď?
  • Jsou tu stále moji nejbližší spolupracovníci?
  • Je firma v pořádku, nebo se jedná o větší restrukturalizaci?

Tato motivace je lidská a předvídatelná. Předvídatelné chování však může být stále škodlivé.

Problém soukromí: stav propuštění je citlivá informace

Událost, která je součástí ukončení pracovního poměru, není jen „pracovní záležitost“. Jde o citlivé osobní informace o pracovním statusu dané osoby, často spojené s benefity, imigrací, zdravotním pojištěním a budoucími pracovními vyhlídkami.

I když společnost plánuje veřejně oznámit snížení počtu zaměstnanců, totožnost jednotlivců a jejich umístění se obvykle zveřejňují na základě nezbytné potřeby:

  • Potřebné podrobnosti o personálním oddělení a mzdách.
  • IT oddělení potřebuje provést offboarding.
  • Právní potřeby k zajištění souladu.
  • Manažeři musí komunikovat přímo se svými týmy.

Široké interní sdílení seznamu propuštěných zaměstnanců je jiné. Může:

  • Odeberte postižené osobě schopnost ovládat vyprávění.
  • Odhalte něčí polohu nebo příslušnost k týmu.
  • Podporujte drby a spekulace („bylo to představení?“, „bylo to politické?“).
  • Zvyšovat riziko cíleného obtěžování nebo doxingu mimo společnost.

Pinterestovo tvrzení, že narušil soukromí bývalých kolegů, není jen PR. Je to skutečná kategorie újmy.

Bezpečnostní problém: řízení přístupu není totéž co autorizace

Mnoho interních systémů pracuje s hrubými oprávněními: pokud jste inženýr, můžete dotazovat adresář nebo používat interní API. To neznamená, že jste oprávněni ho používat pro každý účel.

Právě s tím se mnoho organizací potýká. Budují si interní nástroje, které jsou:

  • Snadné použití,
  • Silný,
  • Špatně řízeno.

A pak se spoléhají na politiku („nedělejte to“) jako na primární zábranu. Když je tlak vysoký, zábrany založené pouze na politice selhávají.

NIST SP 800-53 je jeden ze standardních katalogů, které organizace používají k úvahám o skupinách kontrol, jako je řízení přístupu a audit. I bez ztrácení se v ID kontrol zde platí základní myšlenka: přístup k datům by měl být omezen, monitorován a přiřaditelný legitimním obchodním účelům – zejména u citlivých kategorií informací.

Jinými slovy: „technicky vzato si to přečtete“ by se nikdy nemělo chápat jako „je v pořádku, abyste si to přečetli“.

Kulturní problém: Slack se stal organizační strukturou

Většina firem má nyní dvě paralelní reality:

  1. Formální realita: systémy lidských zdrojů, hierarchie, oficiální oznámení.
  2. Realita, kterou člověk prožívá: Slack kanály, skupinové DM, zmínky na GitHubu, střídání pohotovostí.

Když se něco změní ve formálním systému (například odchod z práce), okamžitě to vytvoří viditelné artefakty v živém systému. Zaměstnanci interpretují tyto artefakty jako pravdu – někdy silněji, než důvěřují komunikaci vedení.

Tento nesoulad vytváří zvrácenou motivaci:

  • Pokud vám vedení neřekne, co se děje,
  • Zrekonstruujete ho z jakýchkoli úniků telemetrie.

Tato událost nám připomíná, že „interní transparentnost“ není jen komunikační strategií – je to také strategie informační bezpečnosti. Pokud si lidé myslí, že musí z úniků dat poskládat realitu, udělají to.

Kde inženýři překročili hranici

I když chápete, proč by někdo mohl takový skript vytvořit, existují alespoň tři jasné hranice, které se překračují:

1) Omezení účelu

Pokud je zdrojem dat „důvěrná firemní informace“, očekává se, že bude použita pro legitimní obchodní funkci, nikoli pro průzkum propouštění.

Rámec ochrany osobních údajů NIST klade důraz na řízení rizik pro soukromí a používání postupů, které chrání jednotlivce. Praktický překlad zní „shromažďovat a používat data pro konkrétní, legitimní účely a vyhýbat se sekundárnímu použití, které vytváří nová škodlivá opatření“.

Skript pro identifikaci propuštěných kolegů je téměř definitivně druhořadým využitím: signály pro odchod existují k ochraně systémů a provádění HR procesů, nikoli k generování interního seznamu propouštěných.

2) Zesílení

Lidé si v Slacku všímají mizení přirozeně – to je únik informací z okolí.

Skript přemění únik informací z okolí na strukturovanou datovou sadu (jména, umístění, pravděpodobné týmy, čas ukončení). To je zesílení: potenciál poškození prudce roste, když se z vágních signálů stane čistý seznam.

3) Redistribuce

Sdílení výstupu „širším způsobem“ je krok, který ztěžuje jeho obhajobu jako pouhou zvědavost. Vytváří nový distribuční kanál pro citlivé informace a činí autory odpovědnými za následné zneužití.

Co mohou firmy udělat: omezit úniky, zvýšit důvěru a zpřísnit kontroly

Existuje mylná představa, že řešením je „uzamknout všechno“. V praxi potřebujete tři doplňkové kroky: správu a řízení, technické kontroly a komunikaci.

1) Zacházejte s událostmi offboardingu jako s citlivými a navrhujte je s ohledem na soukromí

Offboarding nevyhnutelně mění systémy, ale můžete snížit informační vyčerpání:

  • Minimalizujte změny veřejně přístupných adresářů, dokud nedojde ke komunikaci.
  • Vyhněte se hromadnému odstraňování uživatelů, u kterých se dá snadno zjistit rozdíl.
  • Zvažte odložení některých aktualizací, které nejsou kritické z hlediska zabezpečení, o několik hodin, aby nefungovaly jako informační kanál o propouštění v reálném čase.

Cílem není navždy skrývat realitu. Jde o to, aby se z bolestivé události nestal hon na poklad.

2) Přidejte řízení přístupu a protokolování na základě účelu

Pokud interní API dokáží odhalit změny stavu zaměstnanců ve velkém měřítku, pak:

  • Přístup by měl být omezen na role, které ho potřebují.
  • Hromadný vývoz by měl vyžadovat odůvodnění.
  • Dotazy by měly být zaznamenávány s identitou a záměrem.
  • Automatizované hlasování by mělo vyniknout.

Zde je důležitý přístup „auditu a odpovědnosti“: pokud skript vyjmenovává uživatele a vysílá upozornění, měl by spustit detekci.

3) Mějte humánní komunikační plán pro případ propouštění

Největším hnací silou sledování stínů je nejistota.

Firmy mohou omezit nutkání k vybírání interních nástrojů tím, že budou explicitní:

  • Kdy budou dotčení zaměstnanci informováni?
  • Kdy budou týmy informovány?
  • Co a kdy lze sdílet?
  • Kam by se měli lidé obracet pro ověřené aktualizace?

Pokud vedení poskytuje včasné a konkrétní informace, „potřeba“ seznamů „udělej si sám“ klesá.

4) Poskytněte zaměstnancům schválený způsob, jak kontrolovat spolupracovníky

To je nenápadné, ale důležité. Lidé nejsou jen zvědaví – snaží se koordinovat práci a zjišťovat, jak jsou na tom jejich přátelé.

Jednoduchá, schválená zpráva o stavu adresáře („tento účet již není aktivní“) bez časových razítek, polohy nebo seznamů by mohla uspokojit základní potřeby, aniž by umožňovala hromadnou rekonstrukci.

Širší trend: propouštění jako zátěžový test informační bezpečnosti

Propouštění odhaluje slabá místa v řízení, protože vytváří:

  • záplava citlivých událostí,
  • vysoká emoční teplota,
  • a velký počet odchodů uživatelů.

Přesně tehdy se setkáte s okrajovými případy: zaměstnanci scrapingují systémy, manažeři improvizují a nástroje se používají způsoby, pro které nikdo nebyl navržen.

Stránky jako Layoffs.fyi existují, protože lidé chtějí nezávislý signál o rozsahu propouštění v tomto odvětví. Uvnitř firmy existuje stejná potřeba – až na to, že signály jsou přímější a v sázce je osobní záležitost.

Sečteno a podtrženo

Propouštění inženýrů z Pinterestu za skriptování sledování propouštění není jen „nebuďte zvědaví“. Je to varování, že interní pozorovatelnost se může stát interním dohledem v okamžiku, kdy klesne důvěra v organizaci.

Pokud vaše nástroje umožňují snadno proměnit odliv identit v seznam propuštěných spolupracovníků, lidé to udělají – zejména během propouštění. Řešením není jen potrestání lidí, kteří scénář napsali; je to budování systémů a komunikačních postupů, které nepromění odchod z práce v únik dat a které budou s pracovním statusem zacházet jako s citlivou informací, kterou je.

Zdroje

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...
Čeština