Time-sharing and the invention of boundaries

Suppose you have an expensive computer and a queue of people with short questions. Running one large job at a time may keep the machine busy, but everyone else waits. Time-sharing changed the experience: several people could interact with a shared computer and receive useful responses.

Sharing time created more than a scheduling problem

MIT’s Compatible Time-Sharing System, or CTSS, was demonstrated in 1961. Time-sharing aimed to make a shared machine feel responsive to individual users. It did not require the processor to execute every user’s instruction at exactly the same instant. Rapid switching and resource management could support the interactive experience.

Now imagine two fictional students using that machine. One is editing private notes; the other is compiling a class project. The operating system must allocate processor time, keep their work organized, and decide which resources each may use. Giving them equal turns does not stop one from reading the other’s files. Scheduling and protection are different jobs.

Multics treated the computer as a shared service

The Multics project began in 1965 as a collaboration involving MIT, Bell Labs, and General Electric. It sought a broadly useful computing utility, with protection and controlled sharing woven into the design. Multics entered service at MIT in 1969; operation then required administrators, maintenance, and policies as well as research ideas.

This is more relevant than simply calling Multics an ancestor of later systems. It confronted a question that still appears in a cloud workspace: how do people cooperate on some resources while keeping others private? Influence can travel through design ideas without every later system inheriting the same source code.

Knowing a name is not granting a request

Authentication establishes an identity according to a mechanism. Authorization decides whether that identity may perform a particular operation on a resource. A logged-in student might read their own notes, edit a group document, and be refused another student’s draft, all during one session.

In 1975, Jerome Saltzer and Michael Schroeder published principles for protecting information in computer systems. Two useful ideas are least privilege and checking relevant access decisions rather than assuming a previous check settles every later action. These are design questions, not a claim that one historical system implemented every protection perfectly.

PredictA student leaves a project group but stays logged in. Should the team assume the old login proves they may keep opening the group’s files?

No. Identity, current membership, cached permissions, and already-open resources can have different lifetimes. A real design must specify when revocation takes effect; a login alone cannot answer that question.

The change was from running isolated jobs to serving interacting people. What persisted was the need to define authority precisely. Today’s shared documents, service accounts, and online classrooms still need rules for both separation and intentional sharing.