Pinterest a concediat inginerii care au urmărit concedierile în Slack — ce spune despre confidențialitate, încredere și telemetrie internă

/General/ De

Pinterest ar fi concediat doi ingineri după ce aceștia au scris scripturi pentru a identifica colegii care erau eliminați din instrumentele interne în timpul unei concedieri - și apoi au distribuit această listă pe scară largă. La prima vedere, aceasta este o poveste dramatică la locul de muncă. În esență, este un studiu de caz neobișnuit de clar despre modul în care funcționează de fapt companiile moderne: sistemele de identitate ca sursă de adevăr, platformele de chat ca organigrame de facto și „date interne” care sunt accesibile din punct de vedere tehnic cu mult înainte de a fi acceptabile din punct de vedere social.

Incidentul contează dincolo de Pinterest, deoarece aceleași ingrediente există în aproape fiecare companie de tehnologie: identitate centralizată, Slack sau Teams, sisteme de resurse umane și o serie lungă de tablouri de bord și API-uri interne. Când vremurile sunt calme, nimeni nu se gândește prea mult la linia dintre observabilitate și supraveghere. Când au loc concedieri, acea linie se aprinde.

În această explicație, vom analiza ce s-a întâmplat probabil, de ce este tentant să se facă acest tip de urmărire, unde depășește limitele etice și politice și ce pot face organizațiile pentru a reduce atât daunele aduse vieții private, cât și nevoia de a colecta informații din umbră.

Ce s-a întâmplat (și ce înseamnă probabil „un scenariu” aici)

Potrivit BBC, Pinterest a declarat că „doi ingineri au scris scripturi personalizate care accesează în mod necorespunzător informații confidențiale ale companiei pentru a identifica locațiile și numele tuturor angajaților concediați și apoi le-au distribuit pe scară largă”, numind acest lucru o încălcare a politicii și o problemă de confidențialitate pentru personalul afectat. Raportul descrie, de asemenea, mecanismul ca fiind o supraveghere pentru eliminarea sau dezactivarea numelor angajaților în cadrul unui instrument de comunicare internă „precum Slack”.

În multe companii, Slack (sau similar) este legat direct de furnizorul de identitate (Okta, Azure AD, Google Workspace etc.). Când un cont este dezactivat, urmează o cascadă de evenimente: token-urile de acces expiră, grupurile se modifică, iar utilizatorul nu mai apare în anumite căutări în directoare, canale și integrări. Dacă aveți acces API (chiar și doar pentru citire), puteți deduce adesea cine a fost dezactivat pur și simplu prin detectarea modificărilor de stare:

  • Un utilizator dispare din lista „utilizatori activi”.
  • Profilul unui utilizator devine dezactivat.
  • Un bot nu le mai poate trimite mesaje directe.
  • Calitatea de membru al acestora se schimbă în funcție de canal sau grup de utilizatori.

Un „script” în acest context nu trebuie să fie sofisticat. Ar putea fi câteva zeci de linii de cod care interoghează o API, compară lista de utilizatori de ieri cu cea de azi și emite o alertă. Dintr-o perspectivă pur tehnică, este același tipar pe care inginerii îl folosesc pentru sarcini operaționale legitime: compararea a două instantanee pentru a detecta modificările.

Diferența constă în ce se detectează (persoanele), de ce se detectează (concedierile) și unde se distribuie rezultatele (sunt distribuite pe scară largă).

De ce fac angajații asta în timpul concedierilor

Există un adevăr inconfortabil despre concedieri: oamenii află de obicei despre natura evenimentului prin canale secundare înainte ca conducerea să clarifice ceva. Uneori, asta se datorează faptului că conducerea nu poate încă să împărtășească detalii. Alteori, pentru că „încă lucrăm la detalii” este un eufemism pentru „nu vrem să spunem”.

Așadar, angajații apelează la orice semnale existente:

  • Prietenii amuțesc brusc.
  • Invitațiile din calendar dispar.
  • Accesul la depozite este revocat.
  • Statusul Slack se schimbă sau persoana dispare din director.

Urmărirea acelor semnale poate părea o acțiune de autoapărare. Oamenii vor să știe:

  • Este echipa mea afectată?
  • Managerul meu a fost concediat?
  • Mai sunt aici cei mai apropiați colaboratori ai mei?
  • Este compania în regulă sau este vorba de o restructurare mai amplă?

Această motivație este umană și previzibilă. Însă un comportament previzibil poate fi totuși un comportament dăunător.

