Pinterest je odpustil inženirje, ki so v Slacku spremljali odpuščanja – kaj to pove o zasebnosti, zaupanju in notranji telemetriji

/Splošno/ Avtor

Pinterest naj bi odpustil dva inženirja, potem ko sta napisala skripta za ugotavljanje, kateri sodelavci so bili med odpuščanjem odstranjeni iz internih orodij – nato pa je ta seznam delil širše. Na prvi pogled gre za zgodbo o drami na delovnem mestu. V osnovi pa gre za nenavadno jasno študijo primera, kako sodobna podjetja dejansko delujejo: sistemi identitete kot vir resnice, platforme za klepet kot dejanske organizacijske sheme in »interni podatki«, ki so tehnično dostopni že dolgo preden so družbeno sprejemljivi.

Incident je pomemben tudi onkraj Pinteresta, saj iste sestavine obstajajo v skoraj vsakem tehnološkem podjetju: centralizirana identiteta, Slack ali Teams, sistemi za človeške vire in dolg rep notranjih nadzornih plošč in API-jev. Ko so časi mirni, nihče preveč ne razmišlja o meji med opazovalnostjo in nadzorom. Ko pride do odpuščanj, se ta meja zasveti.

V tej razlagi si bomo ogledali, kaj se je verjetno zgodilo, zakaj je skušnjava izvajati tovrstno sledenje, kje presega etične in politične meje ter kaj lahko organizacije storijo, da zmanjšajo tako škodo za zasebnost kot tudi potrebo po zbiranju informacij v senci.

Kaj se je zgodilo (in kaj tukaj verjetno pomeni "skript")

Po poročanju BBC-ja je Pinterest sporočil, da sta »dva inženirja napisala skripte po meri, s katerimi sta nepravilno dostopala do zaupnih podatkov podjetja, da bi ugotovila lokacije in imena vseh odpuščenih zaposlenih, nato pa jih delila širše«, kar je označilo za kršitev pravilnika in vprašanje zasebnosti prizadetih zaposlenih. Poročilo opisuje tudi mehanizem kot spremljanje, ali so bila imena zaposlenih odstranjena ali deaktivirana znotraj orodja za notranjo komunikacijo, »kot je Slack«.

V mnogih podjetjih je Slack (ali podoben) neposredno povezan s ponudnikom identitete (Okta, Azure AD, Google Workspace itd.). Ko je račun onemogočen, sledi kaskada: žetoni za dostop potečejo, skupine se spremenijo in uporabnik se neha prikazovati v določenih iskanjih imenikov, kanalih in integracijah. Če imate dostop do API-ja (tudi samo za branje), lahko pogosto sklepate, kdo je bil prekinjen, preprosto z zaznavanjem sprememb stanja:

  • Uporabnik izgine s seznama »aktivnih uporabnikov«.
  • Uporabniški profil postane deaktiviran.
  • Bot jim ne more več pošiljati zasebnih sporočil.
  • Njihovo članstvo se spreminja med kanali ali uporabniškimi skupinami.

»Skript« v tem kontekstu ni nujno zapleten. Lahko gre za nekaj deset vrstic kode, ki anketirajo API, primerjajo včerajšnji seznam uporabnikov z današnjim in oddajo opozorilo. S čisto tehničnega vidika gre za isti vzorec, ki ga inženirji uporabljajo za legitimne operativne naloge: primerjava dveh posnetkov za zaznavanje sprememb.

Razlika je v tem, kaj se zaznava (ljudje), zakaj se zaznava (odpuščanja) in kam gredo rezultati (široko se delijo).

Zakaj zaposleni to počnejo med odpuščanji

Pri odpuščanjih obstaja neprijetna resnica: ljudje običajno izvedo o poteku dogodka po stranskih kanalih, preden vodstvo karkoli pojasni. Včasih je to zato, ker vodstvo še ne more deliti podrobnosti. Včasih zato, ker je »še vedno delamo na podrobnostih« evfemizem za »ne želimo povedati«.

Zaposleni torej posegajo po vseh obstoječih signalih:

  • Prijatelji nenadoma utihnejo.
  • Povabila v koledar izginejo.
  • Dostop do repozitorijev je preklican.
  • Status v Slacku se spremeni ali pa oseba izgine iz imenika.

Sledenje tem signalom se lahko zdi kot samoobramba. Ljudje želijo vedeti:

  • Ali je to vplivalo na mojo ekipo?
  • Je bil moj vodja odpuščen?
  • So moji najbližji sodelavci še vedno tukaj?
  • Je podjetje v redu ali gre za večje prestrukturiranje?

Ta motivacija je človeška in predvidljiva. Vendar je lahko predvidljivo vedenje še vedno škodljivo.

Težava z zasebnostjo: status odpuščanja je občutljiva informacija

