Why the Word “User” Is Killing Your Software Security and Design

When you discover after six months that the lightweight assumptions you made at the start of a project were completely wrong, you realize you have spent far more effort than expected; using the correct terminology from the beginning could have prevented this.

No Real "Users"

The author claims that most software systems do not actually have a generic "user" entity; the business logic is far more complex.

Airline Reservation System Has No "Users"

In an access‑control design for a ticket‑booking system, the requirements are:

Passengers view reservations using a reservation code.

Buyers modify reservations by providing the last four digits of a credit‑card number.

Travel agencies can view and edit their bookings.

Airline check‑in staff, based on role and airline, can view and edit reservations after the passenger supplies identity information.

These concepts are better expressed as "passenger", "agent" (the website acting as an agent), and "buyer"; the word "user" adds no value and is never used in the actual requests, which must contain passenger and agent credentials, not a generic user credential.

Unix Has No "Users"

At first glance Unix (POSIX) appears to have users who log in and run code, but a deeper look reveals distinct identities:

System services such as mail or web servers run under a "user" account (e.g., nginx runs as httpd).

Multiple administrators often share a single SSH account (e.g., the default Ubuntu VM uses the "ubuntu" account).

The root account, which is separate from the others.

Treating all these disparate identities as a single "user" blurs boundaries and creates security problems because POSIX does not provide a way to restrict a specific account to only Alice and Bob.

SaaS Providers Have No "Users"

Jeremy Green recently tweeted about user models in SaaS, noting that a SaaS service is almost always:

A person in an organization pays for the service.

One or more people actually use the service.

If you model these people as a single "user" you cannot represent team relationships or shared‑payment models, forcing costly redesign later. The author suggests that the essential concepts are "team" (for organization and billing) and "member" (the actual service consumer).

"Users" Is a Security Problem

The term "user" not only confuses business logic but also introduces security risks by merging two distinct concepts: a person and their representation in software.

Consider a malicious website that causes a browser memory overflow, then uploads files from the victim's machine. The browser runs under the system account, which is also considered a "user"; therefore the system assumes the file upload is the victim's intent, illustrating the Confused Deputy problem.

The Value of Early Design

Spending less effort to solve the same problem is key to being a productive programmer. Using vague concepts like "user" wastes time fixing issues later. Starting a new project by spending a few hours defining precise terminology and concepts may not be perfect, but it dramatically reduces future rework and improves productivity.

Source: https://21cto.com/article/2093