PinterestはSlackでレイオフを追跡していたエンジニアを解雇した。プライバシー、信頼、そして社内テレメトリについて何が語られているのか

Pinterestは、レイオフ中に社内ツールからどの同僚が削除されるかを特定するスクリプトを作成した2人のエンジニアを解雇し、そのリストを広く共有したと報じられています。表面的には、これは職場のドラマのようですが、その裏には、現代の企業の実態を非常に明確に示すケーススタディがあります。アイデンティティシステムが真実の源泉となり、チャットプラットフォームが事実上の組織図となり、「社内データ」は社会的に受け入れられるずっと前から技術的にアクセス可能になっています。

この事件はPinterestだけにとどまらず、大きな問題となっています。なぜなら、ほぼすべてのテクノロジー企業に共通する要素、つまり集中管理されたID、SlackやTeams、人事システム、そして膨大な社内ダッシュボードとAPIが存在するからです。平穏な時は、監視と監視の境界線について深く考える人はいません。しかし、レイオフが発生すると、その境界線は明確になります。

この解説では、何が起こった可能性があるのか​​、なぜこの種の追跡を行う誘惑に駆られるのか、それが倫理的およびポリシーの境界を越える箇所はどこなのか、そしてプライバシーの侵害と影の情報収集への欲求の両方を軽減するために組織が何ができるのかについて見ていきます。

何が起こったのか(そしてここでの「スクリプト」とはおそらく何を意味するのか)

BBCによると、Pinterestは「2人のエンジニアがカスタムスクリプトを作成し、会社の機密情報を不正にアクセスして解雇された従業員全員の所在地と氏名を特定し、それをさらに広く共有した」と述べ、これはポリシー違反であり、影響を受けた従業員のプライバシー問題だと非難した。報道によると、この仕組みは「Slackのような」社内コミュニケーションツール内で従業員の名前が削除または無効化されるのを監視しているという。

多くの企業では、Slack(または類似のサービス)はIDプロバイダー(Okta、Azure AD、Google Workspaceなど)に直接紐付けられています。アカウントが無効化されると、アクセストークンの有効期限切れ、グループの変更、そして特定のディレクトリ検索、チャンネル、統合機能へのユーザーの表示停止といった一連の影響が発生します。APIアクセス権限(読み取り専用権限であっても)があれば、状態の変化を検知するだけで、誰が停止されたのかを推測できる場合が多くあります。

  • ユーザーが「アクティブユーザー」リストから消えます。
  • ユーザーのプロフィールが非アクティブになります。
  • ボットはDMを送信できなくなりました。
  • メンバーシップは、チャネルまたはユーザー グループによって変わります。

ここで言う「スクリプト」は、必ずしも高度なものである必要はありません。APIをポーリングし、昨日のユーザーリストと今日のユーザーリストを比較してアラートを発行する、数十行のコードで十分です。純粋に技術的な観点から言えば、これはエンジニアが正当な運用タスクで用いるのと同じパターン、つまり2つのスナップショットを比較して変更を検出するというものです。

違いは、何が検出されるか(人)、なぜ検出されるか(レイオフ)、および結果がどこに行くか(広く共有される)です。

従業員がレイオフ中にこれを行う理由

レイオフには、ある不都合な真実があります。経営陣が何かを明確にする前に、人々は通常、裏ルートを通じてイベントの全体像を把握します。それは、経営陣がまだ詳細を共有できないからという場合もあります。また、「詳細はまだ詰めているところです」という言い方は、「言いたくない」という婉曲表現に過ぎないからという場合もあります。

そのため、従業員は存在するあらゆるシグナルに手を伸ばします。

  • 友人たちは突然黙り込んでしまう。
  • カレンダーの招待状が消えます。
  • リポジトリへのアクセスは取り消されます。
  • Slack のステータスが反転したり、その人がディレクトリから消えたりします。

こうした信号を追跡することは、自己防衛のように感じられるかもしれません。人々は次のことを知りたいのです。

  • 私のチームは影響を受けていますか?
  • 私のマネージャーは解雇されたのでしょうか?
  • 私の最も親しい協力者はまだここにいますか?
  • 会社は大丈夫なのか、それとも大規模なリストラなのか?