Odpoved pogodbe o zaposlitvi ni le »delovne zanimivosti«. Gre za občutljive osebne podatke o zaposlitvenem statusu osebe, pogosto povezane z ugodnostmi, priseljevanjem, zdravstvenim zavarovanjem in prihodnjimi zaposlitvenimi možnostmi.

Tudi če podjetje načrtuje javno objavo zmanjšanja števila zaposlenih, se identiteta posameznikov in njihove lokacije običajno razkrijejo na podlagi potrebe po seznanitvi:

  • Potrebujete podrobnosti o kadrovski službi in plačah.
  • IT mora izvesti offboarding.
  • Pravne potrebe za zagotavljanje skladnosti.
  • Vodje morajo neposredno komunicirati s svojimi ekipami.

Široka notranja delitev seznama odpuščenih zaposlenih je drugačna. Lahko:

  • Odstranite prizadeti osebi možnost nadzora nad pripovedjo.
  • Razkrijte lokacijo ali pripadnost nekoga ekipi.
  • Spodbujajte trače in ugibanja (»je bil to nastop?« »je bil to političen?«).
  • Povečajte tveganje za ciljno nadlegovanje ali doxing zunaj podjetja.

Pinterestovo uokvirjanje – da je kršil zasebnost nekdanjih kolegov – ni le odnos z javnostmi. Gre za resnično kategorijo škode.

Varnostna težava: nadzor dostopa ni isto kot avtorizacija

Mnogi interni sistemi delujejo na podlagi grobih dovoljenj: če ste inženir, lahko morda poizvedujete po imeniku ali uporabljate interni API. To ne pomeni, da ste pooblaščeni za njegovo uporabo za vsak namen.

Tukaj se veliko organizacij sooča s težavami. Gradijo notranja orodja, ki so:

  • Enostavna uporaba,
  • Močan,
  • Slabo vodeno.

In potem se zanašajo na politiko (»tega ne delajte«) kot primarno varovalo. Ko je pritisk visok, varovala, ki temeljijo zgolj na politiki, odpovejo.

NIST SP 800-53 je eden od standardnih katalogov, ki jih organizacije uporabljajo za razmišljanje o družinah kontrol, kot sta nadzor dostopa in revidiranje. Tudi brez poglobljenega raziskovanja ID-jev kontrol se tukaj osnovna ideja jasno uporablja: dostop do podatkov mora biti omejen, nadzorovan in pripisljiv legitimnim poslovnim namenom – zlasti za občutljive kategorije informacij.

Z drugimi besedami: »tehnično lahko to preberete« se nikoli ne sme obravnavati kot »v redu je, da to preberete«.

Kulturni problem: Slack je postal organizacijska shema

Večina podjetij ima zdaj dve vzporedni realnosti:

  1. Formalna realnost: sistemi za človeške vire, linije poročanja, uradne objave.
  2. Živa resničnost: Slack kanali, skupinska zasebna sporočila, omembe na GitHubu, rotacije dežurstev.

Ko se v formalnem sistemu nekaj spremeni (kot je na primer umik iz službe), to takoj ustvari vidne artefakte v živem sistemu. Zaposleni te artefakte interpretirajo kot resnico – včasih bolj kot zaupajo komunikaciji vodstva.

To neskladje ustvarja perverzno spodbudo:

  • Če vam vodstvo ne pove, kaj se dogaja,
  • Rekonstruirali ga boste iz kakršnih koli puščanj telemetrije.

Ta incident je opomnik, da »notranja preglednost« ni le komunikacijska strategija – gre tudi za strategijo informacijske varnosti. Če ljudje menijo, da morajo iz uhajanja informacij sestaviti resničnost, to tudi bodo storili.

Kjer so inženirji prestopili mejo

Tudi če sočustvujete z razlogi, zakaj bi nekdo lahko zgradil takšen skript, obstajajo vsaj tri svetle meje, ki jih je treba prečkati:

1) Omejitev namena

Če je vir podatkov »zaupni podatek podjetja«, se pričakuje, da se uporablja za legitimno poslovno funkcijo in ne za iskanje odpuščanj.

Okvir za zasebnost NIST-a poudarja upravljanje tveganj za zasebnost in uporabo praks, ki ščitijo posameznike. Praktičen prevod je »zbiranje in uporaba podatkov za določene, legitimne namene ter izogibanje sekundarni uporabi, ki ustvarja novo škodo«.

Skript za identifikacijo odpuščenih sodelavcev je skoraj definicijsko sekundarne uporabe: signali za odpuščanje obstajajo za zaščito sistemov in izvajanje kadrovskih procesov, ne pa za ustvarjanje notranjega seznama odpuščanj.

2) Ojačanje

Ljudje v Slacku organsko opazijo izginotja – to je uhajanje informacij iz okolja.

