Компания Pinterest уволила инженеров, отслеживавших увольнения в Slack — что это говорит о конфиденциальности, доверии и внутренней телеметрии.

/Общий/ К

По сообщениям, Pinterest уволил двух инженеров после того, как они написали скрипты для определения того, каких сотрудников удаляют из внутренних инструментов во время сокращения штата, а затем распространили этот список среди более широкого круга лиц. На первый взгляд, это история о корпоративной драме. Но на самом деле это необычайно наглядный пример того, как на самом деле работают современные компании: системы идентификации как источник достоверной информации, чат-платформы как де-факто организационные схемы и «внутренние данные», которые технически доступны задолго до того, как становятся социально приемлемыми.

Этот инцидент имеет значение не только для Pinterest, потому что одни и те же составляющие присутствуют почти в каждой технологической компании: централизованная идентификация, Slack или Teams, системы управления персоналом и множество внутренних панелей мониторинга и API. В спокойные времена никто особо не задумывается о грани между наблюдаемостью и слежкой. Но когда происходят увольнения, эта грань становится очевидной.

В этом пояснении мы рассмотрим вероятные обстоятельства произошедшего, причины соблазна к подобному отслеживанию, места, где оно выходит за рамки этических и политических норм, а также то, что организации могут сделать для уменьшения как вреда конфиденциальности, так и стремления к скрытому сбору информации.

Что произошло (и что, вероятно, означает здесь «сценарий»)

По данным BBC, компания Pinterest заявила, что «два инженера написали пользовательские скрипты, неправомерно получив доступ к конфиденциальной информации компании, чтобы определить местоположение и имена всех уволенных сотрудников, а затем распространили эту информацию», назвав это нарушением политики компании и нарушением конфиденциальности пострадавших сотрудников. В репортаже также описывается механизм, отслеживающий удаление или деактивацию имен сотрудников во внутренней системе коммуникации, «например, Slack».

Во многих компаниях Slack (или аналогичные сервисы) напрямую связан с поставщиком идентификационных данных (Okta, Azure AD, Google Workspace и т. д.). При отключении учетной записи происходит цепная реакция: истекает срок действия токенов доступа, меняются группы, и пользователь перестает отображаться в результатах поиска по определенным каталогам, каналам и интеграциям. Если у вас есть доступ к API (даже только для чтения), вы часто можете определить, кто был уволен, просто отслеживая изменения состояния:

  • Пользователь исчезает из списка «активных пользователей».
  • Профиль пользователя деактивируется.
  • Бот больше не может отправлять им личные сообщения.
  • Состав их групп меняется в зависимости от каналов или групп пользователей.

В данном контексте «скрипт» не обязательно должен быть сложным. Это может быть несколько десятков строк кода, опрашивающих API, сравнивающих список пользователей за вчерашний день с сегодняшним и выдающих оповещение. С чисто технической точки зрения, это тот же шаблон, который инженеры используют для выполнения законных операционных задач: сравнение двух снимков для обнаружения изменений.

Разница заключается в том, что именно выявляется (люди), почему это выявляется (увольнения) и куда распространяются результаты (они широко распространяются).

Почему сотрудники так поступают во время сокращений?

Есть неприятная правда об увольнениях: обычно люди узнают о деталях через неофициальные каналы, прежде чем руководство что-либо прояснит. Иногда это происходит потому, что руководство пока не может поделиться подробностями. Иногда это происходит потому, что фраза «мы все еще прорабатываем детали» — это эвфемизм для «мы не хотим говорить».

Поэтому сотрудники стремятся использовать любые доступные сигналы:

  • Друзья внезапно замолкают.
  • Приглашения в календарь исчезают.
  • Доступ к репозиториям отозван.
  • Статус в Slack меняется, или человек исчезает из списка контактов.

Отслеживание этих сигналов может восприниматься как самозащита. Люди хотят знать:

  • Это затронет мою команду?
  • Моего менеджера уволили?
  • Мои ближайшие соратники всё ещё здесь?
  • Всё ли в порядке с компанией, или это более масштабная реструктуризация?

Такая мотивация свойственна человеку и предсказуема. Но предсказуемое поведение всё равно может быть вредным.

Проблема конфиденциальности: информация о статусе увольнения является конфиденциальной.