その動機は人間的であり、予測可能です。しかし、予測可能な行動であっても、有害な行動となる可能性があります。

プライバシーの問題:解雇状況は機密情報である

解雇情報は単なる「仕事上の些細な情報」ではありません。雇用状況に関する機密性の高い個人情報であり、福利厚生、移民、健康保険、将来の就職の見通しなど、様々な問題に関わってきます。

企業が人員削減を公表する予定であっても、削減対象者の身元や所在地は通常、必要に応じて開示されることになります。

  • 人事と給与には詳細が必要です。
  • IT 部門はオフボーディングを実行する必要があります。
  • 法令遵守を保証する法的必要性。
  • マネージャーはチームと直接コミュニケーションを取る必要があります。

解雇された従業員のリストを社内で広く共有する場合は、状況が異なります。次のようなことが可能です。

  • 影響を受けた人の物語をコントロールする能力を削除します。
  • 誰かの所在地やチーム所属を公開する。
  • 噂話や憶測を奨励します(「パフォーマンスだったのか?」「政治的なものだったのか?」)。
  • 社外での標的型嫌がらせや個人情報の漏洩のリスクが高まります。

Pinterestが元同僚のプライバシーを侵害したという主張は、単なるPRにとどまりません。これは紛れもない実害です。

セキュリティ上の問題: アクセス制御は認可と同じではない

多くの社内システムは、大まかな権限で動作します。エンジニアであれば、ディレクトリを照会したり、社内APIを使用したりできるかもしれません。しかし、それはあらゆる目的で使用できる権限があるという意味ではありません。

多くの組織がここで苦労しています。彼らは次のような社内ツールを構築しています。

  • 使いやすい、
  • 強力、
  • 統治が不十分。

そして、彼らは政策(「そんなことはするな」)を第一のガードレールとして頼りにします。しかし、圧力が高まると、政策だけのガードレールは機能しなくなります。

NIST SP 800-53は、アクセス制御や監査といった制御ファミリーについて組織が検討する際に用いる標準カタログの一つです。制御IDに惑わされることなく、基本的な考え方はここに明確に当てはまります。データアクセスは、特に機密性の高い情報に関しては、制限され、監視され、正当な業務目的に帰属するものでなければなりません。

言い換えれば、「技術的にはこれを読むことができます」は、「これを読んでも問題ありません」と決して扱われるべきではありません。

文化的な問題:Slackが組織図になった

現在、ほとんどの企業には 2 つの並行した現実があります。

  1. 正式な現実: 人事システム、報告ライン、公式発表。
  2. 現実の出来事: Slack チャンネル、グループ DM、GitHub メンション、オンコール ローテーション。

正式なシステム(例えばオフボーディング)に何か変化が起きると、それは即座に、実社会のシステムに目に見える形で現れます。従業員はそれらの変化を真実として解釈し、時には経営陣からのメッセージよりも強く信じることがあります。

この不一致により、逆効果の誘因が生まれます。

  • リーダーシップが何が起きているのか教えてくれないなら、
  • 漏洩したテレメトリからそれを再構築することになります。

この事件は、「内部の透明性」が単なるコミュニケーション戦略ではなく、情報セキュリティ戦略でもあることを改めて認識させる。もし人々がリーク情報から現実をつなぎ合わせなければならないと感じれば、彼らはそうするだろう。

エンジニアが限界を超えた場所

誰かがなぜこのようなスクリプトを作成するのかに共感したとしても、越えるべき明確な境界線が少なくとも 3 つあります。

1) 目的の制限

データ ソースが「会社の機密情報」である場合、レイオフの偵察ではなく、正当な業務機能のために使用されることが期待されます。

NISTのプライバシー・フレームワークは、プライバシーリスクの管理と個人を保護するための慣行の活用を重視しています。具体的には、「特定の正当な目的のためにデータを収集・使用し、新たな害をもたらす二次利用を避ける」ということです。

解雇された同僚を識別するためのスクリプトは、定義上は二次的な用途に過ぎません。退職信号は、システムを保護し、人事プロセスを実行するために存在し、社内解雇リストを生成するために存在するのではありません。

2) 増幅

Slack での消失は自然に人々が気づきます。それが環境情報漏洩です。