Skript pretvori uhajanje podatkov iz okolja v strukturiran nabor podatkov (imena, lokacije, verjetne ekipe, čas prekinitve). To je ojačanje: potencial škode se močno poveča, ko nejasni signali postanejo čist seznam.

3) Prerazporeditev

Širša delitev rezultatov je korak, zaradi katerega jih je težko zagovarjati kot zgolj radovednost. Ustvarja nov distribucijski kanal za občutljive informacije in avtorje nalaga odgovornosti za zlorabo v nadaljnji fazi.

Kaj lahko storijo podjetja: zmanjšajo uhajanje informacij, povečajo zaupanje in poostrijo nadzor

Obstaja zmotno prepričanje, da je rešitev »zakleniti vse«. V praksi potrebujete tri dopolnjujoče se poteze: upravljanje, tehnični nadzor in komunikacijo.

1) Dogodke odjave obravnavajte kot občutljive in jih oblikujte tako, da upoštevajo zasebnost.

Offboarding neizogibno spremeni sisteme, vendar lahko zmanjšate izčrpavanje informacij:

  • Zmanjšajte spremembe javno dostopnih imenikov, dokler ne pride do komunikacije.
  • Izogibajte se množičnim odstranjevanjem uporabnikov, ki jih je enostavno razlikovati.
  • Razmislite o odložitvi nekaterih posodobitev, ki niso kritične za varnost, za več ur, da ne bodo delovale kot vir odpuščanj v realnem času.

Cilj ni za vedno skrivati ​​resničnost. Gre za to, da se boleč dogodek ne spremeni v lov na zaklad.

2) Dodajte nadzor dostopa in beleženje na podlagi namena

Če lahko interni API-ji razkrijejo spremembe statusa zaposlenih v velikem obsegu, potem:

  • Dostop bi moral biti omejen na vloge, ki ga potrebujejo.
  • Za izvoz v razsutem stanju je treba zahtevati utemeljitev.
  • Poizvedbe je treba beležiti z identiteto in namenom.
  • Avtomatizirano anketiranje bi moralo izstopati.

Tukaj je pomembna miselnost »revizije in odgovornosti«: če skript našteva uporabnike in oddaja opozorila, bi moral sprožiti zaznavanje.

3) Imejte načrt humane komunikacije za odpuščanja

Največji dejavnik sledenja senci je negotovost.

Podjetja lahko zmanjšajo impulz za krajo notranjih orodij z jasnostjo:

  • Kdaj bodo prizadeti zaposleni obveščeni?
  • Kdaj bodo ekipe obveščene?
  • Kaj se lahko deli in kdaj?
  • Kam naj ljudje poiščejo preverjene posodobitve?

Če vodstvo zagotovi pravočasne in specifične informacije, se »potreba« po seznamih »naredi sam« zmanjša.

4) Zagotovite zaposlenim odobren način preverjanja sodelavcev

To je subtilno, a pomembno. Ljudje niso le radovedni – poskušajo uskladiti delo in preveriti prijatelje.

Preprosto, odobreno sporočilo o stanju imenika (»ta račun ni več aktiven«) brez časovnih žigov, lokacije ali seznamov bi lahko zadovoljilo osnovne potrebe, ne da bi omogočilo množično rekonstrukcijo.

Širši trend: odpuščanja kot stresni test informacijske varnosti

Odpuščanja razkrivajo šibke točke v upravljanju, ker ustvarjajo:

  • izbruh občutljivih dogodkov,
  • visoka čustvena temperatura,
  • in veliko odliva dostopov.

Točno takrat opazimo skrajne primere: zaposleni, ki izkoriščajo sisteme, vodje, ki improvizirajo, in orodja, ki se uporabljajo na načine, za katere nihče ni bil zasnovan.

Spletna mesta, kot je Layoffs.fyi, obstajajo, ker ljudje želijo neodvisen signal o obsegu odpuščanj v panogi. Znotraj podjetja obstaja ista potreba – le da so signali bolj neposredni in gre za osebne stvari.

Bistvo

Odpuščanje inženirjev na Pinterestu zaradi skriptiranja sledenja odpuščanjem ni le "ne bodite radovedni". Gre za opozorilo, da lahko notranja opazovalnost postane notranji nadzor v trenutku, ko se zaupanje v organizacijo zmanjša.

Če vaša orodja omogočajo enostavno pretvorbo odhoda identitet v seznam odpuščenih sodelavcev, bodo ljudje to storili – še posebej med odpuščanji. Rešitev ni le kaznovanje ljudi, ki so napisali scenarij; gre za izgradnjo sistemov in komunikacijskih praks, ki odhoda iz službe ne spremenijo v uhajanje podatkov in ki zaposlitveni status obravnavajo kot občutljivo informacijo, kar tudi je.

Viri

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...
l Slovenščina