Problema confidențialității: statutul concedierilor este o informație sensibilă

Un eveniment de concediere nu este doar o „curiozitate profesională”. Este vorba despre informații personale sensibile despre statutul de angajare al cuiva, adesea legate de beneficii, imigrare, asigurare medicală și perspective de angajare viitoare.

Chiar dacă o companie intenționează să anunțe public o reducere a numărului de angajați, identitatea persoanelor și locațiile acestora sunt de obicei menite să fie dezvăluite pe baza principiului „necesității de a le cunoaște”:

  • Detalii despre resurse umane și salarizare.
  • Departamentul IT trebuie să execute offboarding-ul.
  • Nevoi legale pentru a asigura conformitatea.
  • Managerii trebuie să comunice direct cu echipele lor.

Partajarea internă generală a unei liste de angajați concediați este diferită. Aceasta poate:

  • Elimină capacitatea persoanei afectate de a controla narațiunea.
  • A expune locația sau afilierea cuiva la o echipă.
  • Încurajați bârfele și speculațiile („a fost performanță?”, „a fost politică?”).
  • Crește riscul de hărțuire țintită sau doxxing în afara companiei.

Încadrarea Pinterest - conform căreia a încălcat intimitatea foștilor colegi - nu este doar o formă de relații publice. Este o categorie reală de prejudiciu.

Problema securității: controlul accesului nu este același lucru cu autorizarea

Multe sisteme interne funcționează cu permisiuni brute: dacă ești inginer, ai putea interoga un director sau să utilizezi o API internă. Asta nu înseamnă că ești autorizat să o folosești în orice scop.

Aici se confruntă multe dificultăți. Ele construiesc instrumente interne care sunt:

  • Ușor de utilizat,
  • Puternic,
  • Slab guvernat.

Și apoi se bazează pe politici („nu faceți asta”) ca principală barieră de protecție. Când presiunea este mare, barierele de protecție bazate exclusiv pe politici eșuează.

NIST SP 800-53 este unul dintre cataloagele standard utilizate de organizații pentru a analiza familiile de control, cum ar fi controlul accesului și auditul. Chiar și fără a ne pierde în ID-urile de control, ideea de bază se aplică perfect aici: accesul la date ar trebui să fie restricționat, monitorizat și atribuibil unor scopuri comerciale legitime - în special pentru categoriile sensibile de informații.

Cu alte cuvinte: „tehnic vorbind poți citi asta” nu ar trebui niciodată tratat ca „e în regulă să citești asta”.

Problema culturală: Slack a devenit organigrama

Majoritatea companiilor au acum două realități paralele:

  1. Realitatea formală: sisteme de resurse umane, linii de raportare, anunțuri oficiale.
  2. Realitatea trăită: canale Slack, mesaje directe de grup, mențiuni GitHub, rotații la gardă.

Când ceva se schimbă în sistemul formal (cum ar fi o retragere din activitate), acest lucru produce imediat artefacte vizibile în sistemul existent. Angajații interpretează aceste artefacte ca fiind adevăr - uneori mai puternic decât au încredere în comunicările conducerii.

Această nepotrivire creează un stimulent pervers:

  • Dacă conducerea nu vă spune ce se întâmplă,
  • îl vei reconstrui din orice scurgeri de telemetrie.

Acest incident ne reamintește că „transparența internă” nu este doar o strategie de comunicare - este și o strategie de securitate a informațiilor. Dacă oamenii simt că trebuie să reconstituie realitatea din scurgerile de informații, o vor face.

Unde inginerii au depășit linia

Chiar dacă empatizezi cu motivele pentru care cineva ar putea construi un astfel de scenariu, există cel puțin trei aspecte clare care pot fi depășite:

1) Limitarea scopului

Dacă sursa de date este „informații confidențiale ale companiei”, se așteaptă ca aceasta să fie utilizată pentru o funcție comercială legitimă, nu pentru recunoașterea concedierilor.

Cadrul de confidențialitate al NIST pune accentul pe gestionarea riscului de confidențialitate și utilizarea unor practici care protejează persoanele. O traducere practică este „colectarea și utilizarea datelor în scopuri specifice, legitime și evitarea utilizărilor secundare care creează noi daune”.

Un script pentru identificarea colegilor concediați este aproape prin definiție o utilizare secundară: semnalele de concediere există pentru a proteja sistemele și a executa procesele de resurse umane, nu pentru a genera o listă internă de concedieri.

2) Amplificare

Oamenii observă disparițiile în Slack în mod organic — aceasta este scurgerea de informații ambientale.