スクリプトは、周囲の漏洩情報を構造化されたデータセット(氏名、場所、想定されるチーム、解雇時刻)に変換します。これが増幅です。曖昧なシグナルが明確なリストになると、被害の可能性は急激に高まります。

3) 再分配

成果物を「より広く」共有することは、単なる好奇心として弁解することを困難にするステップです。機密情報の新たな流通経路が生まれ、著者は下流での悪用に対して責任を負うことになります。

企業ができること:漏洩を減らし、信頼を高め、管理を強化する

解決策は「すべてをロックダウンすること」だという誤解があります。実際には、ガバナンス、技術的制御、そしてコミュニケーションという3つの相補的な対策が必要です。

1) オフボーディングイベントを慎重に扱い、プライバシーに配慮した設計にする

オフボーディングによって必然的にシステムが変更されますが、情報の流出を減らすことができます。

  • 通信が行われるまで、公開ディレクトリの変更を最小限に抑えます。
  • 簡単に差分が取れる大量のユーザー削除は避けてください。
  • セキュリティ上重要でない特定の更新を数時間遅らせて、リアルタイムのレイオフ フィードとして機能しないようにすることを検討してください。

目標は現実を永遠に隠すことではない。辛い出来事が宝探しゲームのようになってしまうのを避けることだ。

2) 目的に基づいたアクセス制御とログ記録を追加する

内部 API が従業員のステータスの変化を大規模に明らかにできる場合、次のようになります。

  • アクセスは、それを必要とするロールに限定する必要があります。
  • 一括エクスポートには正当な理由が必要です。
  • クエリは ID と意図とともにログに記録する必要があります。
  • 自動投票は目立つはずです。

ここで「監査と説明責任」の考え方が重要になります。スクリプトがユーザーを列挙してアラートを発している場合は、検出をトリガーする必要があります。

3) レイオフに対する人道的なコミュニケーション計画を立てる

シャドウトラッキングの最大の要因は不確実性です。

企業は、次のことを明確にすることで、社内ツールをスクレイピングする衝動を抑えることができます。

  • 影響を受ける従業員にはいつ通知されますか?
  • チームにはいつ通知されますか?
  • 何をいつ共有できますか?
  • 検証済みの更新情報はどこで入手できますか?

リーダーシップがタイムリーで具体的な情報を提供すると、DIY リストの「必要性」は低下します。

4) 従業員に協力者をチェックする正式な方法を与える

これは微妙ですが重要です。人々は好奇心だけでなく、仕事の調整や友人の様子を確認しようとしているのです。

タイムスタンプ、場所、またはリストのない、シンプルで承認されたディレクトリ ステータス メッセージ (「このアカウントはアクティブではなくなりました」) は、大量の再構築を可能にすることなく基本的なニーズを満たすことができます。

より広範な傾向:情報セキュリティのストレステストとしてのレイオフ

レイオフは次のような事態を引き起こすため、ガバナンスの弱点を明らかにします。

  • 敏感な出来事の連続、
  • 感情的な高ぶり、
  • アクセスの離脱も多発しています。

まさにそのとき、エッジケースが見られるのです。つまり、従業員がシステムをスクラップしたり、管理者が即興で対応したり、誰も想定していなかった方法でツールが使われたりするのです。

Layoffs.fyiのようなサイトが存在するのは、業界における人員削減の規模について、独立したシグナルを人々が求めているからです。企業内にも同様のニーズが存在します。ただし、シグナルはより直接的で、利害関係は個人的なものです。

結論

Pinterestがレイオフ追跡スクリプトを作成したエンジニアを解雇したのは、単に「詮索するな」というだけの行為ではない。これは、組織内の信頼が失われた瞬間、内部の観察可能性が内部監視に変わる可能性があることを警告しているのだ。

もしツールがIDの変更を解雇された同僚のリストに簡単に変換できるなら、人々はそれをやってしまうでしょう。特にレイオフの際にはなおさらです。対策としては、スクリプトを書いた人を罰するだけでは不十分です。オフボーディングをデータ漏洩に繋がらないシステムとコミュニケーション方法を構築し、雇用状況を機密情報として扱うことが重要です。


出典

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...
日本語