Pinterest avskedade ingenjörer som spårade uppsägningar i Slack – vad det säger om integritet, förtroende och intern telemetri

/Allmän/ Av

Pinterest ska ha avskedat två ingenjörer efter att de skrivit manus för att identifiera vilka medarbetare som togs bort från interna verktyg under en uppsägning – och sedan delat den listan mer allmänt. Vid första anblicken är detta ett arbetsplatsdrama. Under ytan är det en ovanligt tydlig fallstudie av hur moderna företag faktiskt fungerar: identitetssystem som källa till sanning, chattplattformar som de facto organisationsscheman och "intern data" som är tekniskt tillgänglig långt innan den är socialt acceptabel.

Händelsen är betydelsefull även utanför Pinterest eftersom samma ingredienser finns i nästan alla teknikföretag: centraliserad identitet, Slack eller Teams, HR-system och en lång rad interna dashboards och API:er. När tiderna är lugna tänker ingen särskilt mycket på gränsen mellan observerbarhet och övervakning. När uppsägningar sker lyser den gränsen upp.

I den här förklaringen ska vi titta på vad som sannolikt hände, varför det är frestande att göra den här typen av spårning, var det överskrider etiska och policymässiga gränser, och vad organisationer kan göra för att minska både skador på integriteten och behovet av skugginformationsinsamling.

Vad som hände (och vad "ett manus" förmodligen betyder här)

Enligt BBC sa Pinterest att "två ingenjörer skrev anpassade skript som felaktigt åtkom från konfidentiell företagsinformation för att identifiera platser och namn på alla uppsagda anställda och sedan delade det mer brett", och kallade det ett policybrott och ett integritetsproblem för berörd personal. Rapporten beskriver också mekanismen som att övervaka om anställdas namn tas bort eller inaktiveras i ett internt kommunikationsverktyg "som Slack".

I många företag är Slack (eller liknande) direkt kopplat till identitetsleverantören (Okta, Azure AD, Google Workspace, etc.). När ett konto inaktiveras följer en kaskad: åtkomsttokens löper ut, grupper ändras och användaren slutar visas i vissa katalogsökningar, kanaler och integrationer. Om du har API-åtkomst (även skrivskyddad) kan du ofta dra slutsatsen vem som avslutades helt enkelt genom att upptäcka tillståndsändringar:

  • En användare försvinner från listan över "aktiva användare".
  • En användares profil inaktiveras.
  • En bot kan inte längre skicka ett direktmeddelande till dem.
  • Deras medlemskap ändras mellan kanaler eller användargrupper.

Ett ”skript” i det här sammanhanget behöver inte vara sofistikerat. Det kan vara några dussin rader kod som pollar ett API, jämför gårdagens användarlista med dagens och skickar ut en varning. Ur ett rent tekniskt perspektiv är det samma mönster som ingenjörer använder för legitima operativa uppgifter: att differentiera två ögonblicksbilder för att upptäcka förändringar.

Skillnaden är vad som upptäcks (personer), varför det upptäcks (uppsägningar) och vart resultaten tar vägen (delas brett).

Varför anställda gör detta under uppsägningar

Det finns en obekväm sanning om uppsägningar: folk får vanligtvis veta hur händelsen har gått till genom sidokanaler innan ledningen klargör något. Ibland beror det på att ledningen inte kan dela detaljer ännu. Ibland beror det på att "vi arbetar fortfarande igenom detaljerna" är en eufemism för "vi vill inte säga något".

Så anställda griper efter vilka signaler som helst:

  • Vännerna blir plötsligt tysta.
  • Kalenderinbjudningar försvinner.
  • Åtkomst till repo-enheter är återkallad.
  • Slack-status ändras, eller så försvinner personen från katalogen.

Att spåra dessa signaler kan kännas som självförsvar. Folk vill veta:

  • Påverkas mitt lag?
  • Blev min chef uppsagd?
  • Är mina närmaste medarbetare fortfarande här?
  • Är företaget okej, eller är det här en större omstrukturering?

Den motivationen är mänsklig och förutsägbar. Men förutsägbart beteende kan fortfarande vara skadligt.