Увольнение — это не просто «случайность, касающаяся работы». Это конфиденциальная личная информация о статусе занятости человека, часто связанная с льготами, иммиграцией, медицинским страхованием и перспективами трудоустройства в будущем.

Даже если компания планирует публично объявить о сокращении штата, информация о личности и местонахождении сотрудников, как правило, должна раскрываться только тем, кому она действительно необходима:

  • Отделу кадров и бухгалтерии необходимы подробные сведения.
  • ИТ-отдел должен осуществить увольнение сотрудников.
  • Правовые нормы должны обеспечивать соблюдение законодательства.
  • Руководителям необходимо напрямую общаться со своими командами.

Широкое внутреннее распространение списка уволенных сотрудников — это другое дело. Оно может включать в себя:

  • Лишить пострадавшего человека возможности контролировать ход событий.
  • Раскрыть местоположение человека или его принадлежность к той или иной команде.
  • Поощряйте сплетни и домыслы («было ли это представление?», «было ли это политическим актом?»).
  • Повышается риск целенаправленного преследования или раскрытия личных данных за пределами компании.

Заявление Pinterest о нарушении конфиденциальности бывших коллег — это не просто пиар. Это реальная категория причиненного вреда.

Проблема безопасности: контроль доступа — это не то же самое, что авторизация.

Во многих внутренних системах используются общие права доступа: если вы инженер, вы можете запрашивать информацию из каталога или использовать внутренний API. Это не означает, что вы имеете право использовать его для любых целей.

Именно здесь многие организации сталкиваются с трудностями. Они создают внутренние инструменты, которые:

  • Простой в использовании,
  • Мощный,
  • Плохое управление.

И тогда они полагаются на политику («не делайте этого») как на основной ограничитель. Когда давление велико, ограничители, основанные исключительно на политике, оказываются неэффективными.

Стандарт NIST SP 800-53 — один из стандартных каталогов, используемых организациями для анализа семейств средств контроля, таких как контроль доступа и аудит. Даже без углубления в идентификаторы средств контроля, основная идея здесь применима однозначно: доступ к данным должен быть ограничен, отслеживаться и соответствовать законным деловым целям — особенно для конфиденциальных категорий информации.

Иными словами: фразу «технически вы можете это прочитать» ни в коем случае нельзя воспринимать как «вам можно это прочитать».

Проблема культурного характера: Slack стал организационным шаблоном.

В настоящее время большинство компаний существуют в двух параллельных реальностях:

  1. Официальная реальность: системы управления персоналом, иерархия подчиненности, официальные заявления.
  2. Реальность такова: каналы в Slack, групповые личные сообщения, упоминания в GitHub, дежурства по вызову.

Когда в формальной системе происходят изменения (например, увольнение сотрудников), это немедленно приводит к видимым последствиям в реальной работе системы. Сотрудники воспринимают эти последствия как истину — иногда даже сильнее, чем доверяют сообщениям руководства.

Это несоответствие создает порочный стимул:

  • Если руководство не хочет рассказывать вам, что происходит,
  • Вы восстановите её из любых утечек телеметрии.

Этот инцидент напоминает о том, что «внутренняя прозрачность» — это не просто коммуникационная стратегия, это также стратегия информационной безопасности. Если люди чувствуют необходимость восстановить реальность по утечкам, они это сделают.

Где инженеры перешли черту

Даже если вы понимаете, почему кто-то мог создать подобный скрипт, есть как минимум три четких правила, которые здесь нарушаются:

1) Ограничение по назначению

Если источником данных является «конфиденциальная информация компании», предполагается, что она используется в законных деловых целях, а не для сбора информации о сокращениях.

В рамках концепции защиты конфиденциальности NIST особое внимание уделяется управлению рисками, связанными с конфиденциальностью, и использованию методов, защищающих отдельных лиц. Практический перевод звучит так: «собирать и использовать данные для конкретных, законных целей и избегать вторичного использования, которое может привести к новым негативным последствиям».

Использование скрипта для идентификации уволенных сотрудников практически по определению является второстепенным: сигналы об увольнении существуют для защиты систем и выполнения кадровых процессов, а не для формирования внутреннего списка уволенных.

2) Усиление

Люди замечают исчезновения пользователей в Slack естественным образом — это утечка информации из фонового потока.

