Pinterest sparket ingeniører som sporet oppsigelser i Slack – hva det sier om personvern, tillit og intern telemetri

/General/ Av

Pinterest skal ha sparket to ingeniører etter at de skrev manus for å identifisere hvilke kolleger som ble fjernet fra interne verktøy under en permittering – og deretter delte den listen bredere. På overflaten er dette et drama på arbeidsplassen. Underliggende er det en uvanlig tydelig casestudie av hvordan moderne selskaper faktisk opererer: identitetssystemer som kilde til sannhet, chatplattformer som de facto organisasjonskart og «interne data» som er teknisk tilgjengelige lenge før de er sosialt akseptable.

Hendelsen er viktig utover Pinterest fordi de samme ingrediensene finnes i nesten alle teknologiselskaper: sentralisert identitet, Slack eller Teams, HR-systemer og en lang rekke interne dashbord og API-er. Når tidene er rolige, tenker ingen for mye på grensen mellom observerbarhet og overvåking. Når oppsigelser skjer, lyser den grensen opp.

I denne forklaringen skal vi se på hva som sannsynligvis skjedde, hvorfor det er fristende å gjøre denne typen sporing, hvor det krysser etiske og politiske grenser, og hva organisasjoner kan gjøre for å redusere både personvernskade og trangen til å samle inn skyggeinformasjon.

Hva som skjedde (og hva «et manus» sannsynligvis betyr her)

Ifølge BBC sa Pinterest at «to ingeniører skrev tilpassede skript som feilaktig fikk tilgang til konfidensiell bedriftsinformasjon for å identifisere plasseringen og navnene til alle oppsagte ansatte, og deretter delte det mer bredt», og kalte det et brudd på retningslinjene og et personvernproblem for berørte ansatte. Rapporten beskriver også mekanismen som å overvåke om ansattnavn blir fjernet eller deaktivert i et internt kommunikasjonsverktøy «som Slack».

I mange selskaper er Slack (eller lignende) knyttet direkte til identitetsleverandøren (Okta, Azure AD, Google Workspace osv.). Når en konto deaktiveres, følger en kaskade: tilgangstokener utløper, grupper endres, og brukeren slutter å vises i visse katalogsøk, kanaler og integrasjoner. Hvis du har API-tilgang (selv skrivebeskyttet), kan du ofte utlede hvem som ble sagt opp ganske enkelt ved å oppdage tilstandsendringer:

  • En bruker forsvinner fra listen over «aktive brukere».
  • En brukers profil blir deaktivert.
  • En bot kan ikke lenger sende dem direkte.
  • Medlemskapet deres endres på tvers av kanaler eller brukergrupper.

Et «skript» i denne sammenhengen trenger ikke å være sofistikert. Det kan være noen dusin kodelinjer som poller et API, sammenligner gårsdagens brukerliste med dagens og sender ut et varsel. Fra et rent teknisk perspektiv er det det samme mønsteret som ingeniører bruker for legitime driftsoppgaver: å skille mellom to øyeblikksbilder for å oppdage endringer.

Forskjellen er hva som oppdages (personer), hvorfor det oppdages (oppsigelser), og hvor resultatene havner (deles bredt).

Hvorfor ansatte gjør dette under permitteringer

Det er en ubehagelig sannhet om oppsigelser: folk får vanligvis vite hvordan hendelsen har utviklet seg gjennom sidekanaler før ledelsen avklarer noe. Noen ganger er det fordi ledelsen ikke kan dele detaljer ennå. Noen ganger er det fordi «vi jobber fortsatt med detaljene» er en eufemisme for «vi vil ikke si noe».

Så ansatte griper etter hvilke signaler som finnes:

  • Venner blir plutselig stille.
  • Kalenderinvitasjoner forsvinner.
  • Tilgang til depoter er tilbakekalt.
  • Slack-statusen endres, eller personen forsvinner fra katalogen.

Å spore disse signalene kan føles som selvforsvar. Folk vil vite:

  • Er teamet mitt påvirket?
  • Ble sjefen min oppsagt?
  • Er mine nærmeste samarbeidspartnere fortsatt her?
  • Går det bra med selskapet, eller er dette en større omstrukturering?

Den motivasjonen er menneskelig og forutsigbar. Men forutsigbar atferd kan fortsatt være skadelig atferd.

