Pinterest avrebbe licenziato due ingegneri dopo aver scritto degli script per identificare quali colleghi sarebbero stati rimossi dagli strumenti interni durante un licenziamento, per poi condividere l'elenco con altri. In apparenza, si tratta di una storia di dramma sul posto di lavoro. In realtà, è un caso di studio insolitamente chiaro su come funzionano effettivamente le aziende moderne: sistemi di identità come fonte di verità, piattaforme di chat come organigrammi di fatto e "dati interni" tecnicamente accessibili molto prima di essere socialmente accettabili.
L'incidente ha un'importanza che va oltre Pinterest, perché gli stessi ingredienti sono presenti in quasi tutte le aziende tecnologiche: identità centralizzata, Slack o Teams, sistemi HR e una lunga serie di dashboard e API interne. Quando i tempi sono calmi, nessuno si sofferma troppo sul confine tra osservabilità e sorveglianza. Quando si verificano licenziamenti, quel confine si illumina.
In questa spiegazione, analizzeremo cosa è probabilmente successo, perché è allettante effettuare questo tipo di monitoraggio, dove supera i confini etici e politici e cosa possono fare le organizzazioni per ridurre sia i danni alla privacy sia la necessità di raccogliere informazioni nascoste.
Cosa è successo (e cosa probabilmente significa qui "una sceneggiatura")
Secondo la BBC, Pinterest ha affermato che "due ingegneri hanno creato script personalizzati accedendo in modo improprio a informazioni aziendali riservate per identificare le posizioni e i nomi di tutti i dipendenti licenziati e poi le hanno condivise con un pubblico più ampio", definendo l'accaduto una violazione delle policy e un problema di privacy per il personale interessato. Il rapporto descrive anche il meccanismo come un sistema di controllo dei nomi dei dipendenti rimossi o disattivati all'interno di uno strumento di comunicazione interna "come Slack".
In molte aziende, Slack (o simili) è direttamente collegato al provider di identità (Okta, Azure AD, Google Workspace, ecc.). Quando un account viene disabilitato, si verifica una serie di conseguenze: i token di accesso scadono, i gruppi cambiano e l'utente non compare più in determinate ricerche di directory, canali e integrazioni. Se si dispone di accesso API (anche in sola lettura), è spesso possibile dedurre chi è stato disabilitato semplicemente rilevando i cambiamenti di stato:
- Un utente scompare dall'elenco degli "utenti attivi".
- Il profilo di un utente viene disattivato.
- Un bot non può più inviarli tramite DM.
- La loro appartenenza cambia a seconda dei canali o dei gruppi di utenti.
Uno "script" in questo contesto non deve essere necessariamente sofisticato. Potrebbe essere costituito da poche decine di righe di codice che interrogano un'API, confrontano l'elenco utenti di ieri con quello di oggi ed emettono un avviso. Da un punto di vista puramente tecnico, si tratta dello stesso schema che gli ingegneri usano per le attività operative legittime: confrontare due snapshot per rilevare eventuali modifiche.
La differenza sta nel cosa viene rilevato (persone), nel perché viene rilevato (licenziamenti) e nella destinazione dei risultati (condivisi in modo ampio).
Perché i dipendenti fanno questo durante i licenziamenti
C'è una scomoda verità sui licenziamenti: di solito le persone apprendono la portata dell'evento attraverso canali secondari prima che la dirigenza chiarisca qualcosa. A volte questo accade perché la dirigenza non può ancora condividere i dettagli. A volte perché "stiamo ancora lavorando sui dettagli" è un eufemismo per "non vogliamo dirlo".
Quindi i dipendenti cercano qualsiasi segnale disponibile:
- Gli amici improvvisamente tacciono.
- Gli inviti del calendario scompaiono.
- L'accesso ai repository è revocato.
- Lo stato di Slack cambia o la persona scompare dalla directory.
Monitorare questi segnali può sembrare un atto di autodifesa. Le persone vogliono sapere:
- Il mio team è interessato?
- Il mio manager è stato licenziato?
- I miei collaboratori più stretti sono ancora qui?
- L'azienda sta bene o si tratta di una ristrutturazione più ampia?
Questa motivazione è umana e prevedibile. Ma un comportamento prevedibile può comunque rivelarsi dannoso.
Il problema della privacy: lo stato di licenziamento è un'informazione sensibile
Un evento di licenziamento non è solo una "banalità lavorativa". Si tratta di informazioni personali sensibili sullo stato occupazionale di una persona, spesso legate a benefit, immigrazione, assicurazione sanitaria e prospettive di lavoro future.
Anche se un'azienda ha intenzione di annunciare pubblicamente una riduzione del personale, l'identità dei singoli dipendenti e la loro sede sono solitamente destinate a essere divulgate solo se strettamente necessario:
- Sono necessari dettagli per le risorse umane e la gestione delle paghe.
- L'IT deve eseguire l'offboarding.
- Esigenze legali per garantire la conformità.
- I manager devono comunicare direttamente con i loro team.
La condivisione interna su larga scala di un elenco di dipendenti licenziati è diversa. Può:
- Togliere alla persona interessata la capacità di controllare la narrazione.
- Rendere pubblica la posizione di qualcuno o l'affiliazione a un team.
- Incoraggiare pettegolezzi e speculazioni ("era una performance?" "era una questione politica?").
- Aumenta il rischio di molestie mirate o di doxxing all'esterno dell'azienda.
La posizione di Pinterest, secondo cui avrebbe violato la privacy degli ex colleghi, non è solo una questione di pubbliche relazioni. È una vera e propria categoria di danno.
Il problema di sicurezza: il controllo degli accessi non è la stessa cosa dell'autorizzazione
Molti sistemi interni funzionano con permessi grossolani: se sei un ingegnere, potresti essere in grado di interrogare una directory o utilizzare un'API interna. Ciò non significa che tu sia autorizzato a utilizzarla per qualsiasi scopo.
È qui che molte organizzazioni incontrano difficoltà. Costruiscono strumenti interni che sono:
- Facile da usare,
- Potente,
- Mal governato.
E poi si affidano alla politica ("non farlo") come principale barriera di sicurezza. Quando la pressione è alta, le barriere basate solo sulla politica falliscono.
Il NIST SP 800-53 è uno dei cataloghi standard che le organizzazioni utilizzano per concepire famiglie di controllo come il controllo degli accessi e l'audit. Anche senza perdersi in ID di controllo, l'idea di base si applica perfettamente anche in questo caso: l'accesso ai dati deve essere limitato, monitorato e attribuibile a legittimi scopi aziendali, soprattutto per le categorie di informazioni sensibili.
In altre parole: "tecnicamente puoi leggere questo" non dovrebbe mai essere interpretato come "va bene che tu legga questo".
Il problema culturale: Slack è diventato l'organigramma
La maggior parte delle aziende oggi si trova a dover affrontare due realtà parallele:
- La realtà formale: sistemi di risorse umane, linee di riporto, annunci ufficiali.
- La realtà vissuta: canali Slack, messaggi diretti di gruppo, menzioni su GitHub, turni di reperibilità.
Quando qualcosa cambia nel sistema formale (come l'offboarding), si producono immediatamente artefatti visibili nel sistema reale. I dipendenti interpretano questi artefatti come verità, a volte con più convinzione di quanto si fidino delle comunicazioni dei dirigenti.
Questa discrepanza crea un incentivo perverso:
- Se la leadership non ti dice cosa sta succedendo,
- lo ricostruirai da qualsiasi perdita di telemetria.
Questo incidente ci ricorda che la "trasparenza interna" non è solo una strategia di comunicazione, ma anche una strategia di sicurezza informatica. Se le persone sentono di dover ricostruire la realtà partendo dalle fughe di notizie, lo faranno.
Dove gli ingegneri hanno oltrepassato il limite
Anche se si comprende il motivo per cui qualcuno potrebbe scrivere una sceneggiatura del genere, ci sono almeno tre linee chiare che vengono oltrepassate:
1) Limitazione dello scopo
Se la fonte dei dati è costituita da "informazioni aziendali riservate", ci si aspetta che vengano utilizzate per una funzione aziendale legittima e non per la ricognizione sui licenziamenti.
Il Privacy Framework del NIST enfatizza la gestione del rischio per la privacy e l'adozione di pratiche che proteggano gli individui. Una traduzione pratica è "raccogliere e utilizzare i dati per scopi specifici e legittimi ed evitare usi secondari che creino nuovi danni".
Uno script per identificare i colleghi licenziati è quasi per definizione un utilizzo secondario: i segnali di offboarding esistono per proteggere i sistemi ed eseguire i processi delle risorse umane, non per generare un elenco interno di licenziamenti.
2) Amplificazione
Le persone notano le sparizioni su Slack in modo naturale: si tratta di una perdita di informazioni ambientali.
Uno script trasforma le perdite ambientali in un set di dati strutturato (nomi, posizioni, probabili team, ora di conclusione). Questa è amplificazione: il potenziale di danno aumenta drasticamente quando i segnali vaghi diventano un elenco pulito.
3) Ridistribuzione
Condividere i risultati "più ampiamente" è il passaggio che rende difficile difenderli come mera curiosità. Crea un nuovo canale di distribuzione per informazioni sensibili e rende gli autori responsabili di eventuali abusi a valle.
Cosa possono fare le aziende: ridurre le perdite, aumentare la fiducia e rafforzare i controlli
C'è l'idea sbagliata che la soluzione sia "bloccare tutto". In pratica, occorrono tre mosse complementari: governance, controlli tecnici e comunicazione.
1) Trattare gli eventi di offboarding come sensibili e progettare per la privacy
L'offboarding inevitabilmente modifica i sistemi, ma è possibile ridurre lo spreco di informazioni:
- Ridurre al minimo le modifiche alla directory pubblica finché non si verificano comunicazioni.
- Evita le rimozioni di massa degli utenti, che sono facili da distinguere.
- Si consiglia di posticipare di alcune ore determinati aggiornamenti non critici per la sicurezza, in modo che non fungano da feed di licenziamento in tempo reale.
L'obiettivo non è nascondere la realtà per sempre. È evitare di trasformare un evento doloroso in una caccia al tesoro.
2) Aggiungere controlli di accesso e registrazione basati sullo scopo
Se le API interne possono rivelare su larga scala i cambiamenti di stato dei dipendenti, allora:
- L'accesso dovrebbe essere limitato ai ruoli che ne hanno bisogno.
- L'esportazione in blocco dovrebbe richiedere una giustificazione.
- Le query devono essere registrate con identità e intento.
- Dovrebbero distinguersi i sondaggi automatizzati.
È qui che entra in gioco la mentalità di "controllo e responsabilità": se uno script enumera gli utenti ed emette avvisi, dovrebbe attivare il rilevamento.
3) Avere un piano di comunicazione umano per i licenziamenti
Il principale fattore che determina il tracciamento delle ombre è l'incertezza.
Le aziende possono ridurre l'impulso a eliminare gli strumenti interni essendo esplicite:
- Quando verranno informati i dipendenti interessati?
- Quando verranno informate le squadre?
- Cosa può essere condiviso e quando?
- Dove si possono trovare gli aggiornamenti verificati?
Se la dirigenza fornisce informazioni tempestive e specifiche, la “necessità” di elenchi fai da te diminuisce.
4) Offrire ai dipendenti un modo autorizzato per controllare i collaboratori
È un dettaglio sottile ma importante. Le persone non sono solo curiose: cercano anche di coordinare il lavoro e di stare in contatto con gli amici.
Un semplice messaggio di stato della directory autorizzato ("questo account non è più attivo") senza timestamp, posizione o elenchi potrebbe soddisfare esigenze di base senza consentire una ricostruzione di massa.
Una tendenza più ampia: i licenziamenti come stress test per la sicurezza informatica
I licenziamenti rivelano i punti deboli della governance perché creano:
- una raffica di eventi sensibili,
- una temperatura emotiva elevata,
- e un elevato tasso di abbandono degli accessi.
Ed è proprio in questi casi che si verificano casi limite: dipendenti che utilizzano i sistemi, manager che improvvisano e strumenti utilizzati in modi per cui nessuno li ha progettati.
Siti come Layoffs.fyi esistono perché le persone vogliono un segnale indipendente sull'entità dei tagli nel settore. All'interno di un'azienda, esiste la stessa esigenza, solo che i segnali sono più diretti e la posta in gioco è personale.
In conclusione
Il licenziamento degli ingegneri da parte di Pinterest per aver creato uno script per il monitoraggio dei licenziamenti non è solo un "non essere ficcanaso". È un avvertimento: l'osservabilità interna può trasformarsi in sorveglianza interna nel momento in cui la fiducia nell'organizzazione cala.
Se i tuoi strumenti facilitano la trasformazione del ricambio di identità in una lista di colleghi licenziati, la gente lo farà, soprattutto durante i licenziamenti. La soluzione non è solo punire chi ha scritto la sceneggiatura; è costruire sistemi e pratiche di comunicazione che non trasformino l'offboarding in una fuga di dati e che trattino lo stato occupazionale come un'informazione sensibile.
Italiano
English
العربية
Čeština
Dansk
Nederlands
Eesti
Suomi
Français
Deutsch
Ελληνικά
Magyar
日本語
한국어
Latviešu valoda
Lietuvių kalba
Norsk bokmål
Polski
Português
Română
Русский
Slovenčina
Slovenščina
Español
Svenska
Türkçe