Скрипт преобразует скрытую утечку информации в структурированный набор данных (имена, местоположения, вероятные команды, время увольнения). Это и есть усиление: потенциальный вред резко возрастает, когда расплывчатые сигналы превращаются в четкий список.

3) Перераспределение

Распространение результатов «более широким кругом лиц» — это шаг, который затрудняет оправдание их публикации как простого любопытства. Он создает новый канал распространения конфиденциальной информации и возлагает на авторов ответственность за последующее неправомерное использование.

Что могут сделать компании: сократить утечки, повысить доверие и ужесточить контроль.

Существует ошибочное мнение, что решение заключается в том, чтобы «все закрыть наглухо». На практике необходимы три взаимодополняющих шага: управление, технический контроль и коммуникация.

1) Относитесь к мероприятиям по увольнению как к деликатным событиям и обеспечивайте конфиденциальность при проектировании помещений.

Увольнение неизбежно меняет системы, но можно уменьшить информационный поток:

  • Сведите к минимуму изменения в общедоступных каталогах до тех пор, пока не наладится обмен данными.
  • Избегайте массового удаления пользователей, результаты которого легко сопоставить с результатами других операций.
  • Рассмотрите возможность задержки на несколько часов некоторых обновлений, не имеющих критического значения для безопасности, чтобы они не служили источником информации о сокращениях в режиме реального времени.

Цель состоит не в том, чтобы навсегда скрыть реальность. Цель — избежать превращения болезненного события в квест.

2) Добавить средства контроля доступа, ориентированные на конкретные задачи, и ведение журналов.

Если внутренние API-интерфейсы позволяют отслеживать изменения статуса сотрудников в больших масштабах, то:

  • Доступ должен быть ограничен только теми ролями, которым он необходим.
  • Для осуществления массового экспорта необходимо найти обоснование.
  • Запросы следует регистрировать с указанием идентификатора и цели.
  • Автоматизированные опросы должны выделяться.

Здесь важен подход, основанный на «аудите и подотчетности»: если скрипт перечисляет пользователей и выдает оповещения, он должен запускать обнаружение.

3) Разработайте гуманный план коммуникации при увольнениях.

Основной фактор, влияющий на отслеживание теней, — это неопределенность.

Компании могут снизить желание использовать внутренние инструменты для сбора данных, если будут четко это оговаривать:

  • Когда будут уведомлены пострадавшие сотрудники?
  • Когда команды будут проинформированы?
  • Что можно публиковать и когда?
  • Где можно найти проверенные обновления?

Если руководство своевременно предоставляет конкретную информацию, необходимость в составлении списков своими силами снижается.

4) Предоставьте сотрудникам санкционированный способ контролировать работу коллег.

Это тонкий, но важный момент. Люди не просто любопытствуют — они пытаются скоординировать работу и узнать, как дела у друзей.

Простое, разрешенное сообщение о состоянии каталога («эта учетная запись больше не активна») без меток времени, местоположения или списков могло бы удовлетворить основные потребности без необходимости массового восстановления.

Более широкая тенденция: увольнения как проверка на прочность информационной безопасности.

Сокращение штата выявляет слабые места в системе управления, поскольку оно приводит к следующим последствиям:

  • череда важных событий,
  • высокий эмоциональный накал
  • и значительная текучесть пользователей.

Именно тогда и возникают нестандартные ситуации: сотрудники копируют данные из систем, менеджеры импровизируют, а инструменты используются способами, для которых они не были предназначены.

Такие сайты, как Layoffs.fyi, существуют потому, что люди хотят получать независимую информацию о масштабах сокращений в отрасли. Внутри компании существует та же потребность — только сигналы более прямые, а ставки носят личный характер.

Итог

Увольнение инженеров из Pinterest за создание скриптов для отслеживания сокращений — это не просто «не будьте любопытными». Это предупреждение о том, что внутренняя наблюдательность может превратиться во внутреннюю слежку в тот момент, когда падает доверие к организации.

Если ваши инструменты позволяют легко превратить смену персонала в список уволенных коллег, люди будут это делать — особенно во время сокращений. Решение заключается не только в наказании тех, кто написал этот сценарий; оно состоит в создании систем и методов коммуникации, которые не превращают увольнение в утечку данных и рассматривают статус занятости как конфиденциальную информацию.

Источники

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...
Русский