Personvernproblemet: Oppsigelsesstatus er sensitiv informasjon

En oppsigelseshendelse er ikke bare «jobbtrivia». Det er sensitiv personlig informasjon om noens ansettelsesstatus, ofte knyttet til ytelser, immigrasjon, helseforsikring og fremtidige jobbmuligheter.

Selv om et selskap planlegger å kunngjøre en reduksjon i antall ansatte offentlig, er det vanligvis ment at identiteten til individene og deres lokasjoner skal offentliggjøres etter behov:

  • Trenger detaljer om HR og lønn.
  • IT må gjennomføre offboarding.
  • Juridiske behov for å sikre samsvar.
  • Ledere må kommunisere direkte med teamene sine.

Bred intern deling av en liste over oppsagte ansatte er annerledes. Det kan:

  • Fjern den berørte personens evne til å kontrollere fortellingen.
  • Avslør noens plassering eller lagtilhørighet.
  • Oppmuntre til sladder og spekulasjoner («var det en forestilling?», «var det politisk?»).
  • Øk risikoen for målrettet trakassering eller doxing utenfor selskapet.

Pinterests framing – at det krenket tidligere kollegers personvern – er ikke bare PR. Det er en reell skadekategori.

Sikkerhetsproblemet: tilgangskontroll er ikke det samme som autorisasjon

Mange interne systemer bruker grove tillatelser: Hvis du er ingeniør, kan du kanskje spørre en katalog eller bruke et internt API. Det betyr ikke at du er autorisert til å bruke det til alle formål.

Det er her mange organisasjoner sliter. De bygger interne verktøy som er:

  • Enkel å bruke,
  • Mektig,
  • Dårlig styrt.

Og så er de avhengige av regelverket («ikke gjør det») som det primære rekkverket. Når presset er høyt, svikter rekkverk som kun er basert på regelverket.

NIST SP 800-53 er en av standardkatalogene organisasjoner bruker for å tenke på kontrollfamilier som tilgangskontroll og revisjon. Selv uten å gå seg vill i kontroll-ID-er, gjelder den grunnleggende ideen tydelig her: datatilgang bør begrenses, overvåkes og tilskrives legitime forretningsformål – spesielt for sensitive informasjonskategorier.

Med andre ord: «teknisk sett kan du lese dette» skal aldri behandles som «det er greit at du leser dette».

Det kulturelle problemet: Slack har blitt organisasjonskartet

De fleste selskaper har nå to parallelle virkeligheter:

  1. Den formelle virkeligheten: HR-systemer, rapporteringslinjer, offisielle kunngjøringer.
  2. Den levde virkeligheten: Slack-kanaler, gruppe-DM-er, GitHub-omtaler, rotasjoner på vakt.

Når noe endres i det formelle systemet (som offboarding), produserer det umiddelbart synlige artefakter i det levende systemet. Ansatte tolker disse artefaktene som sannhet – noen ganger sterkere enn de stoler på ledelsens kommunikasjon.

Den uoverensstemmelsen skaper et perverst insentiv:

  • Hvis ledelsen ikke forteller deg hva som skjer,
  • Du vil rekonstruere den fra eventuelle telemetrilekkasjer.

Denne hendelsen er en påminnelse om at «intern åpenhet» ikke bare er en kommunikasjonsstrategi – det er også en strategi for informasjonssikkerhet. Hvis folk føler at de må sette sammen virkeligheten fra lekkasjer, vil de gjøre det.

Der ingeniørene krysset grensen

Selv om du forstår hvorfor noen lager et slikt manus, er det minst tre klare linjer som blir krysset:

1) Formålsbegrensning

Hvis datakilden er «konfidensiell bedriftsinformasjon», er forventningen at den brukes til en legitim forretningsfunksjon, ikke til rekognosering av oppsigelser.

NISTs personvernrammeverk legger vekt på å håndtere personvernrisiko og bruke praksiser som beskytter enkeltpersoner. En praktisk oversettelse er «samle inn og bruke data til spesifikke, legitime formål, og unngå sekundær bruk som skaper ny skade».

Et skript for å identifisere oppsagte kolleger er nesten definisjonsmessig en sekundær bruk: offboarding-signalene eksisterer for å beskytte systemer og utføre HR-prosesser, ikke for å generere en intern permitteringsliste.

2) Forsterkning

