Pinterest vallandas insenerid, kes jälgisid koondamisi Slackis – mida see ütleb privaatsuse, usalduse ja sisemise telemeetria kohta

/Üldine/ Autor

Pinterest vallandas väidetavalt kaks inseneri pärast seda, kui nad kirjutasid skriptid, et tuvastada, millised töökaaslased koondamiste ajal sisemistest tööriistadest eemaldatakse – ja jagasid seda nimekirja seejärel laiemalt. Pealiskaudselt on see töökoha draamalugu. Sisuliselt on see ebatavaliselt selge juhtumiuuring sellest, kuidas tänapäeva ettevõtted tegelikult toimivad: identiteedisüsteemid tõe allikana, vestlusplatvormid de facto organisatsiooniskeemidena ja „siseandmed”, mis on tehniliselt kättesaadavad ammu enne, kui need on sotsiaalselt aktsepteeritud.

See juhtum on oluline ka väljaspool Pinteresti, sest samad koostisosad eksisteerivad peaaegu igas tehnoloogiaettevõttes: tsentraliseeritud identiteet, Slack või Teams, personalijuhtimissüsteemid ning pikk rida sisemisi juhtpaneele ja API-sid. Rahulikes oludes ei mõtle keegi liiga palju jälgitavuse ja seire vahelise piiri peale. Koondamiste korral see piir aga helendab.

Selles selgitavas artiklis vaatleme, mis tõenäoliselt juhtus, miks on sellise jälgimise tegemine ahvatlev, kus see ületab eetilisi ja poliitilisi piire ning mida organisatsioonid saavad teha nii privaatsusele tekitatud kahju kui ka variinfo kogumise soovi vähendamiseks.

Mis juhtus (ja mida „skript” siin ilmselt tähendab)

BBC andmetel väitis Pinterest, et „kaks inseneri kirjutasid kohandatud skripte, mis pääsesid ebaõigesti juurde ettevõtte konfidentsiaalsele teabele, et tuvastada kõigi vallandatud töötajate asukohad ja nimed ning seejärel jagasid seda laiemalt“, nimetades seda poliitika rikkumiseks ja privaatsusprobleemiks mõjutatud töötajate jaoks. Aruandes kirjeldatakse mehhanismi ka nii, et jälgitakse töötajate nimede eemaldamist või deaktiveerimist sisemises suhtlusvahendis „nagu Slack“.

Paljudes ettevõtetes on Slack (või sarnane) otse seotud identiteedipakkujaga (Okta, Azure AD, Google Workspace jne). Konto keelamisel järgneb järgnev astmeline areng: juurdepääsutokenid aeguvad, grupid muutuvad ja kasutaja enam teatud kataloogiotsingutes, kanalites ja integratsioonides ei ilmu. Kui teil on API-juurdepääs (isegi kirjutuskaitstud), saate sageli järeldada, kelle konto sulgeti, lihtsalt oleku muutusi tuvastades:

  • Kasutaja kaob „aktiivsete kasutajate” nimekirjast.
  • Kasutajaprofiil deaktiveeritakse.
  • Bot ei saa neile enam otseteadet saata.
  • Nende liikmelisus muutub kanalite või kasutajarühmade lõikes.

Selles kontekstis ei pea „skript” olema keerukas. See võib olla paar tosinat koodirida, mis küsitleb API-t, võrdleb eilset kasutajaloendit tänasega ja saadab hoiatuse. Puhttehnilisest vaatenurgast on see sama muster, mida insenerid kasutavad õigustatud operatiivsete ülesannete puhul: kahe hetktõmmise eristamine muutuste tuvastamiseks.

Erinevus seisneb selles, mida tuvastatakse (inimesed), miks seda tuvastatakse (koondamised) ja kuhu tulemused jõuavad (laialdaselt jagatakse).

Miks töötajad koondamiste ajal seda teevad

Koondamiste kohta on üks ebamugav tõde: inimesed saavad sündmuse sisust tavaliselt teada kõrvalkanalite kaudu, enne kui juhtkond midagi selgitama hakkab. Mõnikord on see tingitud sellest, et juhtkond ei saa veel üksikasju jagada. Mõnikord on see tingitud sellest, et „me alles töötame detailide kallal” on eufemism väljendile „me ei taha öelda”.

Seega töötajad haaravad kinni kõikidest signaalidest:

  • Sõbrad jäävad järsku vait.
  • Kalendrikutsed kaovad.
  • Juurdepääs repositooriumidele on tühistatud.
  • Slacki olek muutub või inimene kaob kataloogist.

Nende signaalide jälgimine võib tunduda enesekaitsena. Inimesed tahavad teada:

  • Kas see mõjutab minu meeskonda?
  • Kas mu juht koondati?
  • Kas mu lähimad kaastöötajad on ikka veel siin?
  • Kas ettevõttega on kõik korras või on tegemist suurema ümberkorraldusega?

See motivatsioon on inimlik ja etteaimatav. Kuid etteaimatav käitumine võib ikkagi olla kahjulik.

