Debugger
How to Stop ‘God Mode’ Abuse
Making ‘ghost user’ tools safer for customers starts with changing the frameworks that most apps and services are built on
You might think that as long as you keep your password safe, you’re the only person who can access your online accounts. But Facebook, Twitter, and the majority of tech companies build “user impersonation” tools into their software that allow their employees to peer inside of any account — and act as though they’ve logged into that account — without the owner ever knowing. These tools are generally accepted by engineers as common practice and rarely disclosed to users.
Often called “impersonate mode,” “ghost user,” or “proxy user,” they allow customer service representatives to see a service through a user’s account in order to diagnose errors and help engineers build better products by showing them how they work inside real users’ accounts.
But this type of internal tool can be abused. Most famously, Uber employees used the app’s “God mode” to track the movements of everyone from politicians to ex-girlfriends. Lyft provided similar tools, which were also abused by employees. And Ring recently fired employees for watching customer videos, which they easily could have found using a user impersonation tool, though Ring did not disclose how the employees accessed videos.
Part of the problem is how the programming tools that many developers use to build apps and services handle their user impersonation features.
One of the most popular libraries for the programming language Ruby on Rails, ActiveAdmin, provides one such feature and has been installed over 7.9 million times. Laravel, a popular PHP-based language, offers a similar package called Spark as do many other development tools.
Out-of-the-box user impersonation tools provided by these frameworks typically don’t ask for users’ permission or even notify users when their account has been accessed. For those with administrator access, popping into accounts is as easy as clicking around the app.
A developer using Laravel Spark to build an app, for instance, manually “white lists” users with administrator access that would allow access to impersonator mode. Users of the application who are signed in with a white-listed email address then see features that regular users can’t access. In apps built with Spark, one of those features is an option to “impersonate” another user’s account.
Those with administrator’s access can search for a specific user, click an “impersonate” button, and instantly view the app through that user’s account as if they had legitimately logged in with a password.
Not only is the unsuspecting user not asked to consent to someone viewing their account, but they aren’t notified, and by default, the development framework doesn’t require the administrator to provide any sort of internal note or reason for accessing an account.
Instead of creating a white list of users who can access user accounts, which Spark requires, some startups instead simply grant access based on the email address of an employee, which means that anyone who signs up for an account with a company email address can access user accounts. Because employees generally sign employment contracts that cover access to user data, it’s assumed they can be trusted with such access — but as companies grow, this becomes a bigger risk to take.
And because impersonation tools provide little value to users, they can be the last tools to be improved or restricted as a growing company scrambles to keep customers happy. Though many companies do appropriately lock down access to user accounts as they grow, it’s not uncommon for impersonation tools to be left in their uncontrolled or companywide default for years until a security incident like Uber’s causes the company to change the way it’s implemented.
While large companies like Facebook have said they now have “rigorous administrative, physical, and technical controls in place to restrict employee access,” it’s telling that as a user of the service, there’s no way to actually know when someone internally accesses your account. While abusing such tools is the “easiest way to get fired” from the company, according to VentureBeat, such processes are invisible, and we must trust that Facebook actually audits this.
There are easy ways to make impersonation tools safer for customers. Some services require the user to specifically invite administrators in before they can access an account. Others, including Uber after the God mode scandal, require employees to make a request for access to security staff, with detailed notes, which is manually granted and logged internally.
If development frameworks were to take a stance on this, it would change the way services are built from the very beginning. If Laravel or Ruby were to bake in a way for users of a service built with their frameworks to see when employees have accessed their accounts, it might become the standard for every service going forward.
Developers should reconsider being intentional about how these features, which can be useful tools, are offered as they build their services from the beginning — before they’re abused by employees, not after.