Folk legger merke til forsvinninger i Slack organisk – det er lekkasje av omgivende informasjon.

Et skript gjør om lekkasje fra omgivelsene til et strukturert datasett (navn, steder, sannsynlige team, tidspunkt for avslutning). Det er forsterkning: skadepotensialet øker kraftig når vage signaler blir til en ren liste.

3) Omfordeling

Det er vanskelig å forsvare resultatet som ren kuriositet ved å dele det «mer bredt». Det skaper en ny distribusjonskanal for sensitiv informasjon og gjør forfatterne ansvarlige for misbruk nedover.

Hva bedrifter kan gjøre: redusere lekkasjer, øke tilliten og stramme inn kontrollene

Det er en misforståelse at løsningen er å «låse ned alt». I praksis trenger man tre komplementære grep: styring, tekniske kontroller og kommunikasjon.

1) Behandle offboarding-arrangementer som sensitive og utform med tanke på personvern

Offboarding endrer uunngåelig systemer, men du kan redusere informasjonsmengden:

  • Minimer endringer i offentlig katalog inntil kommunikasjon finner sted.
  • Unngå massefjerning av brukere som er enkle å endre.
  • Vurder å utsette visse ikke-sikkerhetskritiske oppdateringer med flere timer, slik at de ikke fungerer som en sanntidsstrøm for permitteringer.

Målet er ikke å skjule virkeligheten for alltid. Det er å unngå å gjøre en smertefull hendelse om til en skattejakt.

2) Legg til formålsbaserte tilgangskontroller og logging

Hvis interne API-er kan avsløre endringer i ansattes status i stor skala, så:

  • Tilgang bør begrenses til roller som trenger det.
  • Bulkeksport bør kreve begrunnelse.
  • Spørringer bør logges med identitet og hensikt.
  • Automatiserte avstemninger bør skille seg ut.

Det er her «revisjons- og ansvarlighets»-tankegangen er viktig: hvis et skript lister opp brukere og sender ut varsler, bør det utløse deteksjon.

3) Ha en human kommunikasjonsplan for oppsigelser

Den største driveren for skyggesporing er usikkerhet.

Bedrifter kan redusere impulsen til å skrape interne verktøy ved å være eksplisitte:

  • Når vil berørte ansatte bli varslet?
  • Når vil lagene bli informert?
  • Hva kan deles, og når?
  • Hvor bør folk gå for å få bekreftede oppdateringer?

Hvis ledelsen gir rettidig og spesifikk informasjon, synker «behovet» for gjør-det-selv-lister.

4) Gi ansatte en godkjent måte å sjekke samarbeidspartnere på

Dette er subtilt, men viktig. Folk er ikke bare nysgjerrige – de prøver å koordinere arbeid og sjekke hvordan det går med venner.

En enkel, godkjent katalogstatusmelding («denne kontoen er ikke lenger aktiv») uten tidsstempler, plassering eller lister kan dekke grunnleggende behov uten å muliggjøre masserekonstruksjon.

En bredere trend: oppsigelser som en stresstest for informasjonssikkerhet

Oppsigelser avslører svake punkter i styringen fordi de skaper:

  • en rekke sensitive hendelser,
  • en høy emosjonell temperatur,
  • og mye tilgangsfrafall.

Det er akkurat da du ser kanteksempler: ansatte som skraper systemer, ledere som improviserer og verktøy som brukes på måter ingen har designet for.

Nettsteder som Layoffs.fyi eksisterer fordi folk ønsker et uavhengig signal om omfanget av kuttene i bransjen. Innad i et selskap finnes det samme behovet – bortsett fra at signalene er mer direkte og innsatsen er personlig.

Konklusjon

At Pinterest sparker ingeniører for å ha skriptet oppsigelsessporing er ikke bare «ikke vær nysgjerrig». Det er en advarsel om at intern observerbarhet kan bli intern overvåking i det øyeblikket tilliten i organisasjonen faller.

Hvis verktøyene dine gjør det enkelt å gjøre identitetsskifte til en liste over oppsagte kolleger, vil folk gjøre det – spesielt under permitteringer. Løsningen er ikke bare å straffe de som skrev manuset; den handler om å bygge systemer og kommunikasjonspraksiser som ikke gjør offboarding til en datalekkasje, og som behandler ansettelsesstatus som den sensitive informasjonen den er.

Kilder

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 Norsk bokmål