A former Gizmodo writer changed name to 'Slackbot', stayed undetected for months
A former Gizmodo writer’s prank of renaming his account to “Slackbot” after leaving the company sparks broader concerns about how poorly many organizations handle access revocation in tools like Slack. Commenters highlight weak offboarding, reliance on manual processes instead of SSO/SCIM, and the ease of impersonation via Unicode lookalike characters as serious security risks, especially given potential legal exposure under laws like the CFAA. Several weigh trade-offs between tight identity controls and workplace “whimsy,” but most see better automation and policy enforcement as overdue.
Security through obscurity & “service accounts”
- Several comments note the “best place to hide” is as a system/service account no one dares touch.
- Others share the opposite failure mode: an over‑zealous admin deleting mysterious automation accounts, breaking workflows (Chesterton’s fence analogy).
- Some organizations implement strict key/account hygiene (e.g., systems that crawl servers and delete unknown SSH keys), but this adds operational friction.
Legal and ethical concerns (CFAA, impersonation)
- Multiple commenters argue this kind of prank can trigger Computer Fraud and Abuse Act (CFAA) liability.
- There’s debate over statutes of limitations and the difference between civil and criminal actions.
- Discussion distinguishes benign URL parameter changes/scraping public data from deliberately bypassing revocation of access after termination.
- Some frame identity deception (e.g., impersonating staff or police) as inherently aggravating; others argue the crime is access/theft, not the disguise itself.
SSO, SCIM, and deprovisioning gaps
- Many say proper SSO plus SCIM user provisioning should have removed the ex‑employee automatically.
- Others point out gaps: long‑lived sessions, incomplete SCIM adoption, and SSO/SCIM being “enterprise” upsell features (the “SSO tax”).
- Third‑party vendors offer SCIM/Slack integrations but at per‑connection cost, influencing why smaller apps/companies don’t enable it.
- Some report still having full Slack/Google/insurance access long after leaving, often because Slack/IdP integration was misconfigured or missing.
Name changes, impersonation, and policy variance
- Concern that allowing arbitrary display‑name changes enables easy impersonation of CEOs, bots, or services.
- Some orgs lock names and avatars via SAML/SCIM; others enforce frequent re‑auth and rapid deactivation.
- Many workplaces intentionally permit playful name changes for culture/morale, or for functional uses (e.g., embedding availability/vacation info in names).
- Thread notes that “undetected” in the story really means undetected by management; colleagues knew and treated it as a joke.
Unicode, homoglyphs, and namespace collisions
- The trick relied on Unicode homoglyphs (e.g., Cyrillic “о” for Latin “o”), an attack pattern long known in security.
- Developers describe tools/plugins to highlight suspicious Unicode and recount bugs from “smart” quotes/dashes or non‑standard spaces.
- Broader discussion on hard namespace problems: wildcard subdomain dashboards, offensive or reserved slugs, and real users named “Admin,” “Null,” or “True” colliding with system assumptions.
Meta: value of the article
- Some see the article as thin, essentially reprinting a tweet; others say it adds context for non‑Slack users and a corroborating source.