Integritetsproblemet: uppsägningsstatus är känslig information

En uppsägning är inte bara en "arbetsfråga". Det är känslig personlig information om någons anställningsstatus, ofta kopplad till förmåner, immigration, sjukförsäkring och framtida jobbmöjligheter.

Även om ett företag planerar att offentliggöra en personalminskning, är det vanligtvis meningen att individernas identitet och var de befinner sig ska offentliggöras i mån av tillgång:

  • Behöver detaljer om HR och lön.
  • IT behöver genomföra offboarding.
  • Rättsliga behov för att säkerställa efterlevnad.
  • Chefer behöver kommunicera direkt med sina team.

Bred intern delning av en lista över uppsagda anställda är annorlunda. Det kan:

  • Ta bort den drabbade personens förmåga att kontrollera berättelsen.
  • Avslöja någons plats eller lagtillhörighet.
  • Uppmuntra skvaller och spekulationer (”var det ett framträdande?”, ”var det politiskt?”).
  • Öka risken för riktade trakasserier eller doxing utanför företaget.

Pinterests framing – att det kränkte tidigare kollegors integritet – är inte bara PR. Det är en verklig kategori av skada.

Säkerhetsproblemet: åtkomstkontroll är inte samma sak som auktorisering

Många interna system arbetar med grova behörigheter: om du är ingenjör kan du kanske fråga en katalog eller använda ett internt API. Det betyder inte att du har behörighet att använda det för alla ändamål.

Det är här många organisationer kämpar. De bygger interna verktyg som är:

  • Lätt att använda,
  • Kraftfull,
  • Dåligt styrt.

Och sedan förlitar de sig på policyn ("gör inte så") som det primära skyddsräcket. När trycket är högt fallerar skyddsräcken som enbart är baserade på policyn.

NIST SP 800-53 är en av standardkatalogerna som organisationer använder för att tänka på kontrollfamiljer som åtkomstkontroll och revision. Även utan att fördjupa sig i kontroll-ID:n gäller grundidén tydligt här: dataåtkomst bör begränsas, övervakas och hänföras till legitima affärsändamål – särskilt för känsliga informationskategorier.

Med andra ord: ”tekniskt sett kan du läsa det här” ska aldrig tolkas som ”det är okej för dig att läsa det här”.

Det kulturella problemet: Slack har blivit organisationsschemat

De flesta företag har nu två parallella verkligheter:

  1. Den formella verkligheten: HR-system, rapporteringsvägar, officiella tillkännagivanden.
  2. Den levda verkligheten: Slack-kanaler, grupp-DM, GitHub-omnämnanden, jourrotationer.

När något förändras i det formella systemet (som offboarding) skapar det omedelbart synliga artefakter i det levda systemet. Medarbetarna tolkar dessa artefakter som sanning – ibland starkare än de litar på ledningens kommunikation.

Den obalansen skapar ett perverst incitament:

  • Om ledningen inte berättar vad som händer,
  • du kommer att rekonstruera det från eventuella telemetriläckor.

Denna händelse är en påminnelse om att ”intern transparens” inte bara är en kommunikationsstrategi – det är också en informationssäkerhetsstrategi. Om folk känner att de måste pussla ihop verkligheten från läckor, så kommer de att göra det.

Där ingenjörerna gick över gränsen

Även om du förstår varför någon kan bygga ett sådant manus, finns det minst tre tydliga gränser som överskrids:

1) Ändamålsbegränsning

Om datakällan är "konfidentiell företagsinformation" är förväntan att den används för en legitim affärsfunktion, inte för rekognoscering av uppsägningar.

NIST:s ramverk för integritetsskydd betonar hantering av integritetsrisker och användning av metoder som skyddar individer. En praktisk översättning är "samla in och använda data för specifika, legitima ändamål och undvika sekundära användningsområden som skapar nya skador".

Ett skript för att identifiera uppsagda kollegor är nästan definitionsmässigt en sekundär användning: offboarding-signalerna finns för att skydda system och genomföra HR-processer, inte för att generera en intern uppsägningslista.

2) Förstärkning

Folk märker försvinnanden i Slack organiskt – det är läckage av omgivande information.