Un script transformă scurgerile ambientale într-un set de date structurat (nume, locații, echipe probabile, ora încheierii). Aceasta este amplificare: potențialul de daune crește brusc atunci când semnalele vagi devin o listă curată.

3) Redistribuire

Partajarea rezultatelor „pe scară mai largă” este pasul care face dificilă apărarea lor drept simplă curiozitate. Creează un nou canal de distribuție pentru informații sensibile și îi face pe autori responsabili pentru utilizarea abuzivă în aval.

Ce pot face companiile: reducerea scurgerilor, creșterea încrederii și înăsprirea controalelor

Există o concepție greșită conform căreia soluția este „blocarea tuturor aspectelor”. În practică, sunt necesare trei mișcări complementare: guvernanță, controale tehnice și comunicare.

1) Tratați evenimentele de dezactivare a contului ca fiind sensibile și proiectați-le pentru a ține cont de confidențialitate

Renunțarea la informații schimbă inevitabil sistemele, dar poți reduce evacuarea informațională:

  • Minimizați modificările directoarelor cu acces public până la apariția comunicărilor.
  • Evitați eliminările în masă ale utilizatorilor ușor de diferențiat.
  • Luați în considerare amânarea anumitor actualizări care nu sunt critice din punct de vedere al securității cu câteva ore, astfel încât acestea să nu acționeze ca un flux de concedieri în timp real.

Scopul nu este să ascundem realitatea pentru totdeauna. Ci să evităm transformarea unui eveniment dureros într-o vânătoare de comori.

2) Adăugați controale de acces bazate pe scop și înregistrare în jurnal

Dacă API-urile interne pot dezvălui modificările statutului angajaților la scară largă, atunci:

  • Accesul ar trebui limitat la rolurile care îl necesită.
  • Exportul în vrac ar trebui să necesite justificare.
  • Interogările ar trebui înregistrate cu identitate și intenție.
  • Sondajele automate ar trebui să iasă în evidență.

Aici contează mentalitatea de „audit și responsabilitate”: dacă un script enumeră utilizatorii și emite alerte, ar trebui să declanșeze detectarea.

3) Aveți un plan de comunicare uman pentru concedieri

Cel mai mare factor determinant al urmăririi umbrelor este incertitudinea.

Companiile pot reduce impulsul de a extrage instrumente interne prin a fi explicite:

  • Când vor fi anunțați angajații afectați?
  • Când vor fi informate echipele?
  • Ce poate fi partajat și când?
  • Unde ar trebui oamenii să meargă pentru actualizări verificate?

Dacă conducerea oferă informații specifice și la timp, „nevoia” de liste personalizate scade.

4) Oferiți angajaților o modalitate autorizată de a verifica colaboratorii

Acest lucru este subtil, dar important. Oamenii nu sunt doar curioși - încearcă să-și coordoneze munca și să-și vadă prietenii.

Un simplu mesaj de stare a directorului autorizat („acest cont nu mai este activ”), fără marcaje temporale, locație sau liste, ar putea satisface nevoi de bază fără a permite reconstrucția în masă.

O tendință mai largă: concedierile ca test de stres pentru securitatea informațiilor

Disponibilizările dezvăluie puncte slabe în guvernare deoarece creează:

  • o explozie de evenimente sensibile,
  • o temperatură emoțională ridicată,
  • și o pierdere semnificativă a accesului.

Exact atunci vezi cazuri limită: angajați care extrag sisteme, manageri care improvizează și instrumente utilizate în moduri pentru care nimeni nu a fost conceput.

Site-uri precum Layoffs.fyi există deoarece oamenii își doresc un semnal independent despre amploarea reducerilor de personal din industrie. În interiorul unei companii, există aceeași nevoie - doar că semnalele sunt mai directe, iar miza este personală.

Concluzie

Faptul că Pinterest concediază ingineri pentru că a programat urmărirea concedierilor nu înseamnă doar „nu fiți curioși”. Este un avertisment că observabilitatea internă poate deveni supraveghere internă în momentul în care încrederea organizațională scade.

Dacă instrumentele tale facilitează transformarea pierderii de identități într-o listă de colegi concediați, oamenii vor face asta - mai ales în timpul concedierilor. Soluția nu constă doar în pedepsirea persoanelor care au scris scenariul; ci și în construirea de sisteme și practici de comunicare care nu transformă pierderea de identități într-o scurgere de date și care tratează statutul de angajare ca informația sensibilă care este.

Surse

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 Română