Privaatsusprobleem: koondamisstaatus on tundlik teave

Töösuhte lõpetamine ei ole lihtsalt „tööalane tühiasi“. See on tundlik isiklik teave kellegi töösuhte staatuse kohta, mis on sageli seotud hüvitiste, immigratsiooni, tervisekindlustuse ja tulevaste töövõimalustega.

Isegi kui ettevõte plaanib töötajate arvu vähendamise avalikult välja kuulutada, avalikustatakse isikute identiteet ja asukohad tavaliselt teadmisvajaduse alusel:

  • Personalijuhtimise ja palgaarvestuse vajaduse üksikasjad.
  • IT peab teostama töötajate mahalaadimise.
  • Nõuetele vastavuse tagamiseks on vaja juriidilist tuge.
  • Juhid peavad oma meeskondadega otse suhtlema.

Koondatud töötajate nimekirja laialdane sisemine jagamine on erinev. See võib:

  • Eemalda mõjutatud isikult võime narratiivi kontrollida.
  • Paljastage kellegi asukoht või meeskonna kuuluvus.
  • Julgusta klatši ja spekulatsioone („kas see oli etendus?“, „kas see oli poliitiline?“).
  • Suurendab sihipärase ahistamise või ettevõttevälise doksimise ohtu.

Pinteresti väide – et see rikkus endiste kolleegide privaatsust – ei ole lihtsalt avalike suhete teema. See on tõeline kahju.

Turvaprobleem: juurdepääsu kontroll ei ole sama mis autoriseerimine

Paljud sisemised süsteemid töötavad ligikaudsete õiguste alusel: kui oled insener, võid sa küll kataloogi päringuid teha või sisemist API-t kasutada. See ei tähenda, et sul on õigus seda igaks otstarbeks kasutada.

Siin on paljudel organisatsioonidel raskusi. Nad loovad sisemisi tööriistu, mis on:

  • Lihtne kasutada,
  • Võimas,
  • Halvasti juhitud.

Ja siis toetuvad nad peamise kaitsepiirdena poliitikale („ära tee seda“). Kui surve on suur, siis ainult poliitikal põhinevad kaitsepiirded ebaõnnestuvad.

NIST SP 800-53 on üks standardkataloogidest, mida organisatsioonid kasutavad selliste kontrollrühmade nagu juurdepääsu kontroll ja auditeerimine üle mõtisklemiseks. Isegi ilma kontroll-ID-desse eksima jäämata kehtib põhiidee siin selgelt: andmetele juurdepääs peaks olema piiratud, jälgitav ja omistatav õigustatud ärieesmärkidele – eriti tundlike teabekategooriate puhul.

Teisisõnu: lauset „te võite seda tehniliselt lugeda” ei tohiks kunagi käsitleda kui „teil on õigus seda lugeda”.

Kultuuriline probleem: Slackist on saanud organisatsiooniskeem

Enamikul ettevõtetel on nüüd kaks paralleelset reaalsust:

  1. Formaalne reaalsus: personalisüsteemid, aruandlusliinid, ametlikud teadaanded.
  2. Elatud reaalsus: Slacki kanalid, grupi otsesõnumid, GitHubi mainimised, valvekordade rotatsioonid.

Kui formaalses süsteemis midagi muutub (näiteks töötajate väljaviimine), tekitab see koheselt nähtavaid artefakte reaalses süsteemis. Töötajad tõlgendavad neid artefakte tõena – mõnikord tugevamalt, kui nad usaldavad juhtkonna kommunikatsiooni.

See ebakõla loob perversse stiimuli:

  • Kui juhtkond ei ütle sulle, mis toimub,
  • Sa rekonstrueerid selle mis tahes telemeetrialekete põhjal.

See juhtum tuletab meelde, et „sisemine läbipaistvus” ei ole ainult kommunikatsioonistrateegia – see on ka infoturbestrateegia. Kui inimesed tunnevad, et nad peavad leketest reaalsuse kokku panema, siis nad seda ka teevad.

Kus insenerid piiri ületasid

Isegi kui sa mõistad, miks keegi sellise skripti võiks luua, on vähemalt kolm selget piiri, mis ületatakse:

1) Eesmärgi piiramine

Kui andmeallikas on „konfidentsiaalne ettevõtte teave”, eeldatakse, et seda kasutatakse õiguspärase ärifunktsiooni jaoks, mitte koondamiste kohta teabe saamiseks.

NISTi privaatsusraamistik rõhutab privaatsusriskide haldamist ja üksikisikuid kaitsvate tavade kasutamist. Praktiline tõlgendus on „koguda ja kasutada andmeid konkreetsetel ja õigustatud eesmärkidel ning vältida teisest kasutamist, mis tekitab uut kahju”.

Vallandatud kolleegide tuvastamise skript on peaaegu definitsiooniliselt teisejärguline kasutusala: koondamissignaalid on olemas süsteemide kaitsmiseks ja personaliprotsesside teostamiseks, mitte sisemise koondamisnimekirja genereerimiseks.

2) Võimendamine