Ett skript omvandlar omgivande läckage till en strukturerad datamängd (namn, platser, troliga team, tidpunkt för uppsägning). Det är förstärkning: skadepotentialen ökar kraftigt när vaga signaler blir en ren lista.

3) Omfördelning

Att dela resultatet "mer brett" är det steg som gör det svårt att försvara det som ren kuriositet. Det skapar en ny distributionskanal för känslig information och gör författarna ansvariga för missbruk nedströms.

Vad företag kan göra: minska läckage, öka förtroendet och skärpa kontrollerna

Det finns en missuppfattning att lösningen är att ”låsa ner allt”. I praktiken behövs tre kompletterande åtgärder: styrning, tekniska kontroller och kommunikation.

1) Behandla offboarding-evenemang som känsliga och utforma med hänsyn till integritet

Offboarding förändrar oundvikligen system, men du kan minska informationsutsläppet:

  • Minimera ändringar i den offentliga katalogen tills kommunikation sker.
  • Undvik massborttagning av användare som är lätta att ändra.
  • Överväg att fördröja vissa icke-säkerhetskritiska uppdateringar med timmar så att de inte fungerar som ett realtidsflöde för uppsägningar.

Målet är inte att dölja verkligheten för alltid. Det är att undvika att förvandla en smärtsam händelse till en skattjakt.

2) Lägg till ändamålsbaserade åtkomstkontroller och loggning

Om interna API:er kan avslöja förändringar i anställdas status i stor skala, då:

  • Åtkomst bör begränsas till roller som behöver det.
  • Bulkexport bör kräva motivering.
  • Frågor bör loggas med identitet och avsikt.
  • Automatiserade opinionsundersökningar bör sticka ut.

Det är här som "revisions- och ansvarsskyldighets"-tankesättet spelar roll: om ett skript räknar upp användare och skickar ut varningar, bör det utlösa detektering.

3) Ha en human kommunikationsplan för uppsägningar

Den största drivkraften bakom skuggspårning är osäkerhet.

Företag kan minska impulsen att skrapa interna verktyg genom att vara tydliga:

  • När kommer berörda anställda att informeras?
  • När kommer lagen att informeras?
  • Vad kan delas, och när?
  • Vart ska folk gå för att få verifierade uppdateringar?

Om ledningen tillhandahåller aktuell, specifik information minskar "behovet" av gör-det-själv-listor.

4) Ge anställda ett sanktionerat sätt att kontrollera samarbetspartners

Detta är subtilt men viktigt. Människor är inte bara nyfikna – de försöker koordinera arbete och kolla läget med vänner.

Ett enkelt, sanktionerat statusmeddelande för katalogen ("detta konto är inte längre aktivt") utan tidsstämplar, plats eller listor skulle kunna tillgodose grundläggande behov utan att möjliggöra massrekonstruktion.

En bredare trend: uppsägningar som ett stresstest för informationssäkerhet

Uppsägningar avslöjar svagheter i styrningen eftersom de skapar:

  • en explosion av känsliga händelser,
  • en hög känslomässig temperatur,
  • och mycket åtkomstbortfall.

Det är precis då man ser edgefall: anställda som skrapar ihop system, chefer som improviserar och verktyg som används på sätt som ingen annan utformat för.

Sajter som Layoffs.fyi finns för att folk vill ha en oberoende signal om omfattningen av nedskärningarna i branschen. Inom ett företag finns samma behov – förutom att signalerna är mer direkta och insatserna är personliga.

Slutsats

Att Pinterest sparkar ingenjörer för att de spårar uppsägningar på grund av skript är inte bara "var inte nyfiken". Det är en varning om att intern observerbarhet kan bli intern övervakning i det ögonblick som organisationens förtroende minskar.

Om era verktyg gör det enkelt att förvandla identitetsbortfall till en lista över uppsagda kollegor, kommer folk att göra det – särskilt under uppsägningar. Lösningen är inte bara att straffa de personer som skrev manuset; det handlar om att bygga system och kommunikationsmetoder som inte förvandlar offboarding till en dataläcka, och som behandlar anställningsstatus som den känsliga information den är.

Källor

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...
v Svenska