Inimesed märkavad Slackis kadumisi orgaaniliselt – see on ümbritseva info leke.

Skript muudab ümbritseva lekke struktureeritud andmekogumiks (nimed, asukohad, tõenäolised meeskonnad, lõpetamise aeg). See on võimendamine: kahju potentsiaal suureneb järsult, kui ebamäärased signaalid muutuvad selgeks nimekirjaks.

3) Ümberjaotamine

Väljundi „laiemalt” jagamine on samm, mille puhul on seda raske pelga uudishimuna kaitsta. See loob tundliku teabe jaoks uue levitamiskanali ja muudab autorid vastutavaks hilisema väärkasutuse eest.

Mida ettevõtted saavad teha: vähendada lekkeid, suurendada usaldust ja karmistada kontrolli

On ekslik arvamus, et lahendus on „kõik kinni panna“. Praktikas on vaja kolme teineteist täiendavat sammu: juhtimist, tehnilist kontrolli ja suhtlust.

1) Käsitlege üleandmisüritusi tundlikuna ja arvestage privaatsusega

Väljaspoolt tarkvara müümine muudab paratamatult süsteeme, kuid saate vähendada informatsioonilist ammendumist:

  • Minimeerige avalikult kättesaadavate kataloogide muudatusi kuni side toimumiseni.
  • Väldi massilisi kasutajate eemaldamisi, mida on lihtne eristada.
  • Kaalu teatud mitteturvalisuse seisukohast kriitiliste värskenduste edasilükkamist tundide võrra, et need ei toimiks reaalajas koondamiste voona.

Eesmärk ei ole reaalsust igaveseks varjata. Eesmärk on vältida valusa sündmuse muutumist aaretejahiks.

2) Lisage eesmärgipõhised juurdepääsukontrollid ja logimine

Kui sisemised API-d suudavad töötajate staatuse muutusi suures mahus paljastada, siis:

  • Juurdepääs peaks olema piiratud rollidega, kes seda vajavad.
  • Massilise ekspordi puhul peaks olema vaja põhjendust.
  • Päringud tuleks logida koos identiteedi ja kavatsusega.
  • Automaatne küsitlus peaks silma paistma.

Siin on oluline „auditi ja vastutuse” mõtteviis: kui skript loetleb kasutajaid ja saadab teateid, peaks see käivitama tuvastamise.

3) Koostage koondamiste jaoks humaanne kommunikatsiooniplaan

Varjude jälgimise suurim liikumapanev jõud on ebakindlus.

Ettevõtted saavad vähendada soovi oma sisemisi tööriistu ära kasutada, olles selgesõnalised:

  • Millal teavitatakse mõjutatud töötajaid?
  • Millal meeskondi teavitatakse?
  • Mida ja millal saab jagada?
  • Kuhu peaksid inimesed kontrollitud värskenduste saamiseks pöörduma?

Kui juhtkond pakub õigeaegset ja konkreetset teavet, siis väheneb „tee-ise“ nimekirjade „vajadus“.

4) Andke töötajatele lubatud viis kaastöötajate kontrollimiseks

See on peen, aga oluline. Inimesed pole mitte ainult uudishimulikud – nad püüavad tööd koordineerida ja sõprade järele pärida.

Lihtne ja heakskiidetud kataloogi olekuteade („see konto pole enam aktiivne“) ilma ajatemplite, asukoha või loenditeta võiks rahuldada põhivajadused ilma massilist rekonstrueerimist võimaldamata.

Laiem trend: koondamised kui infoturbe stressitest

Koondamised paljastavad valitsemise nõrgad kohad, sest need loovad:

  • tundlike sündmuste plahvatus,
  • kõrge emotsionaalne temperatuur,
  • ja palju juurdepääsukaotust.

Just siis näebki äärepealt esinevaid juhtumeid: töötajad kraapivad süsteeme, juhid improviseerivad ja tööriistu kasutatakse viisil, milleks keegi pole ette näinud.

Sellised saidid nagu Layoffs.fyi on loodud seetõttu, et inimesed soovivad sõltumatut signaali tööstusharu koondamiste ulatuse kohta. Ettevõtte sees on sama vajadus olemas – välja arvatud see, et signaalid on otsesemad ja panused isiklikud.

Lõpptulemus

Pinteresti otsus vallandada insenere koondamiste jälgimise skriptimise pärast ei ole lihtsalt „ära ole uudishimulik“. See on hoiatus, et sisemine jälgitavus võib muutuda sisemiseks järelevalveks hetkel, kui organisatsiooni usaldus langeb.

Kui teie tööriistad võimaldavad hõlpsalt muuta identiteedivahetuse vallandatud töökaaslaste nimekirjaks, siis inimesed teevad seda – eriti koondamiste ajal. Lahendus ei seisne ainult skripti kirjutajate karistamises; see hõlmab süsteemide ja suhtlustavade loomist, mis ei muuda koondamist andmelekkeks ja mis käsitlevad töösuhte staatust tundliku teabena.

Allikad

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 Eesti